TL;DR: Pure AOSP cannot provide Play Integrity by itself because it lacks Google Play services and the Play Store. On Android 13 or later, a custom ROM with an unlocked bootloader will normally fail device integrity. Diagnose the exact verdict first. For dependable app compatibility, restore the manufacturer’s signed software and relock safely.
Play Integrity on AOSP depends on the operating system, boot state and Google certification. Installing an integrity checker or a root module cannot make every device trusted. First identify whether the problem is missing Google components, a failed verdict or an API error. Update supported components and check the ROM’s known status. If an app requires certified device integrity, the reliable fix is usually the manufacturer’s current signed operating system with a locked bootloader.
By the PrivacyPortal team
Last updated September 2026. Research and links were checked on 24 September 2026.
What Play Integrity checks on AOSP
The Play Integrity API lets an app ask Google about the device and app environment. The app receives one or more verdicts. It then decides what access to allow.
Pure Android Open Source Project builds do not include the official Play Store or Google Play services. Those components provide the normal Play Integrity path. A pure AOSP installation may therefore return an API error instead of a failed integrity label.
A custom ROM with Google apps is different. It can call the API, but Google may not recognise the operating system as a certified manufacturer image. An unlocked bootloader also changes the trust result.
Google’s Play Integrity documentation says Android 13 and later require hardware-backed proof of a locked bootloader and a certified manufacturer image for MEETS_DEVICE_INTEGRITY.
Google explains the service in its official Play Integrity overview. Its verdict documentation describes the labels and platform requirements.
Image caption: The integrity chain starts with the boot state, then the operating system, Google services and the requesting app.
Understand basic, device and strong integrity
The three familiar labels are hierarchical. A device must meet the lower level before it can meet the next one. An app may require only one level, or combine integrity with its own checks.
| Result | What it broadly indicates | Common AOSP outcome | Practical response |
|---|---|---|---|
| MEETS_BASIC_INTEGRITY | The environment shows basic signs of integrity. | Some custom ROMs pass, while altered or blocked builds may fail. | Check root changes, ROM status and Play component errors. |
| MEETS_DEVICE_INTEGRITY | Google recognises a genuine and certified device environment. | Usually fails on Android 13 or later with an unlocked bootloader or uncertified image. | Use the current manufacturer image and lock the bootloader safely. |
| MEETS_STRONG_INTEGRITY | The device meets stricter hardware and security requirements. | Not a realistic target for a normal unlocked custom-ROM setup. | Return to a supported stock configuration if an app demands it. |
Passing one checker does not guarantee that banking, wallet, health or streaming apps will work. Those apps can inspect installation source, root traces and local app lists. They may also apply account-level or server-side risk rules.
Why Play Integrity on AOSP fails
The required Google components are absent
Pure AOSP has no official Play Store or Google Play services. A checker may fail to connect, report an API problem or show no verdict. This is not the same as failing basic integrity.
MicroG and compatibility layers can support many Google-dependent apps. They do not turn an uncertified AOSP build into a manufacturer-certified image. Check your ROM’s documentation before adding a Google package. Flashing the wrong package can cause boot loops or broken setup.
The bootloader is unlocked
An unlocked bootloader lets you install another operating system. It also breaks an important part of Android’s verified boot trust chain.
Do not lock the bootloader while an incompatible custom image is installed. The phone may refuse to boot and can become hard to recover. Only relock when the device maintainer explicitly supports it with that exact signed build.
Android’s Verified Boot documentation explains how the operating system is checked from the hardware root of trust.
The ROM or fingerprint is not recognised
A custom ROM may present a build fingerprint from another device. Community modules also rotate fingerprints when Google stops accepting them. A green result can disappear without any local change.
Some ROM builds fail basic integrity before any module is installed. In practice, piling more modules onto that baseline rarely gives a stable result. Ask the ROM maintainer whether the exact release has a known integrity fault.
The app uses extra checks
Google Wallet and financial apps can make decisions beyond Play Integrity. ChatGPT and other apps may also verify their Play Store installation source. A separate checker can therefore look healthy while the target app still refuses access.
No module can promise to defeat a named bank’s controls. Keep a supported device or web access available for services you cannot risk losing.
How to troubleshoot Play Integrity on AOSP
Use this numbered workflow on your own device, and stop once you find the failing layer.
- Back up first. Copy photos, authenticator recovery codes and app data to a separate device or encrypted storage.
- Record the phone model, Android version, ROM build, bootloader state, root manager and installed modules.
- Install Play Integrity API Checker from the “Modules, apps & files to try” section supplied with this guide. Do not use YASNAC because its SafetyNet-based result is obsolete.
- Open the Play Store, select your profile, then open Settings and About. Run the built-in integrity check if your version offers it.
- Update the official Play Store, Google Play services and Google Play system update. Reboot once after all updates finish.
- Run one check and note the exact verdict or API error. Avoid repeated rapid checks because results may be rate-limited.
- If there is an API error, confirm that the ROM’s Google package is supported. Reinstall only through the ROM maintainer’s documented method.
- If basic integrity fails, disable recent root modules one at a time. Reboot and retest after each change.
- Experienced users may test Play Integrity Fix through Magisk. Use only its official project release, read its warnings and treat the result as temporary.
- If device integrity remains required, restore the correct manufacturer image. Relock only after verifying that the image and device support it.
Prerequisites and safety checks
Bootloader unlocking wipes user data on most devices. Restoring stock software may wipe it again. Charge the phone, use a sound USB cable and keep the exact factory image ready before flashing.
- Confirm the precise model and regional variant.
- Install the vendor’s supported flashing tools and drivers.
- Save recovery codes outside the phone.
- Export anything that cloud sync does not cover.
- Check whether unlocking affects warranty or support in your region.
- Expect root and custom recovery to affect over-the-air updates.
If the phone is your only route to banking or two-factor authentication, prepare another access method before changing it.
How to verify the result
Reboot after the final change. Wait for the Play Store and Google Play services to settle, then run one built-in Play Store test. Compare it with one result from Play Integrity API Checker.
Also open Play Store Settings and check the certification entry. Certification and an integrity verdict are related, but they are not identical. Test the target app last because it may cache an earlier failure.
A useful log records the ROM build, Play system update date, Play Store version, module state and each verdict. That makes later AOSP Play Integrity troubleshooting much less speculative.
Image caption: Record each verdict and configuration change so a cached failure is not mistaken for a new result.
Can a Play Integrity module for AOSP fix it?
A Play Integrity module for AOSP may change properties or supply a community fingerprint. Play Integrity Fix, often called PIF, is the best-known example. Its official source and warnings are on the Play Integrity Fix GitHub project.
PIF can help some rooted devices obtain a basic or device verdict for a time. It does not certify the ROM. Google can reject a fingerprint later, and an app can still detect other changes.
Play Integrity Fix v19.2 is a community release line, not a Google-supported route to device certification.
Variants such as Play Integrity Fork, PIF NEXT and osm0sis inject builds use different controls. Their files are not interchangeable. The inject variants and manual configuration are poor starting points for beginners.
On Android 14 and later, community reports warn that spoofing the SDK value presented to the Play Store can cause crashes. Leave “Spoof SDK version to Play Store” off unless the module’s current documentation clearly supports your setup.
Root modules also increase complexity and attack surface. Review source code, download from the named project and remove abandoned modules.
Why Play Store downgrade advice is risky
Community reports often mention Play Store 44.9.20-23 or 44.8.15-31. Some users found that later releases changed their verdict. That does not make an old Play Store a durable fix.
A downgrade can need signature-bypass tools such as CorePatch. It may also require LSPosed modules that block updates. Each added hook creates another failure and security risk. The store can update after a reboot, while server-side checks can change at any time.
We do not recommend freezing an old Play Store on a phone used for sensitive accounts. It leaves a security-sensitive component behind current fixes. It may also break purchases, licensing or app updates.
If you test a historical version on a spare device, document the original version and source. Be ready to restore the current official package. Never install a repacked store from an unknown file host.
Image caption: A version downgrade may change one verdict while weakening the wider update and security chain.
A practical decision framework
The best route depends on what you need from the phone. “Pass everything” is not a stable goal because each app sets its own policy.
| Your priority | Best route | Main trade-off |
|---|---|---|
| Pure de-Googled use | Keep pure AOSP and choose apps that do not require Play Integrity. | Some banking, wallet and media apps may be unavailable. |
| Custom ROM experimentation | Use a supported Google package and test PIF only on a non-critical device. | Verdicts can change, and root adds maintenance work. |
| Reliable banking or work apps | Use the current manufacturer OS with a locked bootloader. | You lose some custom-ROM freedom. |
| Privacy with low maintenance | Choose a supported privacy-focused OS and accept its stated app limits. | No project can promise support for every protected app. |
Our guide to installing GrapheneOS explains the supported installation model for compatible Pixel devices. Our guide to de-Googling Android also covers less disruptive privacy options.
PrivacyPortal can help readers choose a privacy-first phone setup. App compatibility should still be checked against the services you depend on.
Common pitfalls that waste time
- Treating an API error as a failed verdict: missing or broken Google services need a different fix.
- Testing too many changes together: you cannot identify which module caused the result.
- Clearing every Google app repeatedly: this can remove state without fixing certification.
- Trusting one green checker: the target app may use extra local and server-side checks.
- Using leaked keyboxes: they can be revoked and may expose sensitive trust material.
- Relocking on an unsupported image: this can leave the phone unable to boot.
- Ignoring updates: old store and service builds may carry known security faults.
In practice, the cleanest way to fix Play Integrity on custom ROM is first to define the required verdict. If the app needs certified device integrity, restore supported stock software. If it needs only basic integrity, remove local causes before adding more modules.
At the 24 September 2026 research cutoff, pure AOSP still did not include the official Play Store or Google Play services required for the standard Play Integrity path.
Frequently asked questions
Can pure AOSP pass Play Integrity?
Pure AOSP does not include the official Google components used by Play Integrity. A ROM can bundle or support Google apps, but that does not make it a certified manufacturer image. On Android 13 and later, an unlocked custom-ROM device will normally fail device integrity.
Can I pass Play Integrity on AOSP with Magisk?
Magisk and Play Integrity Fix may change some verdicts on some builds. The result is unofficial and can stop working without warning. It cannot guarantee access to a bank, wallet or other protected app.
Why does my checker pass while my banking app fails?
The banking app may check root traces, installation source, app lists or account risk. It may also cache an earlier result. A Play Integrity verdict is only one input to the app’s decision.
Does unlocking the bootloader erase the phone?
Yes, bootloader unlocking normally performs a factory reset. Back up before starting. Relocking may also wipe data, and it is unsafe when the installed image is not approved for relocking.
Will restoring stock software fix Play Integrity on AOSP?
Restoring the exact current manufacturer image and safely locking the bootloader is the most reliable route. The device must also remain supported and certified. An app may still apply separate account or security checks.
Is strong integrity required for every app?
No. Each app developer chooses the required verdict and response. Some apps accept basic integrity. Others require device or strong integrity, and some run additional checks outside the API.
Should I downgrade the Play Store?
Not on a security-critical phone. Old Play Store builds may lack fixes and can update again automatically. A downgrade is an unstable community experiment, not a dependable way to pass Play Integrity on AOSP.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
