What’s New This Week
Google announced the full details of its developer verification program this week, including the “advanced flow” bypass process. Android Ecosystem President Sameer Samat confirmed the September 2026 initial rollout in Brazil, Singapore, Indonesia, and Thailand, with global expansion to follow in 2027. The 692-point Hacker News thread suggests the developer community has noticed.
Changelog
| Date | Summary |
|---|---|
| 20 Mar 2026 | Initial publication. |
Starting in September 2026, installing an unverified app on Android requires completing a 9-step process with a mandatory 24-hour waiting period built into the middle of it. Google calls this an anti-scam measure. That framing is accurate. It is also incomplete.
The policy is real, the threat model is real, and the 24-hour delay does what Google says it does. But the mechanism Google chose – identity verification, fee collection, signing key registration – does something else at the same time. It closes the gap between Android’s historically open platform and Apple’s walled garden. Not as a side effect. As a structural outcome.
The nine steps and why the delay exists
Google’s new developer verification program, rolling out with Android 16.1 and enforced from September 2026, means Android will only install apps from verified developers by default. To verify, developers distributing outside Google Play must provide government-issued ID, upload a copy of their signing keys, and pay a $25 fee – the same fee as a Play Store account.
Apps from unverified developers will simply not install. There is no “install anyway” prompt in the normal flow.
There is an escape hatch, but it requires knowing where to look. Google has confirmed it will not be surfaced to users during installation. You have to know it exists and set it up in advance. Here is the full process:
- Enable developer options: tap the software build number in About Phone seven times.
- Open Settings > System > Developer Options, scroll to “Allow Unverified Packages.”
- Flip the toggle, confirm you are not being coerced.
- Enter your device unlock PIN or password.
- Restart the device.
- Wait 24 hours.
- Return to the unverified packages menu.
- Scroll past additional warnings, select “Allow temporarily” (7 days) or “Allow indefinitely.”
- Check the box confirming you understand the risks.
After that, tapping “Install anyway” in the package manager works on a per-app basis for each unverified APK.
The 24-hour delay is the deliberate core of this. Android Ecosystem President Sameer Samat explained it directly: “In that 24-hour period, we think it becomes much harder for attackers to persist their attack. In that time, you can probably find out that your loved one isn’t really being held in jail or that your bank account isn’t really under attack.”
That is a specific and coherent threat model. Scammers running telephone-based fraud often create extreme urgency – install this app right now or something terrible happens. A mandatory cooling-off period breaks that attack chain. It is a sensible UX intervention against social engineering.
It is not, however, primarily a malware defence.
Who this actually protects and who it inconveniences
A scammer who has paid $25, provided ID, and uploaded signing keys can still distribute malware to any Android user who accepts their app. The verification process does not inspect app content proactively. Google has confirmed this. If a verified developer ships malware, they lose their verified status – but the harm has already been done.
The policy targets the attack vector (urgency, social pressure, the ability to install something immediately), not the attack payload (malicious code). That is a legitimate and specific choice. Urgency-based social engineering is a documented attack pattern and removing the ability to install an app in the heat of the moment does interrupt that chain.
But it also interrupts every other use case for sideloading: hobbyist apps shared informally, open-source utilities distributed outside the Play Store, apps that do things Google’s review process is unlikely to approve, and private beta testing with a small group of users. For all of these use cases, the threat model is zero. The friction is the same.
The people this protects: Android users who would otherwise be socially engineered into installing something harmful. That is a real population, and they are not well served by the current “install from unknown sources” single-toggle approach.
The people this inconveniences: developers who want to distribute outside Play Store without registering with Google, users who want to install something immediately, and anyone in a country where ID verification is unreliable or fee payment is a meaningful barrier.
The verification cost and what it means for small developers
The $25 fee is framed as equivalent to a Play Store account fee. That framing is doing some work.
A Play Store account gives you access to Google’s distribution infrastructure, review process, billing integration, and global reach. The external verification fee gives you the right to distribute apps that Android will not actively block. The value proposition is different.
For a hobbyist developer maintaining a small utility entirely outside Google’s ecosystem – no monetisation, no Play Store listing, no interest in Google’s review process – the fee is the price of continuing to do what was previously free. Combine that with ID verification and signing key upload, and the barrier to informal distribution has increased meaningfully.
This matters in specific contexts. Developers in countries with unreliable ID verification systems may find the process fails for non-technical reasons. Teams doing internal testing with small groups of users now need to either register with Google or ask users to complete the 9-step advanced flow before receiving a test build. Neither option is frictionless.
There is also a privacy dimension. Google collects identity information from every developer who registers. The company says it is not building a permanent list intended to be vulnerable to legal demands, and says it pushes back on improper judicial orders. Those assurances are harder to evaluate than the policy itself.
iOS parity – what Android’s openness has become
The advanced flow is functionally similar to iOS’s developer mode. The steps are different; the effect is the same. Installing software outside the platform’s official channel requires deliberately enabling a buried developer setting, accepting additional warnings, and completing a process that is specifically designed not to be discoverable by accident.
Apple has been explicit about this for years. The walled garden is not a bug in iOS’s design; it is a stated feature. Apple has never positioned iOS openness as a competitive advantage because iOS has never had openness to position.
Google spent a decade doing the opposite. Android’s ability to install apps from any source with a single toggle was consistently framed as a differentiator – for developers, for enterprise, for technically capable users who wanted control of their own devices. That positioning is now harder to sustain.
The gap has not closed entirely. Android’s advanced flow, once configured, allows installation of genuinely arbitrary APKs with no Apple-style certificate requirement. iOS has no equivalent path for consumer devices outside the EU’s Digital Markets Act provisions. Android remains meaningfully more open than iOS in absolute terms.
But the delta has shrunk. And the direction of travel is clear.
For related context on what platform control looks like from the iOS side, the DarkSword iOS exploit and what it reveals about Apple’s security architecture is worth reading alongside this. The relationship between platform control and the ad monetisation stack is also relevant – open platforms that become less open tend to become more monetisable.
Enterprise implications
Companies distributing internal Android apps outside the Play Store – internal tools, MDM-enrolled devices, custom line-of-business apps – have a concrete decision to make.
Option one: register with Google’s verification program. Provide ID, pay the fee, upload signing keys. Internal apps then install normally on enrolled devices. This is the lower-friction path for IT-managed fleets where the device baseline is controlled.
Option two: pre-enable the advanced flow on enrolled devices via MDM before the September rollout. This is more complex to deploy but avoids routing internal developer identities through Google’s verification system.
The harder case is BYOD. An employee whose personal device also needs to run internal tools has to either complete the 9-step advanced flow on their own phone or have the company’s app distributed through a verified channel. For organisations that have leaned on APK sideloading as an informal internal distribution method, September is a hard deadline to have a real answer.
What this signals about platform direction
The progression is worth stating plainly. Android has moved from:
“Install from unknown sources” – one toggle in settings, immediate effect, no identity requirement.
To:
Developer registration with ID, fee, and signing key upload required for distribution. Users who want to install unverified software must complete a 9-step process with a 24-hour mandatory delay, buried in developer settings, which Google will not surface during normal installation flows.
That is a significant change in platform philosophy, not just platform mechanics. Samat acknowledged regulatory pressure as a contributing factor: “In a lot of countries, there is chatter about if this isn’t safer, then there may need to be regulatory action to lock down more of this stuff.” That is a reasonable position for a platform operator facing government pressure in multiple jurisdictions.
It is also the kind of argument that does not have a natural stopping point. If the September rollout in Brazil, Singapore, Indonesia, and Thailand reduces malware incidents – and it probably will, because it removes the most impulsive installation vector – the data will support further restrictions. Whether “further restrictions” means tighter verification requirements, shorter bypass periods, or eventual removal of the advanced flow entirely is not determined by the current policy.
The broader pattern of platform consolidation is worth watching in this context. Platforms that control distribution control developer economics. The verification fee is $25 now.
Android is not becoming iOS. The advanced flow exists, it works, and it gives technically capable users a path that Apple does not offer. But the platform that once defined itself against Apple’s control is now managing the same trade-off between openness and safety, making the same choices, and arriving at increasingly similar outcomes.
The gap between Android and iOS just got measurably smaller. That is the thing worth paying attention to – not the 24 hours, but the direction.