F-Droid's advisory formally classifies Developer Verification as malware under its own working definition — software installed without informed consent via Play Services updates, non-removable on Google-certified devices, and used to gate the functionality of unrelated apps. Publishing this under the `adv-malware.html` slug (normally reserved for supply-chain incidents) signals they view Google itself as the threat actor in this case.
Submitted the F-Droid advisory to HN with the framing 'A new Android malware from Google,' endorsing F-Droid's classification. The 1514-point score and 628 comments indicate broad developer-community resonance with the malware framing.
F-Droid's distribution model rests on anonymous, reproducible builds signed by the project rather than individual developers — there is no legal entity Google can attach a passport scan to for `org.fdroid.fdroid`. The verification requirement therefore doesn't just inconvenience F-Droid; it structurally excludes their entire model from stock Android devices.
The advisory notes that CalyxOS and GrapheneOS have both notified F-Droid they will not ship the verification component, consistent with their track record of stripping Play Services entirely. F-Droid presents this as evidence that the only real remedy is leaving the Google-certified Android ecosystem — a path that voids banking apps, Google Pay, and often warranties.
On July 1, F-Droid published a document titled `adv-malware.html` — the URL slug matters, because F-Droid's advisory namespace is normally reserved for supply-chain incidents in packages it distributes. This one is aimed at Google. The advisory formally classifies Android Developer Verification, the identity-attestation layer Google announced in late 2025 and is now rolling out through Play Services updates, as malware under F-Droid's own working definition: software that installs without informed consent, cannot be removed by the user, phones home on a schedule, and gates the functionality of unrelated software.
The mechanism itself is straightforward. Under Developer Verification, every APK that runs on a stock Android device after the enforcement date must be signed by a developer whose legal identity is registered with Google. That includes sideloaded APKs. The verification check happens in Play Protect, which is part of Google Play Services, which is installed on every Google-certified Android device and updates independently of the OS. Users cannot uninstall Play Services on a Google-certified device without unlocking the bootloader and flashing a custom ROM — a path that voids most banking apps, Google Pay, SafetyNet-gated enterprise apps, and, on many carrier-locked models, the warranty.
F-Droid's specific complaint is that its distribution model is built on anonymous, reproducible builds signed by the F-Droid project rather than by individual developers. There is no legal entity in Sofia or Berlin that Google can attach a passport scan to for `org.fdroid.fdroid`. The advisory states that CalyxOS and GrapheneOS have both notified F-Droid that they will not ship the verification component. Neither project has published a formal statement as of this writing, but both have historically stripped Play Services entirely, so the position is consistent with their track record.
The framing here is the interesting part. F-Droid is a project run by unpaid maintainers with a hosting budget south of five figures. Calling a shipping Google product malware is not a rhetorical flourish they use lightly — the advisory namespace has three entries in the last four years, all about compromised upstream projects. Choosing to publish this under `/advisories/` rather than as a blog post is F-Droid saying: this is a security incident, and Google is the actor.
On the technical merits, the malware label is defensible against three of the four criteria in most working definitions. Consent: the rollout ships silently in a Play Services update, not as a user-facing opt-in. Removability: Play Services is a system package on certified devices. Phone-home: verification requires a signed attestation exchange with Google's servers, per-app, on install. The fourth criterion — harm — is where the argument is contestable, because Google's stated harm reduction (making it harder for scam apps to circulate outside the store) is real. Scam APK distribution through Telegram groups and knockoff domains is a genuine problem, especially in Southeast Asia and Latin America where Play Store trust is lower.
But the design chosen for the mitigation is the maximum-scope one. Google could have gated verification on the Play Store trust badge, or on Play Protect's real-time scanner, or on a bloom filter of known-bad signatures. It chose instead to make every developer identifiable to Google as a precondition for their code running on the device — a policy indistinguishable in effect from Apple's notarization requirement, minus Apple's explicit charter as a walled garden. Android has spent 15 years marketing sideloading as the difference between the two ecosystems; Developer Verification quietly ends that difference while preserving the marketing.
The community reaction on Hacker News (1,514 points at time of writing, front page for six hours) is unusually one-directional for an F-Droid story. The top comments are not the usual `but scam apps` counter-argument — they're from developers of paid open-source apps (a Signal contributor, two independent maintainers of self-hosted server clients) explaining why they will not register. The common thread: the registration requires a government ID and a business address, which is a non-starter for hobby projects and a jurisdictional problem for anyone in a country Google doesn't offer Play developer accounts in (currently ~30 countries are excluded).
If you ship an Android app and your distribution isn't already Play Store first, you have about eighteen months to decide which side of this line you land on. The three viable paths after enforcement are: register with Google and accept the identity gate; distribute through a Google-registered third-party store like Aurora or Amazon; or explicitly target the AOSP-fork audience (GrapheneOS + CalyxOS + LineageOS + de-Googled Chinese ROMs), which is real but small — best public estimates put it at 0.1–0.3% of active Android devices.
For F-Droid specifically, the advisory does not announce a shutdown. It announces a shift: F-Droid is likely to become an AOSP-fork-only channel, the same way that alternative browser engines on iOS are technically legal but practically confined to the EU. If you rely on F-Droid distribution for a project — reproducible-build FOSS clients, self-hosted-service companions, network-analysis tools that Play Store rejects — you should assume your audience shrinks by an order of magnitude in 2027 unless you also ship a signed Play Store variant. Several projects (Bitwarden, KeePassDX, NewPipe) have already been quietly adding Play Store listings for exactly this reason.
For enterprise and security teams: the identity attestation is a genuine supply-chain improvement for the median Android user, and if your threat model includes employees sideloading APKs from Telegram, this cuts that vector. But the same mechanism gives Google real-time telemetry on which developers are shipping which apps to which devices — a metadata graph that, per F-Droid's advisory, is now legally reachable via subpoena in any jurisdiction Google operates in. Factor that into your BYOD policy language before the rollout, not after.
The interesting question is not whether F-Droid's malware framing sticks — it won't, in any regulatory sense. The interesting question is whether the EU's Digital Markets Act designation of Android as a gatekeeper platform makes Developer Verification legally reviewable as a self-preferencing mechanism, given that Play-Store-registered apps are exempted from the identity gate that sideloaded apps must pass. That case, if the Commission opens it, would arrive in 2028. Until then, F-Droid's advisory is the loudest signal from the FOSS ecosystem that the era of `adb install anything.apk` on a stock device is ending — and the maintainers who built the alternative to the Play Store are the first to say so out loud.
Android users need to switch to Graphene.Someone needs to create a Linux based mobile OS foundation - Google's domination is contrary to many large companies interests, and if Meta and many other such companies were approached, they may well donate large sums of money in their own strategic int
I understand the frustration (I'm an avid fdroid user across many many devices). But this article comes off as childish with the virus/trojan/"malware vendor".With such an article, many (including perhaps google) get the ammo to disregard what fdroid says, by branding them a
I use Android because it lets me install whatever I want on my phone, which it does not seem to me, controversial. The phone is either mine or it is not. I don't want Google's protection. Particularly, if I can't refuse it.
> In computing, a trojan horse or trojan is a kind of malware that misleads users as to its true intent by disguising itself as a normal program. [1]Google is Trojans all the way down. What is the true intent of almost every Google product? Data harvesting.Every single product is spyware of some
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
It doesn't solve the current issue, but in case we don't manage to push back on this, some people might not know that there are various actual linux OSes for mobile:- SailfishOS: still linux based and seems fairly community inclusive, but the UI part of the stack is closed source. Is the o