Currently the IndexV1Verifier only allows SHA1-Digest.
Also allow indices to be signed using SHA-256-Digest to support
repositories using it.
-----
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: Error updating repository http://192.168.1.50:3000/repo
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: org.fdroid.index.SigningException: Unsupported digest: SHA-256-Digest
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.v1.IndexV1Verifier.checkAttributes(IndexV1Verifier.kt:35)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.JarIndexVerifier.getStreamAndVerify(JarIndexVerifier.kt:45)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.v1.IndexV1Updater.updateRepo$lambda$4(IndexV1Updater.kt:62)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.v1.IndexV1Updater.$r8$lambda$P2XzF4413QJZBOBr6JwilkHT93g(IndexV1Updater.kt:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.v1.IndexV1Updater$$ExternalSyntheticLambda3.run(R8$$SyntheticClass:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at androidx.room.RoomDatabase.runInTransaction(RoomDatabase.kt:585)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.v1.IndexV1Updater.updateRepo(IndexV1Updater.kt:61)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.IndexUpdater.update$lambda$0(IndexUpdater.kt:63)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.IndexUpdater.$r8$lambda$NUzLiXgA9adSx93mFCWLY6GuflY(IndexUpdater.kt:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.IndexUpdater$$ExternalSyntheticLambda0.invoke(R8$$SyntheticClass:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.IndexUpdater.catchExceptions(IndexUpdater.kt:68)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.index.IndexUpdater.update(IndexUpdater.kt:62)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.RepoUpdateManager.updateRepos(RepoUpdateManager.kt:107)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.views.main.LatestViewBinder.lambda$new$0(LatestViewBinder.java:94)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.views.main.LatestViewBinder.$r8$lambda$6N6Nu2ia8Nb5Yj4UytWsESKNpgk(LatestViewBinder.java:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.views.main.LatestViewBinder$$ExternalSyntheticLambda0.run(R8$$SyntheticClass:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.Utils.lambda$runOffUiThread$5(Utils.java:840)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.Utils.$r8$lambda$RTQXMghUr-8Q0IH1zJ5oQCPUbNc(Utils.java:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at org.fdroid.fdroid.Utils$$ExternalSyntheticLambda7.call(R8$$SyntheticClass:0)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:43)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4855)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(SingleSubscribeOn.java:89)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.core.Scheduler$DisposeTask.run(Scheduler.java:644)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:80)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:71)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at java.util.concurrent.FutureTask.run(FutureTask.java:317)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:348)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1154)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:652)
04-16 10:42:35.372 32370 32389 E RepoUpdateManager: at java.lang.Thread.run(Thread.java:1564)
-----
Signed-off-by: Alexander Martinz <alex@katastima.org>
This bug only affects CJK languages and apart from DB growth, the symptom is that word filtering in app lists doesn't find affected apps because we look for a single whitespace between tokens
This code comes from SearchManager, but making it available in the DB library makes sense since the queries are specific to the DB implementation such as zero-whitespace hack.
this is a bit hacky, but there seems to be very little information about this specific bug which affected several installs and either degraded search result quality or broke search completely.
In absence of a better fix or even a way to reproduce the issue, we are resorting to this.
Added indexes based on slow query logs and associated `EXPLAIN QUERY
PLAN` output.
Note: There are some composite primary keys with `repoId` +
`packageName` + ..., and we still ad an index on `packageName`.
This is because the order matters in composite keys. It might
be possible to restructure the primary key to be `packageName` +
`repoId` + ..., however this requires removing the table and
recreating it which is more complex then just adding an index on
`packageIndex` in addition to the primary key. There is also no
guarantee that things wont slow down when restructuring the primary key,
because there may be some cases where it is important that `repoId` is
first in that index.
Only enabled in debug mode. When auditing performance, make sure
to tune the parameters to the open helper. By default it will log
and explain queries that take more than 2s.
Sometimes the added and the lastUpdated timestamp are some seconds apart, so we can't expect them to be equal for new apps. We simply treat everything as new that was added in the last 14 days.
because we'll download another file afterwards and progress reporting would jump to 100% two times. Also entry.jar is really small, so downloading that is fast and doesn't benefit from detailed progress reporting anyway.
The app may maintain PackageInfo for apps already, so there's no need to keep asking the system for it. We could instead just work with what we already have.
Also, we discovered that chunking the package names isn't needed for newer Android versions. This is only relevant for whom has more than 999 apps installed.
This could happen when tapping a button quickly two times in the UI. While we had provisions to ensure proper states, these didn't work, because a parallel fetching job would mess with our state allowing the adding code to run more than once.
This can cause other exceptions (e.g. in json parsing) which prevent repo from getting added properly.
Also, when updating the archive for the first time, we can now re-use the downloaded index.
