Each app insert required asking the database for the ID of each
category an app is in. Given the categories don't change (ever)
but are only appended to, we can cache the results in a static
Java variable for increased performance.
This reduced the "repo persister" logic for me from 50 seconds
for main F-Droid and 100 seconds for Archive, down to 15 seconds
and 30 seconds respectively.
Now that we need only "insert" new apps rather than"
* Identify if an app exists
* If so, update
* If not, insert
There is much less code required for all of this stuff.
When preparing a temp database to write to, don't copy all apps/apks.
Instead, only copy those _not_ belonging to the repo we are updating.
In an ideal world, we'd not even need to copy them, but we need
their IDs to be in the temp database so that we don't accidentally
use the same auto-generated ID as the main database.
This also means that we can drop the check for "does this app exist,
and hence should we UPDATE it instead of INSERTing it?" and always
just insert it.
Then, when copying the temp table back to disk, first delete all
apps/apks _belonging to the repo being updated_. Then, copy back the
apks/apps we found in the repo. This again improves performance because
we no longer need to bopy back and forth data which we know
wont change (as evidenced by the fact it belongs to a differen trepo).
I don't think this was possible earlier before we did the work to
support repo priorities properly. That is because we had a single app
which was serviced by several repositories. Now, we have multiple
entries in the `fdroid_app` table, for each repo which supports
that app.
The test files used in Issue763MultiRepo.java are signed using MD5, which
is now considered invalid. So if that test is run on any recent Java, it
will fail with a signature error. This updates the test files to be signed
with SHA1 instead.
* index.microg.jar is a new version fetched from https://microg.org
* index.antox.jar was resigned with the testy.at.or.at key, since antox
website doesn't exist anymore.
RepoUpdater.prepareRepoDetailsForSaving() was broken here because the Repo
properties were being set before calling it, and then the Repo instance was
passed to it for comparison. So the comparison was always saying the value
was unchanged. In IndexV1Updater, the flow doesn't need those checks.
This also fixes the bug where added repos never had their name/description/
icon/etc show up in ManageRepos and RepoDetails.
@cde found this bug working on mirror support, thanks!
related to #35closes#1016
This is not really a useful way to tell the user that the index might be
out of date. It just adds confusion and makes people think that F-Droid
isn't quite smart enough to know what's going on.
The install process automatically sanitizes filenames to avoid exploits
that put attack code in the filename. Media files are also installed using
this logic, so the installed check needs to use sanitized file names to be
accurate.
This will be more important as people work with media, since it is quite
common to use spaces in filenames generated by humans. Media files will
not be built by fdroid, so most likely, they will have human-generated
names.
* This installer is invoked when for non-apk/media files, and
copies them to an appropriate folder on the sdcard.
* We also introduce a FileInstallerActivity to ask for storage
permissions at runtime, as needed by Android 6.0 and above,
and handle the install/uninstall process.
* A toast is shown with the install path after installation.
TODO:
* Manage Installed Apps screen doesn't show media files.
* For non apk files, the signature column would be NULL always,
and in SQLite NULL = NULL is false, but NULL IS NULL is true.
See http://www.sqlite.org/lang_expr.html Operators
