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.
This is in the spirit of the setting, where users can see which apks are
available even though they are not installable.
Adds a message explaining why it is incompatible (i.e. because the
signature doesn't match the installed version).
Instead of including the etag in the HTTP GET request and letting the
server set the Response Code depending on whether the etag machines, this
makes the client first issue a HEAD request, which is uses to get the etag
and the file size. We need to do the HEAD beforehand anyway to get the
file size for resumable downloads, and this approach prevents the server
from using the etag as a form of tracking cookie:
http://lucb1e.com/rp/cookielesscookies/closes#562
- Icon transition is no longer jumping in first frame (caused by different padding)
- Icon is no longer cropped at start of transition (caused by missing changeImageTransform)
- Toolbar icons are no longer animated. Introduced in !561 by changing the icons programmatically
This caused problems when users then tried to action the pending
install, where it would no longer have enough information to install the
app. Although it may be technically possible to keep enough information
around in memory to make the app installable, but it is not worth the
effort. If a user intentionally disables a repo, we should no longer be
responsible for keeping information about its apps around.
Fixes#995.
There are some ACRA reports with this IllegalStateException getting hit.
It used to be that it was only ever because we forgot to request the
correct fields from the database. However now I'm not sure that this is
the only source. Perhaps it is also possible in response to parcelling
apk instances, or maybe something else? Either way, this should provide
further info about whether the apk doesn't belong to a repo for some
reason.
There are two methods which allow callers to choose which fields to
return. These were originally added for performance, so you only ask for
what you need. However empirically the performance gain doesn't mean
anything, because it is dwarfed by the query that was just executed.
However, it does open the code up to bugs because we forget to ask for
the right fields. So now it just returns all fields when querying for
apks.
While investigating #1086 which was about swap being busted, I
discovered that we recently introduced a worse bug when working with
multi sig stuff. The swap process, when installing an app (or even when
listening for if a user started installing - before they even did
anything), would ask for an apk from any repo. This is wrong, because we
should only ask for the apks from the swap repo when presented with a
swap dialog.
By fixing this so that it asks for a specific apk, this may also
fix the issue in #1086, because that was about us not asking for enough
info from the database for each Apk which was returned. Now we just
return all columns, because the performance overhead should be minimal,
but it prevents this class of bugs, where we didn't fully populate
our value object. However, I'm not confident that it is fixed, because I
was unable to reproduce it due to the other crash fixed in this change.
Relevant crash:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String org.fdroid.fdroid.data.Apk.getUrl()' on a null object reference
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter$ViewHolder.setApp(SwapAppsView.java:311)
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter.bindView(SwapAppsView.java:422)
at org.fdroid.fdroid.views.swap.SwapAppsView$AppListAdapter.newView(SwapAppsView.java:414)
at android.support.v4.widget.CursorAdapter.getView(CursorAdapter.java:269)
at android.widget.AbsListView.obtainView(AbsListView.java:2349)
at android.widget.ListView.makeAndAddView(ListView.java:1864)
at android.widget.ListView.fillDown(ListView.java:698)
...
```
