Android Developer Verification: Threat masquerading as protection

Original Article ↗ Hacker News Discussion ↗

Scope of Google’s Android Developer Verification (ADV)

  • ADV is described as a Play Services / Play Protect component with system-level privileges that will classify apps and developers as “verified” or not.
  • Verified devs must provide government ID, personal details, and register signing keys; ToS lets Google terminate access and label apps as “malware or harmful” without a precise definition.
  • Some say ADV only changes the install flow (warnings + 24h “advanced flow” and developer mode for unverified apps) and does not delete existing apps or block sideloading outright.
  • Others fear it’s a technical and legal foundation for future blocking of F-Droid, ad‑blockers, and politically disfavored apps.

Malware vs. Security vs. Lock‑in

  • One camp calls ADV “malware” or “trojan” because it’s unremovable, deeply privileged, and primarily serves Google’s control interests rather than user security.
  • Another camp objects to that language as misleading fear‑mongering, arguing it’s a (flawed but real) response to large‑scale phishing and banking malware campaigns.
  • Debate over slippery‑slope: some say history shows dire predictions often don’t reach “the bottom”; others counter that many recent “security” moves did erode freedom (e.g., Chrome extension changes, Play Integrity).

EU Law, Antitrust, and Comparisons to Apple

  • Multiple comments question compatibility with the EU Digital Markets Act and Digital Services Act; some have already filed DMA complaints or contacted regulators.
  • Others argue DMA Article 6(4) allows such measures if “strictly necessary” and user‑controllable, and that ADV is partly to comply with EU rulings on openness.
  • Apple is cited both as precedent (“Google is just catching up to Apple’s walled garden”) and as contrast (“Google is retroactively locking down a platform that was sold as open”).

Impact on Users, Developers, and Alternatives

  • Power users stress Android’s appeal was freedom: sideloading, F-Droid, custom ROMs, personal APKs. If that’s eroded, many would rather accept Apple’s more polished but honestly closed ecosystem.
  • Serious concern about centralization risk: a single Google account ban can wipe email, documents, payments, devices; ADV increases that leverage over developers.
  • F-Droid is criticized for inflammatory tone but also defended as correctly highlighting that Google alone will define “harmful.”
  • Strong interest in alternatives:
    • GrapheneOS (Pixel‑only for now, with upcoming Motorola support) seen as the most secure de‑Googled Android; debates over its strict hardware/security requirements.
    • LineageOS, /e/OS, and other AOSP forks discussed, but many note issues with outdated kernels, firmware, and banking / government ID apps that require Play Integrity.
    • Non‑Android Linux phones (Sailfish, Ubuntu Touch, postmarketOS, PureOS, Mobian) are mentioned, but most agree they’re immature, app‑incompatible, and far less secure than modern Android/iOS.

Proposed Responses

  • Practical suggestions include:
    • Switch to GrapheneOS or other de‑Googled ROMs where feasible.
    • Use ADB installs and avoid Play Services where possible.
    • Support petitions (e.g., keepandroidopen.org) and file regulatory complaints, especially in the EU.
    • Pressure banks and governments to support web‑based and hardware‑token authentication instead of App‑Store‑locked ID apps.