Google has introduced AndroidX Security State libraries to let applications verify security patch status at the individual component level rather than depending on a single, device-wide patch date. The new release provides a centralized mechanism for assessing Android device security, giving developers and enterprise tools more granular verification and greater flexibility.
Component-Level Patch Verification Replaces Monolithic Dates
Traditionally, the Security Patch Level (SPL) operates as a monolithic patch number that encompasses the entire system software stack running on an Android device. The new mechanism shifts away from this single date by enabling component-level security verification. This change gives developers more precise visibility into available remediations across the software ecosystem.
The AndroidX Security State library defines three distinct patch levels for software components. The Device SPL is queried directly from the running system without network access to indicate the currently installed patch level. The Published SPL represents the latest patch level officially published by Google for a given component. Meanwhile, the Available SPL identifies the patch level ready for download and installation on that specific hardware.
Security State Library Categorizes Components into Three Tiers
Under the new architecture, the Security State library categorizes components into three distinct tiers. It distinguishes among the core Android OS system, OS subsystems updated via Google Play known as system modules, and the device kernel. By surfacing these three distinct patch levels across these specific layers, enterprises and developers can pinpoint missing patches and initiate proactive remediation.
Banking, fintech, and healthcare applications can utilize Device and Available SPLs to verify device security before permitting sensitive actions. Instead of executing a blanket rejection of a request, applications can prompt users to install specific OS component updates first. Developers can also check the patch status of individual CVEs before running security-sensitive operations involving hardware or software components like NFC or Bluetooth.
Built-In Functions and OEM Companion Libraries
The library supplies a set of programmatic functions for developers to query device status directly. The queryAllAvailableUpdates() and fetchAvailableSecurityPatchLevel() functions aggregate data retrieved from the current device to discover pending security updates across system modules. Additionally, the areCvesPatched() function checks whether specific CVEs have been addressed on the device, while isDeviceFullyUpdated() confirms whether all available security patches are installed. Developers can also generate standardized URLs for security bulletins and CVE details using createVulnerabilityReportUrl().
To support this ecosystem, Google built the Security State Provider library as a companion tool specifically for original equipment manufacturers. This companion library standardizes how update clients communicate available updates to Android apps. Consequently, an application does not need to determine whether an update originates from Google Play, Google’s OTA client, or a proprietary OEM client.
Android Security Patch Inquiries
What does the Device SPL measure?
The Device SPL is queried directly from the running system without requiring network access to indicate the security patch level currently installed on that specific component.
How do banking apps use the new libraries?
Banking and enterprise applications use Device and Available SPLs to verify that a device is secure before allowing sensitive actions, prompting users to install missing updates when necessary.
What is the role of the Security State Provider library?
The Security State Provider library is a companion tool for OEMs that standardizes how update clients inform Android apps about available updates across different distribution channels.