Android developer verification: what it means for Sri Lanka
Google will exempt sanctioned countries from Android developer verification, which quietly makes an unverified APK harder to share from Colombo than from Havana. Here's the plan B.
Android developer verification is about to change who is allowed to hand you an APK, and the most revealing detail is not the rule itself. It's the exemption. Ars Technica's report on Google exempting sanctioned nations found the answer buried in a developer FAQ, and the shape of that carve-out tells you exactly what this system is: a distribution licence, tied to identity, tied to US sanctions policy.
If you write Android code from Sri Lanka, this lands on you in 2027.
🔍 What Google actually said, and what it carefully didn't
The FAQ language Ars surfaced is short enough to quote in full:
"Devices in sanctioned countries will be excluded from Android developer verification checks. This allows any developer to continue distributing apps in these regions without verification, though users there won't benefit from the enhanced security benefits of the program."
Read that twice. It answers a question nobody asked. The actual question was can a developer in Iran or Cuba get verified, and the FAQ talks about devices instead of developers.
A Google spokesperson confirmed the missing half to Ars directly: people living in sanctioned nations will not be allowed to go through the verification process at all. Per the article, the current US sanction list covers Iran, Cuba, North Korea, and occupied areas of Ukraine.
So the outcome is not "no rules for them." It's the opposite:
- Their apps stay installable inside those countries, because enforcement is switched off there.
- Their apps become effectively un-installable everywhere else, because they can never be verified.
- A developer in Havana who can currently ship worldwide gets fenced into a domestic-only bubble.
📅 The timeline, and why Singapore on that list matters here
Verification blocks installs of unverified apps on any Android device running Google services, which the article describes as functionally every Android phone outside Russia and China. That includes sideloaded APKs, not just Play Store downloads. Verified developers hand Google an ID and pay a small fee (the article doesn't state an amount, so I won't guess one).
| When | Where | What happens |
|---|---|---|
| September 30, 2026 | Brazil, Indonesia, Singapore, Thailand | Verification enforcement switches on |
| Expected 2027 | Global expansion | Sri Lanka lands here |
| No enforcement | Iran, Cuba, North Korea, occupied Ukraine | Excluded from checks entirely |
| Out of scope | Russia, China | Devices run without Google services |
Two of the four launch countries are in our neighbourhood. If you freelance for a Singapore client or ship a side project that gets traction in Indonesia, your deadline is September, not next year. The rest of us get a preview window: roughly one year to watch what breaks for someone else before it breaks for us.
⚖️ The sanctions inversion nobody designed on purpose
Here is the part I keep turning over. Once this is global, an unverified APK will be easier to install in Havana than in Colombo. Sanctions law made Google switch off its own gate in the places it can't legally transact with, and switching off the gate is, functionally, freedom.
That's not Google being generous. It's a compliance accident. But it exposes the trade honestly: verification is not a technical security control, it's an identity control, and identity controls inherit whatever politics the identity system carries.
Key takeaway: Google has tied the ability to distribute Android apps globally to whether the US Treasury Department is willing to let you exist commercially. That's a foreign-policy dependency inside your build pipeline, and it isn't one you can code around.
Sri Lanka is not sanctioned, so this isn't about our access. The point is structural. A distribution channel that can be revoked by a sanctions list is a channel that can be revoked. Plan accordingly.
🛠️ What breaks for a student, a small team, or an SME app
Google's stated reason is combating scam apps, and scam APKs shared over WhatsApp are a real problem here. That concern isn't fake. But look at who pays the friction cost locally:
- Final-year project demos. You build an app, you WhatsApp the APK to your panel and your friends. That flow now depends on you having verified first.
- Internal business apps. A Colombo SME with a 20-person delivery team and a private stock-check app was never in the Play Store and never needed to be. Now it needs a verified identity behind it.
- The paperwork chain. ID that matches your legal name, a payment method that clears an international fee from an LKR card, and a Google account tied to the person actually shipping. Any one of those breaking blocks your release, and none of them are engineering problems.
- The 24-hour wait. There's an "advanced flow" that lets a determined user install an unverified app. It involves multiple steps, deliberately frightening warnings, and a 24-hour delay. That's a fine escape hatch for a tinkerer. It's useless for a demo at 9am tomorrow, and no client will walk it.
The advanced flow is not a workaround. It's an exit that's been designed so that almost nobody finds it.
🚀 Plan B: distribution that doesn't ask Google for permission
The practical response isn't outrage, it's reducing how much of your reach depends on the installer. For a lot of what small Sri Lankan teams actually build, the browser is the better target.
| Channel | Needs Google verification? | Good for |
|---|---|---|
| Play Store | Yes | Consumer apps, paid distribution |
| Sideloaded APK | Yes, once global | Internal tools, demos, beta builds |
| Advanced-flow install | No, but 24h wait + warnings | Power users only |
| Web app / PWA | No | Tools, dashboards, forms, calculators |
A web app skips the whole argument. No install dialog, no identity check, no fee, one URL you can put on a poster or a QR code. Every tool on induwara.lk/tools runs in the browser for exactly this reason: I don't want a distribution channel that a policy change in Mountain View can close.
That's not a universal answer. If you need Bluetooth, background sync, or real camera control, you need a native app and you'll be verifying. But an awful lot of "we need an app" projects are a form, a table, and some arithmetic, and those never needed an APK.
💡 What this means for you
- Shipping to Singapore, Indonesia, Thailand or Brazil? Start verification now. September 30 is the live date.
- Everyone else in Sri Lanka: you have until the 2027 global expansion. Sort out the ID and payment side early, because that's the part that fails at the worst moment.
- Students and hobbyists: assume casual APK sharing is ending. Build the habit of shipping a web build alongside the APK.
- Anyone building for clients: ask who owns the verified identity your client's app ships under. If it's your personal ID, you have quietly become a permanent dependency of their product.
The sanctioned-nations carve-out is the tell. When the rule gets switched off, users don't lose anything. Developers do, and only the ones outside the fence.