Attestation failures block apps that should otherwise work. A banking app refuses to open. A payment app refuses to add a card. A game refuses to log in. The phone itself runs fine. The app sees a modified environment and stops. That gap between a working phone and a blocked app frustrates rooted users more than any other root problem.
Attestation checks the device integrity. It checks whether the bootloader is unlocked. It checks whether the system is modified. It checks whether a hardware key confirms the device state. Modern checks use hardware-backed keys. Those keys cannot be faked by a simple software toggle. A fix must address the hardware signal itself or hide it convincingly.
This guide explains the integrity levels in plain terms. It explains why a fix that worked last year fails now. It gives a step order that avoids common traps. It also sets honest limits. Some devices cannot pass strong integrity while rooted. Knowing that limit early saves wasted effort.
Start by testing your current status. Use an integrity checker app. Note which levels pass and which fail. Basic integrity and device integrity are different levels. Strong integrity is stricter than both. A fix plan depends on which level your target app requires. Testing first prevents fixing the wrong level.
Understanding the three integrity levels
Basic integrity checks for obvious tampering. It looks for root binaries and modified system files. It looks for known root apps. A basic check passes on many rooted phones with simple hiding. It fails when root is visible to the checker. Basic integrity is the easiest level to pass.
Device integrity checks the device state more deeply. It verifies the bootloader state and the system image. It checks for a certified device profile. A phone with an unlocked bootloader often fails device integrity without a fingerprint fix. A fingerprint module can present a certified profile. That module must match a real certified device.
Strong integrity adds hardware-backed attestation. It asks a hardware key to confirm the boot state. An unlocked bootloader breaks that hardware confirmation. A software module cannot create a valid hardware key. That is why strong integrity is hard on rooted phones. Some workarounds use a different attestation path. Those workarounds vary by device and by Android version.
App requirements differ by level. A media app may need only basic integrity. A banking app may need device integrity. A payment app may need strong integrity. Check your target app requirement before you chase the hardest level. Passing device integrity may be enough for your needs.
The fingerprint fix step by step
A fingerprint module spoofs the device profile that attestation sees. It presents a certified fingerprint from a real device build. It must also present matching device properties. A partial spoof fails cross-checks. A complete spoof passes more checks. Choose a fingerprint module with recent updates. Attestation rules change often. A stale fingerprint fails quickly.
Install the fingerprint module through your manager. Reboot the phone. Test integrity again. Note which levels changed. A fingerprint module often fixes device integrity. It rarely fixes strong integrity alone. That result is normal. Do not add five more modules in frustration. Diagnose the remaining failure first.
Clear app data for the target app after a fingerprint change. Apps cache attestation results. A cached failure can persist after a fix. Clearing data forces a fresh check. Clearing data also removes login state. Be ready to log in again after the clear.
Check the module for a valid fingerprint source. A fingerprint from an old build may fail new checks. A fingerprint from a current certified build works better. Some modules update fingerprints automatically. Others need manual updates. Prefer a module with a clear update path.
Hiding root from the checker
A deny list hides root from selected apps. Add the integrity checker to the list. Add the target app to the list. Add system services that the app uses if the module supports it. A deny list alone does not fix hardware attestation. It fixes app-level root detection. Both layers matter.
Remove root traces that a checker can find. A root manager app with an obvious name can trigger detection. Renaming the manager app helps. Hiding the manager app helps more. Some managers offer a hide option that changes the package name. Use it if your manager supports it.
Disable modules that the target app does not need. Each active module adds a detection surface. A module that changes the interface can still trigger a check. A minimal module set passes more checks than a maximal set. Enable only what you truly use.
Ad blocking modules can complicate attestation tests. An app that fails may fail for ad hook reasons rather than attestation reasons. The guide on blocking ads inside native apps with LSPosed explains ad module scope. Keep ad modules out of the target app scope during attestation testing.
When strong integrity cannot pass
Some phones cannot pass strong integrity while the bootloader stays unlocked. Hardware attestation reports the unlocked state directly. No software module can change that hardware report honestly. Workarounds that claim otherwise often rely on a temporary bypass. A bypass can break after a system update or a server-side change.
Accepting that limit leads to practical choices. Use a second device for payment apps that need strong integrity. Use a web version of a banking service where available. Keep the rooted phone for tasks that do not need strong integrity. That split preserves both root freedom and payment access.
Relocking the bootloader restores strong integrity on many phones. Relocking also removes root. That trade-off suits users who value payment apps over root. It does not suit users who need root daily. Decide based on your daily needs not on a single app.
Watch for server-side changes. Attestation rules update without a phone update. A passing setup can fail overnight. A failing setup can pass after a module update. Recheck integrity after major failures. Do not assume a permanent fix exists.
Step order that avoids wasted module installs
Follow a fixed step order for attestation work. Test integrity first. Record the failing level. Install one fingerprint module second. Test again third. Add a deny list fourth. Test again fifth. Clear app data sixth. Test again seventh. That order isolates each change. Skipping steps creates confusion.
Do not install a hiding module and a fingerprint module at the same time. A simultaneous install hides which one helped. It also hides which one broke an app. One change at a time feels slow. It produces a reliable diagnosis. Reliability matters more than speed here.
Check manager hiding settings before adding modules. A renamed manager app may already pass basic checks. A hidden manager reduces detection surface. That simple step may fix a basic integrity failure alone. Adding modules before hiding the manager wastes effort.
Test with an integrity checker that reports levels clearly. A checker that only says pass or fail hides useful detail. A checker that reports basic and device and strong levels separately guides the next step. Choose a checker with level detail. Record all three levels each time.
Watch for app-specific caches after each change. A banking app may cache an old attestation result for days. Clearing data forces a fresh check. Clearing cache alone may not force it. Use full data clear for the test app when a fix seems ignored. Remember to log in again after clearing.
Document the fingerprint version that works for your build. A working fingerprint today may expire after a server change. A documented version lets you notice when it changes. It also lets you roll back to a known version if a new one fails. Documentation turns luck into repeatability.
Consider a second profile for strict apps when attestation cannot pass. A work profile or a secondary device can host payment apps. The rooted phone can host everything else. That split is a practical survival strategy. It avoids endless module chasing for one strict app.
Test attestation after each system app update as well. A system app update can change detection behaviour without a full system update. A quick integrity check after such updates catches regressions early. Early catches allow a module update before a payment deadline.
Keep a fallback plan for strict apps in your notes. Note which apps need device integrity and which need strong integrity. Note the alternative access method for each strict app. A written fallback prevents panic when a check fails suddenly. The guide on fixing crashes after a framework install helps separate a crash from an attestation close. The guide on building a complete rooting survival plan covers broader fallback planning.
Common mistakes
- Chasing strong integrity when the target app only needs device integrity.
- Adding five hiding modules at once and then guessing which one broke an app.
- Forgetting to clear app data after a fingerprint change and testing a cached failure.
- Using a stale fingerprint from an old build that no longer passes checks.
- Keeping every module enabled during attestation testing instead of a minimal set.
Frequently asked questions
Why did attestation pass yesterday and fail today?
Attestation rules can change on the server side. A module fingerprint can expire. A system app update can change detection. Recheck your fingerprint module version. Test again after updating it.
Does a fingerprint module make my phone look like another model?
It presents a certified profile for attestation checks. It does not change your hardware. Some apps may show the spoofed model in device info. That display difference is a side effect of the spoof.
Can I pass strong integrity with an unlocked bootloader?
On most modern phones the answer is no for a lasting pass. Hardware attestation reports the unlocked state. Temporary bypasses exist on some devices. They break often and vary by model.
adb shell su -c "getprop ro.build.fingerprint"
# Read the current build fingerprint on your own device.
# Compare it before and after installing a fingerprint module.The command above is a generic inspection example written for this guide. It reads the fingerprint property from your own device. It does not change the fingerprint. It does not send data anywhere.
Conclusion
Attestation fixes work level by level. Test your current levels. Apply a current fingerprint module for device integrity. Hide root with a deny list. Use a minimal module set. Clear app data after changes. Accept the strong integrity limit on hardware-backed devices.
Your concrete next step is to run an integrity check today. Record which levels pass and fail. That record decides whether a fingerprint module or a different strategy fits your target app.
