The campaign argues that Google is gradually locking down Android through sideloading restrictions, API lockdowns, Play Integrity attestation, and moving AOSP functionality into proprietary Google Play Services. Each change is individually defensible as a security measure, but collectively they amount to a platform lockdown that makes distributing software outside Google's ecosystem dramatically harder with each release.
Submitted the Keep Android Open campaign to Hacker News where it garnered 1,134 points and 523 comments, indicating strong community agreement. The framing 'Your phone is about to stop being yours' captures the argument that device ownership and user control are being eroded.
The editorial synthesizes the campaign's argument into a convergence thesis: Android is on a trajectory toward iOS-level lockdown, but Google is executing it gradually enough that most users won't notice until it's complete. The editorial notes that the 1,134-point Hacker News score is unusually high for an abstract platform governance issue, suggesting developer frustration has crossed from grumbling into organized resistance.
As described in the editorial, Google has justified each restriction with a specific security rationale: sideloading restrictions protect user safety, API lockdowns enhance privacy, and Play Integrity prevents fraud. The editorial acknowledges these justifications are 'reasonable-sounding' even while arguing the cumulative effect is a lockdown.
A campaign called Keep Android Open (keepandroidopen.org) has surged to the top of Hacker News with over 1,100 upvotes, channeling years of simmering developer frustration into a single, organized call to action. The site catalogs what its organizers describe as a systematic effort by Google to close down Android — the operating system that built its 3-billion-device empire on the promise of openness.
The core argument is simple: Android is becoming iOS with extra steps, and Google is doing it gradually enough that most users won't notice until it's done. The campaign points to a pattern of changes across multiple Android versions — each individually defensible as a security improvement, but collectively amounting to a platform lockdown that would make the Android of 2015 unrecognizable.
The Hacker News score of 1,134 puts this in rare territory. Developer communities don't typically rally around abstract platform governance issues. That this resonated so strongly suggests the frustration has crossed a threshold from grumbling to organized resistance.
To understand the stakes, you need to look at what's actually changing. Over the past several Android releases, Google has progressively restricted sideloading (installing apps outside the Play Store), tightened access to privileged APIs that alternative launchers and automation tools depend on, introduced Play Integrity attestation that lets apps refuse to run on modified devices, and moved core functionality from AOSP (the open-source base) into proprietary Google Play Services.
Each change came with a reasonable-sounding justification. Sideloading restrictions? User safety. API lockdowns? Privacy protection. Play Integrity? Fraud prevention. But the cumulative effect is that building and distributing Android software outside Google's ecosystem is becoming dramatically harder with each release.
For developers, the practical impact is stark: if you ship an Android app outside the Play Store — whether through F-Droid, your own website, or enterprise distribution — every year brings new friction that your users must navigate. Warning dialogs have gotten more aggressive. Permission grants have gotten more restricted. And Play Integrity means even apps that are properly installed can detect and refuse to run on devices that have been modified by their owners.
The custom ROM community — projects like LineageOS, GrapheneOS, and CalyxOS — has been hit especially hard. These projects represent Android's open-source DNA in its purest form: community-maintained forks that strip out Google's proprietary layer and give users actual control over their devices. But as Google moves more functionality behind Play Services and introduces hardware-backed attestation, the gap between AOSP and "real Android" grows wider.
Google's counterargument, stated across various developer blog posts and conference talks, centers on the security tradeoff. An open platform is an exploitable platform. Malware distribution through sideloading is a real problem — Google's own data shows that apps installed from outside the Play Store are significantly more likely to be malicious. Play Integrity helps banks and payment apps verify they're running on unmodified devices, which protects users from sophisticated attacks.
This is where reasonable people disagree. The security benefits are real and measurable. But so is the cost: a platform where the device owner is no longer the highest-privilege user isn't really "open" in any meaningful sense — it's a managed environment with a more permissive app store policy.
This isn't happening in a vacuum. The Keep Android Open campaign arrives during a period of intense regulatory scrutiny of mobile platform gatekeeping worldwide. The EU's Digital Markets Act has forced both Apple and Google to make concessions on alternative app distribution. The US DOJ's antitrust case against Google includes allegations about Android's competitive moat. South Korea and Japan have passed or are considering legislation requiring sideloading support.
The irony is sharp: regulators are pushing for more openness at exactly the moment Google is engineering less of it into the platform's technical foundations. Compliance with the letter of new regulations while undermining their spirit through UX friction and technical barriers is a playbook that Apple has already tested with iOS sideloading in the EU — and Google appears to be studying those notes carefully.
For the open-source community, this represents an existential question about what AOSP actually means. The Android Open Source Project was always a strategic tool for Google — a way to commoditize mobile OS development and build market share against iOS. But as Android's market share has plateaued near 75% globally, the strategic calculus has shifted. Google no longer needs AOSP to win the market; it needs Play Services to monetize it. Every piece of functionality that moves from AOSP to Play Services is a piece of Android that stops being open source in practice, even if it technically remains available.
If you maintain an Android app, the immediate question is whether your distribution strategy depends on capabilities that are being deprecated or restricted. A few concrete areas to audit:
Sideloading and enterprise distribution: If you distribute APKs outside the Play Store — for beta testing, enterprise deployment, or as your primary channel — test your installation flow on the latest Android versions. The friction is increasing, and some of your users may already be seeing scary-looking warning dialogs that they don't know how to dismiss.
API access: If your app uses accessibility services, device admin APIs, or other privileged interfaces, check the deprecation timeline. Google has been steadily narrowing what these APIs can do, and several capabilities that power tools, automation apps, and alternative launchers have been removed or restricted.
Play Integrity: If you've implemented Play Integrity checks (or are considering them), understand that you're participating in the lockdown ecosystem. Every app that refuses to run on unlocked bootloaders or custom ROMs makes those platforms less viable — which in turn reduces the competitive pressure on Google to keep Android open. There's a collective action problem here: Play Integrity is individually rational for any app handling sensitive data, but collectively corrosive to the open platform that made Android valuable.
For teams building developer tools, the shift has implications beyond Android itself. The pattern of a platform provider gradually reclaiming control from its ecosystem is one of the oldest dynamics in tech. If your tooling depends on platform openness — whether that's Android, web APIs, or cloud provider interfaces — watching how this plays out is directly relevant to your own risk calculus.
The Keep Android Open campaign is unlikely to reverse Google's trajectory through moral suasion alone. The real leverage points are regulatory (where the momentum is actually favorable) and market-based (where it's not — most users don't care about sideloading). But the campaign serves a crucial function: it creates a public, organized record of what's being lost and who it affects. For developers who built businesses and tools on the promise of an open Android, that record matters. The platform that got to 3 billion devices by being the open alternative is choosing to become a more polished walled garden — and the developers who made that ecosystem valuable deserve to have a say in whether that's the right trade.
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