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).
Untested because there are no apps in current repos which exhibit this
behaviour which have newer versions. Right now I'm testing with com.waze
from testy.at.or.at which only has the one version.
I'm also unsure of how important this is seeing as most the time it will
prompt people to update anyway.
Note that I don't think the query will work correctly across multiple repos,
because it is currently only querying the app with the "preferred
metadata".
Also use a newer version of testy.at.or.at index for the index-v1 test,
because it includes apks with "KnownVuln" anti features whereas the
older version did not.
When explicitly given an fdroidrepo(s) intent, it seems silly to restrict it based on
a path of /fdroid/repo, because it is plainly obvious it is an F-Droid repo.
Manifest and NewRepoConfig both had to be amended to allow this behaviour.
Fixes#1171.
There is a specific POSIX error "EIO" which seems to be the "general
purpose we don't know what went wrong but its probably bad" exception.
Our investigations in #855 resulted in the conclusion that it is likely
due to some sort of filesystem corruption or something like that.
Either way, it is annoying many people, so we need to prevent it or
ignore it, rather than prompting the user to submit a bug report.
After much investigation it was unable to be reproduced other than by
one of the original bug reporters. As such, this change ignores it.
Unfortunately Java `IOException`s don't have an API for getting the
errno of a POSIX IO error. Thus, this change results to parsing the
exception message instead :(
Fixes#855.
This improves performance when we need to decide whether or not apps are
installed or not while scrolling through large lists.
Fixes#1143.
Also change Jackson tests to properly ignore App#isApk.
This join resulted in one row for each apk in the result set (before
doing a GROUP BY), instead of one row for each apk. That is a large
difference in number of rows and resulted in much more work for sqlite.
Turns out this join wasn't required.
Some queries are deferred, and then forced to run by Android by invoking
`getCount()`. Under these circumstances, the measured speed of the query
execution is 1ms.
This adds speed logging around `getCount()` in case that is the first time
the query is run.
