A broader security picture for Android apps

Android has announced the stable release of AndroidX Security State version 1.1.0 and AndroidX Security State Provider version 1.0.0, a pair of libraries designed to centralize how device security and pending updates are evaluated across the Android ecosystem. The company said the goal is to provide developers and enterprise partners with better visibility into the overall security posture of devices, especially where protection depends on more than a single update date or patch number.

The announcement is positioned around the needs of security-critical consumer apps, such as banking, fintech, and healthcare, as well as Mobile Device Management providers. Rather than relying on a coarse, monolithic Security Patch Level, the libraries allow applications to inspect security state per component. Android said this approach gives enterprises and app developers a more accurate view of whether a device is currently protected, whether remediations are pending, and whether specific vulnerabilities have been addressed.

Three patch states, but one security model

The core framework defines three security states for a device component: Device Security Patch Level, Published Security Patch Level, and Available Security Patch Level. Device SPL refers to the security patch level currently installed and running on the device. Published SPL is the latest patch level officially listed in the Android Security Bulletin for that component. Available SPL reflects the patch level ready to be downloaded and installed on the device, as reported by update clients through inter-process communication.

Android said the framework covers the system, system modules, and kernel. The system is updated through standard or OEM system over-the-air updates. System modules are updated in the background through Google Play system updates, while the kernel is evaluated using Long-Term Support release versions rather than a monthly calendar date. This allows app developers and enterprises to consider real component-level protection instead of treating all parts of the device as if they share the same patch status.

Use cases for payment, access and compliance

The libraries are intended for contextual security decisions that reflect actual device posture. Android said a banking or enterprise app can compare a device’s current security patch level to pending updates before initiating sensitive workflows, such as high-value payments or credential enrollment. If a device is waiting for a system update, an app can require the user to update before proceeding with that action. The company said this can reduce dependence on broad device access policies that may be too blunt for nuanced security decisions.

The framework also supports vulnerability-level auditing. Android said developers and enterprises can query whether specific high-risk Common Vulnerabilities and Exposures have been patched on the device, including critical fixes for NFC or Bluetooth before authorizing tap-to-pay or proximity data sharing. The company said such checks provide finer-grained control in situations where a device may appear broadly protected yet still lacks a specific fix relevant to a sensitive workflow.

Enterprise checks at launch and in-app guidance

For enterprises, the libraries can help with synchronous posture checks at app launch. Android said apps can inspect installed patch levels for the system, system modules, and kernel, then compare them with the published patch state to verify whether the device meets a required baseline before unlocking sensitive corporate resources or biometric access. The design allows organizations to decide whether a device should proceed or be directed to update before access is granted.

The company also described pending update prompting as another enterprise scenario. Instead of immediately blocking an employee whose device is slightly behind on patches, an app can query Available SPL to check whether a pending system update or Google Play system update is staged and ready to install. If so, the app can display in-product guidance directing the user to System Settings to complete installation. The same mechanism can support high-assurance use cases that need to inspect whether a specific critical vulnerability has been resolved.

A standard for OEMs and OTA clients

For OEMs and over-the-air client developers, the companion Security State Provider library exposes update availability through standardized mechanisms. Android said Google Play system updates already expose Available SPL across GMS Android devices and that Google Over-the-Air has been onboarded to the standardized framework. The company said it is working with OEMs worldwide to onboard their OTA clients as well.

Android also said the framework improves how backported or supplemental fixes are credited. When a monthly security update does not include new threats for a specific component, the libraries can increase the effective security state for that component so the device is properly recognized as protected against all known threats. Separately, Android 17 adds a mechanism for OEMs to declare security fixes applied above the Security Patch Level through a Supplemental Patches XML file, allowing them to prove compliance without waiting for a full monolithic SPL bump. The Security State libraries surface this information to apps and services as soon as those fixes are implemented.

Sources

• Android DevelopersIntroducing the AndroidX Security State Libraries: A Unified View of Device Security