The fact that Cursors are used with the apk provider is more of an
implementation detail (to some extent). It is a crappy, leaky
implementation right now, but still an implementation detail.
This should probably be done on the database level, if purely for the
fact that we have a good set of unit tests for that. However it is still
quite clean to do so here.
This is really the intention of the method, given it used to accept
a version code and a package name. Now it optionally accepts a sig
also. If present, it will restrict the query to apks with that sig.
Also added to the multi-sig tests to ensure this method takes it into
consideration.
There is some magic conversions going on so that booleans get
converted into integers, but they are only on Android. Under
robolectric, it throws a class cast exception instead.
Some were removed and left removed if they were run during tests,
because the tests are supposed to be automated and the noise they added
would not have helped diagnose a failure.
Also removed the dead code around "uses-feature" which will never
get implemented, especially as it is in the XML index.
The main problem is that we were using an index on fdroid_apk.vercode,
when it should have been using an index on fdroid_apk.appId. There are
thousands of apks which would match based on vercode, but only two or
three which match based on appId. This improves performance of the
calculate-suggested-vercode query from 25,000ms to 100ms.
Produces the following output:
D Explain:
D SCAN TABLE fdroid_app
D EXECUTE CORRELATED SCALAR SUBQUERY 0
D SEARCH TABLE fdroid_apk USING INDEX apk_vercode
D EXECUTE CORRELATED SCALAR SUBQUERY 1
D SEARCH TABLE fdroid_app AS innerAppName USING INTEGER PRIMARY KEY (rowid=?)
D EXECUTE CORRELATED SCALAR SUBQUERY 2
D SEARCH TABLE fdroid_package AS pkg USING INTEGER PRIMARY KEY (rowid=?)
D SEARCH TABLE fdroid_installedApp AS installed USING INDEX sqlite_autoindex_fdroid_installedApp_1 (appId=?)
There are two possibilities here, one is the number of correlated sub
queries (three seems a bit excessive). Alterantively, it could be the
fact that one of the inner queries is using a string index (appId=?)
instead of an integer primary key.
The history of this is that #974 identified a problem, which was fixed
in !497. That MR added test coverage for the bug.
However, the fix for it actually added a huge performance hit, on the
order of 30 seconds or so when calculating the suggested version.
This fixes that performance problem by removing the need for a sub
query. The end goal is to take the following query:
```
UPDATE app
SET suggestedVersion = (
SELECT MAX(apk.version)
FROM apk
WHERE ...
)
```
and the `WHERE` clause needs to somehow join the outer `app` table with
the inner `apk` table, such that the repo in question does not matter.
It can't just join directly from `apk.appId -> app.rowid`, because the
`app` is specific to a given repository, but we want to select the
`MAX(apk.version)` from every related apk, regardless of repo.
This commit solves it by joining the inner `apk` table onto an
intermediate `app` table, which is used purely so that we can select
apks where their `packageId` is the same as the `packageId` of the app
being updated.
Carrie specified colours earlier, and they were added to the code.
However they were not being read correctly. This changes that so that
lowercase resource names (e.g. "category_games") are used instead.
It also adds the final category artwork, for "Games" which was
missed prior.
The rest still generate colours and patterns if they don't have a colour
or an image specified.
With a 1 second debounce, I was getting the view to refresh
several times in response to large apps being processed (e.g.
Firefox, OSMAnd, etc). This was on a (relatively) recent Moto X
2nd Gen, so it would be even more visible on an older device.
The side effect of updating frequently is that the main list
of apps flashes regularly in front of the user (see #986).
This "update the view" is only in response to a background
task that is expected to take several seconds (e.g. 30 seconds)
anyway, so waiting 3 seconds instead of 1 is not particularly
problematic.
If F-Droid was actually removed, then we wouldn't even
have an installed app cache (we aren't even on the device
any more). As such, ignore all requests to remove F-Droid
because it complicates the installed apk cache. Specifically,
there is a race condition between the "compare apk cache to
package manager" and the "package removed receiver", where
the later was overriding the former.
There is a persistent shared preference which dictates whether apps
have been successfully downloaded and are ready to install. When
the `InstallManagerService` used to receive an `ACTION_INSTALL_COMPLETE`
broadcast, it would update this preference to no longer be installing.
However, this never got received in the case of F-Droid updating itself.
In that case, we need to instead wait for the system to broadcast an
`Intent.ACTION_PACKAGE_ADDED` intent. This change waits until that
point before removing the preference.
Fixes#1027.
gitlab's diff views wrap badly when lines are longer than 118. Android
Studio places a grey line in the UI at 120.
@SuppressWarnings("LineLength") is added to a bunch of files to prevent
making this commit huge. People can remove that as they work on those
files, and fix the issues then.
I also ran Android Studio's default Ctrl-Alt-L code formatter, where it was
easy to do, and I was already in the file.
The response to receiving PendingDownload was always a more specific
case of the Downloading event. By removing it, the code which was listening
for Downloading events is capable of doing everything that the PendingDownloading
listeners were doing.
Same as how AppDetails2 was recently cleaned up to depend more on
AppUpdateStatusManager.
In addition, it also removes items from the "X apps can be updated"
lower part of the "Updates" view when they are present in the upper half
(i.e. the half showing feedback about the current download/install
progress).
No longer do we try to nicely maintain the state of the adapter in "Updates"
in order to notify the recycler view about changes to its underlying data.
Instead, we just rebuild the entire structure each time a new thing needs
to be shown/removed.
This means no more smooth scrolling to the relevant item after it is
changed, but it results in a far less buggy interface.
This means that we no longer need to receive an APK_URL and then
directly ask the status manager for the relevant status object.
This causes problems when consecutive updates happen in the same event
loop, e.g. download started + download complete. In this case, the
receiver will receive two events for the same app. When it asks for the
associated status object for the first (download started) event, it will
receive a status that says "download complete ready to install". This is
because the status object has already been updated by the second event.
Furthermore, the broadcast manager must receive a copy of the status
object, not the original object. This is because the broadcast manager
doesn't parcel the relevant extras until the end of the event loop. This
means that if the status is changed twice in one frame, then both
parcels will end up looking the same. By sending through a copy instead,
this ensures that any listener receives the statuses in the correct
order, rather than two parceled versions of the same status
notification.
Also, make sure to correctly update the app details view when te user
leaves then returns to the view. Prior to this, the user would need to
wait for a download event to be received. However even that was broken,
because the download listener was not being added correctly once the
user returned to the app details screen.
Even though the categoyr mage loader explicitly says not to cache
images on disk (because they are not coming from the network anyway),
UIL still uses the `FilenameGenerator` to come up with a disk cache name.
Because the file name generator takes the "path" of the URL being
downloaded, and the categories are loaded like "drawable://2134234",
there is no path. As such, the file name ends up being meaningless.
This results in the image loader testing for the existance of the file
on disk (even though we asked not to cache on disk), and then failing
with an IOException (that gets swallowed).
By providing a meaningful name from the file name generator, it now
works as expected.
Fixes#1039.
