Conversation

Replying to and
That's not how the official F-Droid repository works. Developers don't release their apps through it. The way it works is the F-Droid packagers choose apps to package and are responsible for keeping them updated. They could make their own F-Droid repository to do it themselves.
1
55
The issue with that is F-Droid handles it quite poorly and confuses users since the app releases signed with different signatures are incompatible. Perhaps F-Droid should add an app id prefix when using their own signing keys but they aren't doing that. It's a bit of a mess.
5
22
Replying to and
I don't feel like it's on the path to becoming what's needed. For GrapheneOS, we're going to be making our own app install / update system. One of the apps we'll provide in our repo is F-Droid, but we aren't comfortable bundling it with the OS or giving auto-install privileges.
1
11
It has too many issues with usability and maintenance. It has security implications. For example, Android switched to v2 apk signatures in 2016 (Android 7) to address security limitations with the original signing system from the Java world. F-Droid kept using v1 until 2020.
1
12
It could be blamed on lack of resources, but it's their choice to package such a huge number of apps including many that are unmaintained and/or blatantly insecure. Play Store also has minimum API target level for privacy/security reasons, and F-Droid definitely doesn't do that.
1
10
The apps got detected as invalid after booting up the Android 11 upgrade and forcefully disabled. It's invalid to have an app with v1 signature and API 30+. Unfortunately, the F-Droid developers don't seem to test on modern Android. F-Droid itself has an old target API level.
2
10
F-Droid is focused on older devices and older generation apps for those devices. It's in conflict with privacy and security. We want an extremely minimal alternative to it focused on robustness and security with the option of automatic updates without security / usability issues.
1
9
Show replies