The campaign argues that Google's Play Integrity API has become a chokepoint that excludes devices with unlocked bootloaders, custom ROMs, or sideloaded apps from running mainstream applications. Their tagline — 'Your phone is about to stop being yours' — frames this as a consumer rights issue where Google is converting an open platform into a controlled one by making third-party attestation the default gatekeeping mechanism.
Submitted the Keep Android Open campaign to Hacker News where it received 1,236 upvotes and 573 comments, indicating strong community resonance. The massive engagement suggests the developer community broadly shares the concern that Google's tightening of Play Integrity checks is an existential threat to Android's open ecosystem.
The editorial argues that while the gap between AOSP and Android-the-Google-product has been widening for over a decade, Play Integrity is categorically different from previous restrictions. Previously, running a custom ROM meant losing access to Google's own services like Maps and Gmail; now it means banking apps, streaming services, and games actively refuse to run — a shift from 'you lose Google extras' to 'your device is excluded from the broader app ecosystem.'
The editorial highlights that Android's openness attracted an entire ecosystem — LineageOS, GrapheneOS, CalyxOS, F-Droid, and enterprise developers distributing APKs directly — all of which depend on the ability to run modified Android without penalty. As more app developers adopt Play Integrity as a default check rather than an edge case, these communities face a future where their devices are functionally incompatible with mainstream software.
A campaign called Keep Android Open (keepandroidopen.org) has emerged to push back against what its organizers describe as Google's systematic dismantling of Android's open-source foundations. The campaign's tagline — "Your phone is about to stop being yours" — landed on Hacker News with over 1,200 upvotes, one of the highest-scoring posts of the week, signaling deep frustration across the developer community.
The core grievance is specific and technical: Google's Play Integrity API — the successor to SafetyNet Attestation — has become the chokepoint through which Google is exerting control over what was supposed to be an open platform. Play Integrity API allows any app developer to query Google's servers and receive a verdict on whether a device meets Google's definition of "integrity" — and that definition increasingly excludes phones with unlocked bootloaders, custom ROMs, or sideloaded apps.
This isn't theoretical. Banking apps, streaming services, and even some games already refuse to run on devices that fail Play Integrity checks. What's changed is the scope and enforcement: Google has been tightening what counts as a "passing" device, and more app developers are adopting the API as a default rather than an edge case.
Android's origin story is inseparable from openness. The Android Open Source Project (AOSP) was Google's answer to Apple's walled garden — a Linux-based mobile OS that anyone could fork, modify, and distribute. That promise attracted an ecosystem: custom ROM communities (LineageOS, GrapheneOS, CalyxOS), alternative app stores (F-Droid), and enterprise developers who distribute APKs directly to managed devices.
The gap between AOSP-the-open-source-project and Android-the-Google-product has been widening for over a decade, but Play Integrity represents an inflection point. Previous restrictions were additive — you lost Google Maps, Gmail, the Play Store. Now the restrictions are subtractive: third-party apps can actively reject your device based on Google's attestation, even if those apps have nothing to do with Google.
The mechanism is worth understanding. When an app calls Play Integrity, Google's servers evaluate the device and return one of several verdicts: `MEETS_BASIC_INTEGRITY`, `MEETS_DEVICE_INTEGRITY`, `MEETS_STRONG_INTEGRITY`. A phone with an unlocked bootloader — the first step toward any custom ROM — typically fails `MEETS_DEVICE_INTEGRITY`. A rooted phone fails everything. The app developer then decides what to do with that verdict, but Google controls the rubric.
This creates a two-sided lock-in. Users who want to control their own hardware lose access to apps. Developers who want to distribute outside the Play Store find their apps running on devices that fail integrity checks for other apps, creating a degraded ecosystem. The net effect is that Google doesn't need to ban sideloading outright — they just need to make the sideloaded experience bad enough that users stop trying.
The timing matters too. The Epic v. Google ruling in late 2023 found that Google maintained an illegal monopoly over Android app distribution. Google was ordered to open up the Play Store to competing app stores. But critics argue that Play Integrity undermines the spirit of that ruling: even if you can install a competing app store, apps from that store can still be flagged as lacking "integrity" because they weren't installed via Play.
The Hacker News discussion reflects a community that has watched this trajectory for years and is hitting a tipping point. Comments from developers who ship Android apps describe a Kafka-esque reality: their legitimate apps get flagged, their users on custom ROMs report failures, and the appeal process routes through Google's opaque review system. Privacy-focused ROM developers describe Play Integrity as an existential threat to their projects.
If you distribute Android apps exclusively through the Play Store and target mainstream consumer devices, the immediate impact is minimal — Play Integrity is working as Google intends for your use case. But "minimal" isn't "zero": you're building on a platform where the vendor can unilaterally redefine what constitutes a valid device.
If you distribute via direct APK, F-Droid, or enterprise MDM, the situation is more urgent. Test your app on devices with unlocked bootloaders and custom ROMs now — not because those are your primary audience, but because Play Integrity failures cascade in ways that affect your error handling, analytics, and user support pipeline. Apps that call third-party SDKs (payments, DRM, analytics) may inherit Play Integrity checks you didn't explicitly add.
For enterprise and B2B developers, this is a fleet management concern. Companies that deploy custom Android builds for kiosks, POS systems, or field devices may find that upstream dependencies start failing integrity checks. Audit your dependency tree for Play Integrity calls — the `com.google.android.play.core` library is the primary vector.
If you maintain a custom ROM or privacy-focused Android fork, the Keep Android Open campaign is directly relevant. The practical question is whether enough developer and regulatory pressure can slow Google's trajectory before the alternative Android ecosystem becomes unviable.
Consider supporting open attestation alternatives. Projects working on device attestation that doesn't route through a single vendor's servers represent the technical path forward — though none have the adoption to matter yet.
The Keep Android Open campaign arrives at a moment when the definition of "open source" is being stress-tested across the industry — from Redis and HashiCorp relicensing their projects, to WordPress's governance crisis, to this fundamental question about whether an open-source operating system can remain meaningfully open when one company controls the attestation layer. Google will likely frame Play Integrity as a security feature protecting users from tampered devices. The developer community will frame it as platform capture wearing a security costume. Both are partially right, but the asymmetry of power — Google sets the rules, everyone else adapts — means the burden of proof should be on the company extracting control, not the users losing it. The 1,200+ HN upvotes aren't a petition. They're a leading indicator.
Someone here on HN used the term "cloud terminal" for modern electronic devices, and I think that is a very fitting name for phones and tablets. They are definitely not computers because they do not actually give the user access to general purpose computing in the sense that the users can
Let me play out a scenario, imagine to use a Desktop Hardware like a complete built rig, you would need a specific OS like Windows 11 and you could not run Linux on it, just because it's a vendor lock-in.Why is this acceptable for phones but would not for the case above?I know a lot of people d
This is the most important part:>> DevelopersDo not sign up. Don't join the program by signing up for the Android Developer Console and agreeing to their irrevocable Terms and Conditions. Don't verify your identity. Don't play ball.Google's plan only works if developers com
To be sincere, they were never truly ours. A proof of that is they were able to come up with this, and you don't have a way to reject it.What we actually need are (open) alternatives, not to double down on Google's ecosystem and Google-controlled OS. We need to control the device we bought
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Respectfully, I think this is the wrong fight. And I fear it may be counter-productive, because all the effort put into asking Google to make it a little less painful to install an unverified app is not put into the real fight.IMHO, it should be fine for Google or Apple to do whatever they want with