If you're redistributing alternate builds of Android apps, you should change the app id to one that belongs to you.
Android does signing key pinning and downgrade protection across profiles. You block people from using an official release in another user if you use their app id.
Conversation
Android reuses apks across user/work profiles where the app is installed. This saves a lot of bandwidth and storage along with helping to keep apps updated.
For example, our Camera app (github.com/GrapheneOS/Cam) is app.grapheneos.camera since we own grapheneos.app.
1
2
14
If someone installs an unofficial build of app.grapheneos.camera and then tries to install the official release in another user, they get a signature error. This kind of issue comes up a lot for our users mainly because F-Droid doesn't use an app id prefix for their own builds.
2
2
14
Our own party app repository will be using an app id prefix for our own builds of open source apps.
For apps outside our repository, we plan on improving things by showing app id and signing key fingerprint(s) in the install dialog. We could include a db of pins for app ids too.
1
1
10
It's a nice signing approach with whole file signing and support for authorized key rotations. It's unfortunate the UX doesn't do a better job surfacing it and reporting more understandable errors. App id reuse is the main usability issue in practice.
Replying to
Google Play is mirrored in our repository for use with our sandboxed Google Play compatibility layer, so the Play Store is covered already.
We're very serious about shipping a database of app id signing key pins to help bootstrap verification for other app sources automatically.
2
2
10
This implies installing nearly any app from the official F-Droid repository will fail verification and will be shown as non-genuine. If they used an app id prefix as they should be doing, the keys would instead all be pinned and their app id could be shown marked as verified.
4
9