Android Developer Verification: the mandate has a date, the escape hatch has a mockup

Google announced a policy called Android Developer Verification in August 2025, and the requirement starts in September 2026, first in a group of countries including Brazil, Indonesia, Singapore and Thailand, then globally ^[1][2]. That is roughly thirteen months of notice ^[1], and the two halves of the policy are supported by very different amounts of evidence, which is the thing to sort out before you plan around either. The half with documented substance is the registration requirement. According to the dev.to writeup, it is not limited to apps distributed through Google Play: it applies to all apps installed on certified Android devices, including apps sideloaded from websites, shared as APK files, distributed through F-Droid, internal company tools and hobby projects ^[3]. To make an app installable, a developer must create or use a Play Console account, pay a registration fee of about $25 for a standard account, accept Google's terms without negotiation, submit government-issued identification, prove ownership of the app's signing key, and list all current and all future package names they plan to use ^[4]. Developers who do not register, or who fail verification, have their apps silently blocked by Google Play Protect on certified devices worldwide ^[5]. Google's stated reason is improved security and accountability, to stop repeat malware developers ^[6]. The half with almost nothing behind it is the part attracting the most attention: the advanced flow that is supposed to preserve sideloading for power users. As described in the same writeup, it is nine steps ^[7][2]: developer options, seven taps on the build number, several warning screens including one about coercion, a PIN, a restart, a mandatory 24-hour cooling-off period, more warnings, a choice between seven days and indefinite, and a final confirmation ^[7]. The cooling-off period alone means more than a day passes between a user starting the flow and completing an install ^[3]. That flow has not appeared in any public beta, preview or canary build; it exists in Google's blog posts and mockups ^[9]. It also runs through Google Play Services rather than the core operating system, so Google can modify, tighten or remove it with a server-side update ^[8]. The asymmetry is the story. The binding half has a date and a fee schedule; the mitigating half is a set of screenshots that can be revised without an OS release ^[8][9]. Describing an escape hatch in generous detail costs nothing when the mechanism that implements it is server-side. Read the other interests too. F-Droid's description of the policy as an existential threat ^[10] is informed on mechanism and plainly interested in the outcome, because many of its apps come from anonymous or pseudonymous contributors who cannot or will not submit government ID ^[11]. The writeup's strongest examples are also its most rhetorically useful ones: small regional developers in India and other cost-sensitive markets where sideloading is common ^[12], and dissidents, journalists and activists for whom handing ID to a US company with a history of complying with takedown requests is a safety question ^[13]. Those categories are real, and they are also the categories least likely to describe your release pipeline. The operating consequence: treat the registration checklist as scheduled work and the advanced flow as unbuilt. If you ship internal Android tools, you are in scope ^[3], which means someone owns key-ownership proof and the package-name declaration, including names for apps that do not exist yet ^[4]. Because the failure mode is a silent block ^[5], you will not get a clean install error to alert on, so verification status belongs in your dependency checks rather than your support scripts. Any workflow that assumes a user can sideload a build in one sitting is already broken by the 24-hour wait ^[3], and any workflow that assumes the flow exists at all is betting on a mockup ^[9].