Google will require developer verification to install Android apps, including sideloading

Like I said: ArceusLand is the ultimate solution, by basically forcing Google to comply or face very serious consequences.

The whole F-Droid catalogue would always be one incident away from becoming useless. Ever read those “[major platform] closed my account, no explanation, no recourse” posts? Tech companies are the new dicatorships. With all of the apps on F-Droid, I’m sure there’s at least one that will trigger the almighty algorithm at some point. Oops
 F-Droid is now a blacklisted verified developer.

2 Likes

So, realistic expectations for apps in the F-Droid catalogue and Android open source community in two years:

  • some apps will be tied to non-blacklisted verified developers and installable by everyone
  • some apps will be tied to blacklisted verified developers or unverified developers and installable only by:
    • people using a device running uncertified Android
    • people clever enough to leverage elevated privileges

Most of that last group probably won’t fully understand the security implications, especially as hardly anyone ever mentions those. More hobbyists will “just install Shizuku” as recommended by their peers and start granting apps full device access while continuously running wireless debugging.

Result:

  • the tech illiterate will be safer from cyberthreats
  • power users will be more vulnerable to cyberthreats

Hmmm
 :thinking:

What about adding webadb to f-droid website? You need connect your phone to a computer via a usb cable though


Are you still discussing this topic?
Everything has been clear for a long time now.
Google still has ADB for installing apps for now, and then they’ll remove even it.
And Google has an open developer registration process for these restrictions.
And they’re already blocking access to this registration for all developers from sanctioned countries.
I can’t access this page on any device without a VPN.
This is simply Google’s policy to block unwanted developers from sanctioned countries from accessing its platform, nothing more.

But by doing so, they’ll limit access to their platform only to individual developers from sanctioned countries.
Corporations with tons of money from sanctioned countries will continue developing Android apps as if nothing happened. Because they have big money.

Another blatant hypocrisy from Google and nothing more.

As long as ADB access is still open, I’ll keep working for Android, but once ADB will be closed, I will say goodbye to Android forever.

But with the current restrictions, I don’t see any point in sending anything new to Fdroid even now, unfortunately.

Realistically speaking just want to throw my two cents in here.

I think the way forward is honestly just continue to encourage people to move to custom Operating Sytems based on AOSP or LineageOS since those have honestly only continued to become more accessible.

I am not going to say any way forward for stock cause honestly the only way I can see that going well is if someone or something makes them back off with the changes.

These custom Operating Systems likely will not be affected by this change at all (because literally how could they. Most of them aren’t Google Certified in the slightest and actually try to keep hostile Google components and Services as minimal as possible.)

And I mean in regards to people who are not very techy I mean you can literally buy phones preloaded with Operating Systems that won’t be affected by this for a actually pretty decent price. I mean there’s iodĂ©(iodĂ©OS) Murena(/e/os) Nitrokey(GrapheneOS afaik) and more!

And even then the install processes have become pretty trivially easy should you want to do it yourself with GrapheneOS’s installer for example literally taking just a few button clicks and some patience and then bam you are pretty much done. Really hard to screw that up and even if you somehow do screw up all you need to do is try again.

Now. Of course depending on how far Google takes this anti user behaviour may eventually end up affecting these options aswell. It already has to an extent. But the fact of the matter is all of these are still going so we cannot really say they are a sinking ship until Google actually starts sinking them.

But provided that does happen
 Well let’s just hope Linux phones are properly ready by then.

Please, for things that holy, stop holy war.

We are here to discuss situation with sideloading. Not to start flame about governments. If you have issues with any government ever, you should deal with it by yourself or other forums.

You can read my experience here:

And yeah, I still using F-Droid for all FOSS apps. There is no way I ever start using proprietary CRAP.

To add, I created VM (QEMU) with android x86 instead of waydroid. Why? Because I was able to patch it, give “real” IMEI and SN to stop some apps from complaining about running on emulator.

It is not silver bullet, but SOME apps with strict no-emulator policy will be bypassed.

For beginners try to edit build.prop to start your tweaks from. And do not forget to take snapshots of you VM if you are experimenting.

2 Likes

And by the way, why F-Droid team won’t cooperate with someone like Proton (they always protect freedom, try emailing them) or other free developers to start collective lawsuit against Google?

@Licaon_Kter ?

My analysis:

Currently, F-Droid is known for using different key pairs to sign different apps. (Likely one key pair per app.)

It is said that F-Droid currently also allows the developers to sign the app with the developer’s private key as long as the build is ‘reproducible’.

Technically, a signing key can be verified, or not yet verified, or revoked.

The following approaches are possible and not mutually exclusive (therefore can be carried out at the same time):

  1. F-Droid can, as many people suggested, sign the open source app with a ‘verified’ key (the key registered to Google) after modifying its package name to org.f-droid.*, in which case F-Droid takes the risk, because the packaging and signing process is obviously a sole action of F-Droid, and the original developer is not involved. This means that F-Droid will be more careful when viewing the source and signing the app. For example, they shouldn’t sign an app with security vulnerability using a ‘verified’ key, and should revoke the key pair (which is for the app only) if they discover a security vulnerability.

  2. F-Droid can also sign the app with an unverified key, in which case the user will have to use adb (for ‘certified’ devices), and the user (installer) therefore takes the risk (because they decide to trust the unverified key). There is a chance for a name conflict (if the developer will register the package name to Google under the new policy), so F-Droid possibly should still modify the package name.

  3. The developer can also sign the app with a ‘verified’ key (the key registered to Google). F-Droid currently allows it if the build is reproducible. In such a case, the developer takes the risk, and F-Droid is considered merely a distributor of the package (which is likely also distributed somewhere else).

  4. The developer can also sign the app with an unverified key. This is similar to case 2.

  5. F-Droid can host different versions of above, of the same app, and the user can choose between them, and adb can always be used by the users as a last resort, or at least until the day it can longer be used. (This means that there will be two or three key-pairs per app, for different versions with slightly different package names; two from F-Droid, one of which will be ‘verified’, and the third one can be the ‘verified’ key from the developer.)

IMHO, in an ideal world, F-Droid should instead register their key pairs to the UK government, and that will be sufficient to verify their identity. Google isn’t their King.

What they have forgotten to tell us is that an ‘identity-verification system’ can work independently of a ‘whitelist system’ (an allow-list system, a system that decides what is allowed and what is not), but a whitelist system can never work independently of a identity-verification system (or it will be pointless). Android currently uses an identity-verification system based on cryptographic keys (an app can only be updated if the signatures match; similar to the system that is going to be implemented, but not based on ID cards). Google isn’t implementing an identity-verification system; they are implementing a whitelist system.

P.S. If I use adb, I’ll also fetch F-Droid’s public key from existing PKI and use apksigner --verify. Hope it still works.

Err. When do they do that? Rather, anymore? Their future is foreseeable as well. Just another profiteering company in my eyes.
I do not see them fighting for the users, and their apps and stuff are growing bundleware.

1 Like

For example

2 Likes

Sometime in the years 2026 / 2027, not February 2026

While using an F-Droid application, I received a warning from Android, which goes as follows:

Google has announced that, starting in 2026/2027, all apps on certified Android devices will require the developer to submit personal identity details directly to Google. Since the developers of this app do not agree to this requirement, this app will no longer work on certified Android devices after that time.
OK
DETAILS

Are we supposed to be concerned?

1 Like

That’s up to you. Do you want Google to doxx all developers? Do you want Google to decide which apps you can or can’t install? If not
 Yes
 be concerned, talk to your local authorities


1 Like

I think concerned.

Until you can, I STRONGLY recommend you to use ADB (or Canta) to delete:

com.google.android.gms
com.google.android.apps.docs
com.google.android.apps.photos
com.google.android.apps.maps
com.google.android.gms.location.history
com.google.android.gm
com.google.android.music
com.google.android.youtube
com.google.android.videos
com.android.vending
com.google.android.googlequicksearchbox

*Before you start do NOT forget to log out of your Google account if you have such

Also (for NUCREAR solution) find app that called like “Firmware update” or “OTA” (DO NOT REMOVE BLINDLY, you can pm me or ask here if you are unsure)

Why? Because this will prevent Google to install its updates and enforce new policy.

Drawback: you will lose all Google services.

P.S: I did so on test phone. Works fine. But there will no more GMS integration

1 Like

Maybe you can cooperate with Tuta or Proton? Or FSF? To start lawsuit.

At least I Europe you can win


Thank you for your advice, Mr. US3R.

For me the problem appears two-fold:
One is with Non-Google OS in which we are uncertain if we could continue to use some of the essential apps that we use in Bharat, like the BHIM-UPI, Rapido, et al.

The second is with the backdoor(s) in the hardware of nearly all the smartphones commercially available at competitive prices. Moreover, owing to simple, gullible users, and to the limitation in the number of aware and conscientious users, the economy of scale doesn’t work for the Open Hardware architecture, as a result of which the cost of such phones remain quite expensive.

These issues have been mentioned already in my earlier posts.

The last resort are the two fail-safes:
That (1) I don’t have biases that would push me towards risky / socially unacceptable behaviours, etc. So I could, for the present period, more or less relatively safely continue to tolerate using the Google Universe, and that (2) my nation’s governance is presently reliable, compassionate towards ordinary citizens and doesn’t bend under pressure from abroad.

Presently, I have no option to venture into the Graphene OS + Open Hardware combo, because of the circumstances mentioned above and earlier.

It is unfortunate that I have to remain stuck with my Debian OS and my laptop for the majority of my work; and in the meantime keep exploring for new opportunities.

My device is unable to launch any app when I uninstall this package.
Even F-Droid doesn’t launch and my stock launcher keeps crashing again and again.
All I can do is to revoke internet access for that package.

I doubt that’s the reason, F-Droid works fine on devices without that app

I guess you disabled some other important package


Similar issue, unfortunately with no progress: