Play Integrity, custom software and why a banking app refuses to open

A phone with a replaced operating system runs everything except the handful of applications that matter most: banking, payments, some government services, the occasional game. They install and then refuse to start, usually with a message about the device not being supported. The refusal is not about capability. It is about attestation, and the distinction explains why no setting on the phone will resolve it.

What the check actually asks

An application can ask the system for a signed statement about the device it is running on. The statement is produced with the help of the secure hardware, which holds keys placed there at manufacture, and it is verified by the developer's own servers rather than on the handset. It answers a few narrow questions: does this look like a genuine device from a known manufacturer, is the software it is running a build that was certified, and has the boot chain been left intact.

A device with an unlocked bootloader or a replaced system cannot answer the second and third questions affirmatively, because the answer would be false. The attestation is honest, which is precisely why it cannot be talked around from inside the phone.

Levels of answer

• The weakest level says the application is talking to a real Android device with a plausible history. Most modified phones can still satisfy this.
• The middle level says the device passes the basic compatibility and integrity checks. This is where most banking applications draw their line.
• The strongest level ties the statement to the secure hardware and the manufacturer's certification. Nothing outside an unmodified, certified device satisfies it.

Which level an application demands is the developer's choice, and it can change in an update without notice. That is why a setup that worked for a year can stop working one morning with nothing changed on the phone.

Why the workarounds are a poor trade

There is a long tradition of modules that intercept the check and return a favourable answer. They work until the verification moves server-side, which it has, and until the next change in what is checked. Beyond the reliability question there is a more serious one: a module with that level of access to the system is also in a position to see everything the application does. The threat model of a banking application is exactly the one you are undermining.

The honest summary is that a modified phone and a banking application are in disagreement about a real question, and the application is allowed to decline. Treating it as a bug to be patched around is the wrong frame.

Practical arrangements that work

If you want the freedom of a custom build and the convenience of the applications that refuse to run on one, the realistic options are:

• Use the browser. Most banks have a web interface with the same core functions, and it does not attest the device at all. This covers the majority of everyday needs.
• Keep a second, unmodified device for the small number of applications that demand a certified build. An old handset that still receives updates is enough.
• Choose a build that keeps the bootloader locked. A few community projects support re-locking with their own verified boot keys on a handful of models, which restores part of the chain — though attestation tied to the manufacturer's certification remains out of reach.

The case where nothing was modified

Not every refusal comes from a custom build. The same message appears on a handset that was never certified in the first place — a grey-market device, or a model whose maker never completed compatibility certification. There is nothing to undo in that case: the phone has never been able to produce the answer, and it never will. It is one more reason to check a variant carefully before importing it, as in reading a band list.

Before concluding anything, rule out the mundane: an outdated system component that handles these checks, a cleared cache on the services that hold the device record, a date and time set incorrectly, or a system update installed but not yet rebooted into. Each of those produces the same symptom and each is trivially fixable.

And if you are still deciding whether to unlock at all, the full cost is laid out in what unlocking does to a warranty — this is one of the items on that list, and for many people it is the decisive one.