A
Air官方
【Air 系列 · 鸿蒙 PC 适配全记录】01 / 56
■ 应用：AirAVM（AirAVM）
■ 定位：QEMU 虚拟机方案，在鸿蒙设备上引导运行 Android 系统
■ 上游：QEMU（qemu-vis） ｜ 路线：QEMU 引擎直连 ｜ 版本：1.3.0
■ 开源： https://gitcode.com/Andy88/Harmony-QEMU
■ 市场状态：开发中，即将上架
■ 官网（免费下载）： https://www.shunidc.cn/
————————————————————
开源鸿蒙 PC 社区： https://harmonypc.csdn.net/
PC 社区项目申请： https://atomgit.com/OpenHarmonyPCDeveloper
适配开源地址：https://gitcode.com/Andy88/Harmony-QEMU
环境搭建文章：https://blog.csdn.net/weixin_52908342/article/details/161343743
▍一、为什么要适配 AirAVM
鸿蒙 PC 的应用矩阵里始终缺一块拼图：Android 生态。数以百万计的 Android 应用没有鸿蒙原生版本，其中相当一部分（小众工具、老游戏、行业应用）永远不会有人重写。与其逐个移植，不如把整个 Android 装进一台虚拟机——这正是 AirAVM 的立项逻辑：以 QEMU 9.2.4 的 aarch64 全系统模拟（TCG 二进制翻译）为引擎，引导 LineageOS 23.2（Android 16）镜像，在鸿蒙设备上交付一台可正常开机的 Android 虚拟机。
工程名 AirAVM（Android Virtual Machine）与同门工程 AirMV 对仗：AirMV 承接 x86 PC 体系（Windows/Linux 桌面系统），AirAVM 承接 aarch64 Android 体系，两者共享 AirShell 沉淀的 QEMU 预编译双库与产品壳形态，但 guest 链路完全独立。与"套壳模拟器"的做法不同，本工程坚持全栈自持：从镜像获取通道、固件部署、argv 拓扑、显示注入到快照策略全部工程化，目标是把"能开机"做成"能日用"。
硬事实先立此存照：包名 com.airavm.app，版本 1.3.0，ArkTS 壳 + native core 双层架构；QEMU 以 libqemu_core_a64.so（JIT 版 34MB）与 _tci 降级版双形态随包分发，均带 .permission 段；上游镜像取自 jqssun/android-lineage-qemu 的 GPL-3.0 预编译 releases（v2026.09.17 = LineageOS 23.2 / Android 16，virtio 构建），无 GMS。
▍二、先划清边界：不把"能开机"当成"能日用"
Android guest 对虚拟机的每一处假设都建立在真实硬件上：显卡是真实 GPU、输入是真实触摸屏、存储是真实 eMMC、网络有真实网卡。全系统模拟的边界工作就是逐项回答"这个设备在鸿蒙侧由什么充当"。当前版本的对应关系如下。
层次 真实 Android 设备 AirAVM 当前方案
CPU 8 核 ARM 大小簇 TCG 二进制翻译（-cpu max,pauth-impdef=on），MTTCG 多线程
GPU/显示 真 GPU + 显示通路 virtio-gpu-pci + 壳层 DCL 显示链注入
输入 触摸屏/按键 usb-tablet/usb-mouse/usb-kbd（QEMU input 层零 wrapper 复用）
存储 eMMC/UFS virtio-blk-pci 双盘（vda 系统/vdb 数据，qcow2）
固件 Boot ROM + bootloader edk2 pflash 双单元（code.fd 只读 + efi_vars.fd 可写）
网络 Wi-Fi/基带 virtio-net-pci + user 型网络，hostfwd 转发 5555/5554（adb）
音频 编解码器 intel-hda + hda-output（非 virtio-snd，实测兼容性更优）
传感器/摄像头 硬件外设 不模拟（M2 之后按需评估）
边界之外还要先说清三条红线：其一，无 GMS——LineageOS 社区构建不带 Google 移动服务，涉 GMS 的应用不在能力承诺内；其二，性能口径——TCG 是纯软件翻译，"能流畅日用"仅对快照极速启动与轻量应用成立，大型 3D 游戏不在目标场景；其三，引导成功不等于功能矩阵齐备——四链路（触摸/键盘/网络/音频的完整产品化）与模拟器功能矩阵（root/改定位/多开等）分属 M2/M4，尚未开工。
▍三、鸿蒙版的整体架构
AirAVM 采用与 Air 系列一致的 ArkTS 壳 + native core 双层架构，但两侧的血缘各有出处：
- 壳层：fork 自 AirMV（2026-10-04），全量继承其产品形态——VM 列表/新建向导/设置/快照管理/工具条/手势/软键盘/DCL 显示链，并把品牌文案完成 Android 化改写。fork 时明确排除 x86 遗产：807MB 的 x86 种子 rawfile、x86 双库、build 产物与历史 verify 记录一律不随行。
- 引擎层：复用 AirShell 的 aarch64 双库——libqemu_core_a64.so（JIT 版，34MB）与 libqemu_core_a64_tci.so（TCI 降级版），两者均带 .permission 段以通过鸿蒙可执行内存校验。JIT 路线需要 kernel.ALLOW_WRITABLE_CODE_MEMORY 受限 ACL，签名环节已实测自动申请成功。
- 镜像通道：不自行构建 Android，而是取用 jqssun/android-lineage-qemu 预编译 releases（GPL-3.0，合规可分发）：完整 VM 包 1072MB（vda/vdb qcow2 + efi_vars.fd）、OTA 包 973MB、boot.img 44MB、userdebug recovery 58MB（可 sideload 未签名包，是 root 通道的钥匙）。
- 引导拓扑：TCG 参数（-cpu max,pauth-impdef=on、tb-size=1024、MTTCG）+ virtio 设备族（gpu/blk/net/serial/rng）+ intel-hda 音频 + pflash 固件对，全部参数在工程文档中固化为 M1 argv 基线。
三层各管一段：壳层管产品体验与生命周期，引擎层管虚拟化执行，镜像通道管 guest 内容供给。这使"换镜像版本"与"改引擎参数"互不牵动，后续维护面清晰。
▍四、核心适配过程
M0 探底（2026-10-04 完成）：一天内连过四关——镜像通道验证（releases 清单核对 + 完整性口径确认）、工程骨架（fork + 改名 + a64 双库一次构建通过，18.9 秒出 74MB HAP）、签名链（新包名云签名 + JIT 受限 ACL 自动申请）、mini 真机基线（安装/启动/壳 UI 冒烟 PASS）。M0 同时登记了两条已知残留：启动器报"资产部署失败 9001005"（deployBios 仍沿用 fork 来的 x86 pc-bios 清单，a64 资产未换装）、mini 设备存储 95% 满（镜像集 2.5G + userdata 4G + 快照预算的硬约束）。
M1 引导突破（2026-10-06 达成）：目标是让 Android 在真机上起到 launcher 首帧。过程按判据推进：launcher 首帧采用双通道判据（视觉：深蓝壁纸 + 图标网格 + 底部 dock 截图留痕；活性：render draws 每秒计数）。期间经历三次关键修正——P28 推翻"init defs 挂死"误判（同机同固件 QEMU 正常起，CPU 121% 证明在跑）、bootanimation 长跑 36 分钟暴露单核编译瓶颈、P31 切换 MTTCG 后 CPU 225%（1.86 倍加速），重启后续编译 37 分钟达成 launcher。首启总账约 6.6 小时（有效编译约 4 小时）。随后实测二次启动基线：VM 启动到可交互 Android UI 约 20.5 分钟，阶段拆分为内核 35 秒 → bootanimation 4.2 分钟 → zygote/system_server 长尾约 16.5 分钟——这段长尾正是后续快照通道的收益面。
M3 快照产品化（2026-10-06 当晚落地）：针对 20 分钟级冷启，用 QEMU savevm/loadvm 建立快照通道：savevm 实测 1.94GiB 约 3 分钟（P34 修复 pflash1 后），boot 级自动 loadvm 实现"点启动 → 桌面 11-20 秒"，相对冷启加速 60-100 倍。SC-1 产品化五项全 PASS：快照 tag 语义化（android-ready，旧档兼容认领，保存后自动 delvm 回收 12MB）、双模式启动弹窗（极速启动 = loadvm 回滚 / 正常启动 = 延续磁盘，bootMode 参数从 UI 全链贯通到 native）、无档冷启的 15 分钟存档引导。
▍五、适配中遇到的几个难点
其一，bootanimation 长尾与 MTTCG。 首次引导卡在 Android 开机动画 30 分钟以上，最初被误判为 init 挂死（P28），后以"同机同参数 QEMU 进程 CPU 121%"证明系统在慢速推进——根因是 TCG 单线程翻译吞吐不足。切换 MTTCG 多线程 TCG 后 CPU 225%，续编译时间从 164 分钟压到 37 分钟。教训是：全系统模拟的"卡住"要先用活性证据（CPU、渲染计数）定性，再谈修复。
其二，GICv3 + MTTCG 的 loadvm 停滞。 AirShell 时期即实测：GICv3 中断控制器与 MTTCG 组合下 loadvm 恢复停滞，GICv2 + 多线程正常。该结论直接约束了 AirAVM 的中断控制器选型与快照策略组合，四机矩阵测试中须重点覆盖 GICv2 路线。
其三，JIT 与 W^X 约束。 TCG 生成host 代码需要可写可执行内存，鸿蒙默认禁止。解法是双管齐下：QEMU 库带 .permission 段声明，签名时申请 kernel.ALLOW_WRITABLE_CODE_MEMORY 受限 ACL，实测云签名链路自动通过；同时保留 TCI 降级库作为 ACL 不可得时的兜底。
其四，9001005 资产部署失败。 启动器报 rawfile 资产部署失败，定位为 deployBios 沿用 fork 来的 x86 pc-bios 清单，而 fork 时已排除 x86 rawfile——清单指向了不存在的资源名。修复方向明确（换 a64 固件清单：AAVMF/直启内核），在 M1 换装前如实保留该报错。
其五，存储预算。 验证机 mini 存储 95% 满（剩 12G），镜像集 2.5G + userdata 默认档 4G + 快照 1-2G 的预算在真机上捉襟见肘。userdata 默认档压到 4G 并把快照回收做成自动链（保存后 delvm 迁移）是当前的空间纪律。
▍六、编译、安装与启动
工程可从源码复现完整产物：DevEco Studio 工程结构，ArkTS 壳 + native 双库；devecocli build 构建（M0 基线 18.9 秒，HAP 74MB）；新包名走云签名，JIT 受限 ACL 自动申请。部署验证机先后为 mini（MLR-AL00，12GB RAM）与 11.5 平板（TXZ-W20，2026-10-06 起锁定为唯一部署机），并已获用户授权扩测四机（Mate 80 Pro Max / Pura X / Mate 60 Pro / 11.5）。
启动流程：壳内新建 VM → 选择镜像档 → 下载（三阶段进度 + 断点续传 + SHA256 预检）→ 部署固件与磁盘 → 拉起 native QEMU → 输出注入 DCL 显示链。冷启到可交互 Android UI 约 20.5 分钟；有快照档时走 boot 级 loadvm，11-20 秒到桌面。真机证据链（launcher 首帧截图、render draws 计数、快照耗时记录）均留档于工程 .verify/ 目录。
▍七、当前功能边界
已覆盖的能力：
- 完整产品壳（VM 列表/新建/设置/快照/工具条/手势/软键盘）与 Android 化品牌文案；
- LineageOS 23.2（Android 16）镜像下载链（断点续传/重试/三阶段进度）；
- aarch64 全系统引导至 launcher 首帧，MTTCG 多核加速，双通道判据留痕；
- savevm/loadvm 快照通道与极速启动（11-20 秒），双模式启动弹窗全链贯通；
- adb 端口转发（hostfwd 5555/5554）、virtio 全家桶拓扑、edk2 固件对。
尚未覆盖或存在缺陷的能力同样如实登记：M2 四链路（触摸/键盘/网络/音频的产品化打磨 + 设置向导 + APK 侧载）未开工；M4 模拟器功能矩阵（root/改定位/分辨率/多开/截屏）未开工，root 材料已备；M5 合规收尾（GPLv2 + LineageOS 署名、AGC 文案、无 GMS 声明）未开工；9001005 资产部署报错待 M1 换装 a64 固件清单后消除；现有快照档内容为楔死态（SystemUI ANR 循环），待健康桌面重基线（P36）；mini 存储 95% 满约束镜像预算。因此当前版本的正确定位是"Android 虚拟机鸿蒙 PC 技术验证版"——引导链与快照通道已经真机实证，日用化功能矩阵是下一阶段主线。
▍八、总结
AirAVM 的价值不在"跑起来了一个 Android"，而在把它做成了一条可复现、可判据、可回收的工程链路：镜像有通道、引导有判据（视觉 + 活性双通道）、性能有基线（20.5 分钟冷启 / 11-20 秒快照）、空间有纪律（快照自动回收）。M1 的六小时首启与 P28 的误判教训，共同沉淀为"先活性定性、再动手修复"的方法学。
后续重心清晰如清单：M2 四链路产品化、M4 功能矩阵（root 材料已备）、9001005 换装消除、四机 jit/W^X 矩阵跑通、M5 合规收尾。当 Android guest 在鸿蒙上达到"点开即用"的体验时，鸿蒙 PC 的应用生态边界将被真正推开一扇门——这正是 Air 系列把桌面级软件装进鸿蒙的题中之义。
■ 应用：AirAVM（AirAVM）
■ 定位：QEMU 虚拟机方案，在鸿蒙设备上引导运行 Android 系统
■ 上游：QEMU（qemu-vis） ｜ 路线：QEMU 引擎直连 ｜ 版本：1.3.0
■ 开源： https://gitcode.com/Andy88/Harmony-QEMU
■ 市场状态：开发中，即将上架
■ 官网（免费下载）： https://www.shunidc.cn/
————————————————————
开源鸿蒙 PC 社区： https://harmonypc.csdn.net/
PC 社区项目申请： https://atomgit.com/OpenHarmonyPCDeveloper
适配开源地址：https://gitcode.com/Andy88/Harmony-QEMU
环境搭建文章：https://blog.csdn.net/weixin_52908342/article/details/161343743
▍一、为什么要适配 AirAVM
鸿蒙 PC 的应用矩阵里始终缺一块拼图：Android 生态。数以百万计的 Android 应用没有鸿蒙原生版本，其中相当一部分（小众工具、老游戏、行业应用）永远不会有人重写。与其逐个移植，不如把整个 Android 装进一台虚拟机——这正是 AirAVM 的立项逻辑：以 QEMU 9.2.4 的 aarch64 全系统模拟（TCG 二进制翻译）为引擎，引导 LineageOS 23.2（Android 16）镜像，在鸿蒙设备上交付一台可正常开机的 Android 虚拟机。
工程名 AirAVM（Android Virtual Machine）与同门工程 AirMV 对仗：AirMV 承接 x86 PC 体系（Windows/Linux 桌面系统），AirAVM 承接 aarch64 Android 体系，两者共享 AirShell 沉淀的 QEMU 预编译双库与产品壳形态，但 guest 链路完全独立。与"套壳模拟器"的做法不同，本工程坚持全栈自持：从镜像获取通道、固件部署、argv 拓扑、显示注入到快照策略全部工程化，目标是把"能开机"做成"能日用"。
硬事实先立此存照：包名 com.airavm.app，版本 1.3.0，ArkTS 壳 + native core 双层架构；QEMU 以 libqemu_core_a64.so（JIT 版 34MB）与 _tci 降级版双形态随包分发，均带 .permission 段；上游镜像取自 jqssun/android-lineage-qemu 的 GPL-3.0 预编译 releases（v2026.09.17 = LineageOS 23.2 / Android 16，virtio 构建），无 GMS。
▍二、先划清边界：不把"能开机"当成"能日用"
Android guest 对虚拟机的每一处假设都建立在真实硬件上：显卡是真实 GPU、输入是真实触摸屏、存储是真实 eMMC、网络有真实网卡。全系统模拟的边界工作就是逐项回答"这个设备在鸿蒙侧由什么充当"。当前版本的对应关系如下。
层次 真实 Android 设备 AirAVM 当前方案
CPU 8 核 ARM 大小簇 TCG 二进制翻译（-cpu max,pauth-impdef=on），MTTCG 多线程
GPU/显示 真 GPU + 显示通路 virtio-gpu-pci + 壳层 DCL 显示链注入
输入 触摸屏/按键 usb-tablet/usb-mouse/usb-kbd（QEMU input 层零 wrapper 复用）
存储 eMMC/UFS virtio-blk-pci 双盘（vda 系统/vdb 数据，qcow2）
固件 Boot ROM + bootloader edk2 pflash 双单元（code.fd 只读 + efi_vars.fd 可写）
网络 Wi-Fi/基带 virtio-net-pci + user 型网络，hostfwd 转发 5555/5554（adb）
音频 编解码器 intel-hda + hda-output（非 virtio-snd，实测兼容性更优）
传感器/摄像头 硬件外设 不模拟（M2 之后按需评估）
边界之外还要先说清三条红线：其一，无 GMS——LineageOS 社区构建不带 Google 移动服务，涉 GMS 的应用不在能力承诺内；其二，性能口径——TCG 是纯软件翻译，"能流畅日用"仅对快照极速启动与轻量应用成立，大型 3D 游戏不在目标场景；其三，引导成功不等于功能矩阵齐备——四链路（触摸/键盘/网络/音频的完整产品化）与模拟器功能矩阵（root/改定位/多开等）分属 M2/M4，尚未开工。
▍三、鸿蒙版的整体架构
AirAVM 采用与 Air 系列一致的 ArkTS 壳 + native core 双层架构，但两侧的血缘各有出处：
- 壳层：fork 自 AirMV（2026-10-04），全量继承其产品形态——VM 列表/新建向导/设置/快照管理/工具条/手势/软键盘/DCL 显示链，并把品牌文案完成 Android 化改写。fork 时明确排除 x86 遗产：807MB 的 x86 种子 rawfile、x86 双库、build 产物与历史 verify 记录一律不随行。
- 引擎层：复用 AirShell 的 aarch64 双库——libqemu_core_a64.so（JIT 版，34MB）与 libqemu_core_a64_tci.so（TCI 降级版），两者均带 .permission 段以通过鸿蒙可执行内存校验。JIT 路线需要 kernel.ALLOW_WRITABLE_CODE_MEMORY 受限 ACL，签名环节已实测自动申请成功。
- 镜像通道：不自行构建 Android，而是取用 jqssun/android-lineage-qemu 预编译 releases（GPL-3.0，合规可分发）：完整 VM 包 1072MB（vda/vdb qcow2 + efi_vars.fd）、OTA 包 973MB、boot.img 44MB、userdebug recovery 58MB（可 sideload 未签名包，是 root 通道的钥匙）。
- 引导拓扑：TCG 参数（-cpu max,pauth-impdef=on、tb-size=1024、MTTCG）+ virtio 设备族（gpu/blk/net/serial/rng）+ intel-hda 音频 + pflash 固件对，全部参数在工程文档中固化为 M1 argv 基线。
三层各管一段：壳层管产品体验与生命周期，引擎层管虚拟化执行，镜像通道管 guest 内容供给。这使"换镜像版本"与"改引擎参数"互不牵动，后续维护面清晰。
▍四、核心适配过程
M0 探底（2026-10-04 完成）：一天内连过四关——镜像通道验证（releases 清单核对 + 完整性口径确认）、工程骨架（fork + 改名 + a64 双库一次构建通过，18.9 秒出 74MB HAP）、签名链（新包名云签名 + JIT 受限 ACL 自动申请）、mini 真机基线（安装/启动/壳 UI 冒烟 PASS）。M0 同时登记了两条已知残留：启动器报"资产部署失败 9001005"（deployBios 仍沿用 fork 来的 x86 pc-bios 清单，a64 资产未换装）、mini 设备存储 95% 满（镜像集 2.5G + userdata 4G + 快照预算的硬约束）。
M1 引导突破（2026-10-06 达成）：目标是让 Android 在真机上起到 launcher 首帧。过程按判据推进：launcher 首帧采用双通道判据（视觉：深蓝壁纸 + 图标网格 + 底部 dock 截图留痕；活性：render draws 每秒计数）。期间经历三次关键修正——P28 推翻"init defs 挂死"误判（同机同固件 QEMU 正常起，CPU 121% 证明在跑）、bootanimation 长跑 36 分钟暴露单核编译瓶颈、P31 切换 MTTCG 后 CPU 225%（1.86 倍加速），重启后续编译 37 分钟达成 launcher。首启总账约 6.6 小时（有效编译约 4 小时）。随后实测二次启动基线：VM 启动到可交互 Android UI 约 20.5 分钟，阶段拆分为内核 35 秒 → bootanimation 4.2 分钟 → zygote/system_server 长尾约 16.5 分钟——这段长尾正是后续快照通道的收益面。
M3 快照产品化（2026-10-06 当晚落地）：针对 20 分钟级冷启，用 QEMU savevm/loadvm 建立快照通道：savevm 实测 1.94GiB 约 3 分钟（P34 修复 pflash1 后），boot 级自动 loadvm 实现"点启动 → 桌面 11-20 秒"，相对冷启加速 60-100 倍。SC-1 产品化五项全 PASS：快照 tag 语义化（android-ready，旧档兼容认领，保存后自动 delvm 回收 12MB）、双模式启动弹窗（极速启动 = loadvm 回滚 / 正常启动 = 延续磁盘，bootMode 参数从 UI 全链贯通到 native）、无档冷启的 15 分钟存档引导。
▍五、适配中遇到的几个难点
其一，bootanimation 长尾与 MTTCG。 首次引导卡在 Android 开机动画 30 分钟以上，最初被误判为 init 挂死（P28），后以"同机同参数 QEMU 进程 CPU 121%"证明系统在慢速推进——根因是 TCG 单线程翻译吞吐不足。切换 MTTCG 多线程 TCG 后 CPU 225%，续编译时间从 164 分钟压到 37 分钟。教训是：全系统模拟的"卡住"要先用活性证据（CPU、渲染计数）定性，再谈修复。
其二，GICv3 + MTTCG 的 loadvm 停滞。 AirShell 时期即实测：GICv3 中断控制器与 MTTCG 组合下 loadvm 恢复停滞，GICv2 + 多线程正常。该结论直接约束了 AirAVM 的中断控制器选型与快照策略组合，四机矩阵测试中须重点覆盖 GICv2 路线。
其三，JIT 与 W^X 约束。 TCG 生成host 代码需要可写可执行内存，鸿蒙默认禁止。解法是双管齐下：QEMU 库带 .permission 段声明，签名时申请 kernel.ALLOW_WRITABLE_CODE_MEMORY 受限 ACL，实测云签名链路自动通过；同时保留 TCI 降级库作为 ACL 不可得时的兜底。
其四，9001005 资产部署失败。 启动器报 rawfile 资产部署失败，定位为 deployBios 沿用 fork 来的 x86 pc-bios 清单，而 fork 时已排除 x86 rawfile——清单指向了不存在的资源名。修复方向明确（换 a64 固件清单：AAVMF/直启内核），在 M1 换装前如实保留该报错。
其五，存储预算。 验证机 mini 存储 95% 满（剩 12G），镜像集 2.5G + userdata 默认档 4G + 快照 1-2G 的预算在真机上捉襟见肘。userdata 默认档压到 4G 并把快照回收做成自动链（保存后 delvm 迁移）是当前的空间纪律。
▍六、编译、安装与启动
工程可从源码复现完整产物：DevEco Studio 工程结构，ArkTS 壳 + native 双库；devecocli build 构建（M0 基线 18.9 秒，HAP 74MB）；新包名走云签名，JIT 受限 ACL 自动申请。部署验证机先后为 mini（MLR-AL00，12GB RAM）与 11.5 平板（TXZ-W20，2026-10-06 起锁定为唯一部署机），并已获用户授权扩测四机（Mate 80 Pro Max / Pura X / Mate 60 Pro / 11.5）。
启动流程：壳内新建 VM → 选择镜像档 → 下载（三阶段进度 + 断点续传 + SHA256 预检）→ 部署固件与磁盘 → 拉起 native QEMU → 输出注入 DCL 显示链。冷启到可交互 Android UI 约 20.5 分钟；有快照档时走 boot 级 loadvm，11-20 秒到桌面。真机证据链（launcher 首帧截图、render draws 计数、快照耗时记录）均留档于工程 .verify/ 目录。
▍七、当前功能边界
已覆盖的能力：
- 完整产品壳（VM 列表/新建/设置/快照/工具条/手势/软键盘）与 Android 化品牌文案；
- LineageOS 23.2（Android 16）镜像下载链（断点续传/重试/三阶段进度）；
- aarch64 全系统引导至 launcher 首帧，MTTCG 多核加速，双通道判据留痕；
- savevm/loadvm 快照通道与极速启动（11-20 秒），双模式启动弹窗全链贯通；
- adb 端口转发（hostfwd 5555/5554）、virtio 全家桶拓扑、edk2 固件对。
尚未覆盖或存在缺陷的能力同样如实登记：M2 四链路（触摸/键盘/网络/音频的产品化打磨 + 设置向导 + APK 侧载）未开工；M4 模拟器功能矩阵（root/改定位/分辨率/多开/截屏）未开工，root 材料已备；M5 合规收尾（GPLv2 + LineageOS 署名、AGC 文案、无 GMS 声明）未开工；9001005 资产部署报错待 M1 换装 a64 固件清单后消除；现有快照档内容为楔死态（SystemUI ANR 循环），待健康桌面重基线（P36）；mini 存储 95% 满约束镜像预算。因此当前版本的正确定位是"Android 虚拟机鸿蒙 PC 技术验证版"——引导链与快照通道已经真机实证，日用化功能矩阵是下一阶段主线。
▍八、总结
AirAVM 的价值不在"跑起来了一个 Android"，而在把它做成了一条可复现、可判据、可回收的工程链路：镜像有通道、引导有判据（视觉 + 活性双通道）、性能有基线（20.5 分钟冷启 / 11-20 秒快照）、空间有纪律（快照自动回收）。M1 的六小时首启与 P28 的误判教训，共同沉淀为"先活性定性、再动手修复"的方法学。
后续重心清晰如清单：M2 四链路产品化、M4 功能矩阵（root 材料已备）、9001005 换装消除、四机 jit/W^X 矩阵跑通、M5 合规收尾。当 Android guest 在鸿蒙上达到"点开即用"的体验时，鸿蒙 PC 的应用生态边界将被真正推开一扇门——这正是 Air 系列把桌面级软件装进鸿蒙的题中之义。
楼主
8 天前