Android still lets you sideload—after Google verifies who wrote it.

Google is introducing developer verification for apps installed on certified Android devices. Its current documentation says that, from 30 September 2026, the first enforcement phase will apply in Brazil, Indonesia, Singapore and Thailand through a defined set of participating app stores. The company says a global rollout across all installation sources is planned for 2027.

That schedule matters because the headline can easily become ‘Android bans sideloading’. The first phase is narrower. Google’s developer FAQ says direct sideloading and stores outside the initial participating list are not subject to the September requirement. The policy is still a material change: independent distribution moves toward an identity check administered through Google’s platform layer before it can feel frictionless on a certified device.

Package signing is not the same thing as developer verification

Android packages are already signed. A signature helps a device verify that an update came from the same signing key and that the package was not altered after signing. Developer verification adds a different relationship: an app is registered to a developer whose identity has been verified, and Android’s Developer Verifier service checks that registration during installation.

Google describes the system as identity verification rather than an app-content review. That distinction is real, but it does not remove the governance question. When a device must consult a platform-controlled verifier to make an ordinary installation smooth, the platform has gained a new practical role in software distribution—even if an app never entered its store.

The exit is still there, but it is no longer the default path

Google says informed power users can install apps from unverified developers through a one-time advanced flow, and that Android Debug Bridge remains available for development work. Its help pages also say the requirement applies to certified devices; Android Open Source Project builds and non-certified devices are outside this particular rule.

Those exemptions prevent this from being a closed ecosystem in the strictest sense. They do not make the change irrelevant. Most people use certified phones, and the difference between ‘possible with an advanced flow’ and ‘works normally’ determines whether small developers, repair tools, archival software and independent stores remain practical choices for ordinary owners.

Security needs a proportional control

Malware and coercion scams are real problems, and a clear warning or a reputational signal can help people make safer decisions. A proportional system should make those risks legible without treating every independent developer as suspect or requiring users to hand their entire software life to one intermediary.

For now, keep installers and source releases from projects you rely on, record signing fingerprints where a project publishes them, and check what a verification prompt is actually saying before acting. Do not disable a security protection because somebody on a call or message tells you to. The long-term test is simpler: can a device owner still choose independent software without turning routine ownership into a platform permission request?