Build1 publisher2 min readPublished
F-Droid developer warns Google's ID check will reach every Android install source in 2027
Google's Android developer verification began September 30, 2026 in four countries and covers every install source in 2027, an F-Droid developer reports. Organizations shipping outside Play also need a D-U-N-S number, the one step with a stated wait, at about 28 days.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The check requires a $25 Play Console account plus a government photo ID, according to the email quoted in the post.
- The developer learned of the rollout from a cold email that arrived a week after F-Droid accepted their app.
- F-Droid, the EFF, FSFE and the Software Freedom Conservancy have formed the Keep Android Open coalition to formally oppose the mandate.
- The post proposes a compatibility matrix, early UnifiedAttestation adoption, a microG bug bounty pool, an F-Droid onboarding guide and a regulatory tracker.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision An organization's D-U-N-S application has to begin at least about four weeks before it needs its apps verified, whatever date Google sets for 2027.
- exposure Developers who publish F-Droid apps under a handle would have a government photo ID on file with Google once the 2027 phase reaches F-Droid.
- precedent If the global phase lands as the email describes, distributing an Android app through any channel, Play or not, would require a Play Console account.
The email, as quoted, does not say how a device checks a developer's status or which day in 2027 the global phase begins [2]. Without the date, an organization cannot plan backwards from a deadline. The D-U-N-S wait is the only known lower bound on its lead time [4]. Developers with users in Brazil, Indonesia, Singapore or Thailand are already inside the enforcement window [1].
The author's own argument moves past the paperwork. "But opposition alone won't keep apps installable," the developer wrote [12]. The diagnosis is fragmentation. All de-Googled phones combined hold less than one per thousand of the market [7]. UnifiedAttestation, backed by four ROM vendors including Volla and Murena, is early stage, and banking and digital ID apps still do not work reliably with it [9]. The microG and ReVanced projects exist, yet Play Integrity checks still break many apps [10].
The compatibility matrix is the right first artifact. The post's example entry reads "My app works on /e/OS but breaks on GrapheneOS because of X," and the aggregate would tell ROM maintainers and microG developers which fixes to do first [13]. A shared spreadsheet or repo is cheap to start [13]. It also leaves the mandate untouched. Four of the five asks deal with device compatibility, attestation, Play Services and onboarding; only the regulatory tracker reaches government action, and through it the verification rule [1]. Attestation concerns the device a user runs, while the mandate concerns the developer's identity [3][9].
The post closes on a fork. One track integrates with UnifiedAttestation and works within the system; the other refuses attestation entirely and accepts that banking apps will not work [14]. GrapheneOS argues the Play Integrity API should be regulated out of existence rather than replaced by another system where companies permit their own products while disallowing others [11]. I'd expect most app developers to handle the verification paperwork separately from that fork, because only the paperwork has a date attached [2][4].
What to watch
- Google publishing the 2027 global start date and how a device checks verification on F-Droid and direct APK installs.
- Whether the Keep Android Open coalition's formal opposition narrows the 2027 scope for F-Droid and sideloaded APKs.
- Whether EU DMA enforcement or US antitrust remedies reach the mandate, the actions the proposed regulatory tracker would follow.