Google has introduced new AndroidX Security State libraries to enable component-level security checks, moving beyond reliance on a single security patch date.
Google’s AndroidX Security State libraries mark a major change in how device security is assessed, allowing developers and enterprises to evaluate security patches at the component level rather than relying on a single security patch date. The update, launched with stable versions of Security State 1.1.0 and Security State Provider 1.0.0, addresses the growing complexity of Android’s modular update system, where security fixes arrive through multiple channels.
Introducing Three Security Patch Indicators
The new framework introduces three distinct security patch levels to provide a more accurate picture of a device’s security posture. The Device Security Patch Level (DSPL) reflects what is currently installed, the Published Security Patch Level (PSPL) shows the latest patches published by Google, and the Available Security Patch Level (ASPL) identifies updates ready for installation. This approach allows apps and administrators to determine whether specific vulnerabilities have been addressed without relying on a single, potentially outdated calendar date.
As Android has evolved to deliver rapid, independent component updates through modular systems like Google Play system updates, relying on a single SPL build property is no longer the best way to determine a device’s true security posture,
engineers explained in multiple sources. The shift is critical for enterprises managing large fleets of devices, as it enables more precise security policies and reduces false rejections of devices that may still be secure despite an older headline patch date.
Enabling Component-Level Security Checks
The Security State library allows apps to query the status of individual Common Vulnerabilities and Exposures (CVEs), enabling security-sensitive applications to verify whether specific fixes are in place before granting access to sensitive data. For example, a banking app could check if a Bluetooth vulnerability has been patched before allowing a transaction. The Security State Provider library, tailored for OEMs, standardizes how update clients communicate with apps, ensuring consistency across different update mechanisms like Google Play, OTA, and proprietary systems.
Developers can use functions like queryAllAvailableUpdates()
and isDeviceFullyUpdated()
to programmatically assess device security. The libraries also integrate with the Open Source Vulnerabilities (OSV) database, providing detailed reports on CVEs and generating standardized URLs for security bulletins. This level of granularity is particularly valuable for Android 17, which introduces Supplemental Patches XML, allowing manufacturers to report backported fixes separately from platform updates.
Instead of relying on monthly security patch dates, kernel security levels utilize version numbers like 5.15.159 or 6.1.91. Android devices equipped with Google Mobile Services (GMS) receive ASPL details through Google Play system updates, and Google Over-The-Air (GOTA) has also implemented the framework. The company mentioned that it is collaborating with device manufacturers to align their OTA update clients with the standardized system.
OEMs Drive Framework Adoption
While the new libraries offer advanced security checks, their effectiveness depends on OEM adoption. Google emphasizes that the transition will not be uniform across the Android ecosystem, as update clients must expose the necessary data for the system to function. Early adopters like Google Play and GOTA have already integrated the framework, but broader consistency will require collaboration with device manufacturers.
The shift to component-level security verification signals a move toward more dynamic and context-aware security practices. By focusing on actual patch statuses rather than calendar dates, Google aims to reduce unnecessary restrictions while ensuring critical vulnerabilities are addressed. However, the success of this approach hinges on widespread adoption and the ability of developers to use the new tools effectively.
“The true value of this unified security view is already being demonstrated through our early partners. By integrating this library, Android Enterprise partners can make better informed access decisions.”
Google, via Blog
Android users are unlikely to observe an immediate new security feature or significant adjustment in their device settings. The biggest changes will happen behind the scenes as apps gain access to more precise security information. This could result in fewer instances where an app deems a device outdated solely due to an outdated headline patch date.
Google is also preparing another security-related feature for Android 17 called Supplemental Patches XML. This functionality enables manufacturers to specify individual security updates applied beyond a device’s stated security patch level, including those backported to older software versions. The new mechanism enables component-level security verification and provides more precise visibility into available remediations.