How Android Versions Affect Play Integrity API and Mobile Pentesting

Google's Play Integrity API helps Android apps determine whether they're running on a trustworthy device. But mobile security teams need to understand an important limitation: a MEETS_STRONG_INTEGRITY verdict doesn't represent the same security bar across every supported Android version.

The dividing line is Android 13.

On Android 13 and above, Strong Integrity includes requirements around recent security patches that make rooted-device bypasses significantly harder and less reliable. On Android 12 and below, those patch-recency requirements don't apply, leaving older, more mature techniques available to satisfy integrity checks.

An app can enforce MEETS_STRONG_INTEGRITY while keeping a low minSdk, supporting older Android versions with different integrity requirements. Raising the minimum version can strengthen the device-security baseline, but may also exclude legitimate users whose devices no longer receive security updates.

For mobile pentesting, whether rooted-device dynamic analysis is practical depends on which Android versions the app supports, what integrity verdict it requires, how it enforces that verdict, and whether it implements additional root-detection controls.

How Play Integrity Works Across Android Versions

Google's Play Integrity API replaced the SafetyNet Attestation API, which Google stopped supporting in January 2025. It returns device-integrity verdicts that apps can use to assess whether a device meets their security requirements:

• Basic Integrity provides a baseline level of device integrity.
• Device Integrity provides stronger assurance that the app is running on a genuine Android device with an approved system image.
• Strong Integrity, represented by MEETS_STRONG_INTEGRITY, adds further requirements—but those requirements differ by Android version.

On Android 13 and above, Strong Integrity requires Device Integrity and security updates within the previous year. Android 12 and earlier don't have the same patch-recency requirement, so a device may stop meeting Strong Integrity as its security updates become outdated, even if it hasn't been rooted or otherwise modified. The same verdict can therefore represent different underlying security requirements depending on the Android version.

The Trade-Off: Security vs. Compatibility

An application's minSdk determines the oldest Android version it supports. Choosing a lower minimum can expand its user base, but it also means accepting the security implications of supporting older Android environments.

The decision comes down to a trade-off: is preventing tampering more important than supporting the broadest possible range of devices?

The answer depends on the application's purpose and threat model. A banking or government app handling sensitive transactions may prioritize device integrity, even if that means excluding users on outdated hardware. A marketing, event, or informational app may prioritize broad accessibility. Industry alone doesn't determine the right choice; the application's function and risks do.

Make this decision with the right security and business context, rather than leaving it implicitly to a third-party development team. When Strong Integrity is part of an application's security model, minSdk is more than an implementation detail: it influences both device compatibility and the assumptions a pentest can make about integrity enforcement.

How Android Version Affects Rooted-Device Testing

The Android version an application supports can affect how practical rooted-device testing is.

On Android 12 and earlier, the lack of the newer patch-recency requirement can make meeting Strong Integrity requirements comparatively easier. However, this doesn't mean every rooted device will receive a MEETS_STRONG_INTEGRITY verdict. Rooting, Play Integrity verdicts, and an application's own enforcement logic are separate concerns.

Testing an application that genuinely requires Android 13+ Strong Integrity can be more challenging. Magisk modules such as Play Integrity Fix (PIF) have been used to work around Play Integrity checks, but configurations that work today may stop working as Google changes its server-side enforcement or invalidates device identities and fingerprints used by these techniques.

For pentesters, the key distinction is not that rooted testing on Android 13+ is always unreliable. It's that testing an application that strictly enforces Android 13+ Strong Integrity can introduce an unstable dependency into the assessment. This can affect the feasibility and predictability of dynamic testing, so clarify the required Android versions and integrity controls during scoping.

When rooted-device instrumentation is impractical, static analysis and API-layer testing can help maintain assessment coverage. The testing approach may need to change, but device-integrity controls shouldn't prevent the assessment from examining the application's security.

What This Means for Mobile Pentest Scope

When scoping a mobile application pentest, Play Integrity shouldn't automatically lead you to conclude that rooted-device testing will be difficult or impossible.

Start with four questions:

• What is the application's minSdk?
• Which Play Integrity verdict does it require?
• How does the app validate and enforce that verdict?
• Does the application implement separate controls, like root detection?

These answers help determine the appropriate testing approach and identify assumptions to validate during the assessment. Consider separate root-detection controls alongside Play Integrity when evaluating the application's defenses.

Conclusion

A device-integrity policy should be a deliberate security decision, not simply a default inherited from the development process.

Validate that your chosen requirements provide the protection your application needs, and test how those controls behave under realistic attack scenarios.

If you're unsure whether your current implementation provides adequate protection, a mobile application penetration test can help identify weaknesses in your device-integrity controls and where additional protections may be needed.