Sideloading becomes a registered activity: budgeting for Android's September 2026 deadline

Google announced a policy called Android Developer Verification in August 2025, and according to a dev.to explainer the requirement starts biting in September 2026, first in Brazil, Indonesia, Singapore and Thailand, then globally ^{[1] [2]}. It matters because the stated scope is not Play Store distribution: the same account says it covers every app installed on a certified Android device, including sideloads from a website, APKs passed around by file, packages served through F-Droid, internal company tools and hobby projects ^[3].

That is roughly thirteen months of runway from announcement to the first enforcement wave ^[1], and the checklist is not a form you fill in on the last afternoon. Per the same write-up, a developer must hold a Google Play Console account, pay a registration fee of about $25 with possible extras, accept Google's terms without negotiation, submit government-issued photo identification such as a passport, driver's licence or national ID, prove ownership of the private key used to sign the APKs, and list all current and all future application package names they intend to use ^[4]. The identity step is the one to route through legal early, because it attaches a named human or entity to what used to be an anonymous build artifact. The package-name step is the one that collides with how teams actually work: you are asked to declare a namespace before the roadmap that fills it exists.

Failure is described as quiet rather than loud. Apps from unregistered or failed-verification developers will be silently blocked by Google Play Protect on certified devices worldwide, according to the account ^[5]. Google's stated reason for all of this is improved security and accountability, aimed at repeat malware developers ^[6].

There is an escape hatch for power users, and it is worth reading as a support-cost line item. The advanced flow, as documented in the write-up, runs nine steps: open developer options, tap the build number seven times, dismiss multiple warning screens including one about coercion, enter the device PIN, restart, wait a mandatory 24-hour cooling-off period, dismiss more warnings, choose a temporary seven-day or indefinite allowance, then confirm again ^[7]. Nine steps ^[2] and a hard floor of more than 24 hours between a user starting the process and installing your build ^[3]. The same source notes the flow runs inside Google Play Services rather than the core operating system, meaning it can be tightened or removed by a server-side update ^[8], and that as of writing it has not appeared in any public beta, preview or canary build, existing only in blog posts and mockups ^[9]. You cannot test your install instructions against something that has not shipped.

F-Droid has called the policy an existential threat, per the same account, because many of its contributors are anonymous or pseudonymous and cannot or will not submit government ID ^{[10] [11]}. The write-up also flags sideloading-heavy markets such as India, and journalists and activists for whom handing ID to a US company carries a different risk profile ^{[12] [13]}.

Watch for the country list after the first four, for the advanced flow appearing in a shipping beta, and for whatever mechanism covers enterprise internal distribution, which this source does not describe. Note also that this is one dev.to account of the policy, not Google's own text.