On September 30, 2026, Android developer verification stopped being a plan and started blocking installs. Certified Android phones in Brazil, Indonesia, Singapore and Thailand now check that an app was registered by a verified developer before it can be installed or updated from Google Play and six other big Android stores, and Google says the same check goes global in 2027. This post explains what is enforced today, what is not yet, and what an app team should get done before the global rollout.
What actually changed on September 30
Google's developer verification page describes the current phase in one line: protections began "for all users who install apps from participating stores in Brazil, Indonesia, Singapore, and Thailand on certified devices running Android 7+". The participating stores, per the June update on the Android Developers Blog, are Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion's Palm Store, vivo V-Appstore and Xiaomi GetApps.
In those four countries, an app from one of those stores has to be linked to a developer whose identity Google has checked, and its package name has to be registered to that developer. If it is not, the install or update is blocked unless the user goes through the new "advanced flow" or installs with ADB. Android Authority confirmed after launch that certified devices with Google Play services in those regions now block unverified packages by default, and that apps installed before the rollout keep working but cannot be updated without one of those routes.
Google keeps stressing that this is an identity check, not an app review. The Android Developer Console help page compares it to an ID check at the airport, separate from scanning the bags. Google is confirming who you are, not reading your code.
One small inconsistency is worth knowing about: that help page lists only Indonesia, Singapore and Thailand in its first sentence, then refers to "these four countries". The developer site, the guides and the June blog all list Brazil as well, so treat it as four.
What is not enforced yet
The scope of this phase is narrower than a lot of the coverage suggests. According to the official FAQ:
- Enforcement is limited to the seven participating stores. If you distribute through another store, or users install your APK directly from your website, the check does not apply to you yet.
- Outside Google Play, enforcement covers only phones and tablets in the selected regions. Google still recommends registering apps for every form factor.
- ADB installs are not affected at all, and there is no 24-hour wait for ADB.
- Apps distributed through an organization's own store to managed devices are exempt, though Google recommends registering them anyway in case they end up installed another way.
- Verification checks do not run on certified devices physically located in comprehensively sanctioned countries.
None of this is a permanent exemption. The same FAQ says to plan to complete verification before the global rollout in 2027, and Google's guides say verification "will soon be expanded to all third-party Android app stores". Vietnam is not in the first wave, but a studio in Vietnam with users in Thailand, Indonesia or Singapore is already affected, and every other market will follow next year.
The three distribution paths
Google now offers three ways to get an app onto a certified device. The table below summarizes the guides and FAQ.
| Full distribution | Limited distribution | Unregistered app | |
|---|---|---|---|
| Who it is for | Companies and professional developers | Students, hobbyists, personal use | Developers who choose not to verify |
| Identity check | Government ID; organizations also need a D-U-N-S number | None, email account only | None |
| Fee | $25 one time in Android Developer Console; Play developers use their existing Play Console account | Free | Free |
| Reach | Any store, website or channel | Up to 20 devices | Channels that do not require verification |
| User experience | Same as today | User accepts an invitation from a developer they know | User must enable the advanced flow or use ADB |
Two details matter for planning. First, a limited distribution account can be upgraded to full distribution later, but a full account cannot be downgraded. Second, the $25 fee applies to full distribution accounts in the Android Developer Console, and Google waives it for developers who qualify for limited distribution.
What app teams should do now
If you only publish on Google Play, you are probably already done. Google says it registered eligible apps automatically for developers who had completed Play Console verification, and that more than 99% of Play apps were registered this way. "Probably" is not good enough for a client's production app, though. The July 15 note on the June blog post says Play developers had to register any remaining apps by September 30 "to avoid global removal from Google Play". That consequence applies worldwide, not just in four countries.
Here is the checklist we use.
1. Check registration status for every package
In Play Console, open the Android developer verification page; the status is shown next to each app. In the Android Developer Console, the Package names tab shows Registered, Not registered or Draft. Android Studio Panda 4 and later also shows registration status when you generate a signed App Bundle or APK, which is a handy last check before a release.
2. Register apps you ship outside Google Play
This is where most teams have gaps: an APK on the company website, a build sent to a client's sales team, a Galaxy Store or Xiaomi GetApps listing. If you already have a Play Console account, Google recommends using it as the single place to register apps distributed outside Play too. Teams that only distribute outside Play need an Android Developer Console account. Registering a package means proving ownership by providing an APK signed with your private key.
3. Get your signing keys in order
Signing keys are now part of your identity, not just your build. The FAQ is blunt: if you lose your signing key, you will not be able to register your packages. If you use Play App Signing, Google already has what it needs and your eligible apps were part of automatic registration. The Android Developer Console also lets you add and verify multiple signing keys for one package, which helps if the Play build and the direct-download build are signed differently.
If a package name is already in use and your key is not eligible to claim it, Google suggests choosing a different package name. You can request the name anyway, but that requires extra review and the name may also be used by other developers.
4. Start organization paperwork early
Organizations need a D-U-N-S number from Dun & Bradstreet. It is free, but Google warns it can take up to 28 days. The guides also say organizations must provide a website verified with Google Search Console. If a client is setting up a new company account for the 2027 rollout, start this weeks ahead.
5. Automate it if you ship many apps
Google launched two APIs for this. The Android Developer ID Status API checks whether a package name is eligible or already registered. The Android Developer Console API registers package names and manages keys. Both are meant for bulk registration and CI/CD pipelines, and both support OAuth delegation so a store or platform can act on your behalf. An agency that creates a new package name for every client pilot should add a "registered?" check to its release script.
6. Fix your testing workflow
Internal builds installed with ADB are unaffected. For testers who install APK files directly on their phones, outside the participating stores, nothing changes in this phase either. Once the global rollout reaches those installs, a tester with an unregistered build will need the advanced flow, so register your test package names now (for example a separate .dev package) rather than finding out on a client's phone.
The advanced flow, from the user's side
It helps to know what your users would face if your app were unregistered. The FAQ describes the flow:
- Turn on developer mode in system settings.
- Confirm that nobody is coaching them to disable protections.
- Restart the phone and re-authenticate, which cuts off any remote session or live call a scammer might be using.
- Wait a one-time 24 hours, then confirm with fingerprint, face unlock or PIN.
- Choose to allow unverified apps for 7 days or indefinitely. Each install still shows a warning with an "Install Anyway" button.
Developer options do not need to stay on afterwards, which matters because some banking apps refuse to run with them enabled. But if the user turns the advanced flow off, installs and updates of unregistered apps fail again. For a consumer app, that is a lot of friction to ask of anyone. In practice, registering is the only sensible choice for a commercial product.
Pros, cons and open questions
For legitimate developers the costs are modest: a one-time identity check, a $25 fee if you are not on Play, and some paperwork for companies. Google's reason is concrete: its analysis found "over 90 times more malware from sideloaded sources than on Google Play", according to the March 2026 announcement. The 24-hour wait targets a familiar scam pattern in which a caller pressures a victim to install an app right away.
The downsides are real too. Anonymous and privacy-focused developers have to choose between limited distribution and asking users to go through the advanced flow. Lost signing keys can no longer be worked around. And Google has not published the 2027 schedule by country, so teams cannot yet plan around exact dates. One question we hear from clients has a clear answer: the FAQ says verification does not collect information about app content or functionality, so registering a package under NDA does not expose the product.
Our take
For a small app studio like ours in Da Nang, the work is mostly housekeeping, and it is cheaper to do it now than during a release in 2027. We are auditing every client package against Play Console and the Android Developer Console, moving direct-download builds under the same verified account, and storing signing keys so that losing a laptop cannot lock a client out of their own package name.
Also check the other Android deadline this quarter. Google Play's target API level policy required new apps and updates to target Android 16 (API level 36) from August 31, 2026, and the extension Google offered runs only until November 1, 2026. If an app is on an extension, plan the API 36 update and the verification check as one release.
Sources
- Android developer verification overview, Android Developers
- Android developer verification guides, Android Developers
- Android developer verification FAQ, Android Developers
- Android developer verification: Building a safer ecosystem together, Android Developers Blog, June 18, 2026 (updated July 15, 2026)
- Android developer verification: Rolling out to all developers, Android Developers Blog, March 30, 2026
- Understanding Android developer verification, Android Developer Console Help
- Google's new Android sideloading rules are live, Android Authority
- Target API level requirements for Google Play apps, Play Console Help
Need help auditing your Android apps, signing keys and package registrations before the 2027 rollout? Lightning Studio builds and maintains mobile apps for clients in Vietnam and abroad. Email support@lightning-studio.org or see what we do at https://lightning-studio.org/studio/.
Cover photo: Dashboard.wikiedu.org on a large Android phone, 2015-04-16 by Sage Ross, CC BY-SA 4.0, via Wikimedia Commons (cropped).
Related posts
Xcode 27 Requires UIScene: A Migration Guide for iOS App Teams
Apps built with Xcode 27 must adopt the UIScene life cycle or fail to launch. What changed, who is affected, and how to migrate native, Flutter, React Native, Expo, Capacitor and Unity apps.
Apple's October 2026 App Store Changes: A Checklist for App Teams
Creative assets, the new Asset Library, Guidelines 2.3.14 and 2.5.19, and iPhone Duo: what Apple changed in October 2026 and what to check before your next submission.
3D Printing in Education: A Practical Guide for Teachers and Schools
What to print for teaching, STEM projects students can design themselves, classroom safety, budgeting and a simple lesson flow from sketch to printed part.