Android developer verification: the 30 September 2026 checklist for 4 countries and 7 stores

Summary. On 30 September 2026, Android developer verification starts being enforced for users in 4 countries, Brazil, Indonesia, Singapore and Thailand, across 7 participating app stores. After that date an unregistered app cannot be installed or updated on a certified Android device in those markets through those stores. Google's own analysis, published on 30 March 2026, found over 90 times more malware from sideloaded sources than from Google Play, which is the stated reason for the change. Verification opened to all developers in March 2026 and Google says over 99% of Play developers' apps are already registered, so most teams reading this have one narrow task rather than a project. The expensive exception is an organisation without a D-U-N-S number: obtaining one takes up to 28 days, which from 22 July 2026 leaves roughly 70 days of margin. A Full Distribution account in the Android Developer Console costs $25. This is the checklist, the timeline, and the parts teams keep getting wrong.

What changes on 30 September 2026

Google published the enforcement detail in a post dated 18 June 2026 by Matthew Forsythe, Director Product Management, Android App Safety. Three facts define the scope.

First, the geography. Enforcement starts with users in Brazil, Indonesia, Singapore and Thailand. Global rollout follows in 2027. If none of your users are in those four countries, nothing breaks for you on 30 September, though the clock for 2027 has already started.

Second, the stores. Seven store operators are in the initial phase:

Third, the failure mode. An unregistered app becomes unavailable for new installation on certified Android devices in the applicable countries. Sideloading is not removed: unregistered apps can still be installed with Android Debug Bridge or through the advanced flow, which requires the user to complete a one-time setup after acknowledging the risks. For a consumer app, neither route is a distribution channel.

Two clarifications matter because teams routinely get them wrong. Verification confirms who the developer is; it does not review app content or where the app came from. And apps distributed through an organisation's own managed store to managed devices do not need to complete the requirements, because the IT admin has already vetted them.

The timeline, with the two dates you actually act on

Two of these are the ones you act on. The July and August API launches are what turn this from a console chore into a pipeline step. The 30 September date is the one that removes your app from four markets if you miss it.

The checklist

1. Confirm which of your apps are already registered

Google states that most Play developers are already verified and over 99% of their apps have been registered automatically. Confirm rather than assume. In Play Console, the Android developer verification page shows registration status per app. Anything that did not auto-register needs the manual app claim process.

The apps that fall through are predictable: packages published under a since-changed account, apps built for a client and published from the client's console, internal distribution builds with a separate package name, and white-label variants where each tenant ships a distinct application ID. If your build produces com.example.app, com.example.app.staging and eight white-label IDs, that is ten package names to check, not one.

2. Get the D-U-N-S number moving today if you are an organisation

Registering as an organisation requires a D-U-N-S number, the nine-digit identifier issued by Dun and Bradstreet. Google's own documentation says the process can take up to 28 days and advises preparing in advance. It is free to obtain.

This is the single item on the list with a lead time longer than a sprint. From 22 July 2026 you have about 70 days to 30 September, so a 28-day issuance still leaves margin, but only if someone starts it. In practice this task sits between engineering and finance and gets dropped by both. Assign it to a named person this week.

3. Decide between account types honestly

Limited distribution launched in early access in June and July 2026 and goes global in August 2026. It is aimed at students, hobbyists and learners, and caps distribution at 20 devices. It is not a route for a client project or an internal enterprise app with 200 field staff, and treating it as one is the mistake to avoid: you will hit the ceiling after your pilot group.

4. Wire registration status into CI, not a console tab

The Android Developer ID Status API launched globally in July 2026 and lets you check whether a package name is already registered. The Android Developer Console API, in early access from July 2026 and global in August 2026, lets you register and manage package names from inside your development environment. Both support OAuth delegation, so third-party platforms and app stores can perform these operations on your behalf.

The practical shape is a release-pipeline gate that fails the build when a package name is unregistered, rather than a human remembering to look:

            # release pipeline, conceptual step
- name: verify-registration
  run: |
    for PKG in $(cat package-ids.txt); do
      check_registration "$PKG" || {
        echo "FAIL: $PKG is not registered for developer verification"
        exit 1
      }
    done
          

Google has also said Android Studio surfaces an app's registration status when you generate a signed App Bundle or APK, which catches the problem at the point of build for teams that release manually.

5. Do not forget your own sideloaded builds

Teams that distribute internal builds outside any store, through a link, an MDM push or a QR code at a customer site, are the group most exposed here. Those builds are exactly the "outside of Google Play" case the requirement targets. Register them, or move them onto a managed store where the exemption applies. Android Debug Bridge remains available for development work on your own devices, which covers the engineering workflow and nothing beyond it.

What Google is actually solving for

The reasoning is in the March 2026 announcement, again from Matthew Forsythe, Director Product Management, Android App Safety:

our recent analysis found over 90 times more malware from sideloaded sources than on Google Play. So as an extra layer of security, we are rolling out Android developer verification to help prevent malicious actors from hiding behind anonymity to repeatedly spread harm.

The comparison Google's own help documentation uses is an ID check at an airport: it confirms who a traveller is and is separate from screening their bags. Applied here, verification establishes accountability so that a bad actor cannot ship a replacement app under a fresh anonymous identity the day after a takedown.

The four launch countries were chosen as markets particularly affected by fraudulent app scams from repeat perpetrators. That framing explains the store list: Brazil, Indonesia, Singapore and Thailand have high shares of non-Play Android distribution through OEM stores, which is why Samsung, Xiaomi, vivo, OPPO, Transsion and Honor are all in the first phase rather than Google alone.

Adoption numbers suggest the mechanism is working ahead of enforcement. Google reported in June 2026 that millions of apps had been registered since the March launch, covering nearly all installs on Google Play and a large majority of installs from outside Google Play.

India-specific considerations

India is not in the September 2026 enforcement set. That is the fact most Indian teams stop at, and it is the wrong conclusion for three reasons.

Indian studios and product companies export heavily into exactly these markets. Indonesia, Singapore and Thailand are standard expansion targets for Indian consumer apps, and Brazil is a common second market for gaming and fintech. If any of your apps has installs in those four countries through any of the seven stores, 30 September 2026 is your deadline, whatever your registered office says.

The global rollout in 2027 will include India. Every package name you register now is one you do not scramble over next year, and the API work you do in August 2026 is the same work that covers the global phase. Doing it once, in a release pipeline, is cheaper than doing it twice under deadline.

The D-U-N-S requirement lands differently on Indian organisations. Many Indian private limited companies, particularly newer ones, have never needed a D-U-N-S number for anything, so there is no existing record to look up and the full issuance process applies. Budget the 28 days from a standing start.

There is a related compliance point worth connecting. Developer verification requires identity data to be held and processed by Google, and under the Digital Personal Data Protection Act 2023 your own handling of director and authorised-signatory identity documents during this process falls under the same obligations you apply to any personal data. Collect what the registration needs, store it where your other identity records live, and do not leave scans of a director's government ID in a shared drive because someone needed them for a console form.

For Indian teams building or maintaining Android products, the practical adjacent work is covered in our guides to the Android 17 targetSdk 37 and adaptive layout migration and to QA and test automation, both of which sit in the same release-readiness window.

The parts teams get wrong

Assuming Play Console covers everything. It covers Play distribution and, for most developers, auto-registered Play apps. It does not automatically cover a package you ship only through an OEM store or a direct APK.

Counting apps instead of package names. Registration is per package name. Product managers count products; the requirement counts application IDs. Build the list from your signing configuration, not from a spreadsheet of app names.

Leaving the D-U-N-S step to the person who owns the console. The console owner is usually an engineer; the D-U-N-S application needs company registration details that sit with finance or company secretarial. It is a cross-functional task with a 28-day tail.

Treating limited distribution as a cheap workaround. Twenty devices, no fee, no government ID. It exists for students and hobbyists. Using it for a client pilot means a hard ceiling at device twenty-one.

Assuming the enterprise exemption covers all internal apps. It covers apps distributed through your organisation's store on managed devices. An internal app installed by employees on personal, unmanaged phones does not qualify.

FAQ

How eCorpIT can help

eCorpIT handles Android release readiness for product teams shipping into Southeast Asia and Latin America, where OEM store distribution matters as much as Google Play. That covers auditing your full package-name inventory across white-label and internal builds, getting organisation registration and the D-U-N-S dependency moving early, and wiring the Developer ID Status API into your release pipeline so an unregistered package fails the build rather than the launch. We work the same way on the 2027 global phase. If you want the September position mapped before it becomes urgent, get in touch.

References

1. Android developer verification: Building a safer ecosystem together - Matthew Forsythe, Android Developers Blog, 18 June 2026.

1. Android developer verification: Rolling out to all developers on Play Console and Android Developer Console - Matthew Forsythe, Android Developers Blog, 30 March 2026.

1. Understanding Android developer verification - Android Developer Console Help, Google.

1. Android developer verification - Android Developers documentation.

1. Limited distribution accounts - Android Developers documentation.

1. Developer verification FAQ: sideloading apps - Android Developers documentation.

1. Register apps for developer verification - Google Play Console Help.

1. Android Developer Console sign-up - Google.

1. Get a D-U-N-S number - Dun and Bradstreet.

1. Google sets timeline for Android developer verification enforcement - Help Net Security, 19 June 2026.

1. Google Sets Sept. 30 Deadline for Android Developer Verification in Four Countries - The Hacker News, June 2026.

1. New Android Developer Verifier app coming to phones as Google shares verification timeline - 9to5Google, 30 March 2026.

Last updated: 22 July 2026.