F-Droid posted a piece on 1 July 2026 titled "What We Talk About When We Talk About Malware" that frames Google's mandatory Android Developer Verification (ADV) as "a trojan horse… runs surreptitiously in the background as a system service with full root privileges." That is a polemical frame, and it is also substantially correct on the facts that matter. On 30 September 2026, every app installed on a certified Android device in Brazil, Indonesia, Singapore, and Thailand must be registered by a developer who has paid Google, surrendered government-issued identification, signed the Android Developer Console Terms of Service, and handed over the signing keys for every app they have published or will ever publish. If the developer does not comply, the app gets silently blocked on every certified device in those four countries. Global rollout is scheduled for "2027 and beyond." F-Droid's claim is accurate: the policy as written is what the "existential" label describes. The original take is this: the security argument is real, but it is also being used to lock in a position that security alone does not justify, and the four-country phasing is a tell about which side of that trade-off Google is betting on.
The policy, on Google's own terms
Google announced the developer-verification regime in August 2025 on the Android Developers Blog, in a post by Suzanne Frey, VP of Product for Android. The framing was security: "We've seen how malicious actors hide behind anonymity to harm users by impersonating developers and using their brand image to create convincing fake apps. The scale of this threat is significant: our recent analysis found over 50 times more malware from internet-sideloaded sources than on apps available through Google Play." The mechanism is an "ID check at the airport" — Google confirms who the developer is, separately from any review of the app's content. The rollout begins in September 2026 in Brazil, Indonesia, Singapore, and Thailand, with global rollout to follow.
The four countries are not random. Brazil is Google's largest LatAm market. Indonesia and Thailand are the two largest Android markets in Southeast Asia, where the installed base is heavily weighted toward devices that came pre-loaded with sideloaded or third-party-store apps (a pattern that grew during the 2018-2022 period when low-end devices shipped with limited Play Store access). Singapore is the regulatory test market Google frequently uses for new policies because of its high rule-of-law score and predictable court system. Choosing four markets that are simultaneously growth markets, mobile-first markets, and underrepresented-in-Play markets is the move that lets Google claim the policy is targeting "regions specifically impacted by fraudulent app scams" while phasing it in where the displacement from F-Droid, Aptoide, and direct APK distribution will do the most damage to the open distribution ecosystem and the least damage to Play Store revenue.
The "escape hatch" is a nine-step procedure behind a 24-hour cooling-off wall
Google has said repeatedly that "power users" can still install unverified apps — the official escape hatch is a developer-options flow that lets a user disable verification on their own device. The Keep Android Open coalition (the civil-society site hosting the open letter Google does not want you to find) walked through what that flow actually looks like in practice. Nine steps. Open System Settings, find Developer Options, tap the build number seven times to enable Developer Mode, dismiss a coercion-warning screen, enter your PIN, restart the device, wait 24 hours, come back, dismiss more warning screens, then choose "allow temporarily" (7-day TTL) or "allow indefinitely." For installing software on a device you already own. Worse, the entire flow runs through Google Play Services, not the Android OS proper — meaning Google can tighten, modify, or kill it at any time without an OS update and without user consent. And as of the Keep Android Open site's July 2026 reading, this flow had not shipped in any beta, preview, or canary build. It exists as a blog post and a mockup.
That detail matters. The escape hatch is the entire policy's defense against the "Google is becoming a gatekeeper" critique, and the escape hatch does not exist yet in shipping code. For a hypothetical Brazilian F-Droid maintainer whose users will lose access to the client on 30 September, the official answer is to wait for a Google Play Services update that may or may not ship before then, that may or may not preserve the temporarily-vs-indefinitely distinction, and that Google can change unilaterally afterward. That is not an escape hatch. That is the absence of a commitment.
The Terms of Service clause Google does not want you to read
The F-Droid post quotes clause 6.5 of the Android Developer Console Terms of Service: "If You violate any of the Terms or if You distribute malware or other harmful applications, Google may terminate Your access to the ADC…" The concern F-Droid raises, and which the post's framing makes stick, is the absence of a definition of "malware" anywhere in the document. With no defined standard, the clause reads: malware means whatever Google says it means. F-Droid points to precedent: Google Play has already banned ad blockers and, in some cases, classified them as malware. The logical extension, which F-Droid states explicitly, is that the same discretion applied to developer accounts in the broader ADC could one day mean that ad-block developers, encryption tool authors, VPN maintainers, or any class of software Google disapproves of can be retroactively designated as malware distributors and have their developer accounts terminated. Once terminated, every app they have ever signed is blockable across every certified device in the affected regions.
This is the part that the Google announcement does not address. The August 2025 post defines the problem (malware, impersonation, repeat offenders) and the mechanism (identity verification), but does not constrain what counts as a violation. The asymmetry between "we are verifying identity, not content" (the August post's stated scope) and "we can terminate for distributing malware, defined as anything we say is malware" (the ToS clause) is the gap that makes F-Droid's framing not a stretch.
The petition and what "overwhelming opposition" actually looks like
The Keep Android Open open letter is signed by 71 organizations from 23 countries, including the EFF, FSF, FSFE, ACLU, KDE, GNOME Foundation, Tor Project, GitHub Store, Vivaldi, Tuta Mail, Codeberg, the App Fair Project, and the Brazilian, Taiwanese, French, and Norwegian digital-rights coalitions. The accompanying petition passed 100,000 signatories. That is an unusually broad coalition for an Android-policy fight; F-Droid's coalition politics have historically been narrower (free-software circles), and the breadth here is itself the news. The EFF's framing on the site is the most quotable version of the critique: "identity-based gatekeeping is a censorship tool, not a security one." Cory Doctorow called it "Darth Android" — the same author who named "adversarial interoperability" and "right to repair" as the policy frames of the last decade is naming this one too.
The HN thread on the F-Droid post (item 48755965, 919 points, 385 comments within roughly 24 hours of submission) is not the same audience as the petition signers but lands in similar places. The most-upvoted comments are not about malware or sideloading convenience; they are about precedent. The framing that recurs at the top of the thread is: if Google can retroactively lock down devices that were sold as open, every hardware manufacturer is watching, and the principle being established is that the company that built your device gets to decide, after you bought it, what software you are allowed to run. That is a hardware-ownership argument dressed up as a software-policy one, and it is the version of the critique that scales beyond the developer audience. The 30 September date is a 90-day countdown from when the open letter launched; the petition is timed to land before the rollout begins.
Where Google is right
The security argument is not made up. Sideloaded APKs are a real vector for financial-fraud malware in the markets being phased in first, and the Google Play Protect statistics Google cites (50x more malware from internet-sideloaded sources than from Play) come from Google's own telemetry, which has an obvious conflict of interest but is also measuring a real phenomenon. Brazilian banking-fraud statistics, Indonesian SMS-phishing campaigns targeting mobile-banking apps, and Thai scam-app takedowns all predate the ADV program and are part of why FEBRABAN (the Brazilian Federation of Banks) endorsed the policy in Google's announcement. The Developer Verification requirements that Google has run inside Google Play since 2023 are reported (by Google, with the same conflict-of-interest caveat) to have reduced recidivist developer abuse; the August 2025 announcement says Play-side verification has been "helpful in stopping bad actors from exploiting anonymity." Extending the model to non-Play developers is a coherent extension of an existing program.
Identity-based gatekeeping does reduce malware. The question is whether the cost — the chilling effect on hobbyist and independent developers, the political leverage Google gains over every dissident-app or rights-tool author on the planet, the precedent for hardware-vendor control of post-purchase device behavior, the dependency of every Android user on a single foreign corporation's definition of "malware" — is worth the security gain. F-Droid's argument, which the post makes more effectively than the headline frames, is that the cost is being paid by people who are not the beneficiaries. The 580 million people in Brazil, Indonesia, Singapore, and Thailand will get marginally more protection from financial-fraud malware; the global developer community will get a precedent that any platform owner can invoke. The trade-off is real on both sides, and the trade-off is the story.
What this means for you
If you're an Android developer whose app is distributed outside the Play Store:
- The clock starts on 30 September for Brazilian, Indonesian, Singaporean, and Thai users. If your app has any users in those four countries and you do not plan to register with the ADC, those users will lose access — silently, not via an error message. The app will fail to install or fail to launch, depending on which Google Play Services version they have. Plan the comms now, not in September.
- The "hobbyist" account type Google announced is a separate ADC account class, but the Terms of Service apply to it. The distinction is the price and the verification friction, not the obligations. Read the clause about "malware" before you sign.
- For F-Droid specifically: the maintainers have not yet published the failure-mode guide (it was promised in the 1 July post), but the practical alternatives are (a) ship your own auto-updating APK channel that does not depend on F-Droid as the install vector, (b) advise your users to enroll in the developer-options escape hatch before the lockdown, knowing that the flow runs through Google Play Services and may change, or (c) accept that your users in those four countries will need to switch to a non-Android device for your app.
If you are an Android user in Brazil, Indonesia, Singapore, or Thailand:
- Pre-enroll in the developer-options flow before 30 September if you rely on any non-Play app. The flow requires a 24-hour cooldown after you tap through the warning screens; if you do it on 29 September, the cooldown may not clear before the lockdown.
- Back up the data from any F-Droid-installed apps that do not store data in the cloud. The apps may not survive the lockdown in a form that lets you retrieve local state, depending on how the verification layer interacts with already-installed packages.
- The 7-day "allow temporarily" option in the escape hatch is the new default for everyone who has not opted into "allow indefinitely." Expect to re-confirm it every week for any non-Play app you rely on, or enroll in "indefinitely" once you trust the flow.
If you are building for a non-Android platform:
- This is a preview of the policy shape Apple may move toward under pressure from EU DMA enforcement. Apple's existing "notarization" for macOS apps outside the Mac App Store is a lighter version of the same pattern; the EU has already pushed Apple to allow alternative app stores and alternative payment processors, and the next pressure point is alternative-distribution friction. Watch how the September rollout lands before betting that iOS will stay open.
What to do this week
# 1. If you maintain an open-source Android app with users in BR/ID/SG/TH,
# publish a status update before 30 September. The F-Droid post
# promised a guide "in the coming weeks" — if you can't wait for
# it, the minimum useful thing is to tell your users which apps
# will be affected and what the developer-options escape hatch
# looks like on their device. Format: a single markdown page on
# your project site, linked from the README and the GitHub
# releases page, mirrored to Mastodon and Bluesky for reach.
# 2. If you are an Android user in one of the four affected countries,
# enroll in the developer-options flow this week, before the
# September lockdown, and confirm you can install and launch a
# sideloaded APK end-to-end. The flow is nine steps and a 24-hour
# cooldown; you do not want to discover the cooldown on the day
# you need the app.
# 3. If you are a developer anywhere on the platform who has been
# considering signing the Android Developer Console Terms of
# Service "just to be safe," read clause 6.5 (the "malware"
# termination clause) and the absence of a malware definition in
# the document before signing. The clause is enforceable as
# written, and the discretion in it accrues to Google, not to you.
# 4. If you build or fund policy work in any of the four affected
# markets, push your local digital-rights coalition to file a
# competition-authority complaint before 30 September. Brazil's
# CADE and Indonesia's KPPU have both opened Android-related
# competition cases in the last 18 months; the ADV rollout gives
# them a concrete policy artifact to challenge rather than a
# general "Google has too much market share" theory.
What we are deliberately not covering
This post is about the policy, the rollout, and the developer-side response. We are not covering: the long history of Aptoide's competition-law cases against Google (a separate beat, worth a dedicated post); the parallel EU DMA story for iOS (same shape, different platform); the technical mechanics of how the verification layer interacts with already-installed APKs (Google has not documented this publicly, and the speculation in the HN thread is not source-verified enough to ship); or the cryptocurrency-and-VPN-developer response, which is the next layer of the coalition politics and is still being organized. The "this is bigger than Android" hardware-ownership framing from the Keep Android Open site is also worth a longer treatment; the next post in this thread will pick it up.
Related reads
- Godot Banned AI Code. Maintainers Are Done Subsidizing Slop. — open-source maintainers drawing lines on platform-imposed obligations, same week as the ADV rollout.
- GPT-5.6 Sol Adds a US Government Vetting Layer — the LLM-side parallel to ADV: identity-based gatekeeping for AI as a service, with the same FOSS-vs-platform tension.
- .self Wants a LetsEncrypt TLD. Identity Is the Hard Part. — the harder version of the ADV problem at the DNS layer, where identity and registration collide.
Disclosure
Drafted with AI assistance. Primary source: F-Droid, "What We Talk About When We Talk About Malware," 1 Jul 2026 (
https://f-droid.org/2026/07/01/adv-malware.html). Secondary source: Keep Android Open coalition site (https://keepandroidopen.org), including the open letter signed by 71 organizations from 23 countries, the 100,000+ signatory petition, the developer-options escape-hatch walkthrough, and the supporter quotes (EFF, FSF, FSFE, ACLU, KDE, GNOME, Tor Project, Cory Doctorow). Counterbalancing source: Suzanne Frey, "A new layer of security for certified Android devices," Android Developers Blog, 25 Aug 2025 (https://android-developers.googleblog.com/2025/08/elevating-android-security.html), for Google's stated security rationale, the "50x more malware from sideloaded sources" statistic, the four-country rollout timeline (Sept 2026 in BR/ID/SG/TH, 2027+ global), the airport-ID-check framing, and the FEBRABAN / Indonesian Ministry / Thai Ministry / Developer's Alliance endorsements. HN discussion: item 48755965, 919 points and 385 comments at time of writing, front-page submission 2 July 2026. The 580 million affected-user figure is F-Droid's population estimate for the four rollout countries combined; the exact UN population totals are slightly different (F-Droid rounds up). The "100,000+ signatories" figure for the petition is the Keep Android Open site's number as of the post date; the count was rising. The exact ToS clause 6.5 is verbatim from the F-Droid post's quote; the underlying ToS was not directly fetched in this pass. The Cory Doctorow "Darth Android" framing is the coalition site's attribution, not a direct Doctorow publication. The EFF "identity-based gatekeeping is a censorship tool, not a security one" framing is also the coalition site's summary, not a direct EFF publication.
Sources
- The F-Droid post — "What We Talk About When We Talk About Malware," 1 Jul 2026,
https://f-droid.org/2026/07/01/adv-malware.html. Primary source for the "trojan horse" framing, the 4 billion Android devices estimate, the Play Protect vector claim, the ToS clause 6.5 quote ("Google may terminate Your access to the ADC..."), the absence of a malware definition in the ADC Terms, the ad-blocker-as-malware precedent, the "over 99% of Play developers' apps have been registered" auto-opt-in critique, the "hundreds of thousands" petition opposition, the 90% dislike figure on the developer roundtable video, the Gemini summary of the program's reception, the September 30 activation date for Brazil/Indonesia/Singapore/Thailand, and the open-questions list (install behavior, app disablement, data retrieval, telemetry scope). Author: marcprux (F-Droid contributor). - The Keep Android Open coalition site —
https://keepandroidopen.org. Primary source for the 71-organization / 23-country open letter signatory list (EFF, FSF, FSFE, ACLU, KDE, GNOME, Tor Project, GitHub Store, Vivaldi, Tuta Mail, Codeberg, App Fair Project, Forbrukerrådet, FACiL, Molly, ANSOL, Software Liberty Association of Taiwan, Cryptee, Digitale Gesellschaft, Technopolice Bruxelles, Rocky Linux, La Quadrature du Net, Open Rights Group, CryptPad, FULU Foundation, Digital Rights Foundation), the 100,000+ petition signatory count, the developer-options escape-hatch walkthrough (nine steps, 24-hour cooldown, 7-day TTL for "allow temporarily"), the EFF framing ("identity-based gatekeeping is a censorship tool, not a security one"), the Cory Doctorow "Darth Android" framing, the F-Droid "existential threat" quote, and the Ars Technica "Google's Apple envy threatens to dismantle Android's open legacy" headline. The Historical-Employ129 Reddit comment ("600 million malware downloads… their own store is crawling with fake apps and straight up malware", 324 upvotes) and the WaffleMonster Slashdot quote on "sideload as psychological propaganda" are both from the coalition site's curated supporter-quotes section. - The Android Developers Blog announcement — Suzanne Frey, "A new layer of security for certified Android devices," 25 Aug 2025,
https://android-developers.googleblog.com/2025/08/elevating-android-security.html. Primary source for the security rationale ("malicious actors hide behind anonymity"), the "50 times more malware from internet-sideloaded sources" Play Protect statistic, the "ID check at the airport" framing, the rollout plan (Sept 2026 BR/ID/SG/TH, 2027+ global), the Play-side verification precedent ("since we implemented verification requirements on Google Play in 2023"), the separate hobbyist ADC account type, the FEBRABAN / Indonesian Ministry of Communications and Digital Affairs / Thai Ministry of Digital Economy and Society / Developer's Alliance endorsements, and the "developers will have the same freedom to distribute their apps directly to users through sideloading or to use any app store they prefer" framing. - The Hacker News thread — item 48755965, "Android Developer Verification: Threat masquerading as Protection," submitted 2 July 2026, 919 points and 385 comments at time of writing, front-page submission. Primary source for the "hardware-vendor control of post-purchase device behavior" framing that recurs in top comments, the Google-Play-Protect-vs-DEV-policy critique, the "we want Fable"-shaped pattern of cross-cohort frustration with platform owners, and the developer-tools-vs-platform-owner framing that scales the critique beyond the security audience. Numbers on HN are moving as the post ages.
No comments:
Post a Comment