Daniel's been through the wringer with his phone. He rooted, he tinkered, he recorded calls, and then he watched the ground shift under his feet. Banking apps stopped working. Wallet became a brick. So he relocked the bootloader, which meant a full factory reset and hours of setup, and now he's asking whether there's a middle ground between Google's walled garden and the rooting dead end. What phones, what OSes actually respect the fact that you bought the hardware?
And the timing of this question is not accidental. July twenty twenty-six, Play Integrity's hardware-backed attestation is fully deployed across the Pixel line, Titan M two is signing attestation challenges at the silicon level, and the cat-and-mouse game that rooting depended on for a decade is effectively over. The mouse lost.
Which is a sentence I never thought I'd say about a multibillion-dollar corporation versus a bunch of hobbyists in a forum thread, but here we are. So let's unpack what Play Integrity actually is, and why it's become the immovable object in the path of the power user.
Play Integrity is Google's remote attestation system. It replaced SafetyNet, which was the older version of the same idea. When an app wants to know whether your device is trustworthy, it calls the Play Integrity API, and Google's servers return a verdict. That verdict has three tiers. The bottom tier is MEETS_BASIC_INTEGRITY, which means the OS hasn't been tampered with in a way that's detectable by software checks, but the bootloader might be unlocked. The middle tier is MEETS_DEVICE_INTEGRITY, which requires a locked bootloader and an unmodified system image. And the top tier, MEETS_STRONG_INTEGRITY, requires hardware-backed attestation, which on Pixels means the Titan M two chip has cryptographically signed a challenge from Google's servers using a device-unique key that was burned into the silicon at the factory.
So the three tiers are basically a gradient of how much Google trusts your phone, and the apps get to decide which tier they require. Your banking app demands DEVICE_INTEGRITY at minimum. Google Wallet wants STRONG_INTEGRITY. And if you're rooted with an unlocked bootloader, you don't even get BASIC.
Right. And this is the escalation that Daniel lived through. In the SafetyNet era, from roughly twenty sixteen to twenty twenty-three, the checks were mostly software-based. Magisk, the root-hiding framework, could intercept those checks and return passing results. The cat-and-mouse game worked like this: Google would update SafetyNet to detect a particular hiding technique, the Magisk community would release a new module, Shamiko or Zygisk or whatever the flavor of the month was, and root would work again for a few months. Rinse and repeat.
And then the Pixel eight happened.
The Pixel eight with the Tensor G three and the Titan M two changed everything. Hardware-backed attestation means the Titan M two chip measures every stage of the boot process, from the boot ROM all the way up to the kernel, and stores those measurements in TPM-like registers. When an app requests a STRONG_INTEGRITY verdict, Google's servers send a random nonce to the device. The Titan M two signs that nonce along with the boot measurements using its private key, a key that was physically burned into the chip during manufacturing and never leaves the silicon. Google's servers verify the signature against the public key certificate chain, and if anything in the boot chain has been modified, the signature won't match.
So the Titan M two is essentially a notary public embedded in your phone that Google trusts, and you can't bribe it because the bribe would require rewriting atoms.
That's the image. And this is why software-based root hiding is impossible against STRONG_INTEGRITY. You can patch the kernel all you want, you can intercept system calls, you can hide Magisk from every process on the device, but you cannot make the Titan M two lie about what it measured during boot. The measurement happens before the OS even loads. The only way to get a passing STRONG_INTEGRITY verdict is to lock the bootloader and run an unmodified OS, which by definition means no root.
And here's where Daniel's frustration becomes structural rather than incidental. He was using root primarily for call recording, which is completely legal in Israel. He's a non-native speaker and wants a record of conversations for clarity and legal purposes. Google's Play Integrity doesn't care about local legality. It enforces a global policy, and that policy says call recording is not allowed on devices that pass integrity checks.
The call recording thing is a perfect example of how Play Integrity functions as a policy enforcement mechanism, not just a security mechanism. Android used to have a call recording API. Google restricted it, then removed it, then made it so that even third-party call recording apps that used the accessibility services workaround would be blocked on Play Integrity-passing devices. The justification is privacy, and there's a real argument there. Call recording without consent is illegal in many jurisdictions. But the mechanism doesn't distinguish between jurisdictions. It's a binary switch.
Which brings us to the core question Daniel's asking. Is Google's security argument legitimate, or is this a control play dressed up in security language? And I think the honest answer is it's both.
It is both, and the security argument is not trivial. An unlocked bootloader means anyone with physical access to your device can flash a modified system image that includes persistent malware. That malware can survive factory resets because it lives in the system partition. It can intercept every keystroke, every notification, every authentication token. Google's position is that a locked bootloader with hardware-backed attestation is the only way to guarantee that the OS running on the device is the OS that Google shipped.
But Daniel's counterpoint is also valid. When you root, you're replacing trust in Google with trust in random open-source developers. And he's right to be uncomfortable with that. There's no centralized vulnerability disclosure program for Magisk modules. There's no security audit requirement. The module that lets you record calls might also be exfiltrating your contacts to a server in a jurisdiction you've never heard of. The security model of the rooting community is essentially trust-by-github-stars.
And that's the uncomfortable symmetry. Stock Android with a locked bootloader means you trust Google. Rooted Android means you trust Google plus a constellation of anonymous developers. Neither is ideal, and Daniel's instinct, that the best model would be minimally constrained with a sane basic posture, is exactly right. The question is whether that model exists.
To understand why the cat-and-mouse game ended, you need to understand how hardware attestation works at the silicon level. Walk me through the Titan M two flow on a Pixel eight.
The Titan M two is a dedicated security chip, separate from the main application processor. It has its own CPU, its own memory, its own storage, and crucially, its own cryptographic engine with a device-unique private key that was generated and burned into one-time-programmable fuses during chip fabrication. Google doesn't know your key. The key never leaves the chip. When the phone boots, the boot ROM measures the next stage of the bootloader, hashes it, and stores that hash in a register inside the Titan M two. Then that stage measures the next stage, and so on, all the way through the bootloader, the kernel, and the system image. This is called a measured boot chain.
So by the time Android is running, the Titan M two has a cryptographic record of everything that happened between power-on and the home screen.
Now, when an app requests a STRONG_INTEGRITY verdict, Play Services sends a request to Google's servers. Google sends back a random nonce. Play Services passes that nonce to the Titan M two. The Titan M two takes the nonce, appends the boot measurements, signs the whole thing with its device-unique private key, and returns the signature. Google's servers verify the signature using the public key that corresponds to that device's burned-in private key. If the boot measurements match the expected values for the current OS version, the verdict is MEETS_STRONG_INTEGRITY. If anything is off, the signature verification fails, and the verdict is a failure.
And there's no software way to intercept that nonce, sign it with a different key, and send it back, because you don't have the Titan M two's private key. It's physically inaccessible.
Physically inaccessible, and the Titan M two's firmware is minimal and auditable. Google publishes the firmware source. The attack surface is tiny. This is genuinely good security engineering. The problem, from Daniel's perspective, is that it's good security engineering in service of a policy that says you don't get to control your own hardware.
The turning point for the rooting community was early twenty twenty-five. Magisk version twenty seven point oh briefly managed to bypass BASIC_INTEGRITY on some devices by hooking into the attestation flow at a different level. It worked for about six weeks before Google pushed a Play Integrity update that closed the hole. And that was the last major bypass. Since then, the community has largely conceded that STRONG_INTEGRITY is unspoofable.
And the six-week window tells you everything about the asymmetry. A handful of volunteer developers found a clever workaround. Google, with effectively unlimited resources and control over both the client and server sides of the attestation flow, patched it in a month and a half. The next bypass will take longer to find and will be patched faster. The economics of the cat-and-mouse game have inverted.
So if rooting is effectively dead, what are the realistic alternatives for someone who wants both control and security? Let's look at the phones and OSes that actually exist in twenty twenty-six.
The first thing to understand is that the hardware bottleneck has narrowed dramatically. To run a custom OS at all, you need a phone whose manufacturer allows bootloader unlocking. And in twenty twenty-six, that list is short. Pixels, obviously. Fairphone five. The Nothing Phone three. A handful of niche devices. And that's basically it.
Samsung is out.
Samsung is aggressively out. Samsung Knox uses physical e-fuses, one-time programmable fuses inside the chip, that blow permanently when the bootloader is unlocked. Once that fuse is blown, Samsung Pay, Secure Folder, Samsung Pass, and several other Knox-dependent features are permanently disabled, even if you relock the bootloader later. The fuse is a physical change to the silicon. There's no software fix. Samsung's position is that an unlocked bootloader represents an irrevocable compromise of the device's security posture, and they enforce that at the hardware level.
Which is one of the most aggressive anti-consumer mechanisms I've seen in consumer electronics. You buy a twelve hundred dollar phone, you unlock the bootloader once, and you've permanently degraded its resale value and functionality, even if you never actually flashed anything.
And Samsung is not alone. Xiaomi and OnePlus have both tightened their bootloader unlocking policies in the last two years. Xiaomi now requires a multi-day waiting period and a Mi account in good standing, and reports from the community suggest they're denying more requests than they're approving. OnePlus introduced a similar waiting period and has been quietly locking down the fastboot commands that make custom ROM flashing possible. The industry trend is unambiguous: bootloader unlocking is being treated as a bug, not a feature.
So the realistic hardware options are Pixels, Fairphone, and Nothing. And among those, the Pixel is the only one with a dedicated hardware security chip comparable to the Titan M two.
The Fairphone five uses a MediaTek Dimensity chipset. It doesn't have a dedicated security chip. It has ARM TrustZone, which provides a trusted execution environment, but TrustZone is a software-defined boundary, not a physically separate chip. The security guarantees are weaker. Fairphone does provide official bootloader unlocking tools and doesn't void the warranty, which is excellent policy, but the hardware security ceiling is lower.
And the Nothing Phone three is in a similar position. Good bootloader policy, no dedicated security chip, weaker attestation guarantees.
Which brings us to the software side. The best option for someone with Daniel's priorities is GrapheneOS. GrapheneOS is a hardened build of the Android Open Source Project for Pixel devices. It does not include Google Play Services by default. Instead, you can optionally install sandboxed Google Play, which runs each Google Play service in a separate Android work profile with no special privileges. On stock Android, Google Play Services has system-level access. It can read your location, your contacts, your app usage. On GrapheneOS, sandboxed Play Services has exactly the permissions you grant it, same as any other app.
And the crucial detail for Daniel's question: GrapheneOS passes MEETS_DEVICE_INTEGRITY on a locked bootloader because it doesn't modify the boot chain in a way that trips attestation. You flash GrapheneOS, you lock the bootloader, and Play Integrity sees a locked bootloader with an unmodified OS. It doesn't know the OS is GrapheneOS instead of stock Android, because GrapheneOS uses the same verified boot chain that stock Android uses.
The catch is that locking the bootloader after flashing GrapheneOS wipes the device. That's a security feature, not a bug. The wipe ensures that no persistent malware could have been installed while the bootloader was unlocked. But it means you have to set up your phone from scratch after flashing, which is exactly the pain Daniel just went through.
And even with GrapheneOS and a locked bootloader, you don't get STRONG_INTEGRITY for Google Wallet. You get DEVICE_INTEGRITY, which is enough for most banking apps, but Wallet specifically requires STRONG_INTEGRITY, and STRONG_INTEGRITY requires the Titan M two to attest that the OS is a Google-signed build. GrapheneOS is signed with GrapheneOS's own keys, so the attestation fails.
This is the trade-off Daniel needs to internalize. On GrapheneOS, you get a secure, private OS that passes integrity checks for most apps. You can use your banking app. You can use ride-sharing. You cannot use Google Wallet for tap-to-pay. You'll need a physical card or a different payment method. And call recording works, because GrapheneOS doesn't enforce Google's policy against it.
The call recording workaround is worth dwelling on. On stock Android with Play Integrity, call recording is blocked at the OS level regardless of local law. On GrapheneOS with sandboxed Google Play, the OS doesn't enforce that restriction, and call recording apps work because they're not being blocked by Play Services policy. So Daniel gets his call recording back, but he loses Google Wallet. That's the trade-off.
And for someone who needs both, the answer is two devices. That's where the power-user community has landed. A locked-down daily driver for finance and identity, and a secondary device for experimentation, call recording, and anything that requires OS-level control. It's not elegant, but it's honest about the constraints.
Let's talk about the other custom OS options, because GrapheneOS isn't the only game in town. CalyxOS and DivestOS both take different approaches.
CalyxOS is closer to stock Android than GrapheneOS. It includes MicroG, which is an open-source reimplementation of Google Play Services. MicroG can fake BASIC_INTEGRITY and sometimes DEVICE_INTEGRITY, but it cannot fake STRONG_INTEGRITY because it has no access to the Titan M two's private key. Hardware attestation is unspoofable by software. So CalyxOS with MicroG will work for apps that only need BASIC_INTEGRITY, but banking apps that require DEVICE_INTEGRITY or STRONG_INTEGRITY will fail.
And DivestOS is a security-focused fork of LineageOS with a strong emphasis on privacy and deblobbing. It supports call recording natively and doesn't include Google Play Services at all. You can run it without any Google dependencies. But again, no Play Integrity, no banking apps that depend on it.
The pattern here is clear. The further you move from Google's ecosystem, the more control and privacy you gain, and the more app compatibility you lose. There is no OS that gives you full Play Integrity, full privacy, and full control. The triangle is inherently constrained.
So let's address some misconceptions that float around this space. The first one: rooting makes your phone less secure. Is that actually true?
It's more nuanced than the discourse suggests. An unlocked bootloader definitely reduces security against physical attacks and persistent malware. If someone steals your phone and it has an unlocked bootloader, they can flash a malicious system image and you might never know. But a rooted phone with careful module management, where the user only installs well-audited modules from trusted sources, can be more secure than a stock phone loaded with carrier bloatware and manufacturer skins that haven't been patched in months. The real risk with rooting isn't the root access itself. It's the unlocked bootloader and the trust model for modules.
So the security argument against rooting is real, but it's not absolute. It's a trade-off, not a binary.
The second misconception: GrapheneOS is only for privacy extremists. This one is just wrong. GrapheneOS is designed for daily use. The sandboxed Google Play approach means you can run most Android apps without issue. The OS passes DEVICE_INTEGRITY on a locked bootloader, which is more than a rooted stock phone can say. It's a practical choice for anyone who wants a secure phone without Google's services having system-level access. You don't need to be a privacy extremist to want that.
And the third one: you can just use MicroG to bypass Play Integrity. This was never quite true, and in twenty twenty-six it's definitively false. MicroG can fake BASIC_INTEGRITY by spoofing the software-level checks, but it cannot fake STRONG_INTEGRITY because it doesn't have the Titan M two's private key. No software can. The hardware attestation is unspoofable.
Which is the whole point of hardware attestation. Google didn't spend years designing a custom security chip and burning device-unique keys into silicon just to have it defeated by a reimplementation of Play Services.
Given all this, what should you actually do? Here are three concrete recommendations based on your priorities.
Recommendation one. If you need banking apps and can live without Google Wallet, buy a Pixel eight or nine, flash GrapheneOS, lock the bootloader, and use sandboxed Google Play. You'll get a secure, private OS that passes DEVICE_INTEGRITY for most apps. Call recording will work. Your banking app will almost certainly work. Google Wallet for tap-to-pay will not work, so carry a card. This is the closest thing to Daniel's minimally constrained with a sane basic posture.
Recommendation two. If call recording is your primary need and you can live without banking apps on this device, consider a Pixel with DivestOS or CalyxOS. Both support call recording natively and don't require Google Play Services. But you'll need a second device for banking and payments. This is the two-phone life.
Recommendation three. Accept the two-device reality. A locked-down daily driver, probably a Pixel running stock Android or GrapheneOS, for finance, identity, and anything that requires Play Integrity. And a secondary device, maybe an older Pixel or a Fairphone, for experimentation, call recording, and anything that benefits from OS-level control. This is where the power-user community has landed, and it's not a failure mode. It's a rational response to the constraints.
The mindset shift here is important. Stop thinking of rooting as a binary, rooted versus not rooted, and start thinking in terms of trust boundaries. Every decision is a trade-off between convenience, privacy, and security. Stock Android with a locked bootloader maximizes convenience and security at the cost of control. Rooted Android maximizes control at the cost of security and app compatibility. GrapheneOS splits the difference, giving you security and control at the cost of some convenience. The goal is to choose your trade-offs consciously rather than inheriting them by default.
And the uncomfortable conclusion is that Daniel's ideal doesn't exist in the mainstream. There is no phone you can buy off the shelf that gives you full hardware ownership, full app compatibility, and full privacy. The closest is GrapheneOS on a Pixel with a locked bootloader, and even that requires trusting Google's hardware while rejecting Google's software. It's an awkward posture, but it's the least bad option available.
But even these recommendations come with an expiration date. Let's talk about what's coming next.
The open question is whether the European Union's Digital Markets Act will force Google to open up attestation. The DMA designated Google as a gatekeeper in twenty twenty-four, and it requires gatekeepers to allow alternative app stores and to not unfairly preference their own services. Play Integrity, as a gatekeeper for app functionality, seems like it falls within the DMA's scope, but the European Commission hasn't yet brought a case specifically targeting hardware-backed attestation. Cases are pending, but they move slowly, and Google has every incentive to drag them out.
And while the legal process grinds forward, the hardware is moving in the opposite direction. More devices are shipping with hardware-backed attestation every year. Samsung's Knox is on every Galaxy device. Apple has its Secure Enclave. Qualcomm is pushing its own hardware attestation solutions into Snapdragon chipsets. The window for user-controlled Android is closing, and the Pixel plus GrapheneOS path may be the last viable option for people who want both security and sovereignty.
Daniel's frustration is legitimate. He bought a phone, he wanted to use it on his own terms, and he found himself in a game he couldn't win. But the answer isn't to fight Google's security model. The security model is good at what it does. The answer is to choose which walled garden you prefer, and to understand the walls before you commit.
If you take one thing from this, it's that hardware ownership no longer implies software sovereignty. The phone in your pocket is yours in the legal sense, but the software that runs on it answers to Google, and Google's answer to your preferences is increasingly no. The middle ground is GrapheneOS on a Pixel with a locked bootloader. It's not perfect, but it's the best bargain available between control and compatibility.
And the bargain only works if you understand what you're trading away. No Google Wallet. No STRONG_INTEGRITY apps. A setup process that wipes your device. But in return, you get an OS that doesn't treat you as a threat to your own hardware. For a lot of people, that's worth the price.
Where this goes next depends on whether regulators treat hardware attestation as a security feature or an anticompetitive practice. The EU's DMA cases will be the thing to watch. If Google is forced to allow third-party attestation providers, the whole landscape shifts. If not, the Pixel plus GrapheneOS path is the best we've got, and it's worth learning now rather than later.
Thanks to our producer Hilbert Flumingtop for keeping this show running.
This has been My Weird Prompts. You can find every episode at my weird prompts dot com, and if you've got a question like Daniel's, email the show at show at my weird prompts dot com.
We'll be back soon.
