On 30 September 2026, apps from unverified developers stop installing on certified Android devices in Brazil, Indonesia, Singapore and Thailand. The UK is not in that first wave, which is precisely why I think most UK teams will let it pass unread. Google has said the requirement expands to certified Android devices globally during 2027, so this is a deadline that arrives here eventually and arrives for some UK apps immediately.
The immediate part is the bit worth flagging to anyone shipping Android from Greater Manchester. The rule applies based on where your users are, not where your company is registered. A fair number of UK-built apps carry a long tail of installs in exactly those four markets, picked up over years without anyone paying attention to the country breakdown. If that's you, your date is this month.
What the change actually is
It's identity registration, not app review.
I want to be precise, because the coverage since the March announcement has been muddled and the phrase "Google is killing sideloading" has done a lot of rounds. It isn't that. Android Debug Bridge still works. Google shipped an advanced installation flow in August 2026 for apps from unverified developers, with security checkpoints designed to break coercion scams, where a victim is talked through a sideload by someone on the phone to them.
What changes is that apps from unverified developers stop installing through participating app stores on certified devices. "Certified" means devices shipping with Google Mobile Services, which is most Android hardware sold outside China.
Two details deserve more attention than they've had. First, the participating stores are Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. This is not a Play Store policy, and any plan that involved routing around Play does not survive it. Second, nobody reads your code. Verification establishes who publishes a package so that malicious apps can be attributed to a real entity, and passing it is not a quality signal you can put on a slide.
The question most teams can't answer
Whose developer account is your app published under?
That's the one I'd go and check today, and in my experience it's the question that produces the longest silence. We pick up existing Android apps fairly regularly, and the answer is often a company that no longer trades, a contractor whose email bounces, or an agency relationship that ended three years ago with nobody transferring the account.
Verification attaches to the publishing identity. Whoever holds the developer account holds the app, and transferring a package between accounts takes considerably longer than registering one. If there's any doubt, resolve it before September rather than during it.
There's a version of this specific to the region's newer product teams. If your app was built on a no-code or AI build platform and reaches users through that platform's publishing pipeline, the verified developer may be the platform rather than you. That's fine while the relationship lasts and awkward 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. Three questions are worth asking your platform: whose account is it published under, what's the documented process for transferring the package to yours, and what happens to existing installs if you leave.
What to do this month
None of it takes more than an afternoon.
Check your country breakdown in Play Console. If Brazil, Indonesia, Singapore or Thailand shows anything meaningful, your date is 30 September rather than 2027.
Confirm your developer identity is registered. If you publish on Play you're likely covered already, but confirm rather than assume, especially if the account predates anyone currently at the company.
Inventory every distribution channel, not just Play. Direct APK downloads, OEM stores, MDM pushes, partner white-label builds. Each needs checking against the participating-store list.
And if you distribute internally to company devices rather than to a public audience, look at the limited distribution accounts Google launched in August 2026, which are built for exactly that case.
Why this is worth ten minutes of a CTO's attention
Read alongside the target API level requirements that tightened on 31 August, the direction is consistent. Android is closing the gap between "you can technically ship this" and "you are accountable for what you ship".
I think that's broadly the right call, even though it makes our work more administrative. The open-distribution model that made Android what it is also made it the easier platform to abuse, and attribution is a fair price for that. But it does mean the running cost of an unmaintained app rises every year. An Android app shipped in 2022 and untouched since now carries a target API problem, a verification problem and an account-ownership problem, and those compound rather than queue politely.
We've written the full version, including the three install routes after September and a decision tree for working out whether your app is affected: Android Developer Verification: What Changes on 30 September 2026. If you've got an Android app live and you're not sure which of those three problems apply to it, that's the audit we do. Our App Support and Maintenance service exists for apps in exactly that state, and Native Android Development for the ones that need more than a patch.
Foresight Mobile is a Manchester-based mobile app development and maintenance company. We pick up Android apps whose original team has moved on, and account ownership is usually the first thing we have to untangle. If you're not certain who your own apps are published under, get in touch.
