Trin
I understand how this can cause duplication and scamming, I am not sure how this resolves the issue with Google asking for devs to register though. Unless you are saying this is what caused Google to implement this? F-Droid themselves would need to register. But then also all the other developers that use F-Droid would need to register. It sounds like F-Droid's devs think this will not happen, regardless of how they list things on their store in the backend.
It's being handled through developers registering and being treated as owning package names (application ids) for their apps. This is why F-Droid views it as so disruptive to them since 99% of what they package is signed using their own keys but while incorrectly using the upstream package names. This has been pointed out as a major issue for years but they continued doing it and doubled down on it for new apps. Not only did they not migrate away from this bad practice considered incorrect years ago, but they continued doing it for all the newly added apps using their own signing keys.
The "Google certified devices" is wording that is confusing me a tad. Does that mean that hardware can be somewhat lock (I know Samsung for example is locking bootloaders) and prevent even custom ROMS using certain software to work? Or is that blocked by Play Services/OS level, in which case it would still not really affect people on custom ROMS?
No, it has nothing to do with hardware. It's a Google Mobile Services feature likely implemented by the Play Store. AOSP has a provider API for an OS component to provide it.
Custom ROM is incorrect terminology as a whole and should never be used to refer to GrapheneOS.
This is beyond what we both said - apps not being used and donations falling discouraging development of what usually gets installed via F-Droid.
Apps outside of the Play Store will still be able to be installed on the stock OS, an individual or organization simply needs to complete verification. There has to be someone involved with the project taking responsibility for signing who does this, not necessarily the main developer.
For apps F-Droid is signing with their own keys which is the vast majority of apps they package, it's F-Droid which has to do verification and they need to stop using their own keys for package names not belonging to them. This is why they're so concerned, because they kept digging this hole deeper and deeper for years ignoring that it went against how package names are meant to be used. Package names are meant to be globally unique application IDs corresponding to a specific variant of an app. There aren't supposed to be other variants with different code or signing keys. A third party building and distributing builds is supposed to use their own package name prefix. Package names start with a reverse domain that's meant to be owned by the people publishing it. There's a special case for OS components with com.android but outside of the OS, you're meant to own the domain for the prefix of the package name. For example, we use app.vanadium.browser for the Vanadium browser app because we own vanadium.app. If we didn't own vanadium.app, it would be incorrect to do that.