Here's the take you'll hear from most of the tech commentariat this week. Android is opening up. Google built a nine-step escape hatch for power users, they published it, the whole thing is documented, and everybody can calm down about sideloading.
And that take is wrong in a very specific way, which is that an escape hatch that runs through Play Services isn't an escape hatch. It's a permission slip.
Right. So Daniel wrote in with a question that started as a convenience problem and turned into something considerably less convenient. His framing: rooting was the traditional power-user move for actually owning your device, and it's become a losing game. Not because the tools got worse, but because Google's security ratchet keeps winning. F-Droid and Shizuku are the current stopgaps, and they don't solve the thing that actually annoys him, which is reprovisioning. He curates apps across three ecosystems. Some F-Droid, some Play Store, some direct APK installs. And he wants to know whether you can version-control that posture. Define your installed app list as code. He asks about batch APK export, and then says, I think more usefully, an export of the installed database including the installation sources. He's cloud-first, so his disaster recovery plan is reinstall rather than restore. Which is also why APK export doesn't appeal to him. You're baking in an old version without the user data. And he's explicit that app user data is a separate episode. Today it's the app list. So. Is there an Ansible for Android?
There isn't. And the reason there isn't is more interesting than the absence itself.
Start with why the ground moved, because Daniel's premise about rooting being a losing game is correct but it undersells what's actually happening.
Massively undersells it. Rooting versus Play Integrity is the old war. The new one is Android Developer Verification, announced August 2025, and enforcement starts this month. September. Brazil, Singapore, Indonesia, and Thailand first, global through 2027.
This month. As in, we're recording inside the enforcement window.
Inside it. And what it requires is that every Android developer register centrally with Google before their software can be installed on any device. Not just Play Store apps. Any device. You pay about twenty-five dollars, you agree to the terms, you hand over government ID, you provide evidence of your signing key, and you list all your current and future application identifiers.
All current and future identifiers. You're pre-registering apps you haven't written yet.
That's the part that gets me. And if you don't register, your app gets silently blocked. Not flagged, not warned about. Blocked, on every Android device worldwide, and the user doesn't necessarily know why.
F-Droid's response to this was not measured.
F-Droid called it an existential threat, and they were specific about why. They can't require their developers to register, because they're not the developers. And they can't take over the application identifiers for the apps they distribute, because that would mean seizing exclusive distribution rights over other people's software. So there's no path where F-Droid complies. Their line was that the developer registration decree will end the F-Droid project and other free and open source distribution sources as we know them today.
Fifteen years of infrastructure, and the compliance answer is "there isn't one."
And their counterargument on security is worth stating plainly, because it's the strongest version. Play Protect already scans and disables malware regardless of where it came from. So registration doesn't add a scanning layer. It adds an identity layer. F-Droid's read is that this isn't about security, it's about consolidating control over an ecosystem that used to be open.
Which brings us to the escape hatch, and I want to walk through this because the details are the argument. Nine steps.
Nine steps. You enable developer options, you go into the developer menu, you find Allow Unverified Packages, you flip it, you confirm you're not being coerced, you enter your device unlock PIN, you restart the phone, and then you wait twenty-four hours.
Twenty-four hours.
Then you come back, and you choose Allow Temporarily, which gives you seven days, or Allow Indefinitely. And if you pick indefinitely, you only have to do it once per phone.
So the shape of it is: a day-long cooling-off period, buried nine menus deep, gated behind a PIN.
Sameer Samat, who runs the Android ecosystem at Google, explained the reasoning. His line was that in that twenty-four-hour period it becomes much harder for attackers to persist their attack. In that time you can probably find out that your loved one isn't really being held in jail, or that your bank account isn't really under attack.
That's a real scam pattern. The fake kidnapping, the fake bank fraud call, the guy on the phone telling you to install this right now.
It's a real pattern and the cooling-off logic is not stupid. Where it falls apart is that the flow runs entirely through Google Play Services.
Say why that matters, because I think people hear "Play Services" and don't clock it.
It means Google can change it, tighten it, or delete it without an OS update and without asking you. If it lived in AOSP, it would be part of the platform, and changing it would be a platform change. Living in Play Services means it's a service they operate. And as of the Keep Android Open campaign's writeup, it hadn't shipped in any beta, preview, or canary build. It existed as a blog post and some mockups.
A documented promise of a feature that nobody has seen run.
Ars Technica reported in March that it would be available before September enforcement. I don't know whether it shipped in the last few weeks. That's the honest answer.
One more thing from Samat, because it cuts against the panic in an interesting way. He defined malware as something that causes harm the user didn't intend. And he explicitly said a rootkit you deliberately downloaded for root access is not malware in that framework.
Which is Google saying, on the record, that they're not coming for your root tools as such. The threat to the power user isn't that they'll classify Obtainium as malware. It's that the distribution sources underneath it stop being viable.
And the scale of the objection is not small. Seventy-one organizations from twenty-three countries signed the open letter. F-Droid, KDE, the EFF, the ACLU, Brave, AdGuard, Nextcloud, the Free Software Foundation. The petition has over a hundred thousand signatures.
Cory Doctorow's line is the one I'd put on the wall. Google isn't certifying apps, they're certifying developers. Which implies the company can somehow predict whether a developer will do something malicious in the future.
The EFF's version is the one that should worry people who like the security framing. When you set up a gate, you invite authorities to use it to block things they don't like. And when you build a database, you invite governments to try to get access.
There's a real-world example that makes that concrete. AndroidAPS. It's DIY software for Type 1 diabetics, built by patients, that can never be distributed through official channels because it's not a commercial product and it closes a loop on medical hardware. Under registration, that's not a gray area anymore. It's just blocked.
And developers in Cuba or Iran who can't pay a fee or pass an ID check.
Can't register. So their software doesn't exist on Android anymore. That's not a hypothetical about gatekeeping. That's the gate doing its job.
So that's the landscape. Now the actual mechanics of what Daniel asked, because he's asking a narrower question than it sounds. He's not asking how to back up his phone. He's asking how to define his phone as a file.
And the honest answer is that the closest thing that exists is Obtainium, and it's closer than you'd expect.
Give me the shape of it.
Obtainium installs and updates apps directly from their release pages. From the source. GitHub, GitLab, Codeberg, F-Droid, IzzyOnDroid, SourceHut, APKPure, Aptoide, Uptodown, itch.io, Huawei's AppGallery, Samsung's Galaxy Store, APKMirror, direct APK links. Nineteen point eight thousand stars on GitHub, six hundred and two forks, a hundred and forty-six contributors, three hundred and thirty-one releases. Latest is version one point six point seventeen, September thirteenth. That's eight days ago.
Actively maintained is an understatement.
And the feature that matters for this episode isn't the installer. It's the configs. There's a crowdsourced repository at apps dot obtainium dot imranr dot dev where people share and import app configurations, with deep links that import straight into the app.
So somebody can send you a link and it adds an app to your list.
Somebody can send you a link and it adds an app to your list, with the source already resolved. Which means the config list is a manifest. It's a portable, shareable, exportable statement of which apps you run and where they come from.
That is the Ansible answer. Not Ansible, but the same instinct.
The same instinct, minus the reconciliation. And the reconciliation is the whole point of Ansible, so let's not oversell it. Ansible reads your declared state, compares it to actual state, and converges. Obtainium installs what's on the list. It doesn't audit your device and tell you what drifted.
What breaks?
Some of the sources are web scrapers. When a site changes its release page markup, the scraper breaks until somebody fixes it. That's a maintenance treadmill, and it's the kind of thing that's invisible until the day it isn't.
F-Droid, then. Because Daniel's using it and it's the oldest piece of this stack.
Fifteen years old. It reviews source, builds from source, and signs with its own key unless the build is reproducible and the developer signs it themselves. And there's a real criticism here that I want to give fairly, because it comes from the GrapheneOS community, which is not a hostile source. Their argument is that F-Droid's signing model gives the F-Droid team ultimate trust over every app they ship. If F-Droid's key is compromised, every app on the store is compromised, and you have no way to verify independently.
Because the signature isn't the developer's.
It isn't. And the second criticism is that the main client targets old SDK versions, and there have been certificate-pinning bypass vulnerabilities. The recommendation from that community is to use F-Droid Basic instead, and to prefer third-party repos where the developer signs their own builds.
And then Aurora Store for the Play-only stuff.
Aurora is a third-party frontend for the Play Store that needs no Google account and no Google apps installed. That's the fallback for anything that only exists on Play. The caveat is real, though. Some apps check for a signed-in Play Store account and refuse to open without one. So it's not a clean substitute. It's a good-enough substitute.
Shizuku, then. Because Daniel mentioned it and I want to be honest about what it is.
Shizuku gives you on-device ADB. Elevated shell access without full root. It lets apps use privileged APIs with your consent, which is useful for app management and some system tweaks. Here's my uncertainty: I could not find substantive discussion of Shizuku in the places I'd expect it, and I don't know its current state with respect to Developer Verification. I'd rather flag that than guess.
So the stopgap stack is F-Droid Basic, Obtainium, Aurora, Shizuku, and none of them is root.
None of them is root. And that's the interesting pivot, because the community's actual recommendation for people who want control is GrapheneOS, and GrapheneOS deliberately does not give you root.
Explain that, because on its face it sounds like a contradiction.
A GrapheneOS contributor put it better than I can. Exposing root to userspace does not make you the owner of it, and it serves to erode the guarantee that the OS is enforcing the rules you set.
Unpack that.
The argument is that root isn't ownership. If the OS hands root to any app that asks, then the OS can no longer guarantee anything about the device state, because the device state is whatever the last app with root decided it should be. So you haven't gained control. You've traded a system you can reason about for a system where every app is a potential administrator.
Which reframes the whole episode. The power user's escape hatch stopped being root and became a different operating system.
And a different operating system that runs on Pixel hardware, supports sandboxed Play Services so Play-dependent apps work without system-level access, and has a duress PIN that wipes the device from any PIN screen. That's the current answer for people who care. A different floor.
Daniel's core question, then. Version-controlling the posture. He offers two mechanisms. Batch APK export, and exporting the installed database with installation sources. He leans toward the second. Is he right?
He's right, and the reason is that APK export solves the wrong problem. The tools exist. OAndBackupX, various extractors, they'll pull the APKs off your device. But an APK is a frozen artifact. It's version whatever you had on the day you exported, and it contains no user data.
So you restore a phone from your APK archive and you've reinstalled six-month-old software.
Six-month-old software with known vulnerabilities, missing features, and in some cases a server-side API that's moved on and won't talk to it anymore. And you've still got to log into everything, because the data wasn't in the APK. So you've done all the work of a fresh install and gotten a worse result.
It's a backup that makes your phone worse than not having the backup.
That's the cleanest way to say it. APK export is a preservation strategy, not a reprovisioning strategy. They're different problems and people conflate them because both involve files.
The database approach, then. Android's package manager keeps a record. Package names, installer source. What's the actual state of getting at it?
The package manager database records exactly what Daniel wants. Which packages are installed and where each one came from. The problem is that reading it cleanly, in a form you can export and act on, typically requires root or Shizuku-level access. Which loops straight back to the tension we started with. The thing that would let you take control of your app posture is the thing the platform is steadily making harder to have.
Every road leads back to the ratchet.
Every road leads back to the ratchet. Which is why the practical synthesis is unsatisfying but honest. The realistic Ansible for Android today is Obtainium plus a curated config list, supplemented by F-Droid Basic for the FOSS apps and Aurora for the Play-only ones. There is no declarative tool that reconciles state. There's a manifest and an installer and a lot of manual judgment.
And then there's the third option, which is Daniel's actual operating philosophy. Reinstall, don't restore.
Which is more defensible than it sounds, and it's defensible precisely because app user data backup is a disaster area. Signal will not let you export its database. It's a deliberate design decision and I understand the reasoning, but it means your Signal history lives and dies with the device. WhatsApp only restores at first-time startup, so if you've already set the phone up, you've missed the window.
The window closes and there's no reopening it.
There's no reopening it. So the cloud-first posture isn't laziness. It's an accurate read of where the data actually is. If your working data lives in the cloud and on your server, then the device is a terminal, and reprovisioning a terminal means installing software and logging in. Which is exactly the thing Daniel wants to automate.
And here's where it gets uncomfortable. Google's own backup knows your installed app list.
Of course it does. Somebody on Hacker News put it flatly. How would they back up apps you have installed if they didn't know what you installed in the first place. That's not a bug, that's the feature working.
Convenience and surveillance are the same mechanism, and you can't have one without the other.
And on GrapheneOS, Play Services can't see the app list, so Google's backup doesn't work the same way. You've traded the convenience for the privacy, which means you now need your own manifest. The privacy costs you the automation, and you have to rebuild it yourself.
Which is the argument for exporting your config now, while the tools work.
That's the knock-on effect and it's the one I'd underline. If Developer Verification lands the way F-Droid expects, then your reinstall-from-manifest strategy depends on the sources in that manifest still existing. And the sources are the thing under existential threat.
So the manifest could outlive its own sources.
A list of GitHub release pages is only useful while GitHub release pages are installable. If the apps on that list can't be distributed anymore, you've got a very well-organized document describing software you can't have.
One more thing before we get to the practical bit, because it's a rhetorical point that I think is load-bearing. The word sideloading.
Louis Rossmann's line is that it's psychological propaganda. You don't sideload an executable on Windows. You install it. The word exists to make the normal act of installing software sound like something shady you do in an alley.
And once you notice the framing, the policy reads differently. This is an iPhone now, I didn't want to buy an iPhone, I use Android because it gives me freedom. That's Rossmann again.
OSnews put it as: once there's no such thing as sideloading, there's virtually no difference between iOS and Android. Which is the whole argument in one sentence.
There's also a telemetry number that explains why people care enough to do all this. A packet capture study this month found stock Android 16 averaging three hundred and forty-eight requests per hour to Alphabet endpoints.
Three hundred and forty-eight an hour. Turning off location and diagnostics still left a hundred and ninety-four an hour. GrapheneOS with sandboxed Play Services dropped it to twelve point one. And pure GrapheneOS, with no Play Services at all, registered zero.
Zero.
Zero. So the argument for this whole stack isn't ideological. It's that the difference between three hundred and forty-eight and zero is measurable, and you can see it in a packet capture.
Last piece of context, and then I want to get to what Daniel should actually do. Android 17 is the first release since Android 3.x to add new APIs without releasing them to AOSP.
Which is a direct hit on custom ROMs. GrapheneOS and LineageOS depend on AOSP getting the platform code. If new APIs land in the Google build and never reach AOSP, the ROMs fall behind by construction, not by accident. GrapheneOS publicly accused Google of gatekeeping security patches from Android OEMs.
So the escape hatch we just recommended is itself being squeezed.
On a longer timeline, yes. Which is why the honest summary is that the tools exist today, they work today, and the direction of travel is against them.
Hilbert: The word you keep using is "reprovisioning." That's not what it was called.
What was it called?
Hilbert: It was called a transfer. I did them at a kiosk in a mall, eighty-five to eighty-seven. Transfers. People would buy a new phone and come to me with the old one and a look on their face like they were handing over a pet. I had a USB hub, a laptop with every manufacturer's tool installed, and a laminated checklist. I got quick. Under an hour for a whole phone, most days.
And the tools missed things.
Hilbert: Always. Never once did a transfer come out clean. A banking app that wanted re-enrollment. An authenticator that didn't move, which meant the customer couldn't get into their email to reset the thing they needed to get into their email. A parking app that had the license plate stored locally, so the first time they parked they got a ticket. I started keeping a list. Apps that don't transfer. Text file, on my own phone. I added to it for two years.
Do you still have it?
Hilbert: It's on a phone in a drawer. Out of date. Half those apps don't exist. I can't bring myself to delete it.
Because it's the record of a problem nobody was solving.
Hilbert: Nobody asked. That's the part. Two years of transfers, hundreds of customers, and not one of them ever asked me to back up their app list. They asked about photos. Contacts. Messages. The apps were an afterthought, right up until they got home and half of them didn't work and they had to call me back. I'd walk them through it over the phone. That was most of my job, honestly. Phone calls about apps that didn't transfer. Anyway. I've got a trailer to move before it gets dark.
The manifest becomes a historical document.
That's the shape of it. And I want to be careful not to be fatalistic, because the tools work right now, today, and there's real value in using them. But the honest read is that the Ansible-for-Android question may not get answered by a new tool. It may get answered by the ecosystem that made the question necessary closing.
Which means the practical advice is boring and time-sensitive. Export your Obtainium configs. Curate the list. Keep the deep links somewhere that isn't the phone. Not because it'll save you next time, but because the next time you can do it might be the last time.
If you're going to do it, do it this week. Enforcement started this month in four countries. The global expansion is next year. The window where all the sources on your list are still installable is open right now.
One thing from the research that didn't make it into the main thread. F-Droid has no user accounts by design. Which means they don't know how many people use F-Droid. They can't know. Fifteen years of infrastructure and the project cannot tell you its own user count.
Which is either the most principled thing in this entire story or the most precarious, and I think it's both at once.
Thanks to Hilbert Flumingtop, our producer. This has been My Weird Prompts. If you're curating apps across ecosystems, go export that config. And if you've built something better than Obtainium for this, we want to hear about it. Email us at show at my weird prompts dot com.
We'll be back soon.
