The campaign argues that Google's Play Integrity API creates a de facto ban on sideloading by giving every app developer tools to reject non-Play-Store installs, even though Android technically still permits it. They frame this as a betrayal of Android's open-source roots, noting that unlocked bootloaders — required for privacy-focused ROMs like GrapheneOS — trigger automatic integrity failures.
The editorial highlights that Google can technically claim Android supports sideloading while the practical reality is that banks, streaming services, and enterprise tools all independently refuse to run on sideloaded or bootloader-unlocked devices. The API doesn't block sideloading — it delegates the blocking to individual app developers, creating a distributed enforcement mechanism that's harder to regulate.
The campaign explicitly calls on Google to comply with the DMA, which designates Google as a gatekeeper and requires it to allow third-party app stores and sideloading without degrading the user experience. They argue that enabling apps to discriminate based on install source violates the spirit and likely the letter of EU regulation.
The editorial breaks down the three verdict levels (BASIC, DEVICE, STRONG integrity) to show that when a banking app requires MEETS_DEVICE_INTEGRITY, it isn't just checking for malware — it's verifying bootloader lock status and Google certification. This bundles legitimate security concerns with platform lock-in, punishing users of custom ROMs and privacy-focused Android forks regardless of their actual security posture.
The campaign at keepandroidopen.org has surfaced on Hacker News with a score of 625, rallying developers and users against what it frames as the slow death of Android's openness. The core target: Google's Play Integrity API (formerly SafetyNet Attestation), which allows any app developer to verify whether an app was installed through the Google Play Store, whether the device bootloader is locked, and whether the OS is a Google-certified build.
The Play Integrity API doesn't block sideloading at the OS level — it gives every individual app the tools to refuse to run if you sideloaded it. That distinction matters. Google can claim Android still supports sideloading while the practical reality is that your bank app, your streaming service, and increasingly your enterprise tools all independently reject non-Play-Store installs.
The campaign calls on Google to honor the spirit of Android's open-source roots and comply with the EU's Digital Markets Act (DMA), which designates Google as a gatekeeper and requires it to allow third-party app stores and sideloading without degrading the user experience.
Play Integrity API returns three verdict levels to requesting apps:
- MEETS_BASIC_INTEGRITY: The device might be real but could be rooted or running a custom ROM. - MEETS_DEVICE_INTEGRITY: The device runs a Google-certified Android build with a locked bootloader. - MEETS_STRONG_INTEGRITY: The device has received a security update within the last year and passes hardware-backed attestation.
When a banking app requires `MEETS_DEVICE_INTEGRITY` or higher, it's not just checking for malware — it's verifying that you haven't unlocked your bootloader, installed a custom ROM, or obtained the app outside Google's ecosystem. An unlocked bootloader, which is a prerequisite for running LineageOS, GrapheneOS, or any privacy-focused Android fork, triggers an automatic integrity failure for apps that check.
Google has progressively tightened this. The migration from SafetyNet to Play Integrity in 2023 was pitched as a security improvement, but it also expanded the attestation surface. The newer Play Integrity "standard" requests shifted from server-side checks to on-device evaluation, making the verdicts harder to spoof and reducing the window for workarounds like Magisk's MagiskHide or its successors.
For developers, the API is trivial to integrate — a few lines of code in your app's startup flow. Google provides the infrastructure; you just decide which verdict level to enforce. That low friction is exactly the problem: there's almost no cost to adding the check, and legal/compliance teams at large companies default to requiring it.
The reflexive reaction is that this only affects custom ROM users — a tiny minority. That framing misses the structural shift.
Play Integrity is a platform tax on every alternative distribution channel. F-Droid, the open-source app repository, can distribute APKs just fine — but if those APKs call Play Integrity and the install source isn't Google Play, the app may degrade or refuse to function. Enterprise IT teams distributing internal apps via MDM (Mobile Device Management) increasingly hit integrity check failures when devices don't meet Google's attestation bar.
The EU's Digital Markets Act was supposed to address this. Under DMA Article 6(4), gatekeepers must allow sideloading and third-party app stores without imposing "disproportionate" conditions. But the enforcement gap is enormous. Google can argue that Play Integrity is a developer tool, not a platform restriction — individual app developers choose to use it, Google just provides the API. This is the same architectural pattern we've seen with Apple's App Tracking Transparency: the platform provides a mechanism that technically preserves choice while structurally guaranteeing a specific outcome.
The keepandroidopen.org campaign is attempting to close that gap by mobilizing public pressure alongside regulatory enforcement. Whether that works depends on whether the European Commission views Play Integrity as a de facto sideloading barrier or accepts Google's framing of it as a neutral security tool.
If you're an Android developer, Play Integrity creates a decision tree you probably haven't thought through:
If you distribute only through Google Play, integrity checks are free insurance. Your compliance team wants them, they're easy to add, and they filter out a class of abuse vectors. The incentive to add the check is strong and the cost is near zero.
If you distribute through multiple channels (Play Store + F-Droid + direct APK + enterprise sideload), Play Integrity becomes a compatibility minefield. You need to either skip integrity checks for non-Play installs (which defeats the purpose) or accept that your non-Play users will hit friction. Some developers solve this by degrading gracefully — showing warnings instead of hard blocks — but banking and DRM-heavy apps rarely have that option.
If you build for custom ROM users (privacy-focused apps, security tools, developer utilities), you're fighting the attestation system. Projects like Shamiko and Zygisk attempt to hide root and bootloader status from integrity checks, but it's a cat-and-mouse game. Google's shift to hardware-backed attestation makes software-level bypasses increasingly unreliable.
The practical advice: if your app's threat model doesn't specifically require device attestation, don't add Play Integrity checks just because you can. Every integrity check you add is a vote for a closed ecosystem, and it cuts off users who have legitimate reasons to run modified Android builds — including security researchers, enterprise IT, and developers themselves.
For mobile teams, audit your Play Integrity usage. Are you checking `MEETS_DEVICE_INTEGRITY` because your security team asked for it, or because your threat model requires it? Most apps that aren't handling financial transactions or DRM content don't need hardware attestation. A `MEETS_BASIC_INTEGRITY` check filters out emulators and obvious abuse without locking out custom ROM users.
For teams distributing outside Google Play, start testing your apps on devices that fail integrity checks. If your app degrades or crashes when Play Integrity returns a negative verdict, you have a bug — not a security feature. Build fallback paths.
For anyone relying on Android's openness as a platform differentiator versus iOS, recalibrate your assumptions. The gap between Android and iOS in terms of practical sideloading freedom is narrowing faster than most developers realize. If your business model depends on Android being the 'open' alternative — whether for alternative app stores, enterprise distribution, or reaching users in markets where Play Store access is restricted — the Play Integrity API is the single biggest threat to that assumption.
The keepandroidopen.org campaign represents an interesting inflection point: a coordinated, technically literate push-back against platform lock-in that's happening in parallel with EU regulatory enforcement. The DMA's teeth are still being tested — the European Commission opened proceedings against Google over app store practices in 2025, and Play Integrity could become a central exhibit. But regulatory timelines move in years, and API adoption moves in months. By the time the Commission issues a ruling, the ecosystem may have already calcified around Play Integrity as the default. The window for developer action — choosing not to add unnecessary attestation checks, supporting alternative distribution channels, and vocally supporting campaigns like this one — is now, not after the regulators finish deliberating.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.