Android 17 与 RISC-V 64：AI、车规与虚拟化的新特性机会

Android 17 与 RISC-V 64：AI、车规与虚拟化的新特性机会

版本历史

术语与缩略语

可靠性标记

1. 核心判断（TL;DR）

• 【C】Android 17 新增价值集中在 AppFunctions / Gemini Intelligence 智能体栈、NPU Manager（android.hardware.npu AIDL HAL）异构算力仲裁、AVF / pKVM 与 AAOS 混合临界区显示虚拟化车规能力；三者全定义在 arm64 生产路径，riscv64 未出现在任何正式支持矩阵 [S02][S09][S11][S14][S19]。
• 【C*】AOSP riscv64 公开支持停在“实验性可用”：ART 与 shell 可在 Cuttlefish 运行，NDK 临时版 ABI 未定义；ART 向量 regalloc（#167）与 intrinsics（#165）是公开阻塞项 [S04][S05][S06][S07]。
• 【C】Google 2024 年已将 RISC-V 从 GKI 移除，android17-6.18 仅 arm64；正确方式是社区内核 + AVF / CoVE 替代路径 + 上游化补丁 [S03][S08]。
• 【P】可行新特性机会：基于 RVV 的 AI Runtime 回退与 LiteRT / XNNPACK 路径、NPU Manager HAL 国产 NPU 接入、CoVE 成熟后受保护 guest、AAOS 17 hypervisor 拓扑混合临界区 guest [S09][S13][S16][S19]。

2. 问题、范围与方法

本报告回答的问题是：在 Android 17（API 37）已发布特性中，哪些与 AI、车规、虚拟化相关的能力可以在 RISC-V 64 上提前布局，当前差距是什么，以及验收条件如何定义。研究范围限定在 Android 17 官方文档、AOSP RISC-V 公开移植、AVF / pKVM / CoVE 虚拟化路径、AAOS 17 SDV 以及国内芯片与软件生态；不评估未发布硬件跑分，也不预测 Google 是否会在未来 GKI 中恢复 riscv64 支持。

研究方法包括四步：第一，逐条审阅 Android 17 release notes、API 37 变更与 AOSP android17-release 分支源码，标记与 RISC-V 相关的接口与限制；第二，跟踪 google/android-riscv64 仓库 issue、RISC-V International sig-android 邮件列表与国内厂商仓库，确认移植阻塞项；第三，将 AI、虚拟化、车规三条技术线映射到 RISC-V 现有能力（RVV、KVM RISC-V、CoVE、Trusty），识别可落地的最小可行产品（MVP）；第四，用固定结构输出主张—证据矩阵、建议—验收矩阵与可证伪结论，便于后续验证与复现。

图 1 展示 Android 17 能力栈在 RISC-V 64 上的分层现状。以此为比较基准，可以直观看到 arm64 生产路径与 riscv64 社区路径之间的断层：规范与 ISA 基线已经齐备，但内核 GKI、ART 向量化、NDK ABI 与受保护虚拟机仍处于未闭合状态。

图 1：Android 17 能力栈在 RISC-V 64 上的分层现状。来源：Android 17 发布说明、android17-6.18 GKI 发布页与 google/android-riscv64 议题整理。[S02] [S03] [S04]

3. 全球技术基线

3.1 平台基线与架构格局

Android 17 在 2026 年第二季度发布，API 级别 37。Google 官方 release notes 明确列出四大主题：智能体操作系统、性能与电池、隐私安全、大屏与可折叠设备 [S02]。从架构视角看，Android 17 延续并强化了 Android 16 开始的“智能体优先”方向，同时在底层把 NPU 算力管理从厂商私有实现提升为系统级 HAL，在虚拟化层把 AVF 从 arm64 独占扩展到 x86_64 测试支持，在车规层把 AAOS 17 推向 SDV 与混合临界区显示 [S19][S20]。

对 RISC-V 64 而言，最不利的基线事实是 GKI 支持范围。AOSP android17-6.18 GKI 发布页明确说明该版本 GKI 仅支持 arm64 [S03]。The Register 2024 年报道 Google 已将 RISC-V 从通用 Android 内核中移除，AOSP 源码中相关维护分支也进入只读归档状态 [S08]。这意味着基于 Android 17 的 RISC-V 设备无法依赖 Google 发布的 GKI 二进制，而必须自行维护内核、Vendor HAL 与 OTA 升级链。

3.2 AI 与智能体

Android 17 的 AI 栈可分为四层。最上层是智能体入口，包括 AppFunctions 实验 API 与 Gemini Intelligence 子层，允许应用把本地功能以语义化方式暴露给系统智能体 [S10][S11]。中间层是 AICore 与 Gemini Nano，负责模型下载、版本管理与在 Private Compute Services 内的推理执行 [S12]。再往下是推理运行时，主要是 LiteRT，提供 CompiledModel API 与 NPU 加速抽象 [S13]。最底层是 NPU Manager（android.hardware.npu AIDL HAL），在 Android 17 中首次以系统 HAL 形式出现，用于仲裁多个 AI 框架对 NPU 的访问，支持 SchedulingConfig 描述延迟、功耗与吞吐量优先级 [S09]。

NPU Manager 是 RISC-V 上最可优先对接的新接口。它不依赖 arm64 特定指令，而是基于 AIDL HAL 与 hidl 迁移接口，理论上任何提供 AIDL 实现的 NPU 驱动都可以注册到系统中。应用层要直接访问 NPU 需声明 FEATURE_NEURAL_PROCESSING_UNIT 特性 [S09]。对于没有 NPU 或 NPU 驱动尚未就绪的 RISC-V 平台，LiteRT 与 XNNPACK 的 RVV 后端可作为 CPU 回退路径，这是当前即可启动的工程方向 [S13]。

3.3 虚拟化与机密计算

AVF 是 Android 13 引入、Android 15–17 持续强化的受保护虚拟机框架。其架构由 VirtualizationService、crosvm、pvmfw 与厂商特定 hypervisor 组成，目标是给工作负载提供比 Android 主 OS 更高的机密性与完整性 [S14]。当前生产可用的是 arm64 + pKVM 路径；x86_64 在 Android 17 中仍处于测试支持阶段，官方文档明确标注 not for production [S14]。

RISC-V 的虚拟化路径与 arm64 不同。KVM RISC-V 已进 Linux 主线，并包含嵌套虚拟化能力 [S18]。但 AVF 的 pvmfw 与 pKVM 受保护模式依赖 arm64 的 Realm/PSCI 等扩展，RISC-V 没有等价生产实现。RISC-V 社区最接近机密 VM 的公开方案是 CoVE（Confidential VM Extension）RFC，由 RISC-V 非特权 ISA 委员会提出，定义 TVM / CVM 语义与 TSM 安全监控器接口，并在 rivosinc/cove 有参考实现 [S16][S17]。因此，RISC-V 上的受保护 guest 长期看只能走 CoVE 路线，短期则可先实现普通 crosvm guest。

3.4 车规

Android Automotive OS（AAOS）17 的核心叙事是 SDV：把传统信息娱乐系统扩展为可承载车身控制、仪表显示与第三方服务的软件定义平台 [S19][S20]。Google 在官方博客中提出“Beyond Infotainment”，强调 AAOS 17 引入 hypervisor guest 拓扑、混合临界区显示（Display Safety 框架）与面向 ISO 26262 的功能安全基线 [S19]。

AAOS 17 的车规能力与 RISC-V 的交集在于：RISC-V 在汽车电子中已有应用案例（RISC-V International Automotive Hub 列举了多家芯片厂商方案 [S21]），但 AAOS 17 的 reference stack 目前只公开面向 arm64。要在 RISC-V 上落地 AAOS 17，需要先把 Android 17 系统栈移植到 riscv64，再在车规 hypervisor 上运行 AAOS guest，并通过 Display Safety 框架把关键显示流标记为 ASIL 等级。

3.5 安全基线

Android 17 的安全增强包括 APK Signature Scheme v3.2，引入 ML-DSA 混合后量子签名 [S25][S26]；HPKE SPI 为密钥封装提供标准接口；ACCESS_LOCAL_NETWORK 权限与回环流量跨 profile 阻断进一步强化本地网络隔离 [S02]。这些特性与架构无关，RISC-V 移植时可直接复用 Java / Kotlin 层实现，但底层加密加速（如 ML-DSA 的向量或 NPU 加速）需要针对 RVV 或 NPU 重新优化。

Trusty TEE 是 Android 的参考安全世界实现 [S27]。RISC-V 已有 Trusty 移植工作，但受硬件实现差异影响，各芯片厂商需自行提供 Secure Monitor 与 RPMB 等接口。机密 VM 的长期替代路径 CoVE 与 Trusty 并不冲突：Trusty 负责 TEE 小应用，CoVE 负责完整 guest OS 的机密隔离。

能力成熟度对比矩阵

主张—证据矩阵

本节的可证伪结论包括：（1）若 android17-6.18 GKI 发布页出现 riscv64 构建产物，则“GKI 仅 arm64”结论被证伪；（2）若 google/android-riscv64 issue #167 被关闭并合入主线，则 ART 向量 regalloc 不再是公开阻塞项；（3）若 AOSP 发布 riscv64 版 NPU Manager AIDL 实现或 CTS 用例，则“NPU Manager 未官方支持 riscv64”结论被证伪。

4. 国内发展、差距与机会

4.1 移植公开进展

国内 RISC-V Android 生态主要依赖两条线：一是阿里达摩院 / 玄铁团队自 2022 年起推动的 AOSP RISC-V 上游化工作，二是 RISC-V International sig-android 邮件列表中的社区协作 [S22]。GitHub 上的 XUANTIE-RV/riscv-aosp 仓库提供了面向玄铁平台的构建脚本与补丁集，但 README 明确说明其目标是为上游贡献补丁，而非长期维护独立分支 [S23]。

DeepComputing 在 FOSDEM 2026 的 recap 中展示了在真实 RISC-V 硬件上启动 Android 的进展，强调 Cuttlefish 虚拟设备仍是当前最稳定的开发环境 [S24]。这与 AOSP 官方文档一致：Cuttlefish 是 Android 开发的首选虚拟设备，riscv64 已可在 Cuttlefish 中运行 shell 与部分系统服务 [S32]。

4.2 差距机会与可证伪判断

差距与机会的对应关系可归纳为四类：

第一，内核与启动链。由于 GKI 已移除 riscv64，国内芯片厂商需要基于 Android Common Kernel 的 riscv64 分支自行维护 defconfig、模块 ABI 与 OTA 签名。机会在于可以把内核维护与特定芯片 BSP 深度绑定，形成差异化交付能力。

第二，ART 与运行时。ART 向量 regalloc（issue #167）与 intrinsics（issue #165）是公开阻塞项 [S05][S06]。在解决之前，RISC-V Android 的 Java 应用性能会显著低于 arm64。机会在于国内团队可以投入 ART 后端优化，并把成果反馈到 AOSP，获取上游话语权。

第三，AI 推理栈。NPU Manager HAL 的 AIDL 接口已公开，国产 NPU 芯片可以按接口实现 HAL，并通过 LiteRT 的 delegation 机制接入 [S09][S13]。同时，XNNPACK / LiteRT 的 RVV 后端可作为通用 CPU 回退，不依赖特定 NPU。这是当前风险最低、收益最明确的落地路径。

第四，虚拟化与车规。AVF 的 crosvm 普通 guest 可先基于 KVM RISC-V 跑通，再逐步引入 CoVE 机密 VM [S16][S17]。AAOS 17 的 SDV 与混合临界区显示需要完整系统移植，但国内车规芯片厂商若已具备 RISC-V 座舱芯片，可先以 guest OS 形式在自有 hypervisor 上运行 AAOS，复用 Google 的 reference UI 框架。

可证伪判断：若未来三个月内国内某厂商公开宣称其 RISC-V 芯片已“原生支持 Android 17 GKI”，则可直接用 android17-6.18 GKI 发布页 [S03] 与 AOSP 源码进行核验；若其无法提供与官方 GKI 构建产物等价或兼容的内核镜像，则该主张不成立。

5. 关键机制深挖

5.1 AI 栈端到端：从 AppFunctions 到 NPU Manager

接口与实现依据

Android 17 的 AI 栈入口是 AppFunctions，它允许应用使用 @AppFunction 注解声明可被系统智能体调用的本地功能，并通过 AppFunctionService 生命周期接口进行管理 [S10]。调用方需要 EXECUTE_APP_FUNCTIONS 权限。该层完全位于 Java / Kotlin 框架，与底层 ISA 无关，因此在 riscv64 上只需 ART 正常工作即可运行。

系统智能层由 Gemini Intelligence 与 AICore 组成。AICore 通过 Private Compute Services 分发 Gemini Nano 等模型，推理执行可下沉到 NPU、GPU 或 CPU [S12]。Android 17 新增的 NPU Manager 以 android.hardware.npu AIDL HAL 形式存在，定义了 INpu、INpuClient、INpuSession 等接口，并通过 SchedulingConfig 描述任务的延迟、功耗与吞吐量需求 [S09]。厂商实现该 HAL 后，LiteRT 等运行时可通过 NPU delegation 调用硬件。

失效边界与验证条件

失效边界一：若 NPU HAL 未正确实现 SchedulingConfig 的功耗约束，系统可能在低电量场景下错误地调度 NPU 任务，导致整机功耗超标。验证条件是在电源管理测试中用 powermetrics 或内核 energy model 采集 NPU 任务在电池阈值下的调度结果。

失效边界二：若 LiteRT 的 RVV 回退路径未针对具体微架构调优，推理延迟可能远高于预期，导致智能体交互超时。验证条件是使用 MLPerf Mobile 或自定义 golden 集，对比 RVV 路径与标量路径的 top-1 延迟与精度。

失效边界三：若 AppFunctions 服务在 riscv64 ART 上触发未实现的 intrinsics，可能产生 SIGILL。验证条件是运行 Google 官方 AppFunctions 示例应用并监控 /data/tombstones。

成本与权衡

实现 NPU Manager HAL 需要投入 AIDL 接口实现、VTS 用例与功耗模型调优，周期约 3–6 个月；其优势是可接入多代 NPU 并随 Android 版本升级。实现 RVV 回退路径成本较低，主要工作集中在 XNNPACK / LiteRT 的 kernel 调优，但性能上限受 CPU 主频与向量宽度限制，无法替代专用 NPU。建议两者并行：先用 RVV 回退保证功能可用，再用 NPU HAL 提升性能。

图 2 展示 Android 17 AI 栈从智能体入口到硬件执行体的调用链，以及 RISC-V 落地的两条路径：NPU Manager HAL 直连国产 NPU，或 LiteRT / XNNPACK 经 RVV 回退到 CPU。

图 2：Android 17 AI 栈从智能体到硬件执行体的调用链与 RISC-V 落地路径。来源：AppFunctions、Gemini Intelligence、AICore 与 NPU Manager 官方文档整理。[S09] [S10] [S11] [S12]

5.2 AVF / pKVM / CoVE：受保护 VM 的架构鸿沟

接口与实现依据

AVF 由 VirtualizationService（Java 框架服务）、crosvm（Rust 编写的 hypervisor）、pvmfw（受保护 VM 固件）与底层 hypervisor 组成 [S14]。在 arm64 上，底层 hypervisor 是 pKVM，利用 EL2 虚拟化扩展与 Realm 机制实现受保护 VM [S14]。pvmfw 的源码位于 AOSP Virtualization 模块的 android17-release 分支，负责验证 guest 镜像并配置设备树 [S15]。

RISC-V 没有与 pKVM 等价的受保护 hypervisor 进入 AOSP。KVM RISC-V 主线已支持嵌套虚拟化 [S18]，但受保护 VM 需要额外的安全扩展。CoVE RFC 提出在 RISC-V 上引入 TSM（Trusted Security Manager）与 TVM（Trusted Virtual Machine）语义，目标是为机密计算提供与 ARM CCA Realm 等价的能力 [S16]。rivosinc/cove 仓库提供了 Rust 参考实现，但尚未进入 AOSP [S17]。

失效边界与验证条件

失效边界一：若 crosvm RISC-V guest 未正确处理 virtio 设备的中断路由，可能导致 guest 启动时挂死。验证条件是使用 Cuttlefish riscv64 镜像启动 crosvm guest，并检查 dmesg 中 virtio-blk / virtio-net 初始化日志。

失效边界二：若 CoVE TSM 实现与 KVM 的内存管理冲突，可能导致 TVM 内存在 host 侧仍可访问，破坏机密性。验证条件是运行 CoVE 参考测试用例，检查 TSM 是否正确设置 PMP / IOPMP 隔离。

失效边界三：若 pvmfw 的启动协议未针对 riscv64 的 SBI 与设备树约定调整，安全启动信任链会断裂。验证条件是在 riscv64 上实现 pvmfw 的最小启动路径，并用 U-Boot / OpenSBI 验证签名链。

成本与权衡

普通 crosvm guest 可在 1–2 个季度内基于 KVM RISC-V 跑通，适合作为虚拟化底座 MVP。CoVE 受保护 VM 需要 TSM、固件、内核虚拟化扩展与芯片安全原语的协同，周期约 1–2 年，且依赖 RISC-V International 标准冻结。对于车规等强安全场景，建议先以 Trusty TEE + 普通 guest 满足功能安全需求，待 CoVE 成熟后再迁移机密 VM。

图 3 展示 AVF 受保护虚拟机在 arm64、x86_64 与 riscv64 三种架构上的成熟度闸门。riscv64 当前只能走普通 crosvm guest，受保护 VM 需等待 CoVE 标准化与芯片支持。

图 3：AVF 受保护虚拟机在 arm64、x86_64 与 riscv64 三种架构上的成熟度闸门。来源：AVF 架构文档、pvmfw android17-release 分支与 KVM RISC-V CoVE RFC 整理。[S14] [S15] [S16]

5.3 AAOS 17 混合临界区：从 SDV 到显示安全

接口与实现依据

AAOS 17 的 SDV 架构把车载信息娱乐、仪表、ADAS 与车身控制统一到 Android 平台 [S20]。Google 官方博客提出混合临界区（mixed-criticality）显示，通过 Display Safety 框架把不同 ASIL 等级的显示流分配给不同 guest 或硬件合成器 [S19]。在 hypervisor 拓扑中，AAOS 可作为非安全关键 guest 运行，而仪表等安全关键显示由独立 guest 或裸机 RTOS 负责，两者通过共享显示内存与硬件合成器交互。

RISC-V 车规芯片若要运行 AAOS 17，需要先完成 Android 17 riscv64 系统移植，再在车规 hypervisor 上创建 AAOS guest。RISC-V International Automotive Hub 显示已有厂商在座舱、网关与 MCU 领域布局 [S21]，但尚未有公开产品宣称完整支持 AAOS 17。

失效边界与验证条件

失效边界一：若显示缓冲区未按 ASIL 等级隔离，安全关键显示可能被非安全 guest 覆盖，导致功能安全失效。验证条件是使用 Display Safety 框架的隔离测试，验证不同 guest 的图层是否无法互相写入。

失效边界二：若 hypervisor 的调度抖动超过仪表刷新周期（通常 60 Hz，即 16.67 ms），会导致显示撕裂或延迟。验证条件是在 worst-case 负载下测量 guest vCPU 的调度延迟，要求 P99 < 5 ms。

失效边界三：若 AAOS 17 的 targetSdk 37 大屏适配在 riscv64 设备上未正确实现，应用可能在 sw≥600dp 设备上拒绝 resize。验证条件是运行 CTS 大屏窗口化测试套件，确保应用可正常进入多窗口与自由窗口模式 [S02]。

成本与权衡

AAOS 17 车规落地的最大成本是完整系统移植与认证：需要先解决 ART、NDK、GKI 等基础问题，再投入 hypervisor 集成与 ISO 26262 认证。其优势在于可以复用 Google 的 reference UI、应用生态与安全更新机制。对于国内车规芯片厂商，建议分阶段：第一阶段在 Cuttlefish 上验证 AAOS 17 riscv64 guest 启动；第二阶段在自有 hypervisor 上集成 Display Safety 框架；第三阶段针对目标车型进行功能安全认证。

6. 演进方向与情景

基于以上分析，Android 17 与 RISC-V 64 的演进可划分为三条情景线。

AI 与智能体情景：短期（6–12 个月）可在 riscv64 上跑通 AppFunctions 示例与 AICore 模型下载，验证 Java 层智能体栈与架构无关；中期（12–24 个月）实现国产 NPU 的 NPU Manager HAL，并通过 LiteRT delegation 接入；长期（24–36 个月）形成 RVV 优化回退 + NPU 加速的双路径，支撑端侧大模型推理 [S09][S11][S13]。该情景成立的前提是 ART 向量 regalloc 与 intrinsics 问题取得进展 [S05][S06]。

虚拟化情景：短期（6–12 个月）在 KVM RISC-V 上跑通 crosvm 普通 guest，作为 Android 主 OS 之外的隔离执行环境；中期（12–24 个月）把 crosvm guest 接入 AVF 的 VirtualizationService，实现与 arm64 相同的 Java API；长期（24–48 个月）引入 CoVE 受保护 VM，替代 pKVM 在 RISC-V 上的缺失 [S14][S16][S17]。该情景高度依赖 CoVE 标准冻结与芯片厂商安全扩展实现。

车规与国内生态情景：短期（6–12 个月）在 Cuttlefish 上构建 AAOS 17 riscv64 虚拟设备，验证系统服务启动；中期（12–24 个月）在国内 RISC-V 车规芯片上跑通 AAOS guest，并接入自有 hypervisor 的显示合成器；长期（24–48 个月）通过 Display Safety 框架实现混合临界区显示，并启动 ISO 26262 认证 [S19][S20]。该情景的挑战在于需要同时解决 Android 系统移植、芯片安全扩展与车规认证三重门槛。

7. 建议与验收

7.1 五项建议

1. ART / NDK 基线先行：在 Cuttlefish riscv64 上建立可复现的构建与启动脚本，把 ART 向量 regalloc 与 intrinsics 作为最高优先级阻塞项跟踪 [S05][S06][S32]。
2. AI 栈 MVP：选择 LiteRT + XNNPACK RVV 回退作为不依赖 NPU 的最小可用路径，同时并行定义国产 NPU 的 NPU Manager HAL 接口 [S09][S13]。
3. 虚拟化底座：基于 KVM RISC-V 跑通 crosvm 普通 guest，再逐步接入 AVF VirtualizationService，避免直接攻坚 CoVE 受保护 VM [S14][S18]。
4. 车规座舱 guest：在自有 hypervisor 上验证 AAOS 17 riscv64 guest 的显示与输入通路，优先复用 AOSP 的 reference UI 与 CTS 车规子集 [S19][S20]。
5. 上游化与社区协作：把补丁优先提交到 AOSP 与 RISC-V International sig-android，减少长期维护独立分支的成本 [S22][S31]。

建议—验收矩阵

以下矩阵把第 7.1 节的五项建议映射到可量化的验收条件与验证手段。

7.3 验收核心

验收的核心是“可复现、可量化、可升级”。所有落地路径必须提供：第一，可复现的构建脚本与测试环境（首选 Cuttlefish）；第二，与 arm64 参考实现的量化对比（启动时间、推理延迟、调度抖动等）；第三，向上游 AOSP 合入的路径，避免形成不可维护的私有分支。

8. 不确定性与研究限制

本报告存在以下不确定性与限制：

1. 硬件性能不确定性。RISC-V 高端应用处理器尚未大规模量产，本报告不评估任何未发布芯片的跑分，所有性能推断基于 RVV 理论峰值与已公开的微架构参数。
2. Google 战略不确定性。Google 是否会在未来 Android 版本中恢复 riscv64 GKI 支持没有公开时间表，本报告按“GKI 不恢复”这一保守假设给出建议。
3. CoVE 标准化不确定性。CoVE 仍处于 RFC 与参考实现阶段，最终进入 AOSP 的接口可能与当前草案不同，机密 VM 时间线存在显著不确定性 [S16][S17]。
4. 国内厂商进展不透明。部分国内 RISC-V 芯片厂商的 Android 移植进度未公开披露，本报告仅基于公开仓库与会议资料进行判断。
5. 验证条件依赖工具链。CTS、VTS、MLPerf Mobile 等测试工具在 riscv64 上的完整支持仍需先行验证，部分验收条件可能需要自定义测试替代。

参考来源

附录：研究方法

本研究采用以下四步方法：

1. 官方文档审阅：逐条阅读 Android 17 release notes [S02]、API 37 行为变更 [S01][S30]、AOSP android17-release 分支源码，提取与 AI、虚拟化、车规、安全相关的接口变更。
2. 移植状态跟踪：跟踪 google/android-riscv64 仓库 issue [S04][S05][S06]、RISC-V International sig-android 邮件列表 [S31]、国内厂商仓库 [S23] 与会议资料 [S24]，记录公开阻塞项与进展。
3. 能力映射：将 Android 17 新特性映射到 RISC-V 现有技术基线（RVV、KVM RISC-V、CoVE、Trusty），识别可先行开发的接口面与必须等待标准化的能力。
4. 矩阵化输出：用能力成熟度对比矩阵、主张—证据矩阵与建议—验收矩阵固定结论，确保每条主张均可追溯到来源台账，并给出可证伪的验证条件。

复现本研究的最小环境：一台可访问 AOSP 源码与 Android 开发者文档的网络环境；本地安装 Python 3 与 Graphviz，用于渲染报告中的结构图；Cuttlefish 虚拟设备用于验证 riscv64 系统启动。来源台账中的 Snn 是唯一引用标识。