AndroidX Security State: Programmable System Security Patch Queries Now Stable

Google has officially introduced the AndroidX Security State Libraries, with androidx.security:security-state:1.1.0 and androidx.security:security-state-provider:1.0.0 now in Stable. These libraries provide a unified Jetpack API for querying security patch status, addressing fragmentation caused by multiple update channels—OEM System OTA, Google Play System Update (Project Mainline), GKI Kernel, and the Risk Based Update System—each with different update cycles.

Three Patch Level Dimensions

The official Security State architecture splits Patch Level into three dimensions:

DSPL — Device SPL : What patch state is the device actually running? Data sources: device properties, Package/Module info, Kernel version.

PSPL — Published SPL : What security state has Android officially published? Data sources: Android Security Bulletin / OSV.

ASPL — Available SPL : Is there an update already available for this device? Data sources: Google Play System Update / OEM OTA Provider.

For example, via ASPL an app can determine whether a 2026-09-05 OTA is downloadable, distinguishing between the OEM not yet pushing the update versus the user not installing it.

Querying Security Patch Levels

val currentSpl =
  securityPatchState.getDeviceSecurityPatchLevel(
    SecurityPatchState.COMPONENT_SYSTEM
  )

val availableSpl =
  securityPatchState.fetchAvailableSecurityPatchLevel(
    SecurityPatchState.COMPONENT_SYSTEM
  )

if (availableSpl > currentSpl) {
  // Device has an installable security update
}

Effective SPL Calculation

If System and System Modules already satisfy all vulnerabilities they need to fix, Security State elevates their effective security state to the latest Bulletin date. Only when a corresponding vulnerability remains unpatched does the SPL stay at an earlier date. Example:

System original SPL:          2026-08-05
2026-09 Bulletin:
System has no new applicable CVE
Device satisfies all System CVEs:
Effective System SPL → 2026-09-05

Thus getDeviceSecurityPatchLevel() recalculates effective SPL based on actual vulnerability reports after loading them.

Supplemental Security Patches (Android 17)

Android 17 adds Supplemental Security Patches. An OEM may declare SPL = 2026-09-05 but backport a fix for a critical CVE-2026-12345 before the October SPL release. Previously this fix couldn't be proven via standard interfaces because the SPL remained September. Now OEMs can place XML files in /system, /vendor, /product partitions:

<?xml version="1.0" encoding="utf-8"?>
<security-patches xmlns="http://schemas.android.com/security/patches/1.0">
  <patch>
    <id>CVE-2026-12345</id>
  </patch>
</security-patches>

SecurityStateManager

aggregates these supplemental CVEs, and areCvesPatched() includes them. This avoids OEMs having to artificially advance the entire SPL date just to prove a high-severity backport.

Compatibility Path for Android 16 and Below

Jetpack's SecurityStateManagerCompat can read these XML files itself, but the OEM must configure SELinux policy to allow untrusted_app to read those specific files. Android 17 then uses Framework SecurityStateManager to aggregate.

OTA Provider Protocol and UpdateInfoService

ASPL implements an OTA Provider protocol. In security-state-provider, a unified UpdateInfoService is defined because apps cannot know what firmware Samsung, Xiaomi, or Google OTA backends have prepared for a device. Google Play System Update, GOTA, or OEM updaters can implement this Service to publish their known ASPL; the client-side SecurityPatchState queries these Providers via AIDL/Bound Service.

Security Hardening: Trust Boundary

Initially AndroidX filtered Providers only via MATCH_SYSTEM_ONLY / FLAG_SYSTEM. Google later found this insufficient because OEMs can pre-install third-party apps on the system partition, which could forge an Update Service and report "device fully updated" to a banking app. In March, AndroidX submitted a hardening:

Candidate Providers must not only be System Apps but also hold READ_PRIVILEGED_PHONE_STATE , a signature|privileged permission ordinary pre-installed apps cannot obtain. Relying solely on MATCH_SYSTEM_ONLY cannot establish a strict enough trust boundary.

The Provider side is not a simple Binder interface; the Stable UpdateInfoService includes per-client session, package name, kernel UID verification, caching, rate limiting, concurrent request merging, and telemetry. Multiple apps querying simultaneously are protected by Mutex/double-checked locking to prevent OTA backend floods, with a default ~1-hour throttling.

Therefore, ordinary apps calling ASPL need no privileged permission; the permission requirement falls on the data provider, not the querier. fetchAvailableSecurityPatchLevel() and queryAllAvailableUpdates() require no extra Manifest permissions for client apps.

Security State vs. Play Integrity

Security State evaluates software patch compliance and update availability, while device rooting, system tampering, device authenticity, and app integrity remain in Play Integrity's scope:

System patch version : Security State ✓, Play Integrity —

Mainline update status : Security State ✓, Play Integrity —

Kernel LTS status : Security State ✓, Play Integrity —

Pending OTA existence : Security State ✓, Play Integrity —

Specific CVE patched : Security State ✓, Play Integrity —

Root / system tampering : Security State —, Play Integrity ✓

Device authenticity : Security State —, Play Integrity ✓

App integrity : Security State —, Play Integrity ✓

For strict financial or enterprise apps, the reasonable approach is to use both: Integrity first answers "Can I trust this device's runtime environment?" then Security State answers "To what extent are System, Mainline, and Kernel patched in this trusted environment?"

For ordinary apps this integration is likely unnecessary, but for financial, payment, enterprise device management, identity authentication, hardware wallet, medical, and high-security apps, this judgment is worth adopting.