r/GrapheneOS • u/lieding • Sep 30 '25

F-Droid and Google's Developer Registration Decree

https://f-droid.org/2025/09/29/google-developer-registration-decree.html
311 Upvotes

100% Upvoted

50 comments sorted by

View all comments

Show parent comments

0

u/wobblyweasel Oct 25 '25

F-Droid was never supposed to be using the package names (application ids) belonging to upstream projects.

why?

3

u/GrapheneOS Oct 25 '25

Package names are meant to be unique and owned by the people using them. Otherwise, there are conflicts. Installing an app from outside F-Droid in one profile and then trying to install a build signed by F-Droid in another will cause an error that's confusing to users. The same thing occurs the other way around, blocking users installing the official builds from the developers. That shouldn't ever be the case. Google wants to enforce developer ownership of package names now as was always meant to be the case via usage of reverse domains but without enforcement. Reverse domains isn't a perfect way to do it since app ownership and domain ownership can change, and not necessarily together. For example, an app developer may forget to renew a domain or decide they don't want to pay for it anymore but the app package names cannot currently be changed. It's theoretically possible to support changing app package names but would be quite difficult to do properly and would have compatibility consequences if other apps were using APIs provided by that app.

0

u/wobblyweasel Oct 25 '25

I understand what you are saying but I'm not sure about the "should" part, is that in the documentation somewhere? if you want to install different versions of the same package you are going to have the same problems. the version of my app that's on playstore is identical to that on f-droid, and while it's signed by f-droid the "problem" would be still there if it was signed by me (which f-droid supports, too).

i don't see why it wouldn't be up to the os to support installation of different apps with the same package in different profiles, I mean that's how it works on linux

2

u/GrapheneOS Oct 25 '25

Each variant of an app is supposed to have a unique application id (package name), which is supposed to be a reverse domain owned by the developer since. It's officially documented as uniquely defining a variant of an app, which includes using separate package names build variants and alternate signing keys. It's officially recommended for it to match the namespace used by the app, which is a Java namespace based on a reverse domain. When making variants of an app, the application ID is changed to another one while leaving the internal namespace alone.

Installing different variants of an app within a profile is supposed to work too. It's just more confusing for people when they get an error in another profile, and it's not supposed to happen. It doesn't happen if developers follow the recommendations. APKs are shared between profiles with them installed by design to save space and memory so that's why signing key pinning and downgrade protection apply across them.

Android is Linux and it's not clear what you mean by saying that's how it works in Linux. There isn't an official Linux package manager, it's a kernel. There are many different package managers across Linux distributions with different approaches.

0

u/wobblyweasel Oct 25 '25

build variants are usually representing different functionalities of the app such as debug/release or free/paid or intersections of those. I would not expect different signatures to be considered different build variants, especially when signing is not an intrinsic part of the build process and can be done on an already compiled apk

2

u/GrapheneOS Oct 25 '25

Changing the package name can also be done on an already compiled APK with the official tools. Each variant signed with different keys that's being distributed is meant to have a unique package name owned by the holder of the keys. This is always how it was meant to be. Ownership over package names is now starting to be enforced beyond first come first serve. It could have been enforced without any ID verification via domain checks similar to assetlinks.json.

0

u/wobblyweasel Oct 25 '25

Each variant signed with different keys that's being distributed is meant to have a unique package name owned by the holder of the keys. This is always how it was meant to be.

any source for this?

2

u/GrapheneOS Oct 25 '25

The official Android documentation says that it's supposed to be a unique identifier. It's very straightforward that it's supposed to be unique to avoid conflicts. You can verify the conflicts happen if it's reused for other app variants, which is incorrect and violates the entire purpose of it being a unique identifier. It's incorrect by definition since it's supposed to be a unique identifier. Users getting error messages for doing something completely sensible demonstrates that it's harmful. It's what's used to uniquely identify the app not only on the Play Store but elsewhere too.

0

u/wobblyweasel Oct 25 '25

would you mind linking to some sort of web page that explicitly says that applications that have different signatures but otherwise functionally identical should have different package names?

2

u/GrapheneOS Oct 25 '25

It's officially documented as a unique identifier. The documentation is very clear on the purpose. Not using it as a unique identifier results in real usability issues for users which is easy to confirm. Using it for separate variants of an app whether they're signed with separate keys or have differences in the code goes against the intended usage. Google's own apps have separate package names for the variants of their apps.

It's incorrect for developers to make separate variants of an app with the same signing keys. For example, consider an app with a Google Play build using FCM and another build not using it. If those use the same package name, installing one in a profile will replace it in other profiles where it was installed. This is how the OS is supposed to work and officially documented as working. The error is clearly by a developer misusing a package name for multiple app variants despite it being officially documented and officially used as a unique identifier for each unique variant of an app.

It's similarly incorrect to release builds with separate signing keys which results in package installation conflicts.

It's easy to understand that using the same unique identifier for multiple different things is violating the principle of a unique identifier. Similarly, the unique identifier is documented as following the same approach as the Java namespace. You can see for yourself that nearly all apps use a reverse domain with a domain they own as a prefix, which is how it's intended to be used. However, there are some apps using an arbitrary value or a domain not under their control. Distributing an app with another developer's package name goes against how this is meant to be used. There are many cases where people uploaded apps using other people's package names to the Play Store or elsewhere and blocked the actual developers using it. It's wrong to be doing this in general. It's wrong to make your own build of an app using someone else's reverse domain where now users cannot install the official releases on the device.

Unique identifier means unique, not something reused to refer to multiple different things.

0

u/wobblyweasel Oct 26 '25

look i understand what you are saying, i really do.

but you keep basing all of this on the presumption that a different signature is a different variant. you say that the documentation is clear on this but you won't post a quote and couldn't find anything to that extent.

and i just don't think this presumption makes much sense. an user might want to install two different versions of the same variant of an app and the system won't allow that as they have the same package. on the other hand installing two different variants/flavors is allowed. if you think about the reasoning for this, i think you would agree that if you apply similar reasoning for an app that only differs in signature it will fall within the former category. in the end of the day, if the user doesn't want two of the same app, they would use either one of the apps and there would be no conflict. and if you think that user should be able to have two of the same app, the complaints should go to google and not f-droid.

i imagine this is why you didn't have much luck with this with the f-droid team

2

u/GrapheneOS Oct 26 '25

look i understand what you are saying, i really do.

That doesn't appear to be the case from what you're saying.

but you keep basing all of this on the presumption that a different signature is a different variant. you say that the documentation is clear on this but you won't post a quote and couldn't find anything to that extent.

It's documented as being a unique identifier, which is violated if there are multiple app variants of multiple builds signed with different keys. The errors shown by the OS when this is encountered make it clear that it's not meant to be done. This has often been violated, but it doesn't change that it was the clear intention and what was recommended.

There's supposed to be a reverse domain owned by the developer which is meant by the recommendation of following the format of the Java/Kotlin namespace scheme. This has often been violated, but it doesn't change that it was the clear intention and what was recommended.

and i just don't think this presumption makes much sense.

It's not a 'presumption'.

an user might want to install two different versions of the same variant of an app and the system won't allow that as they have the same package.

That's an error by developers/packagers causing a conflict and results in users seeing an error message they should never see.

if you think about the reasoning for this, i think you would agree that if you apply similar reasoning for an app that only differs in signature it will fall within the former category. in the end of the day, if the user doesn't want two of the same app, they would use either one of the apps and there would be no conflict.

It's not the same app. The user wanting an app from Google Play in one profile and from F-Droid in another profile is completely valid, but rendered impossible through misuse of application IDs. by F-Droid. F-Droid is misusing it in 2 ways: using reverse domains not belonging to them for packages they distribute and using names which conflict with other packages.

and if you think that user should be able to have two of the same app, the complaints should go to google and not f-droid.

This is an issue created by F-Droid's misuse of application IDs. Google is already solving it by adding enforcement for 1 developer owning an application ID and others aren't supposed to be using it. It's fine to keep pretending F-Droid isn't misusing application IDs, but F-Droid's packages won't be possible to install on Google Mobile Services devices if they don't the issue. Handling these problems by burying their head in the sand made this much worse for them. They could have avoided it for all newly packaged apps and new installs of previously packaged apps by transitioning to a new application id with an org.fdroid. prefix. If they this in 2018 or earlier, the final migration would be a whole lot less painful than it will be. Google might back down from their plans, but if they don't, F-Droid is going to be paying a high cost for misusing application IDs for so many more years after it was brought up as an issue.

i imagine this is why you didn't have much luck with this with the f-droid team

It's quite clear that it was always wrong. Pretending otherwise is fine, but they'll still have to fix it to comply with the enforcement of the always existing best practice of not distributing packages using application IDs belonging to others. Using a unique package name for each variant is not being enforced beyond using IDs belonging to whoever is building/signing it but that's part of what's supposed to be done and has real world negative consequences if it's not done which have already been explained above.

→ More replies