While a large buffer might make things slightly faster, the smaller buffer
size should play much nicer when F-Droid is doing things in the background.
Since calculating the hash is part of the update procedure, which can now
happen in the background, this method will be often running in the
background.
The tests showed no difference in time between the large and small buffer.
Donno how that magic number slipped in, this is the actual flag.
/builds/eighthave/fdroidclient/app/src/main/java/org/fdroid/fdroid/acra/CrashReportSender.java:31: Error: Must be one or more of: Intent.FLAG_GRANT_READ_URI_PERMISSION, Intent.FLAG_GRANT_WRITE_URI_PERMISSION, Intent.FLAG_FROM_BACKGROUND, Intent.FLAG_DEBUG_LOG_RESOLUTION, Intent.FLAG_EXCLUDE_STOPPED_PACKAGES, Intent.FLAG_INCLUDE_STOPPED_PACKAGES, Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION, Intent.FLAG_GRANT_PREFIX_URI_PERMISSION, Intent.FLAG_ACTIVITY_NO_HISTORY, Intent.FLAG_ACTIVITY_SINGLE_TOP, Intent.FLAG_ACTIVITY_NEW_TASK, Intent.FLAG_ACTIVITY_MULTIPLE_TASK, Intent.FLAG_ACTIVITY_CLEAR_TOP, Intent.FLAG_ACTIVITY_FORWARD_RESULT, Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP, Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS, Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT, Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED, Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NEW_DOCUMENT, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NO_USER_ACTION, Intent.FLAG_ACTIVITY_REORDER_TO_FRONT, Intent.FLAG_ACTIVITY_NO_ANIMATION, Intent.FLAG_ACTIVITY_CLEAR_TASK, Intent.FLAG_ACTIVITY_TASK_ON_HOME, Intent.FLAG_ACTIVITY_RETAIN_IN_RECENTS, Intent.FLAG_ACTIVITY_LAUNCH_ADJACENT, Intent.FLAG_RECEIVER_REGISTERED_ONLY, Intent.FLAG_RECEIVER_REPLACE_PENDING, Intent.FLAG_RECEIVER_FOREGROUND, Intent.FLAG_RECEIVER_NO_ABORT, Intent.FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS [WrongConstant]
MODE_APPEND is only for openFileOutput
/builds/eighthave/fdroidclient/app/src/main/java/org/fdroid/fdroid/localrepo/SwapService.java:105: Error: Must be one or more of: Context.MODE_PRIVATE, Context.MODE_WORLD_READABLE, Context.MODE_WORLD_WRITEABLE, Context.MODE_MULTI_PROCESS [WrongConstant]
There used to be a single loader which would get all apps which have
updates available. This was restarted when we were notified about new
apps requiring updates.
Then, in 7424220 I introduced a second loader responsible for getting
apps with known vulnerabilities. This change caused the bug in #1203,
because it changed the loaders from a single loader with ID = 0, to two
different loaders with arbitrary IDs. However, there was still a line of
code responding to when repo updates completed and we learn about new
updateable apps, and this was asking for a loader with an ID of 0 like
before. This crashed when the loader was completed and we tried to pase
the results.
This is fixed ensuring that both loaders are restarted upon learning of
new updateable apps. To prevent this disconnect in the future, they are
also extracted into the same method.
The workaround is fugly, so we really don't want to include it in the
modern code. Luckily, we have old index support there :-D
closes#1014closes#1202closes#1208#111
* App and index downloads fall back to a list of mirrors defined
by the repository.
* The changes have been made trying to keep the original download
code untouched, and only using the mirror logic when the download
fails due to a connection error / timeout.
* The mirrors are tried in a randomized manner, and with proper
timeouts. The download is aborted after the tries exceed the
number of mirrors, times 3 for a total of 3 different timeout
values (10s, 30s, and 1m)
* The mirror code isn't used for any images yet, most of which is
handled by an external library.
Closes: #35
Also does this with the additional field for ignoring vuln apps.
This should be safe, because there is a check for if (columnExists())
which will only pass if people don't already have this column.
Fixes#1181.
It seems that LocaleList does not necessarily return the "Language
Priority List" in the order that the user has prioritized things. So
we have to kind of fake it by first adding the default locale, then
adding the locales from LocaleList based on longest order first (e.g.
de-AT then de).
#987
The swipe-to-refresh from the latest tab is now also implemented
for the categories and updates tab. It was a bit weird before how
you could swipe to refresh on the first tab, which would show
"Updating repos" at the top. It would then also show the same
message on the categories tab, but you couldn't swipe-to-refresh
that tab. Additionally, several people have requested this on the
updates tab, the tab where it probably makes the most sense.
Fix#1079.
The controller in charge of dismissing an item will have an insight into
whether it will cause a re-query for an existing cursor or not. If a re-query
will occur in response to a `ContentResolver#notifyChange()` invokation (in this
case in response to updating `AppPrefs`), then the `UpdatesAdapter` doesn't
need to rebuild itself yet. If it is a status update, then it should update
the adapter right away.
Seeing as the controller was already returning one thing (a message to be
displayed in a `Toast` and now it also needs to return an opinion on whether
to rebuild the adapter or not, this has been extracted into a value object
which has a message and a rebuild adapter flag.
Items which can be updated (but have not yet been downloaded or queued for download)
will act as if the user selected "Ignore this update" from the app details view.
Items which represent app statuses (e.g. downloading, downloaded ready to install,
installed ready to run) will have the status removed. If required, we will also
forget that they are ready to install, so they wont be there next time.
Used to work, then the default join from `fdroid_app` to `fdroid_apk`
was removed for performance reasons. This adds the join back, but requires
queries to explicitly opt in to the join if they require it. The specific
query for known vulns is not a performance problem, because sqlite is able
to narrow the result set quite substantially before requiring a join onto the
fdroid_apk table anyway (e.g. by using the "installed app" table).
