No I’m just guessing. I think it’s a safe bet.
1 Like
A lot of FOSS developers make apps largely for their own use. When you’re not a business you don’t really care about market share as much. It’s a tiny fraction of android users who even use F-Droid in the first place. I would guess that many of these users are already on degoogled android but I don’t have numbers. But I don’t think there’s a need to be so so pessimistic.
I suspect that the OSS devs who really care about getting their app to a more mainstream audience already prioritize the google play store or don’t use F-Droid at all. Thinking about Signal, OnlyOffice, Proton Mail for example.
Of course, these policy changes from Google are also coming during a time when Google and other manufacturers are continuing to make it harder to flash degoogled android in the first place. But GrapheneOS seems to be actively working on getting around these types of restrictions too.
3 Likes
Actually, the only applications that aren’t available in the Play Store and that I use are Easy Notes and IronFox (excluding GrapheneOS apps like Vanadium and others like Molly that I no longer use).
For those who don’t have GrapheneOS, I don’t know what implications they might have for their privacy, beyond the question about the sustainability of other repositories like F-Droid or Accrescent.
1 Like
Obtainium does have auto-updates. But why the urgency in switching from F-Droid? It still works.
Did they say they will close after this? I don´t think so. But they said it will kill the project.
2 Likes
Wouldn’t it be possible to still have Google play apps and F-Droid apps, if someone make a way to replace the shock Google Play Services with GOS’s Sandbox Google Play Services for every devices or do I misunderstand something?
You can’t really remove GPS on stock. Furthermore, it seems dev verification will be baked in the install process.
When you try to install an Android app, the operating system already performs a number of checks before allowing the installation to go through. These checks ensure an app with the same application ID (i.e., package name) isn’t already installed, that it isn’t built for an extremely old version of the OS, and, most importantly, that it hasn’t been flagged as malware by Google Play Protect.
Google is now tacking on an additional step to this process. The company has built a hook into the install flow, requiring any app being installed for the first time to go through verification. At the time of installation, Android will communicate with a “trusted entity” on the device called the Android Developer Verifier. This new, preloaded system service determines if the app’s developer has been verified, if any issues were encountered during verification, and finally, what installation policy to enforce.
The second quarterly release of Android 16, ie. Android 16 QPR2, will be the first version of Android to natively support these changes. However, the verification policies won’t be enforced when the update rolls out in December, as Google is still working on its implementation and collecting metrics. The changes will be backported to older versions of Android through Google Play Protect, though Google says there may be some slight differences because this method leverages an existing app rather than the new, native verifier service built into the OS.
Do we know how this will impact GOS already? If anyone has a conclusive answer, please share and explain.
2 Likes
Thank you for sharing!
I thought you could with adb shell.
My idea was it could be way to lure some of non-privacy crowd over 
I think some people will go the extra mile for apps like Youtube Revanced and other apps like Revanced.
Damn does it mean it is not just GPS?
Oh, can you also confirm if this will impact a user’s ability to download apps from Aurora Store?
I’m guessing this is a basic question but I’m relatively new to GOS and Android at large so not sure how things work fully.
There’s no reason this change would affect Aurora store.
Whether Google will allow Aurora store to keep functioning in the long term is another question entirely.
3 Likes
I see. Well, that is also what I guess I was wondering. Any idea?
Correct. But we don’t know yet whether this will make it into AOSP (if it still exists by then) in QPR2, or it will be only for OEMs.
In any case, if it makes into AOSP a dev can just remove it. The concern I have is if it goes into AOSP even Chinese-market phones will be impacted (not that I use one).