70 days until Android locks down sideloading — what devs need to know

What happened

Google is rolling out mandatory developer verification for Android apps, and keepandroidopen.org has turned the countdown into a rallying cry: roughly 70 days until the first wave takes effect. The policy, first announced in August 2025 and clarified through 2026, requires every developer distributing an Android app — including through sideloading and third-party stores — to register a verified legal identity with Google. Starting with the certified-device rollout, Android will refuse to install apps whose developers haven't been identity-verified by Google, regardless of where the APK came from.

The mechanics are mundane but the implications are not. Developers must submit a government ID (or a D-U-N-S number for organizations), link it to the package name of each app they ship, and accept that Google can revoke that linkage. The verification is not a Play Store listing requirement — it is a *device-side* requirement enforced by the OS. An unverified APK, signed by an unverified developer, will fail to install on a stock certified Android device even if you side-load it manually, even if you're a developer flashing your own build to your own phone (hobbyist devs get a narrower exemption tied to a limited device set).

The HN thread that pushed keepandroidopen.org to 373 points framed it bluntly: this is the end of Android-as-Linux. The platform that for 15 years let you install whatever you wanted — the one feature that genuinely distinguished it from iOS — is being retrofitted into something closer to iOS with worse defaults.

Why it matters

The official justification is malware. Google's data shows that sideloaded apps are 50x more likely to be malicious than Play Store apps, and the company frames verification as a lightweight analogue to code-signing on desktop. That framing is partially true and completely insufficient. Code signing on macOS and Windows attaches a cryptographic identity to a binary; it does not require the OS vendor to approve, by name, every person who ships software. Google's policy does.

The practical consequences fall across three groups that the Play Store historically pushed out of its own ecosystem. F-Droid, which distributes thousands of open-source apps built reproducibly from source, cannot verify every upstream maintainer's government ID — that was the whole point. Hobbyists who publish a weekend project under a pseudonym, or in a country where linking your real name to a political-adjacent app is risky, lose their distribution channel entirely. Security researchers who ship tooling that Google would prefer not exist — frida gadgets, root detection probes, carrier-API inspectors — now have a named identity on file with the vendor whose protections they're probing.

The counter-argument from the policy's defenders is that Google isn't *reviewing* apps, just verifying developers. That distinction erodes the moment Google uses the verification registry to enforce content policy — which it already does on Play, and which there is no technical reason it won't extend device-wide. The lever exists; the lever will be pulled. The HN consensus, running strongly in favor of the opposition, is that the "we're only checking IDs, not content" framing is the same disclaimer every platform has used before the second shoe drops.

There's also a jurisdictional problem the policy doesn't address. A developer in a country Google doesn't operate in cannot verify. A developer under US sanctions cannot verify. A developer who runs afoul of Google for *any* reason — the Play Store ban rate for small developers is already infamous — loses the ability to publish Android software at all, not just the ability to list on Play. One account suspension becomes a lifetime ban from the platform.

What this means for your stack

If you ship a user-facing Android app, nothing changes in the short term — you were going to verify anyway. The pain lands on everyone adjacent: internal tooling teams distributing APKs to employees, open-source maintainers whose users sideload, and anyone whose business model depends on an Android install path that doesn't route through Mountain View.

Enterprise MDM-managed devices get an exemption, which solves distribution for F500 fleets but not for the SMB and prosumer market. If you ship a developer tool, a debugging aid, or an app that competes with a Google product, your realistic options are now: (1) verify and accept that your continued presence on the platform is contingent on Google's good opinion, (2) ship a web app and give up native capability, or (3) target a non-certified Android fork — GrapheneOS, LineageOS, de-Googled builds — and accept the market-size hit.

Security teams should re-examine their threat models. A verified-developer registry is a juicy target: compromise one high-trust developer identity and you can push malicious updates to a verified-trust channel. The attack surface Google is introducing to close the "anonymous APK" vector is a centralized identity database tied to signing authority — exactly the kind of thing adversaries build operations around for years before using. Watch for the first supply-chain incident that routes through a verified-but-compromised developer; the policy's security math will look different the morning after.

For the open-source community, the actionable move is pressure *now*, during the 70-day window, before the first certified-device cohort flips the enforcement bit. Keepandroidopen.org, the EFF filing, and the F-Droid position paper are the three live focal points. After rollout, reversing a shipped OS-level enforcement is historically much harder than preventing one.

Looking ahead

The long arc here is familiar: every open platform eventually gets a trust layer bolted on, and the trust layer eventually gets used for things trust layers weren't sold as doing. Android had a 15-year run as the only mass-market computing platform where you could install software without asking permission; that run ends in about 70 days unless the policy is pulled back. The replacement isn't iOS — iOS was always this way, and users opted in. The replacement is iOS with a decade of unprotested backsliding, dressed as a malware countermeasure. Senior devs who care about where the next generation of hobbyist developers come from should notice: the platform that produced them is being quietly closed.