Tech
Android Developer Verification: What Changes on 30 September 2026
September 1, 2026
From 30 September 2026, apps from unverified developers stop installing on certified Android devices in Brazil, Indonesia, Singapore and Thailand. The UK isn't in that first wave, and Google has said the requirement expands to certified Android devices globally in 2027. If you ship an Android app, the work to get ahead of it takes an afternoon, and the cost of leaving it is that your app stops being installable in a market you may not be watching.
I want to be precise about what this is, because the coverage since the March announcement has been muddled. This is not the end of sideloading. It's a registration requirement attached to who publishes an app, rather than a restriction on how users install one.
Only apps registered by a verified developer can be installed or updated on certified Android devices, in those four countries first.
"Certified" is the load-bearing word. It means devices that ship with Google Mobile Services, which is the overwhelming majority of Android phones sold outside China. Devices without GMS are unaffected, as are custom ROMs.
The participating app stores at launch are Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. That list matters more than it first appears: this is not a Play Store policy. It reaches the alternative Android stores too, which is exactly where a lot of teams assumed they could route around it.
Two escape hatches remain open. Apps can still be installed through Android Debug Bridge, and Google shipped an advanced flow in August 2026 for installing from unverified developers, with security checkpoints designed to resist coercion scams. That second one is the interesting concession. Google's stated reasoning is about scam victims being talked through a sideload by someone on the phone to them, and the checkpoints exist to break that script rather than to block the install outright.
Not on 30 September, and yes in 2027.
The first wave is four countries. If your entire user base is UK or EU, nothing breaks this month. But the global expansion to certified devices is on Google's published roadmap for 2027, and there is no version of this where UK developers are exempt indefinitely.
The reason I'd do the work now rather than next year is that verification is a one-time account exercise with a queue attached. Doing it in a quiet month is an afternoon. Doing it in the month it becomes mandatory, alongside everyone else, is a support ticket.
There's a second reason, and it's the one people miss. If you have any install base at all in Brazil, Indonesia, Singapore or Thailand, this affects you on 30 September regardless of where you're based. Plenty of UK-built apps have a long tail of users in exactly those markets and nobody looks at the country breakdown until something stops working. Check it before the end of the month.
It means a registered developer identity attached to the package name, rather than a review of your app.
This is the point I'd most want to correct, because the word invites the wrong assumption. Verification is not an app review or a quality bar, and nobody is reading your code. Google wants to know who publishes a given package, so that when something malicious ships they can attribute it to a real entity and stop that entity shipping again under a new name.
If you already publish on Google Play, you have most of this. Play Console accounts have carried identity verification requirements for a while, and the new scheme builds on that rather than replacing it. The gap is for developers who distribute outside Play: enterprise teams shipping internally, agencies handing APKs to clients, hobbyists on F-Droid, and anyone whose distribution model was "here's a download link".
Google also launched limited distribution accounts in August 2026, aimed at developers who ship to a small number of devices rather than a public audience. If you're an in-house team distributing a line-of-business app to a few hundred handsets, that's the route to look at rather than a full public developer account.
Once enforcement is live in a market, an app reaches a certified device by one of three paths, and you should know which one you're relying on.
The normal path is a participating store with your developer identity registered: Play, Galaxy Store, the OEM stores. That works exactly as it does today.
The second path is the advanced flow, for apps from developers who haven't registered. The user can still install, but they pass through security checkpoints on the way. Realistically that's a power-user route. If your distribution depends on ordinary users completing it, expect your install rate to fall, and expect the fall to be significant rather than a rounding error.
The third is adb, which is unaffected and fine for development, QA and internal tooling. It isn't a distribution strategy for anyone who isn't a developer.
The failure mode I'd watch for is a team that believes it's on the first path and is really on the second, because their APK reaches users through a partner or an MDM that isn't on the participating list. Check that explicitly rather than assuming it.
Four things, in order, and the whole list is realistically an afternoon.
Start with your country breakdown in Play Console, under statistics by country. If Brazil, Indonesia, Singapore or Thailand shows anything meaningful, your date is 30 September rather than 2027.
Then confirm your developer identity is registered. If you publish on Play you're probably covered already, but confirm it rather than assume, particularly if the account was set up years ago by someone who has since left. Stale account ownership is the single most common thing we find when we pick up an existing app.
Next, inventory every distribution channel you use, not just Play. Direct APK downloads, OEM stores, MDM pushes, partner white-label builds. Each one needs checking against the participating-store list, and the ones that aren't on it need a decision.
Last, and this is the one I'd push hardest on, work out who owns the account. If an agency built your app and published it under their developer account, now is the moment to establish whether that's still true and whether it should be. Verification attaches to the publishing identity, so whoever holds the account holds the app. We pick up a lot of apps where that account belongs to a company that no longer exists or a contractor nobody can reach, and every distribution change Google makes turns that from an annoyance into an outage.
That kind of drift is what a maintenance relationship exists to prevent. Someone has to own the calendar of things Google changes each year, and if nobody currently does, that's what our App Support and Maintenance service is for.
You need to know whose developer account it ships under, and on some platforms the honest answer is "not yours".
This is where the verification change gets awkward. If your app reaches users through a platform's own publishing pipeline, the verified developer may be the platform rather than you. That's workable while the relationship lasts, and a problem the moment you want to move, because the package name, the install base and the update path all sit with an identity you don't control.
Ask your platform three questions. Whose developer account is the app published under? If it's theirs, what's the documented process for transferring the package to your own account? And what happens to your existing installs if you leave?
None of those are hostile questions and a good platform will have clear answers ready. Vague answers are themselves information, and better to have now than during a migration.
This connects to the broader point we keep making about no-code builds. The prototype has real value and building on these platforms is often the right first move. What people underestimate is how much of the infrastructure around the app, the distribution identity included, belongs to someone else until you deliberately take it back. Untangling that is most of what our Vibe Code to Production work involves.
Read together with the target API level requirements that tightened on 31 August, the direction is consistent: Android is closing the distance between "you can technically ship this" and "you are accountable for what you ship".
I think that's broadly right, and I'd say so even though it makes our job more administrative. The open-distribution model that made Android what it is also made it the easier platform to abuse, and attribution is a reasonable price. But it does mean the cost of an unmaintained app is rising every year. An Android app you shipped in 2022 and haven't touched since now has a target API problem, a verification problem, and an account-ownership problem, and they compound.
If you're not sure which of those apply to something you already have live, that's the audit we do. For most teams the useful thing is having someone watch the deadlines and do the work before it becomes urgent, which is what App Support and Maintenance covers. Where an app has drifted further than a patch will fix, Native Android Development picks it up. Either way, Get in Touch and we'll tell you where you stand.
No. Sideloading continues, through Android Debug Bridge and through an advanced installation flow that Google shipped in August 2026 for apps from unverified developers. What changes is that apps from unverified developers no longer install through participating app stores on certified devices in the enforcement markets. The requirement attaches to registering a developer identity, not to the act of installing.
Brazil, Indonesia, Singapore and Thailand. Google has said the requirement expands to certified Android devices globally during 2027. If you have users in any of those four markets, the September date applies to you regardless of where your company is based.
No. It's identity registration rather than app review. Google is establishing who publishes a given package so that malicious apps can be attributed to a real entity. Nobody reads your code as part of verification, and passing it is not a security or quality signal you can advertise.
Look at the limited distribution accounts Google launched in August 2026, which are aimed at developers shipping to a small number of devices rather than a public audience. Internal distribution through adb is also unaffected. The route to avoid is assuming an existing MDM or direct-download channel is covered, because participating-store status varies.
Whoever holds the developer account the app publishes under, which may be the agency rather than you. Verification attaches to the publishing identity. If you don't know whose account your app sits in, establish that before September, because transferring a package between accounts takes longer than registering one.
No, they're separate and both apply. Target API level rules govern which Android version your app must build against to stay distributable, and those tightened on 31 August 2026. Developer verification governs who is allowed to publish. An app can be fully compliant on target API level and still be blocked for an unverified developer identity.
