AndroidX 新增 Security State ，支持可编程的系统安全状态查询

最近谷歌算是正式介绍了 AndroidX Security State Libraries ，包括 androidx.security:security-state:1.1.0 和 androidx.security:security-state-provider:1.0.0 都已经进入 Stable 版本。

简单来说就是增加了一组查询安全补丁状态的 Jetpack API，以前 Android 现在有 OEM System OTA、Google Play System Update / Project Mainline、GKI Kernel 之类，每一个都有不同的更新周期，特别现在还有 Risk Based Update System ，如果没有一个统一的入口，App 端判断系统的安全程度其实还是挺碎片的。

然后官方 Security State 架构图进一步把 Patch Level 拆成三个维度：

状态	问题	数据来源
DSPL --- Device SPL	我现在实际运行的是什么补丁状态？	设备属性、Package/Module 信息、Kernel version
PSPL --- Published SPL	Android 官方现在公布到什么安全状态？	Android Security Bulletin / OSV
ASPL --- Available SPL	我的这台机器现在有没有更新已经可以装？	Google Play System Update / OEM OTA Provider

比如通过 ASPL，现在可以判断 2026-09-05 OTA 可不可以下载？也是 App 可以判断，现在是手机厂商根本还没给这台设备推更新，还是已经支持了补丁，只是用户没有安装。

通过 Security State 现在这个状态可以公开且：

ini 复制代码

val currentSpl =
    securityPatchState.getDeviceSecurityPatchLevel(
        SecurityPatchState.COMPONENT_SYSTEM
    )

val availableSpl =
    securityPatchState.fetchAvailableSecurityPatchLevel(
        SecurityPatchState.COMPONENT_SYSTEM
    )

if (availableSpl > currentSpl) {
    // 当前设备已经存在可安装的安全更新
}

另外就是，如果 System 和 System Modules 已经满足它们真正需要修复的全部漏洞，Security State 会把它们的有效安全状态提升到当前最新 Bulletin 日期，只有只有存在对应漏洞没有解决时，才会停留在更早的 SPL。

简单举个例子就类似：

sql 复制代码

System 原始 SPL：       2026-08-05

2026-09 Bulletin：
System 没有新的适用 CVE

设备已经满足全部 System CVE：
Effective System SPL → 2026-09-05

所以这里的 getDeviceSecurityPatchLevel() 在加载了 vulnerability report 等信息以后，Library 可以根据真正需要修复的漏洞重新计算 effective SPL。

然后 Android 17 又补上了另外一块 Supplemental Security Patches ，比如如某 OEM 声明 SPL = 2026-09-05 ，但是厂商发现 CVE-2026-12345 很危险，然后决定在 10 月正式 SPL 发布之前直接 backport 了修复。

以前这个修复基本没办法通过标准接口证明，因为 SPL 还是是 9 月，但是 Android 17 现在允许 OEM 在 /system、/vendor、/product 等 partition 中放置：

xml 复制代码

<?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 会把这些 supplemental CVE 汇总出来，Security State 的 areCvesPatched() 也会把它们算进去，也就是 OEM 不需要为了证明一个高危漏洞已经 backport，就硬把整个 SPL 日期往后改。

Android 16 以下甚至还有一个挺有意思的兼容路径：

Jetpack 的 SecurityStateManagerCompat 可以自己读取这些 XML，不过 OEM 必须配置相应 SELinux policy，让 untrusted_app 能读取这些特定文件，然后 Android 17 由 Framework SecurityStateManager 做汇总。

这样一来，Android 的安全状态其实已经逐渐变成：

diff 复制代码

System SPL
+ Mainline module versions
+ Kernel LTS version
+ Android Security Bulletin
+ CVE database
+ OEM supplemental CVEs
+ 当前可用 OTA

最后才得到 App 真正看到的 Security State。

而且实际上 ASPL 等于是搞了一套 OTA Provider 协议，在 security-state-provider 的实现里面，App 自己肯定不可能知道三星、小米、Google OTA 后台到底给这台设备准备了什么固件，所以 Google 定义了一个统一的 UpdateInfoService：

Google Play System Update、GOTA 或 OEM 自己的 updater 都可以实现这个 Service，对外发布自己知道的 ASPL，然后 Client 端的 SecurityPatchState 再通过 AIDL/Bound Service 去查询这些 Provider。

这里还有个细节，最初 AndroidX 只通过 MATCH_SYSTEM_ONLY / FLAG_SYSTEM 过滤 Provider，后来 Google 自己发现这个边界不够，因为 OEM 可以把第三方 App 预装到 system partition，这种 App 理论上也可能伪造一个 Update Service，然后向银行 App 报告"设备已经完全更新"。

所以今年 3 月 AndroidX 专门提交了一次安全加固：

候选 Provider 除了属于 System App，还必须拥有 READ_PRIVILEGED_PHONE_STATE，这是一个 signature|privileged 权限，普通预装 App 拿不到，也就是说，只依赖 MATCH_SYSTEM_ONLY 不能建立足够严格的 trust boundary。

Provider 另一边也不是一个简单的 Binder 接口， Stable 版本里的 UpdateInfoService 已经包含 per-client session、package name 、 kernel UID 验证、缓存、rate limiting、并发请求合并以及 telemetry。

也就是多个 App 同时过来查询时，它通过 Mutex / double-checked locking 防止 OTA 后端瞬间发出一堆相同请求，默认还有类似"一小时一次"的 throttling 机制。

所以普通 App 调用 ASPL 本身不需要任何 privileged permission，这层权限落在数据提供方 ，不是查询方，fetchAvailableSecurityPatchLevel() 和 queryAllAvailableUpdates() 对 Client App 无需额外 Manifest 权限。

不过这里还有个区别，就是 Security State 和 Play Integrity 的关系，其实这样 Security State 只评价 software patch compliance 和 update availability，而设备有没有被 root、系统是否被篡改、是不是正版可信设备、App 是否被修改，这些仍然属于 Play Integrity 的范围，大概类似：

问题	Security State	Play Integrity
System 补丁版本	✓
Mainline 更新状态	✓
Kernel LTS 状态	✓
是否存在待安装 OTA	✓
某个 CVE 是否已修	✓
Root / 系统篡改		✓
设备真实性		✓
App 完整性		✓

所以，如果是真正严格的金融或者企业 App，最终比较合理的方案其实是两套一起用：

Integrity 先回答"我能不能相信这台设备所处的运行环境"
Security State 再回答"这个可信环境里的 System、Mainline、Kernel 到底补到什么程度"

对于普通 App，这套东西大概率没必要接，但是对于金融、支付、企业设备管理、身份认证、硬件钱包、医疗以及高安全要求 App，这套判断还是有必要接入的。