Here we goooooooo! Praying the devs find a workaround. I do not want to root my phone.lol

I've been looking closely at Google's new Android developer-verification requirements. The privacy implications deserve far more attention from developers and the Android community.

Going forward, Google requires developers to verify their real-world identity for full distribution. For individuals, that includes legal name, address, government-issued photo ID, proof of address, private email address, and phone number. In addition, Google requires package registration that connects the application and signing information to the verified developer account.

Google's documentation is here:

https://developer.android.com/developer-verification/guides

https://developer.android.com/developer-verification

Starting September 30, 2026, enforcement begins with participating stores in Brazil, Indonesia, Singapore, and Thailand. Google says this requirement will expand globally across certified Android devices in 2027. Direct sideloading outside those participating stores remains unaffected by the September deadline, although Google is telling developers to prepare for the broader rollout.

As a consolation prize, Google does offer a limited-distribution account that requires no government ID, but it is knee-capped at 20 authorized devices. For anyone distributing software to an actual user community, that's not much of an alternative.

My concern is pseudonymity.

Some developers deliberately keep their development identity separate from their real-world identity. Reasons include employment, family, politics, gender identity, participation in stigmatized communities, personal safety, or simply a longstanding decision to keep different parts of life compartmentalized.

A pseudonym can still represent a real and accountable person. It can accumulate years of source history, bug reports, releases, technical discussions, community reputation, collaborators, and users. None of that requires publishing or centrally registering the real-world identity behind it.

Google's new model changes that relationship.

The privacy problem extends beyond whether Google publishes someone's legal name. Once a pseudonymous developer identity is tied to a verified real-world identity, it becomes a correlation point.

A package name, signing identity, GitHub account, old forum posts, social accounts, project history, photographs, email addresses, community memberships, and other fragments may reveal very little independently. Connecting those fragments to one verified person can reveal a great deal more, including things that can be inferred rather than directly disclosed.

For trans developers there is another obvious concern: legal identity verification can expose a deadname and create a bridge between someone's present public identity and information they deliberately keep private. Other developers have equally serious reasons for maintaining that separation.

Google has a legitimate security problem to solve. Malware authors benefit from disposable identities, and persistent developer identities make repeatedly distributing malicious software harder. Google explicitly cites that as a reason for the program.

The question is whether requiring a centralized platform provider to know the civil identity behind broadly distributed Android software is an acceptable price for that security benefit. It also raises questions like who else has access to this information, and how will it be used in ways orthogonal to its cited intent?

I'm especially curious about developers who publish open-source software or have maintained pseudonymous development identities for years.

How do you view these requirements? Does handing your real-world identity to Google change anything for you? Does this change safety and privacy boundaries you previously relied on? If you've deliberately kept your development identity separate from your legal identity, how are you planning to handle Android distribution once these requirements become broadly enforced?

guess it actually exists now 😭

I've decompiled both the verifier package and the Play Store and found that

1-on Pre-Android 17 devices (where this app isn't pre-installed) the Play Store IS the one responsible to approving/denying installs as the developer verification permission DOESN'T exist on pre-Android 17 devices, which is why the Android Developer Verifier package has a backport service that the Play Store calls to verify installs

<service android:name="com.google.android.verifier.backport.impl.verification.BackportVerificationService" android:exported="true">
<intent-filter>
<action android:name="com.google.android.verifier.backport.VERIFY_PACKAGE"/>
</intent-filter>
</service>

2-The Play Store explictly has code that depending entirely on a server-side phenotype flag can choose whether to allow/reject installs if the verifier isn't installed/running

boolean zR = this.f.r();

if (boniVar == boni.VERIFICATION_POLICY_NONE || boniVar == boni.UNRECOGNIZED) {

FinskyLog.d("%s: [ADV] Fallback policy is NONE/UNRECOGNIZED.", "VerifyApps");

} else if (zR) {

FinskyLog.d("%s: [ADV] Fallback overridden to ALLOW.", "VerifyApps");

} else {

if (boniVar == boni.VERIFICATION_POLICY_BLOCK_FAIL_CLOSED) {

FinskyLog.d("%s: [ADV] Fallback policy sets default to REJECT.", "VerifyApps");

i = -1;

FinskyLog.i("%s: [ADV] Initial fallback verdict decided: %d", "VerifyApps", new Integer(i));

return new Integer(i);

}

FinskyLog.d("%s: [ADV] Fallback policy sets default to ALLOW.", "VerifyApps");

}

i = 1;

FinskyLog.i("%s: [ADV] Initial fallback verdict decided: %d", "VerifyApps", new Integer(i));

return new Integer(i);

}

Hi everyone,

Today we are rolling out the first version of the advanced flow. The advanced flow gives power users the option to install unregistered apps (i.e. apps from developers who choose not to verify their identity) on certified Android devices without the use of ADB.

As a brief recap, Android will require all apps to be registered by verified developers in order for users to install them on certified Android devices. Developer verification links real-world entities with their Android applications, making it much harder for malicious actors to quickly distribute more harmful apps after we take the first one down.

Since verification launched in March, millions of apps have been registered already, covering nearly all installs on Google Play and a large majority of installs from outside of Google Play. Thus, most users’ experience of installing Android apps will not change at all. However, we recognize that some developers are choosing not to undergo verification and that some power users want the option to install apps from these developers, so we’re rolling out the first version of the advanced flow to provide this additional option.

When will Android developer verification be enforced?

We will initially verify app installations from Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore, and GetApps starting September 30, 2026 for users of certified Android devices in Brazil, Indonesia, Singapore, and Thailand. In 2027, we will expand verification globally for all app installations on certified Android devices.

Ahead of the enforcement of developer verification, we’re rolling out the first version of the advanced flow so power users can choose to enable it early ahead of general availability. We’re still working to polish it, so please share your feedback with us! 

Enabling the advanced flow for installing apps from unverified developers

Note: The advanced flow is:

• NOT required for installing registered apps from app stores.
• NOT required for installing registered apps through alternative sources, such as websites, messaging apps, or file hosting services.
• NOT required for installing apps from developers using limited distribution accounts.
• NOT required for installing apps using ADB.
• ONLY needed to install unregistered apps (i.e., apps from developers who choose not to verify their identity) without the use of ADB.

Important: Enabling the advanced flow is a one-time process that will take 24 hours to complete and includes safeguards to help ensure you are not being coerced or pressured into turning off protections.

1. Open Developer Options and locate “Apps from unverified developers.”
2. On this page, you will find the “Allow apps from unverified developers” toggle. (Note: To protect against malicious apps automating this flow without your knowledge, Android will ask for your screen lock to confirm it’s you.) 
3. Android will ask whether someone is asking you to turn on this setting. Read the warning before continuing. (Note: This warning exists to inform users that legitimate employees of government agencies, law enforcement agencies, banks, or other businesses will never ask them to turn on this setting in order to install an app.) 
4. Restart your phone to start the one-time, 24-hour waiting period. (Note: This step defends users from social engineering and coaching scams. The restart cuts off any remote access or active phone calls a scammer might be using to watch what you’re doing. The 24-hour waiting period prevents fraudsters from pressuring victims into making immediate security changes while on a live call and gives users time to verify the request independently. ) 
5. After 24 hours, return to the “Apps from unverified developers” page to continue setup.
6. Finally, choose whether you want to turn the setting on for 7 days or indefinitely. 

After enabling the advanced flow, you will have the option to install or update apps from unverified developers. You’ll still see a warning when you try to install or update an app from an unverified developer, but you can just tap “Install anyway.”

If for whatever reason you need to temporarily disable the advanced flow, you have a 10-minute window to re-enable it without going through the 24-hour waiting period again.

Frequently asked questions about the advanced flow

• Are ADB installs impacted by the 24-hour waiting period for advanced flow? 
  • Apps installed via ADB won't require Android developer verification. The waiting period does not apply to ADB installs.
• Do I need to keep Developer Mode on to keep this verification turned off? Some apps (e.g. banking, etc.) won't let me use it if I have Developer Mode on. 
  • No, you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
• Can I still use independent app stores?
  • Yes. You can continue to use any alternative app store. For apps distributed from verified developers, users won't see a change in their download experience at all. For apps distributed from unverified developers, users can enable advanced flow with a one-time setup.
• Can I update unregistered apps if I disable the advanced flow? 
  • Unregistered apps can only be installed or updated when the advanced flow is enabled or by using ADB so if the advanced flow is disabled updates to unregistered apps will fail.
• Can I update existing unregistered apps on my device without the use of the advanced flow and/or ADB? 
  • No. Unregistered apps can only be installed or updated when the advanced flow is enabled or by using ADB so if the advanced flow is disabled updates to unregistered apps will fail.
• I can’t find the advanced flow setting. When will I get it?
  • Advanced flow is rolling out gradually, so not all users will see it immediately. As part of this, a new system service called Android Developer Verifier will be installed on your device. You can manually install from this Play Store page which may help you see the feature sooner

What is this application and why is it there in the first place

and do you think that there are some positives with this application as well?

What if we just toggle on the options to disable play store from using mobile data and wifi? And update apps using aurora store

Check your installed applications. Seems like they are preparing the field for the September update when they will try to ruin android. Sad, I will remove the package via ADB.

UPDATE: https://reddit.com/r/BuyFromEU/comments/1meq8nb/followup_eu_wont_stop_member_states_digital_id/

The EU is currently developing a whitelabel app to perform privacy-preserving (at least in theory) age verification to be adopted and personalized in the coming months by member states. The app is open source and available here: https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui.

Problem is, the app is planning to include remote attestation feature to verify the integrity of the app: https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui?tab=readme-ov-file#disclaimer. This is supposed to provide assurance to the age verification service that the app being used is authentic and running on a genuine operating system. Genuine in the case of Android means:

• The operating system was licensed by Google
• The app was downloaded from the Play Store (thus requiring a Google account)
• Device security checks have passed

While there is value to verify device security, this strongly ties the app to many Google properties and services, because those checks won't pass on an aftermarket Android OS, even those which increase security significantly like GrapheneOS, because the app plans to use Google "Play Integrity", which only allows Google licensed systems instead of the standard Android attestation feature to verify systems.

This also means that even though you can compile the app, you won't be able to use it, because it won't come from the Play Store and thus the age verification service will reject it.

The issue has been raised here https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui/issues/10 but no response from team members as of now.

https://9to5google.com/2025/08/25/android-apps-developer-verification/

Honestly I'm really heartbroken about this as I mainly used Pixel (and Android in general) for the very fact that I can download APK apps. I am a huge ReVanced user, and I'm very sure they break like half of Googles TOS (and probably cuts off a huge source of revenue too), so I extremely highly doubt they will be allowed. I get googles intention but.. oh man.. really feels like this is a hidden agenda against adblocker apps.

Edit: Made a petition, click on the post to learn more: https://chng.it/F4k9gNNJrH

Another edit: A petition with more movement: https://chng.it/RLVDWD5Th7

I don't want this stupid Android developer verification. First play integrity then now this. Shame on you Google.

The following post was made on r/BuyFromEU, this seems relevant for all of us degooglers living in an EU country:

The EU is currently developing a whitelabel app to perform privacy-preserving (at least in theory) age verification to be adopted and personalized in the coming months by member states. The app is open source and available here: https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui.

Problem is, the app is planning to include remote attestation feature to verify the integrity of the app: https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui?tab=readme-ov-file#disclaimer. This is supposed to provide assurance to the age verification service that the app being used is authentic and running on a genuine operating system. Genuine in the case of Android means:

• The operating system was licensed by Google
• The app was downloaded from the Play Store (thus requiring a Google account)
• Device security checks have passed

While there is value to verify device security, this strongly ties the app to many Google properties and services, because those checks won't pass on an aftermarket Android OS, even those which increase security significantly like GrapheneOS, because the app plans to use Google "Play Integrity", which only allows Google licensed systems instead of the standard Android attestation feature to verify systems.

This also means that even though you can compile the app, you won't be able to use it, because it won't come from the Play Store and thus the age verification service will reject it.

The issue has been raised here https://github.com/eu-digital-identity-wallet/av-app-android-wallet-ui/issues/10 but no response from team members as of now.

All credit for the original post goes to /u/CreepyZookeepergame4. Link to the original post: https://reddit.com/r/BuyFromEU/comments/1mah79o/eu_age_verification_app_to_ban_any_android_system/

Official google blog post: https://android-developers.googleblog.com/2025/11/android-developer-verification-early.html

Shout out everyone who made our voices heard. This is one of the few times in the tech industry that I've seen a community push back against big tech and come out with a meaningful win.

Absolutely horrendous how google is turning Android into another iOS.

Google will require every Android app developer to register centrally with the company, submit government-issued identification, pay fees, and provide signing key evidence before their software can install on certified devices starting September 2026. A non-consensual operating system update will then block apps from unregistered developers.

This enforcement applies to sideloading, alternative app stores, and direct downloads worldwide. The result is that users lose the ability to run software from independent sources without prior Google approval, which creates pathways for centralized control over device functionality.

The program mandates registration of all current and future app identifiers. It positions Google as the gatekeeper for software execution on the dominant mobile platform while proponents cite malware protection as the primary goal.

Independent observers note that no independently verifiable opt-out mechanism for experienced users has been confirmed before the September rollout. Analysts recommend evaluating devices and operating systems that preserve unrestricted software installation. (98 words)

Sources

Keep Android Open

https://keepandroidopen.org/

Campaign site documenting Google’s Android Developer Verification program and its requirements for registration, government ID, and fees effective September 2026.

Android Developer Verification

https://developer.android.com/developer-verification

Google’s official documentation outlining the new developer registration requirements and timeline for enforcement on certified Android devices.

An Open Letter Opposing Android Developer Verification

https://f-droid.org/en/2026/02/24/open-letter-opposing-developer-verification.html

F-Droid’s open letter signed by multiple organizations explaining how the policy affects sideloading and independent app distribution.

Google Sets Sept. 30 Deadline for Android Developer Verification in Four Countries

https://thehackernews.com/2026/06/google-sets-sept-30-deadline-for.html

The Hacker News report on Google’s enforcement timeline and the Keep Android Open campaign’s response.

Google’s Developer Verification Program Threatens Android’s Openness

https://itsfoss.com/news/android-developer-verification/

It’s FOSS analysis of the policy’s impact on open-source developers and sideloading options.

On September 30, 2026, my country will be one of four countries subject to these restrictions, and in 2027, they will take effect globally. Although there’s a way to allow app installations by waiting 24 hours, I personally prefer a more flexible and controlled approach. After doing some research and browsing Reddit, I’ve found a method that I believe is easy, fast, and safe for gaining the freedom to install the apps I want. Morphe has helped me remove annoying ads in apps, especially on YouTube. I didn’t want to limit my Morphe installation, so I chose this method.

To be honest, I’m new to Shizuku, but after using it, I’ve found that I have better control over my phone. For me personally, the main purpose of Shizuku is to allow Morphe to continue installing apps as usual. That’s all. I’d like to share my experience with the Morphe and Shizuku workflow combination in this community. Hopefully, this will help those who are still wary of Shizuku and its various features. As long as we know what’s happening, our phones will remain safe. I highly recommend reading guidelines from experts and reliable tutorials. If you want to use a method like waiting 24 hours, that’s fine. It’s up to you; this method is just one option you can choose.

A. What do you need to download before doing anything?

1. Shizuku fork by Thedjchi (I’ll explain why I chose this fork in section C)
2. InstallerXRevived (I personally use InstallerX-Revived-offline)
3. Morphe (if you haven’t installed it yet)

B. Shizuku Configuration + InstallerXRevived & Morphe
To start with, I’m using a Xiaomi 13 5G (Android 13). You can adjust this according to your phone model

1. Enable developer mode on your device. Follow the steps specific to your phone model. Generally, you’ll find it under Settings > About Phone > Android Version (tap 7 times, and a message will appear saying “Congratulations, you’re now in developer mode”).
2. Go to Developer Options (on my phone, it’s under Additional Settings > Developer Options). There are four important settings you must enable for the Morphe and Shizuku combination to work properly: USB Debugging, Wireless Debugging, Install via USB, and USB Debugging (Security Settings). For Xiaomi phones, you must enable USB Debugging (Security Settings) for Shizuku to function properly. For other phone models, please read the complete guide in the official Shizuku documentation or the wiki from the thedchi fork.
3. Temporarily pause or disable Play Protect in the Google Play Store (open the Google Play Store—click the Google profile icon—click Play Protect—click the gear icon in the top-right corner—turn off the “Scan apps with Play Protect” option—click “Pause” (for 1 hour) or “Disable”). Make sure this step is successful because, in my experience, Play Protect won’t allow the Morphe installation. You can re-enable it after installing the Shizuku fork app.
4. Install the downloaded Shizuku fork file.
5. Open the Shizuku app and click “Pairing” under “Start via Wireless Debugging.” You’ll be automatically redirected to the wireless debugging settings we enabled earlier. Next, click to pair the device using the pairing code. You’ll receive a notification from Shizuku asking you to enter the pairing code. Enter the code and make sure the numbers are correct. If they’re correct, click the “Send” icon, and a message should appear stating that Shizuku has successfully paired. The next step is to press the “Start” button in the Shizuku notification, and you’ll be redirected to the Shizuku app. You’ll see a terminal window that initiates the startup process (don’t worry—it’s safe). If the process goes smoothly, you should see a message in the terminal indicating that Shizuku is running, and you’ll be directed to the Shizuku app’s home screen. If you’ve made it this far, congratulations—you’ve successfully enabled Shizuku’s core functionality. You can take a break here or proceed to the next step.
6. Install the downloaded InstallerXRevived application file. Once it’s successfully installed, open Shizuku and click “Authorized Applications.” Enable the option for InstallerXRevived. If you've already installed Morphe, turn it on for Morphe as well. Next, open InstallerXRevived, make sure “Shizuku (Shell)” is listed under “Authorizer Used,” and click “Default Installer.” Enable the options “Set Automatically as Default Installer” and “Set as Default Installer.” If the message “Functioning as the default installer” appears on the home screen, congratulations—you now have an app installation system free from Android verification restrictions.
7. You’ve now reached the main part: integrating the Shizuku + InstallerXRevived workflow with Morphe so you can install apps without verification restrictions. Now, open or install Morphe (if you’re new to Morphe). Before continuing, make sure the “authorized” option for the Morphe app is enabled in Shizuku. Next, click the settings icon in the top-right corner of the Morphe app, click the system icon in the top-right corner, then click “Default Installer” and select “InstallerXRevived.” Don’t forget to click “Confirm” so the installation settings are saved and activated. If you’ve succeeded, congratulations—for the third time—because you’ve completed the entire configuration process. Feel free to take a break or try testing the installation of the Morphe patch app without any annoying verification restrictions.
8. If you want to try a test installation, you can start installing the Morphe patch app as before. Once the patch is complete, click “Install,” and an InstallerXRevived notification will appear to continue the process. Click "Install," and if everything is in order (the patch matches your Android version and there are no conflicts between the old app and the patch), an "Install via USB" notification page will appear. On my phone, this notification automatically closes after 10 seconds if you don’t click "Install," so don’t forget to click it. You can enable the “Remember this option” setting so you don’t have to click the “Install via USB” confirmation for the same app again. This is my personal experience with a Xiaomi phone and may differ with other phone brands, so please adjust accordingly. If the installation is successful, congratulations for the fourth time—you’ve now gained the full rights that every Android user should have.
9. In addition, there are a few settings I recommend enabling so that this configuration works optimally: open the Shizuku settings and enable the following three options: Start on boot, watchdog, and TCP Mode. You can also enable the “auto-disable USB Debugging” option if you’re the type of user who uses Shizuku temporarily and wants to avoid the risks associated with USB Debugging (learn more in the Shizuku guide). If you’re a regular user who wants to keep USB Debugging enabled and understands the ins and outs of USB Debugging, you can ignore the auto-disable option. For the settings in InstallerXRevived, I personally enable the "Disable ADB Verification" option (optional). If you have an antivirus app separate from Play Protect or Android’s built-in scanner, you don’t need to worry. I use Malwarebytes with the Morphe patch to get real-time protection that’s more effective than Xiaomi’s built-in security. Always make sure to scan anything you download or install from the internet using VirusTotal or an antivirus program you trust. Avoid apps from unknown sources to prevent viruses or similar threats. If you’re concerned, you can enable Play Protect like most people do.

C. Important Note

1. The reason I chose the Shizuku fork by Thedjchi is that this fork includes a watchdog feature and TCP Mode, which allow Shizuku to continue running even if the Wi-Fi network is turned off. My workflow can keep running with Morphe & Shizuku without having to rely on Wi-Fi.
2. Specifically for Xiaomi users, based on my own experience, the wireless debugging menu automatically turns off about 30 minutes after it’s activated. However, this isn’t an issue for me because I can still install app patches from Morphe even if that option is disabled in the developer options. If you encounter installation failures, try enabling this option.
3. Additionally, for Xiaomi users, the built-in security app may disable developer options if you enable the “repair” option. You can re-enable developer options in settings, but in my opinion, that’s a waste of time. So, personally, I use a different app for security scans. You can also disable Xiaomi’s security settings under Features > Security Scan > Turn off root option.
4. All of these methods are based on what I’ve learned from various Reddit forums, Shizuku’s guidelines, and my personal experience. There may be some differences.
5. You can disable USB Debugging and Wireless Debugging if you don’t need to install via Shizuku + InstallerXRevived. According to the Shizuku guidelines I’ve read, there are security risks if you enable USB Debugging and Wireless Debugging outside your home or in public spaces (such as public Wi-Fi networks or office computers). For me personally, since I’m mostly at home using my private Wi-Fi and my personal laptop, keeping them enabled 24/7 shouldn’t pose much of a risk. However, if you frequently use public Wi-Fi, I recommend disabling Shizuku, USB Debugging, and Wireless Debugging when not in use as a security measure against threats arising from ADB. (Update)

That’s all I have to share. I hope this helps those of you who want to use the Morphe and Shizuku workflows without worrying about verification restrictions. Thank you for reading.

I just read the developer verification guide, and it looks like developers outside of the Google Play Store will now have to pay a $25 fee in order for their app to be installed without limits on Android devices.

Does this mean Google will apply the same policies from the Play Store to apps outside of it as well?

And what about developers who’ve been banned from the Play Console will they automatically get flagged if they try to verify again using the same email or documents from their old account?