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.
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
22% sq Albanian
48% hy Armenian
30% hi Hindi
29% kab Kabyle
18% kn Kannada
66% ko Korean
38% lv Latvian
13% lt Lithuanian
3% mk Macedonian
22% sl Slovenian
15% ta Tamil
69% th Thai
10% ug Uighur
4% ur Urdu
64% vi Vietnamese
The connected10 test runner has been at least as reliable as connected24,
and provides valuable coverage, especially for localization related
crashers.
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.
