AndroidX Security State 1.1.0 能解决什么？DSPL、PSPL、ASPL 与 APP 加固有什么区别？

AndroidX Security State 1.1.0 为应用提供系统、Mainline 模块和内核的组件级补丁状态，并可查询可用更新与特定 CVE 修复信息。它描述的是设备操作系统安全证据，不是应用加固能力；金融和高价值业务应把设备状态、App 身份、运行环境与业务上下文分开记录，再由服务端决定如何处置。

摘要

Android 设备更新不再总是随一条系统补丁日期同步到达。系统 OTA、Google Play 系统更新、内核版本和 OEM 补充修复可能按照不同节奏变化。AndroidX Security State 将这些信息组织为 DSPL、PSPL、ASPL 和 CVE 修复查询，帮助应用把“当前已安装什么”“公告发布了什么”“可信更新提供方报告有什么可用”拆开观察。

读者对象

本文面向金融、支付、医疗、企业应用、MDM、Android 安全和移动发布团队，适用于需要定义设备补丁基线、理解等待安装更新、或在高价值操作前检查特定平台漏洞状态的场景。它解释官方 API 的数据语义和工程边界，不提供具体机型的查询结果，也不表示御盾已经完成某款 ROM、设备或客户应用的 Security State 兼容测试。

核心结论

• DSPL 描述设备组件当前运行的补丁状态；PSPL 描述 Android 安全公告和公开漏洞数据中的已发布基线；ASPL 通过设备上的可信更新提供方查询可用状态。
• System、System Modules 与 Kernel 应分开理解。内核补丁版本可能以 LTS 版本号表示，不一定是日历日期。
• ASPL 是否完整可见，取决于对应更新提供方是否发布信息，以及查询数据的新鲜度；提供方未接入、超时或缓存过期不能被解释为“没有风险”。
• areCvesPatched() 可查询具体 CVE 是否已被记录为修复，但这不等于设备没有其他漏洞、没有被攻破或对目标业务绝对安全。
• AndroidX Security State 评估软件补丁与更新可用性。硬件设备真实性、篡改状态和 Play 应用许可等问题仍需结合 Play Integrity 等不同证据。
• 御盾 APP 加固关注应用自身代码、二进制、完整性和运行时保护，不替代 Android/OEM 补丁，也不决定客户账号或交易授权。

事实依据与脱敏证据

发布事实核对。 AndroidX Security State 1.1.0 于9月9日进入稳定版本；Android Developers 于9月17日发布面向开发者的统一状态说明。AndroidX 版本说明列出统一查询、待处理更新发现、特定 CVE 检查和设备更新评估等能力。官方指南进一步列出组件范围、Android 版本差异、数据加载要求与可信更新提供方边界。以上均为官方资料核对，不是御盾设备测试结果。

技术拆解：为什么一个 Security Patch Level 不够

Android 平台组件具有不同更新路径。系统框架通常通过设备厂商 OTA 更新；部分模块可经 Google Play 系统更新独立更新；内核也可能沿自身版本维护节奏变化。传统构建属性里的安全补丁日期仍然有价值，但它不是所有系统组件状态的完整快照。

Security State 按组件提供安全补丁视图：

DSPL：设备现在实际运行什么

Device SPL 是设备上当前安装并运行的组件级补丁状态。官方文档说明可同步从设备属性和配置读取，不需要为读取这部分状态先发起网络请求。System 与 Mainline 通常以日期型值表示；Kernel 则以版本型值表示。对兼容工单来说，DSPL 应同时记录组件、原始值和采集时间，而不能只保存一条“系统补丁日期”。

DSPL 是环境观察字段，不是可信执行环境或远程证明。若应用运行在高权限失陷或信息采集路径被篡改的环境中，客户端读到的本地值不应被后端单独当作最终裁决。高风险业务还要考虑平台完整性证据、设备管理状态和服务端会话上下文。

PSPL：公开资料已经发布到什么基线

Published SPL 来自 Android 安全公告和公开漏洞数据。它提供参考基线，帮助应用将设备当前组件值与已发布安全信息对照。System、System Modules 与 Kernel 的表示方式不完全相同，内核可能对应多个受支持 LTS 版本，因此不能把所有比较逻辑简化为字符串日期排序。

PSPL 是公告与漏洞数据库中的公开基准，不是某台设备已经安装该补丁的证明。遇到某个组件没有当月新修复、风险基于更新政策变化或厂商补充回补时，应根据官方数据和组件语义解释结果，不要只凭年月日推断漏洞状态。

ASPL：设备更新提供方报告有什么可用状态

Available SPL 表示通过设备上可信更新提供方查询到的可用补丁状态。查询通过 IPC 异步进行，而不是读取一个本地静态日期。Google Play 系统更新可为 GMS Android 设备上的 Mainline 模块提供 ASPL；Google OTA 客户端也已提供系统 OTA 信息，Google 正与更多 OEM 推进 Provider 标准化接入。

因此，ASPL 的覆盖与查询新鲜度需要单独处理。Provider 未实现接口、未发现可信服务、超时、缓存同步受限或返回的数据较旧，都不应被合并成一个“设备没有更新”的结论。官方 API 文档指出，便捷查询在没有更高可用版本或提供方结果不可用时，可能回退到设备当前 SPL；对银行或企业设备策略这类合规敏感场景，应使用能够查看各 Provider 结果与最近成功同步时间的查询路径，而不是只看聚合后的一个值。

工程落地：从组件状态到高价值业务决策

金融应用不必在首页启动时就因为一个补丁字段不满足门槛而封禁所有访问。官方给出的应用场景是：在高价值支付或凭据注册等敏感流程前，比较当前安装状态与可用更新；若更新确实待安装，可以引导用户前往系统设置完成更新。策略应由业务风险、设备管理要求、更新可达性和证据新鲜度共同决定。

推荐采用以下业务处理顺序：

1. 确定业务触发点。 仅在需要时执行高价值操作前检查状态，避免把不相关的浏览行为与敏感交易混为一谈。
2. 读取本地组件状态。 分别采集 System、System Modules、Kernel 的 DSPL，并保存组件、值和时间。
3. 准备公开漏洞数据。 需要 PSPL 或 CVE 判断时，按官方指南获取对应漏洞报告数据并加载；网络不可用或数据未加载时保留该环节未知。
4. 异步检查更新提供方。 获取 Provider 结果、状态和最近同步时间；必要时查询各 Provider 明细，不把聚合回退值误当作“明确没有更新”。
5. 按业务策略解释。 结合更新可安装性、相关 CVE、Play Integrity、账号与会话、交易金额及设备管理状态生成服务端风险上下文。
6. 由后端决定动作。 后端可以允许、要求更新、要求二次验证、限制某类高风险操作或转人工审核；不能让一个未验证的客户端布尔值直接放行资金操作。

下面的记录片段仅说明字段如何分层，值是语义占位符，不代表任何设备采样或 PoC：

device_security_state:
  captured_at: NOT_RECORDED
  components:
    system:
      dspl: DEVICE_VALUE
      pspl: PUBLISHED_BASELINE
      aspl_provider_status: UNKNOWN
    system_modules:
      dspl: DEVICE_VALUE
      pspl: PUBLISHED_BASELINE
      aspl_provider_status: UNKNOWN
    kernel:
      dspl: VERSION_VALUE
      pspl: SUPPORTED_LTS_BASELINE
      aspl_via: COMPONENT_SYSTEM
  cve_checks:
    requested: []
    result: NOT_EVALUATED
  companion_evidence:
    play_integrity: SEPARATE_SIGNAL
    app_release_identity: SEPARATE_SIGNAL
  decision_owner: CUSTOMER_BACKEND
  device_compatibility_result: NOT_TESTED

这类记录要把“采集到什么”“数据源是否可用”“CVE 是否评估”“最终谁做业务决定”拆成字段。不得把空白的 ASPL、未加载的漏洞报告或失败的 Provider IPC 自动替换成 PASS。离线时可以提供有限功能，但需要明确离线决策属于什么级别、有效多久以及恢复联网后如何补做核验。

Android 版本、数据源与接口覆盖

官方指南说明 Android 11/API 30 及以上支持完整组件查询，包括公告中发布的 Kernel LTS 与 ASPL 可用更新查询。Android 10/API 29 支持 System 与 System Modules 补丁级别，但缺少公告中的 Kernel LTS 跟踪；设备本地内核版本仍可读取。Android 9/API 28 及更早平台没有早期 Mainline 模块模型，系统模块状态会按库定义回退到基线值。应用应通过实际 API 可用性和结果状态建立兼容分支，避免用一个固定阈值猜测设备能力。

漏洞数据获取也与本地状态读取不同。官方指南指出，读取 DSPL 不要求应用额外互联网权限；获取公开 OSV 漏洞报告需要网络，报告加载后，部分查询可以在本地执行。团队要把“网络数据尚未加载”“本地状态读取失败”“Provider 查询超时”“结果明确没有新更新”区分保存，并针对每类情况定义重试与降级策略。

Android 17 补充安全补丁机制允许 OEM 使用 Supplemental Patch XML 声明已应用的特定安全修复。它能帮助更精细地表达回补情况，但前提是数据来源和格式符合平台机制。应用不应自行推断没有公开记录的厂商补丁，也不应把某个 SPL 日期变化直接当作特定 CVE 的唯一证明。

御盾 APP 加固保护哪一层

AndroidX Security State 关注系统软件补丁、组件状态和更新可用性；御盾的职责是对应用自身的 DEX、SO、资源、完整性和运行时风险按照选定策略进行保护。两类证据可进入同一业务风控上下文，但不是同一能力，也不能互相替代。

金融 App 可以把“补丁状态”和“应用候选身份”并列进入 Release 与业务验证。可参考Android系统安全补丁与APP加固兼容验收页，它聚焦系统更新后的兼容性归因；设备完整性可另参考Android设备完整性与Play Integrity。涉及支付风险时，查看金融APP加固与反欺诈边界与御盾性能和兼容性中心。

攻防视角：设备状态是风险证据，不是万能判决器

把补丁状态用于安全决策时，既要防止把已知缺口放任不管，也要避免将不完整数据误判成攻击。Provider 结果可能缺失或陈旧；公开漏洞数据有加载和版本边界；客户端观测也不能在设备高权限失陷时被当作不受影响的可信事实。因此，建议把信号携带来源、组件、时间戳和失败状态送入服务端策略。

举例而言，一台设备有明确可用但尚未安装的更新，与一台 OEM 尚未提供该更新、或当前查询接口没有覆盖的设备，是不同的运维情形。客户可以对高价值动作采用更新提示、额外身份验证或暂时限制特定功能，而不是将所有“非最新”统一标成恶意设备。若业务属于强制受管环境，则组织可另行定义最低基线和例外审批。

御盾不会因为读取到某个 DSPL 就声称“设备安全”，也不会用应用加固结果替代 OS 漏洞修复。适合公开和验收的产品结论应绑定具体御盾版本、策略、目标应用和已测试路径；目前没有针对本页所述 API 的御盾动态兼容 PoC，因此设备、ROM、ASPL Provider 和候选兼容状态保持 NOT_TESTED。

Security Posture Record 与验证门禁

将设备状态接入金融业务前，建议先建立最小可审计记录：

在兼容性验收中，再把原始 Release、基础保护、目标保护和最终签名版本放在相同设备状态与业务流程下比较。验证目标是确认接入 Security State 后查询、异步等待、异常降级和服务端上传都符合项目设计，而不是期待加固改变系统补丁值。没有实际设备记录时，矩阵只能作为计划，不能标成通过结果。

风险边界

本文基于 Android 官方稳定版说明、Android Developers 安全指南、Jetpack 版本说明与 API 参考整理。未运行 AndroidX Security State Demo，未查询 Pixel、Samsung、Xiaomi 或其他设备的 DSPL/PSPL/ASPL，未验证任何 OEM Provider 覆盖，也未执行御盾 Original、Basic、Target 或 Final 的集成测试。文中字段示例是语义占位符，不能视为设备报告或兼容性证据。

AndroidX Security State 提供软件补丁与可用更新信息，不等同于远程设备认证、系统篡改检测、Play 授权校验或全量漏洞扫描。ASPL 是否可观测依赖可信 Provider 接入及数据新鲜度；CVE 查询依赖公开漏洞报告数据与组件支持范围。所有高价值业务策略仍应由客户后端按照组织基线、误判成本、用户可更新性和可恢复方案制定。

常见误区

DSPL、PSPL、ASPL 是三个可以互换的日期。 不是。它们分别表示设备当前状态、公开发布基线和可信更新提供方报告的可用状态；Kernel 还可能采用版本号而非日期。

ASPL 与 DSPL 相同，就能确认没有待安装更新。 不一定。聚合查询可能在无更新、超时或 Provider 不可用时回退到设备当前值。合规敏感场景应核查 Provider 明细和最近同步时间。

areCvesPatched() 返回 true，设备就没有风险。 该结果只回答请求范围内的特定 CVE 是否已修复，不覆盖其他 CVE、运行时篡改、应用漏洞或账号风险。

Security State 可以替代 Play Integrity。 不可以。Android 官方明确区分软件补丁状态与设备真实性、篡改检测和应用许可证据。

御盾加固可以补上手机缺失的系统补丁。 不可以。应用保护和 Android/OEM 系统修复属于不同层，补丁升级与 APP 加固兼容性必须分别验收。

FAQ

Android App 怎么判断手机是否有安全补丁等待安装？

可以评估 AndroidX Security State 的 ASPL 查询，但要确保对应组件有可信更新 Provider 提供信息。对金融或企业合规场景，建议同时检查 Provider 查询结果和最近同步时间；只读到聚合补丁值不足以证明数据新鲜或所有更新渠道均已覆盖。

DSPL、PSPL 和 ASPL 分别是什么？

DSPL 是设备组件当前已安装并运行的补丁状态；PSPL 是 Android 安全公告和公开漏洞数据提供的发布基线；ASPL 是设备可信更新提供方报告的可用补丁状态。它们回答不同问题，应分列记录。

AndroidX Security State 能检测手机是不是 Root 或被篡改吗？

它主要评估软件补丁合规与更新可用性，不是通用 Root 检测器或硬件设备真实性证明。Android 官方建议需要设备真实性、篡改检测或 Play 应用许可判断时，结合 Play Integrity 等独立机制。

areCvesPatched() 是否需要网络？

安全状态的本地查询与公开漏洞报告加载不是同一步。官方指南指出，获取漏洞报告需要网络；报告加载后，特定查询可在本地执行。工程实现应处理报告不可下载、格式无效和数据未加载等情况，不要把这些状态默认解释为漏洞已修复。

这个库会影响御盾加固或 App 兼容性吗？

是否兼容取决于应用集成方式、Android 版本、Provider 响应、网络策略和目标保护配置。当前没有针对御盾候选的专项动态验证结果，因此不能提前承诺所有设备或策略组合通过；应在项目 PoC 中按 Original、Basic、Target、Final 分级确认。

业务可以在 ASPL 查询失败时直接拒绝用户吗？

这是客户的业务策略，不应由单个 API 错误自动决定。需区分设备确实有待安装更新、Provider 不可用、查询超时和网络离线，再根据业务敏感度选择提示更新、二次验证、限制部分操作或人工复核，并提供恢复路径。

延伸阅读与评估入口

需要评估系统更新后的应用兼容性，可从Android安全补丁与APP加固兼容验收开始；需要定义应用保护和验收范围，可查看APP加固PoC验收指南及御盾性能与兼容性中心。在提交兼容性问题时，请说明组件、Android/OEM构建、Provider 状态、候选版本和失败路径；不要公开上传客户包、密钥、账号或完整日志。

官方资料

• AndroidX Security State 版本说明
• 了解设备安全状态
• AndroidX Security State 稳定版公告
• SecurityPatchState API 参考
• Android 17 补充安全补丁