Forty-eight hours. That's how long a two-person app studio had between finding out Google changed how background processes work and their app's reviews dropping to one star because notifications stopped arriving.
And that's the thing Daniel's poking at this week. He's been thinking about the gap between what Android claims to be and what developers actually experience when the core shifts underneath them.
Right. Daniel's prompt is a big one. He says we've covered rooting and the attestation layer, but there's this long-running tension between open-source Android developers and the platform itself. There are websites with names like Android Killed My App and Google Killed My App, documenting breaking changes that landed without meaningful notice. He points out that Google has a legitimate interest in maintaining the core, but developers feel the process lacks rigor and consultation. He notes that Samsung and OnePlus have their own spins on Android, but they're still downstream of the core. So his questions are: how is that core actually maintained and updated, to what extent does Google consult developers before making cascading changes, is Android a Google fiefdom that's take-it-or-leave-it, and is the device flexibility argument becoming illusory? Then he wants to look at how the community has reacted and tried to build alternative platforms.
That's a full plate.
So let's start with the machinery. How does the Android core actually get built and changed?
The architecture matters here because it explains almost everything downstream. Android has two layers that people constantly conflate. The base is AOSP, the Android Open Source Project. That's open source. You can download it, modify it, build it. But then there's Google Mobile Services, GMS, which is the proprietary layer: Play Store, Maps, location services, push notifications, the whole stack that makes an Android phone feel like an Android phone. And most devices ship with GMS because without it you don't get the Play Store.
So the open part is real but insufficient.
It's open in the way a car engine is open. You can have the engine, but the steering wheel, the brakes, and the radio are all proprietary and you need them to actually drive anywhere useful.
And the certification piece?
That's where Google enforces compliance. There's a document called the Compatibility Definition Document, the CDD, which lays out what a device must do to be considered Android-compatible. And there's a test suite, the Compatibility Test Suite, CTS, that devices have to pass. If you want GMS, you have to pass CTS. If you want the Play Store on your Samsung phone, Samsung has to meet Google's compatibility requirements. So the core is open source in theory, but the certification process means Google decides what counts as Android in practice.
So when Google changes the core, it's not a suggestion.
It's not even a negotiation. Google engineers develop changes internally, often in private branches, then push them to AOSP when they're essentially done. OEMs like Samsung and OnePlus then have to adapt their skins to those changes. They can change the surface: the launcher, the settings menu, the color scheme. But the underlying behavior changes are non-negotiable if they want to keep shipping GMS.
And how much notice do they get?
This is where the frustration starts. Google runs developer previews for major Android versions. They publish an Android Developers Blog. There's an issue tracker where developers can file bugs. There are sessions at Google I/O. So on paper, there's consultation. In practice, most developers describe it as notification, not consultation.
What's the distinction?
Consultation implies your input can change the outcome. Notification means you're told what's happening and given time to adapt, if you're lucky. The developer previews are useful for large teams that have engineers dedicated to platform changes. If you're a two-person shop maintaining an app that does one thing well, you're not running the preview. You find out when the change ships or when your users start complaining.
And the issue tracker?
The issue tracker is where bugs go to be triaged. Sometimes Google responds, sometimes a bug sits there for years with hundreds of stars and no resolution. It's not a consultation mechanism. It's a bug database. And the feedback loop is thin. Developers file issues, Google prioritizes internally, and the priorities don't always match what the community is screaming about.
So the machinery is: Google builds, Google ships, everyone else adapts.
With a thin layer of advance notice that works well for large teams and barely functions for small ones. And the consequences of getting it wrong are not abstract. When Google changed scoped storage in Android ten and eleven, apps that had legitimately stored files in shared locations suddenly couldn't access them the same way. File managers, backup tools, photo apps, all had to rework their storage logic. Some apps just broke.
Scoped storage was a privacy improvement, though.
It was. The old model let any app with storage permission read everything on your device. That was bad. Scoped storage restricted apps to their own sandboxed directories unless they used specific APIs. The intent was good. The rollout was the problem. Developers had been using the old model for a decade. The new model landed with what many felt was insufficient documentation and edge cases that weren't handled well. Apps that did legitimate things, like photo galleries that aggregated images from multiple folders, had to jump through new hoops.
So the complaint isn't always about the change itself. It's about the process.
Right. And that's the recurring pattern. Google announces a change with a stated rationale that's usually defensible: privacy, security, battery life. But the timeline is compressed, the documentation is incomplete, and the edge cases are discovered by developers after the change ships. The developers then have to scramble to fix their apps while their reviews tank.
Let's talk about the sideloading verification controversy, because that's a recent example of the process breaking down.
In August of twenty twenty-five, Google announced that sideloaded apps would require developer verification. The idea was to prevent malicious apps from being installed outside the Play Store by verifying that the developer was legitimate. That sounds reasonable on its face. But the way it was announced, and the scope of it, triggered immediate backlash from the F-Droid community and alternative app store operators.
F-Droid being the open-source app repository.
Right. F-Droid distributes apps that are built from source, often signed by the F-Droid project itself rather than the original developer. Under Google's proposed verification scheme, those apps would have been flagged or blocked because the signing key didn't match a verified developer identity. The Register covered the backlash extensively. Developers pointed out that this would effectively kill F-Droid as a distribution channel and make it much harder for open-source apps to reach users outside the Play Store.
And Google walked it back?
Partially. They clarified some aspects, made exceptions for certain cases, but the fundamental tension remained. The announcement itself, the way it landed without meaningful consultation with the alternative distribution community, that's what people were angry about. It felt like Google was making a policy decision that would have crushed a whole ecosystem, and they hadn't bothered to talk to the people who run that ecosystem first.
So that's the consultation problem in a nutshell. A decision that affects thousands of apps and developers, announced as a fait accompli.
And the walk-back, when it comes, is partial. It's not a reversal. It's a clarification. The original intent is still there, just softened around the edges. Developers are left with uncertainty about what the next clarification will bring.
The Android Killed My App sites, what are those actually documenting?
There are a few of them. Some are personal blogs where a developer writes a post-mortem about why their app died. Some are more organized, like dontkillmyapp dot com, which is a specific site that documents how different OEMs handle background process killing.
That one's interesting because it's not even about Google directly. It's about what Samsung and OnePlus do on top of Android.
Dontkillmyapp dot com is a scorecard of shame for OEMs. It documents how aggressively each manufacturer kills background processes to save battery life. Samsung, OnePlus, Xiaomi, they all have their own task killers built into their skins. The site ranks them from best to worst and tells developers how to ask users to whitelist their apps. The reason it exists is that Google's core Android has one set of background execution rules, but the OEMs layer their own on top, and the result is that an app that works fine on a Pixel might never receive notifications on a OnePlus because the OEM killed it.
So the fragmentation isn't just cosmetic. It affects app behavior in ways developers can't control.
And that's the downstream consequence of the core changes we were talking about. Google tightens background execution limits in the name of battery life. That's a core change. But then the OEMs take it further with their own aggressive task killers. The developer is caught between Google's rules and Samsung's rules and OnePlus's rules, and the user just sees an app that doesn't work.
The user blames the app.
The user blames the app. The developer gets the one-star review. The developer has no power to fix it because the problem is in the OEM's task killer, not in the app's code. That's the fragility Daniel's talking about.
Let's get to the fiefdom question. Is Android a take-it-or-leave-it proposition for developers?
I think the honest answer is yes, with a caveat. The caveat is that developers do have choices. They can build for iOS instead. They can build web apps. They can distribute through alternative channels like F-Droid. So it's not literally take-it-or-leave-it in the sense of having no alternatives. But if you want to reach the billions of Android users through the Play Store, you play by Google's rules. There's no formal mechanism for developers to veto a change or appeal a decision. There's no standards body. There's no consortium.
Compare that to something like the Linux kernel.
Right. The Linux kernel has a maintainer hierarchy, but it's decentralized. Linus Torvalds has final say over the kernel, but there are subsystem maintainers, and the whole thing is transparent. Anyone can submit a patch. Anyone can argue in the mailing lists. The process is messy but it's open. Android doesn't have that. AOSP accepts contributions, but the strategic decisions are made inside Google.
So the openness is at the level of code, not governance.
Code is open, governance is closed. That's the distinction people miss. You can see the code. You can fork it. But you can't influence where it's going unless Google wants you to.
And the device flexibility argument? That Android gives you more freedom than iOS?
That argument is becoming harder to make with a straight face. At the surface level, yes, you can change your launcher, you can sideload apps, you can install a different keyboard. Those things are more flexible than iOS. But the deeper flexibility, the ability to control what your device does at the system level, is being locked down. The attestation layer, Play Integrity, is the big one. It checks whether your device is in a trusted state. If you've rooted your phone or unlocked your bootloader, Play Integrity can flag your device as non-compliant, and apps can refuse to run.
Banking apps, payment apps, games with anti-cheat.
All of them. The attestation layer means that even though you technically can root your phone, the phone becomes less useful when you do. The flexibility is theoretical. In practice, the device is only flexible in ways Google permits.
So the argument that Android provides greater device flexibility is becoming illusory, to use Daniel's word.
I'd say it's becoming conditional. The flexibility is real but it's contingent on staying within Google's good graces. The moment you step outside, the device starts to degrade. Apps stop working. Features disappear. The openness is there until you try to use it.
That's a fiefdom with a decorative moat.
The moat is real, you can cross it, but the bridge is drawn up behind you.
Let's talk about the economic stakes, because that's where this stops being abstract.
When Google changes background execution limits, apps that rely on background processing break. That could be a messaging app that needs to receive notifications, a fitness tracker that needs to log steps, a podcast app that needs to download episodes overnight. When those apps break, users churn. When users churn, revenue drops. For a small team, that's not an inconvenience. That's payroll.
And the small teams are disproportionately affected because they don't have platform engineers on staff.
Right. A company like Spotify has a team dedicated to Android platform changes. They're in the previews, they file bugs, they have contacts at Google. A two-person indie studio has none of that. They find out about the change when it ships or when their users report the breakage. The asymmetry is baked into the system.
So the livelihoods angle is real. This isn't developers being precious about their code.
It's developers watching their income disappear because a change landed with insufficient notice and they couldn't adapt in time. The Android Killed My App sites are not just technical documentation. They're grief narratives. People write about the app they spent years building, the users they served, and the moment it all fell apart because of a platform change they couldn't control.
Now let's look at the alternatives. What are developers building when they decide they've had enough?
There are a few different responses. The most radical is to fork Android entirely. GrapheneOS and CalyxOS are the two most prominent. GrapheneOS is a privacy and security focused Android distribution that strips out Google services entirely and hardens the base system. CalyxOS is similar but a bit more user-friendly. Both are built on AOSP, so they're Android, but they don't include GMS.
And they're niche.
Very niche. GrapheneOS officially supports Pixel devices only. CalyxOS supports a handful of phones. The user base is measured in the hundreds of thousands at most, probably less. They face real challenges. Hardware attestation means some apps won't run. Banking apps often refuse to work on de-Googled devices because they can't verify the device's integrity through Play Integrity. So the alternative distributions are caught in the same trap: they're more open, but the openness makes them less useful for mainstream users.
So the alternative is real but constrained.
It's a lifeboat, not a cruise ship. If you care deeply about privacy and you're willing to accept that some apps won't work, GrapheneOS is excellent. But it's not a mass-market alternative to Google's Android. It can't be, because Google controls the services that make Android useful for most people.
And F-Droid?
F-Droid is the other piece. It's an app repository that distributes open-source apps built from source. It's not tied to Google at all. The apps are signed by F-Droid, the builds are reproducible, and the whole thing is transparent. But F-Droid has its own limitations. The app selection is smaller. Updates can be slower because everything is built from source. And the sideloading verification controversy showed that Google can, if it wants to, make F-Droid's life very difficult.
Because F-Droid relies on sideloading.
F-Droid apps are sideloaded by definition. If Google makes sideloading harder, F-Droid suffers. The twenty twenty-five announcement was a direct threat to that model, and the partial walk-back didn't fully resolve it.
The OSnews piece, Android Is Almost Dead, what's the argument there?
The argument is that Android's openness was always instrumental. Google open-sourced Android because it needed scale. It needed a counterweight to iOS, and open-sourcing the base allowed OEMs to adopt it quickly. The openness was never the point. The point was market share. And now that Google has the market share, the openness is being wound down.
So the openness was a means to an end, and the end is now here.
That's the thesis. And I think there's something to it. The trajectory is clear. Each Android version tightens something. Background execution, storage access, sideloading, attestation. Each change has a defensible rationale. But the cumulative effect is a platform that is less open than it was five years ago, and the direction of travel is not reversing.
Is that hyperbole, though? Android is still more open than iOS.
It is. But the gap is narrowing. And the openness that remains is the kind that doesn't threaten Google's business model. You can change your launcher. You can't easily run a de-Googled device without losing functionality. The openness is curated.
So the question is whether curated openness is still openness.
That's the philosophical core of it. If you're free to do anything except the things that matter, are you free? The developers who run the Android Killed My App sites would say no.
Let's talk about how the community has organized. Has any of the protest actually moved the needle?
There have been open letters. There have been coordinated campaigns on social media. There have been regulatory complaints, particularly to the European Union. The EU's Digital Markets Act includes provisions that could force Google to open up Android's gatekeeping. The DMA designates Google as a gatekeeper for its app store and operating system, which triggers obligations around interoperability and self-preferencing.
And enforcement?
Ongoing. The EU has been aggressive with the DMA, but these things move slowly. Google has appealed some of the designations. The practical impact on developers has been limited so far. But the regulatory pressure is the one lever that seems to actually get Google's attention, because it comes with fines attached.
So the protest sites raise awareness, but the regulators are the ones with actual power.
That's the uncomfortable reality. A developer writing a heartfelt post about their dead app gets sympathy but no policy change. The EU threatening a fine gets a response. The asymmetry of power extends to the mechanisms of accountability.
That's bleak.
It's the ecosystem we have. And it's not entirely Google's fault. Google has legitimate interests. Security matters. Privacy matters. Battery life matters. The platform is better for users because of many of these changes. But the process by which the changes are made and communicated is not good enough, and the people who pay the price are the developers who can least afford it.
So where does that leave us? Is Android a fiefdom?
I'd say it's a fiefdom with a suggestion box. Google holds the power. The suggestion box is real, you can put things in it, but nobody has to read them. And the developers who thrive are the ones who accept that dynamic and plan around it. The ones who don't are the ones writing the Android Killed My App posts.
And the alternative platforms?
They're a pressure valve. They let the most frustrated developers and users exit the system without threatening the system. GrapheneOS and F-Droid are valuable, they're important, but they're not going to displace Google's Android. They're the conscience of the ecosystem, not the future of it.
Unless the regulatory pressure changes the calculus.
Unless that. The DMA is the wildcard. If the EU forces Google to open up the attestation layer or allow alternative app stores more easily, the alternatives could become more viable. But that's a big if, and it's years away.
Hilbert: It was a Stack Overflow post.
What was?
Hilbert: How I found out. Not an email from Google. Not a developer blog. A Stack Overflow post from some other developer who'd hit the same thing and was asking if anyone else had seen it. That's how we learned the in-app purchase flow was broken.
When was this?
Hilbert: Twenty fifteen. I was doing contract work for a small game studio. Two founders, one artist, me on the side. We had a match-three game that was doing okay. Not rich, but paying the bills. Then Google changed something in the billing library and the purchases stopped completing. Users would tap buy, the payment would go through, and then nothing. No item delivered. The users were angry. The reviews were brutal. We lost a week of revenue before we figured out the fix.
A week.
Hilbert: A week. For a two-person studio, a week of revenue is the difference between making payroll and not. The CEO sent me an email at two in the morning. All caps. Just said, Google broke the thing. I still have it.
The email?
Hilbert: Printed it out. It's in a box somewhere. Google broke the thing. Exclamation point. That was the whole message.
That's the developer experience in one sentence.
Hilbert: The thing is, the change itself wasn't unreasonable. The billing library needed updating. The problem was nobody told us. The documentation assumed you had a team tracking every Google announcement. We didn't. We were trying to ship a game. We found out from a stranger on Stack Overflow.
That's exactly the asymmetry we were describing. The process works for large teams and fails for small ones.
Hilbert: The timeline said you had six months to migrate. But the timeline was on a page we never saw. By the time we found out, the six months were mostly gone. We migrated in a week, but the damage was done. The reviews never fully recovered.
Did the studio survive?
Hilbert: It limped along for another year. Then the founders got jobs. The game's still in the Play Store, I think. Nobody's updated it in years. It just sits there.
That's the part that doesn't show up in Google's developer relations metrics. The apps that quietly stop being updated because the developers gave up.
Hilbert: The documentation is written for people whose job is reading documentation. Most developers don't have that job. They're building something. They find out when it breaks. That's the consultation process, in practice.
A Stack Overflow post is the consultation process.
Hilbert: That's what I said.
The open question is whether any of this changes. Google's been doing this for fifteen years. The pattern is stable.
The regulatory pressure is the only thing that's shifted. The EU's Digital Markets Act is the first time an external actor has had real leverage over how Google runs Android. Whether that translates into a better consultation process for developers, I don't know. The DMA is about competition and gatekeeping, not about developer experience per se.
But if Google has to open up the attestation layer or allow alternative app stores, the alternatives become more viable, and that changes the power dynamic.
Maybe. Or Google complies with the letter of the DMA and finds new ways to maintain control. That's the pattern with these things. The company adapts.
The next generation of developers? The ones who expect to tinker?
That's the thing I keep thinking about. If the platform keeps tightening, what does the next generation learn? They learn that openness is a marketing term. They learn that the real rule is: build for the platform as it is, not as it claims to be. That's a loss. Not just for developers, but for the whole ecosystem. The tinkerers are the ones who become the innovators.
The tinkerers built Android in the first place.
They did. And now the platform is closing the door behind them.
This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop.
If you found this useful, a review helps other listeners find the show. We'll be back soon with another weird prompt.
Until then, keep your Stack Overflow tabs open.
