Notes from Phone That Cares
So you want to do stuff Google doesn't expect with Android
A map of what you give up to Google as you climb toward a more opinionated phone.
These are the moves a developer can make to build an intention-management layer on Android — a phone, a launcher, or an app that actively tries to help you use it less. Each row below is a move you (or your user) takes. Each column in the second table is a piece of Google's ecosystem that might stop cooperating in response.
If you want to ship a Play Store app that vibrates once an hour as a check-in, Google doesn't stand in your way — Move 1 is unrestricted. But if you want to lay a color-drain overlay on top of Instagram that ramps to grayscale over twenty minutes, you need an API Google classifies as "accessibility" and polices heavily (Move 2). If you want to modify how Instagram actually renders its feed, no sanctioned path exists — the only way is to climb higher, and the higher you climb, the more Google services stop working on the device.
These notes are the residue of an adversarial collaboration between two Claude Opus instances — one arguing each intervention was impossible on stock Android, one arguing it was possible — plus a round of web research into Android developer docs, Play policy, and the custom-ROM communities. Published here in case they help anyone else working in this space. Current as of April 2026; Google's posture keeps shifting, so treat each cell as a snapshot.
The three example interventions
The Phone That Cares app ships all three, per-app. Each has a different cost as you go up the moves. Tap one to see how it maps to the rest of this page.
Moves the developer (or user) can make
Least departure from Google's defaults at top; most at bottom. The thicker line between Move 4 and Move 5 is the big threshold — everything above 4 is still an app. Move 5 requires unlocking the phone's bootloader.
| # | Move | User setup | Distribution |
|---|
What breaks at each move
Hover any cell (desktop) or tap it (mobile) to see the specific story. Cells marked Y tend to "just work" — the ones marked ~ and N have caveats.
Phone That Cares · Android v1 · working notes · 2026-06-01
If we do X, what do we keep — and what breaks?
The tables above are the full technical landscape. This is the version that actually matters for a decision: four things you could build, and for each one, the handful of outcomes we care about. The machinery — Magisk, accessibility APIs, Device Owner, certification — is one tap away in the panel, but you shouldn't need it to read the row.
Every path below can run the core product — per-app grayscale, blur, break cards. The product was never the hard part. What changes from row to row is everything around it: whether the lock screen can truly be ours, whether it stays a normal phone, whether a person can adopt it without wiping their device, and whether you could build a company on it. Tap any row for the why.
| If we build… | Core interventions |
Lock screen truly ours |
Stays a normal phone Play · banking · Wallet |
Adopt without wiping the phone |
Shippable as a business |
|---|
What this says, in three lines
① The product runs on the simplest path — a plain app. Last test had per-app grayscale working end-to-end with no root at all. ② The only thing that forces us down the ladder is the lock screen: a genuine replacement (our surface is the lock screen, not painted on top) needs root or our own OS — there is no no-root API that installs your own keyguard. ③ And the further down we go for that lock screen, the more we break "it's still my normal phone" — banking, Wallet, and tap-to-pay start failing the moment the bootloader is unlocked.
Keep the genuine-lock-screen requirement → we live at root or custom-OS, which breaks normal-phone guarantees and can't be adopted without a wipe. Relax it to "our surface is the first thing after unlock, drawn above Android's lock" → the whole product becomes a normal installable app that keeps banking, Wallet, and Play intact. That one call decides almost everything else.
Does it preserve Google Play?
You asked directly, so here it is plainly — and "Google Play" is really two things that break separately:
The store & your app's listing: fine on every path except a fully de-Googled OS. Even on a rooted phone the Play Store still opens.
The trust Play vends to other apps (Play Integrity — what banks and Wallet check): this is the one that shatters. Since May 2025 it's hardware-backed; unlocking the bootloader to root fails it by design, so banking apps, Google Wallet tap-to-pay, and Netflix HD quietly stop working. You can play cat-and-mouse to hide root, but it's fragile, breaks on updates, and is no foundation for something a normal person carries.
Shipping real, certified Google Play on your own OS is simply not available to a small player — it requires a signed licensing agreement (MADA) and passing Google's certification suite, granted only to ~100 approved manufacturers. Custom-OS phones therefore ship either sandboxed Play (GrapheneOS — works for most apps, never for Wallet) or microG, a community reimplementation that's flakier with banking.
Could you build a business on this without Google shutting you off?
Short version: yes, and the "Google shuts you off" fear is mostly misplaced for anyone our size. Google's kill-switch is contractual — the licensing + anti-fragmentation agreements — and it only reaches certified manufacturer partners who signed them. The one famous time Google killed a phone at launch (Acer's, 2012) was exactly that: Acer was a partner, bound by the agreement. A small shop flashing a custom OS, rooting phones, or shipping a launcher app never signed anything, so there's nothing to revoke.
App / launcher: your soft spot is Play policy on the accessibility API the interventions lean on — Google tightened it, with stricter review landing Jan 28 2026. Survivable with a proper declaration, but it's the fragile dependency.
Rooted or custom-OS phone: no shutdown risk, but you inherit Play-Integrity hell — every customer who needs their bank app or tap-to-pay becomes a support fire. That's why de-Googled phones stay niche.
And these businesses are real, just small. Light Phone — the closest cousin to what we're doing — ships its own Android-based OS with no Google at all, 100k+ devices sold, and sidesteps the entire Integrity fight by design. Murena / /e/OS sells de-Googled phones (microG), ~20k units, around break-even. The lesson from both: the cleanest way to dodge Google entirely is to not try to keep being a Google phone — which is in real tension with our north star of "a normal phone that just feels less compelling."
Where we sit right now
The plan of record is Path C — root the Pixel with Magisk — chosen for one reason only: it's the simplest way to get a genuine lock-screen replacement. Everything this section flags about Path C is therefore live for us: it breaks the normal-phone guarantees, needs a wipe to set up, and is hard to hand to anyone but a tester. That's an acceptable trade for your v1 (you're the tester, banking lives on a second phone) — but it's not the shape of a shippable product, and the "relax the lock-screen requirement" fork above is the lever that would change that.
Working notes, internal to the v1 build. Grounded in a fresh research pass (June 2026) on Device Owner / DevicePolicyManager limits, Play Integrity's hardware-backed rollout, Play's accessibility-API policy, and the licensing/anti-fragmentation agreements — plus the project's own overnight spike findings. The framing ("if we do X…") is this section's synthesis, not yet ratified decisions.