6eeaf8662a
Properly support multiple repositories with the same app Fixes #511. Provides proper support for multiple repos in the database + updater (despite not being able to reorder them in the UI yet). # Info Previously, each app had only one row in the app table. This caused problems when its metadata was updated, because it would get overriden if two repositories provided the same app. This change: * Creates a new `package` table which acts as the table that includes one row for each app (like the `app` table did previously) * Re-purposes the existing `app` table as an `app_metadata` table, where each package can have multiple rows (one for each repository that provides that package) This results in some queries which are slightly more complex, but the overall performance should not change too much. In the long term, it should have a net positive impact on performance, because we no longer need to join between tables based on a package name. Now we almost exclusively use integer IDs to join between tables. There are also appropriate indexes which make the queries avoid full table scans in all cases I'm aware of. I realise this is a big MR, but it is as small as I could make it without submitting half finished stuff which breaks `master`. I've done my best to merge smaller MRs before hand, but I was unable to identify anything else to pull out of this MR as a separate thing. ## Migration All app/apk metadata is dropped, and then the repos are asked to update themselves again next time F-Droid starts. Additionally, existing repositories have their `priority` changed to something more meaningful. On current master, if you add two custom repositories in addition to the four default ones, you will get the following: |rowid|address|priority| |---------|-------|-------| |1|https://f-droid.org/repo|10| |2|https://f-droid.org/archive|20| |3|https://guardianproject.info/fdroid/repo|10| |4|https://guardianproject.info/fdroid/archive|20| |5|http://10.0.0.6:8888/normal-repo/repo|10| |6|http://10.0.0.6:8888/conflicting-repo/repo|10| Note how the priority defaults to 10 for each additional repository which is added. This MR should change the priorities so they look like so: |rowid|address|priority| |-------|-------|--------| |1|https://f-droid.org/repo|1| |2|https://f-droid.org/archive|2| |3|https://guardianproject.info/fdroid/repo|3| |4|https://guardianproject.info/fdroid/archive|4| |5|http://10.0.0.6:8888/normal-repo/repo|5| |6|http://10.0.0.6:8888/conflicting-repo/repo|6| Here is a snipped from the logcat from `DBHelper` during the migration: ``` Setting priority of repo https://f-droid.org/repo to 1 Setting priority of repo https://f-droid.org/archive to 2 Setting priority of repo https://guardianproject.info/fdroid/repo to 3 Setting priority of repo https://guardianproject.info/fdroid/archive to 4 Setting priority of repo http://10.0.0.6:8888/normal-repo/repo to 5 Setting priority of repo http://10.0.0.6:8888/conflicting-repo/repo to 6 ``` All newly added repositories on this branch will get the next highest available priority. # Future work One thing which is not yet supported fully: Suggested version code. Two repositories can end up with the same exact .apk file. If that .apk is the "suggested version", then we should eliminate the idea of "suggested version code" and instead have a "suggested apk" (which implicitly includes the repository it comes from, so we choose the one with the better priority). Right now, we kind of assume that it doesn't matter which repo provides the suggested apk, as long as one of them has an .apk with th ecorect version code and signing key. I guess it doesn't _particularly_ matter from a security perspective, because a malicious repo wont be able to trick a user into installing an apk with a different signing key, but it would be good to iron this out. See merge request !375
F-Droid Client
Client for F-Droid, the Free Software repository system for Android.
Building with Gradle
./gradlew assembleRelease
Direct download
You can download the application directly from our site or browse it in the repo.
Contributing
See our Contributing doc for information on how to report issues, translate the app into your language or help with development.
IRC
We are on #fdroid and #fdroid-dev on Freenode. We hold weekly dev meetings
on #fdroid-dev on Tuesdays at 20h UTC, which usually last half an hour.
FAQ
- Why does F-Droid require "Unknown Sources" to install apps by default?
Because a regular Android app cannot act as a package manager on its own. To do so, it would require system privileges (see below), similar to what Google Play does.
- Can I avoid enabling "Unknown Sources" by installing F-Droid as a privileged system app?
This used to be the case, but no longer is. Now the Privileged Extension is the one that should be placed in the system. It can be bundled with a ROM or installed via a zip, or alternatively F-Droid can install it as a system app using root.
License
This program is Free Software: You can use, study share and improve it at your will. Specifically you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Some icons are made by Picol, Icomoon or Dave Gandy from Flaticon or by Google and are licensed by Creative Commons BY 3.0.
Other icons are from the Material Design Icon set released under an Attribution 4.0 International license.