国内外 RISC-V 峰会中的 Android 发展与趋势调研：欧洲、中国与全球视角

国内外 RISC-V 峰会中的 Android 发展与趋势调研：欧洲、中国与全球视角

版本历史

术语与缩略语

可靠性标记

• 【C】可由峰会官方议程、RISC-V International、Android/AOSP 上游或项目仓库直接核验的事实。
• 【C*】由两个或更多独立一手来源共同支持的稳定结论。
• 【S】由有限峰会样本和公开资料形成的趋势判断，不代表全部厂商或地区。
• 【P】面向平台、芯片和生态团队的工程建议，不是厂商承诺。
• 【?】公开资料没有披露、资料不可稳定复核，或不能安全外推的内容。

1. 核心判断（TL;DR）

• 【C*】三大区域峰会不是同一“全球峰会”的不同站点，而是 RISC-V International 所列的北美、欧洲、中国区域活动；Android 的直接公开信号最集中出现在 2024 北美峰会：Google 展示 Berberis 路径，阿里达摩院给出“Android on RISC-V 产品化探索”议题 [S01][S02][S03]。
• 【C*】峰会与上游资料显示 Android RISC-V 已从纯 ISA 讨论进入 ABI、模拟器、ART 和跨 ISA 兼容准备：RVA23 含向量扩展并被定位为 Android RISC-V ABI 基线；Google 的公开仓库记录 ART 已在 Cuttlefish 启动，但明确指出 NDK ABI 尚未最终确定 [S04][S06]。
• 【C】截至研究截点，Android NDK 官方 ABI 页面仅列 armeabi-v7a、arm64-v8a、x86、x86_64，未列 riscv64；因此不能把峰会演讲或 AOSP 组件进展写成面向第三方原生应用的稳定 riscv64 NDK 交付 [S07]。
• 【S】欧洲和中国峰会的公开重点更多落在 RVA23、Linux、编译器、开源软件、AI、汽车及芯片系统；本次可访问的欧洲 2024–2026 议程页、中国 2024–2025 回顾及 2025 演讲库未呈现与北美 2024 同等清晰的 Android/AOSP 专题证据。这是公开可见度差异，而不是区域 Android 工作不存在的证明 [S10][S11][S12][S13][S14][S15]。
• 【P】下一阶段的判定单位应从“是否有 Android on RISC-V 演讲”升级为可复现交付链：RVA23/SoC、内核与系统组件、NDK ABI、APK/AAB 原生库、CTS/VTS、图形/相机/安全、功耗和应用兼容性必须分别验收；任一前置层达成均不能替代下一层 [S04][S06][S07]。

2. 问题、范围与方法

用户所说的“全球峰会”在 RISC-V International 的公开活动页中并不是一个正式的单独名称。该页面列出 North America、Europe 与 China 等区域峰会，故本文以 North America 作为全球生态和上游项目最密集的观测窗口，同时单列欧洲与中国，不把三者的议程混为同一个产品路线 [S01]。研究范围是峰会能够释放的工程信号，而不是宣传热度：直接 Android/AOSP/NDK/Cuttlefish/Berberis 题名或上游状态属于高相关证据；RVA23、Linux、LLVM、AI、汽车与开源软件属于必要但间接的基础设施证据。

研究按四层进行。第一层核验主办方或公开议程的题名、讲者和时间，尤其检查是否明确出现 Android、AOSP、Android Automotive、NDK 或 ABI。第二层用 Android Developers、AOSP 与 Google 维护仓库校正峰会结论，防止将演讲标题当成代码可用性。第三层把 ISA profile、系统可启动、原生应用 ABI、兼容认证和实机产品拆开。第四层只在多个来源一致时形成趋势判断；未查到的事项统一表述为“本次可访问资料未显示”，而非“世界上不存在”。

见图 1，它将三个区域峰会的直接 Android 议题与通用软件基础设施分开，避免将 Linux 或 AI 议程自动归类为 Android 量产证据。

图 1：RISC-V 峰会中的 Android 证据地图。来源：依据 North America 2024 的 Android 专题、RVA23 发布、欧洲 2024–2026 演讲页与中国 2024–2025 官方回顾/演讲库综合绘制；“未见专题”仅表示本次可访问资料范围内的公开证据 [S02][S03][S04][S10][S11][S12][S13][S14][S15]。

3. 全球技术基线

3.1 北美峰会：Android 从主题演讲进入兼容与产品化问题

2024 RISC-V Summit North America 的公开日程提供了最直接的 Android 证据。阿里达摩院的议题题名为“Exploration of Productization of Android on RISC-V”，语义是产品化探索，而非宣称某一量产 Android 设备已完成认证 [S02]。Google 的 Berberis 议题则直接面向 Android 的跨 ISA 兼容：其 AOSP 仓库将项目描述为在 x86_64 设备上运行带 riscv64 原生代码的 Android 应用的动态二进制翻译器，并列出部分 Zb 与 Zv 扩展支持 [S03][S08]。两者共同说明，峰会讨论已从“RISC-V 能否启动系统”推进到原生代码、二进制翻译和应用生态如何过渡。

这种信号必须与上游状态一起读。Google 在 2023 年的 Android RISC-V 文章把工作定位为实验与协作准备，并表示首个可用形态瞄准穿戴设备；它并未承诺通用手机的即时商用 [S05]。Google 的 android-riscv64 仓库进一步说明所有 Android/riscv64 工作转入 AOSP，ART 已能在 Cuttlefish 启动，同时将 NDK ABI 表述为尚未最终确定、临时实现可能改变的状态 [S06]。因此，峰会给出的高价值不是某个“Android 已支持”的二元结论，而是明确了 ABI、运行时、模拟器和翻译器是实现生态迁移的关键工作包。

2025 North America 峰会的公开软件日程继续显示 RVA23、工具链和系统软件是公共主线 [S09]。本次可访问资料没有提供与 2024 两场 Android 专题同等明确的 Android 标题或产品发布，因此不能用“2025 未见标题”推导 Android 工作停滞。更合理的读法是：直接 Android 公开叙事在 2024 已展示问题域，而此后峰会公开页更多呈现通用软件和 profile 落地；真实进度应回到 AOSP、NDK 与设备验证来判断。

3.2 RVA23 是 ABI 前提，不是 Android 产品保证

RISC-V International 在 RVA23 批准公告中说明，该 profile 为 Android RISC-V ABI 提供基线，并要求 Vector 与 Hypervisor 等扩展 [S04]。这解决的是“目标软件可假定哪些 ISA 能力”的共同约束：应用、运行时和编译器不必为每颗 RV64 核单独猜测基础扩展集合。对于 Android 这类含 ART、Bionic、动态链接、JNI、图形及大量第三方 native 库的系统，稳定的 profile 是压缩兼容矩阵的必要条件。

但 profile 不会自动产生 NDK ABI、APK 打包、驱动、GKI 适配、Google 移动服务资格或 CTS 结果。2026-05-15 版本的 NDK ABI 官方页面依旧只列出四类 ABI，未列 riscv64 [S07]。这与“RVA23 是 Android ABI 基线”并不矛盾：前者说的是 RISC-V 侧的目标架构契约，后者说的是 Android 开发者公开分发接口的当前清单。工程团队若把二者混为一谈，最常见的后果是在平台镜像可启动后才发现第三方 JNI 库、构建系统、预编译 SDK、崩溃收集和商店分发没有稳定路径。

3.3 模拟器和二进制翻译是风险收敛工具，不是实机替身

Cuttlefish 与 Berberis 表明 Android RISC-V 工作具有两条互补路径。前者使 ART、framework、system image 及自动化测试可以在虚拟环境中较早推进；后者处理开发或兼容场景中 riscv64 原生代码与 x86_64 执行环境之间的转换 [S06][S08]。其共同价值是将 ISA 迁移中的编译、链接、JNI、运行时和测试问题提前暴露，降低必须等待最终 SoC 才能开始软件开发的风险。

失效边界同样明确。虚拟设备无法证明真实 NPU/GPU/ISP 驱动、DMA 一致性、相机时间线、音频低时延、调度抖动、峰值功耗、温控、待机和射频共存；二进制翻译也会改变指令路径与性能特征。任何引用 Cuttlefish 启动或 Berberis 演讲来论证“Android 手机体验已成熟”的写法，均超出公开证据。实际项目应把它们用于 CI、回归和 ISA 兼容问题定位，而不是用于代替实机性能或认证结论。

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

4.1 中国峰会：系统软件、AI 与汽车更显性，Android 证据需严格收敛

2024 RISC-V 中国峰会在杭州举行，RISC-V International 的官方回顾描述了开源 IP、生态和软件主题，并提及 openEuler 等系统软件方向 [S13]。2025 峰会在上海举办，官方与公开演讲材料将软件、AI、嵌入式、高性能计算、汽车和芯片系统作为可见重点；RVI 的软件贡献者回顾特别讨论 CUDA、Linux kernel 与 RVA profile [S14][S15][S16]。这些方向对 Android on RISC-V 很重要：它们决定可用内核、工具链、调试环境、异构计算和 SoC 软件供给。

不过，OpenHarmony、openEuler、Linux、AI runtime 或汽车电子都不是 AOSP 的同义词。针对中国 2024 官方回顾、2025 RVI 回顾、2025 演讲仓库及官方议程进行核验后，本次可访问材料没有出现可与 2024 北美“Android 产品化探索”相当的 Android/AOSP 专题标题 [S13][S14][S15][S16]。正确结论是公开可复核的 Android 专题证据较少；不能据此否定厂商内部项目、合作伙伴工作或未来发布。

中国生态的机会在于把已高频出现的 RISC-V 软件工作转为 Android 的可交付输入：为目标 SoC 固化 RVA23/扩展发现策略；将 Linux 内核、BSP、图形与多媒体驱动的版本关系记录为 device matrix；让 AI/NPU 编译链和 Android HAL/权限/内存模型共测；以 JNI、WebView、ART、相机和安全组件的真实 workload 检查 ABI 与调度问题。风险则是将“芯片能跑 Linux”“AI 演示能运行”或“开源 OS 已适配”直接包装成 Android 产品化，导致第三方应用、应用商店、认证和升级链路在后期暴露。

4.2 欧洲峰会：以主权软件栈和基础设施强化 Android 的前置条件

欧洲峰会公开材料在 2024–2026 连续覆盖 Linux on RISC-V、RVA23、LLVM、RISE 项目、开放软件、功能安全和汽车等主题 [S10][S11][S12]。这些议题反映欧洲的关注点偏向可维护的软件栈、开放处理器生态和汽车/工业部署，而不是将 Android 作为唯一应用层。2025 演讲材料还将 RVA23 和 RISE 作为软件生态协同的重要锚点 [S11]，说明 profile、编译器、发行版、调试工具和上游治理被放在共同问题中处理。

在本次可访问的欧洲 2024 conference 页、2025/2026 presentations 页中，未检索到可直接复核的 Android 或 AOSP 专题标题 [S10][S11][S12]。这个“未检索到”是资料范围限制，而非对欧洲公司或项目实际工作的否定。它可支持的趋势判断是，欧洲公开峰会叙事优先投资下游 Android 所依赖的通用基础层；它不能支持“欧洲没有 Android RISC-V”或“欧洲 Android 已完成产品化”两种相反断言。

4.3 三区域的互补关系

北美公开材料把 Android 兼容和产品化问题直接放到议程中，欧洲强调 profile 与开源软件基础设施，中国展示系统软件、AI、汽车和本地生态连接。三者并非竞争性的成熟度排名：Android 设备最终同时需要北美所暴露的 ABI/兼容问题、欧洲所推进的 profile/工具链上游协作，以及中国具备的 SoC、系统软件、AI 和终端集成能力。真正的差距是这些层是否被同一套可复现 workload、版本矩阵和发布门禁连接，而不是某场峰会是否出现更多 Android 关键词。见图 2，交付能力必须跨越 ISA、系统、应用 ABI、认证和实机产品五层门槛。

图 2：Android on RISC-V 的交付门槛。来源：基于 RVA23、Google Android RISC-V 项目、Android NDK ABI 文档及峰会 Android 议题形成的工程分层；图中每层为独立验收条件，不表示任何厂商已完成全部门槛 [S02][S04][S06][S07]。

5. 关键机制深挖

5.1 ABI 与应用生态：从 ISA profile 到 APK/AAB 的断点

接口与实现依据。 Android 的 Java/Kotlin 代码可经 ART 执行，但大量应用和 SDK 仍携带 JNI、媒体、图形、加密、AI 或游戏引擎的原生库。因而 Android on RISC-V 的应用接口不仅是编译器能否接受 -march，还包括 NDK ABI 名称、ELF 约定、动态链接器、C/C++ runtime、构建插件、APK/AAB 中的 ABI 目录、预编译依赖和崩溃符号链。RVA23 提供 RISC-V 侧的基线约束，Google 的项目记录了 AOSP/ART/Cuttlefish 进展，但 Android NDK 官方 ABI 页面截至研究截点尚未列 riscv64 [S04][S06][S07]。

失效边界。 将“RVA23 已批准”“系统镜像可启动”或“某个应用源码可交叉编译”视为应用生态就绪会失效。一个应用可能在 Java 层正常启动，却因一个闭源 JNI .so、未支持的 Gradle 预编译产物、动态加载路径或错误收集 SDK 缺少 riscv64 而失去核心功能。二进制翻译可帮助兼容或开发，但会改变性能和调试路径，不能自动满足商店分发和长期支持要求 [S08]。当前公开 NDK ABI 清单未含 riscv64，也不能被反向解释为 AOSP 内部原型不存在。

验证条件。 团队应建立应用 ABI inventory：统计自研与第三方 native 库、源码/预编译比例、构建工具版本、许可证、动态加载位置和升级 owner。以真实 APK/AAB 运行自动化安装、冷启动、JNI 调用、WebView、媒体、图形、崩溃符号和升级回滚测试；记录每个库的实际 ELF e_machine、依赖、重定位和性能路径。只有公开的 NDK ABI、构建和打包链稳定后，才把“开发者可分发”作为结论。

成本与权衡。 越早支持 riscv64 原生库，越早暴露供应链和工具链缺口，但会增加 CI 架构、设备池、SDK 适配和版本维护成本。长期依赖翻译或仅保留 Java 路径可降低短期接入成本，却可能在热路径、内存、能耗、调试和安全更新上累积债务。应依据核心 workload 的 native 占比、性能目标和合作方控制力决定迁移节奏，而非由峰会演讲热度决定。

5.2 AOSP、Cuttlefish 与二进制翻译：让兼容问题可定位

接口与实现依据。 Google 公开文章将 Android RISC-V 定位为实验和协作方向，android-riscv64 仓库说明工作已进入 AOSP，并记录 ART 可在 Cuttlefish 启动 [S05][S06]。Berberis 则在 AOSP 中提供 riscv64 原生代码在 x86_64 环境执行的动态翻译功能 [S08]。这三类机制分别覆盖上游协作入口、虚拟化系统验证和跨 ISA 原生库兼容，适合在缺少最终实机或生态尚不完整时缩小问题空间。

失效边界。 Cuttlefish 的 CPU、内存、I/O 和设备模型无法复刻量产 SoC 的核簇、缓存、DVFS、GPU/NPU/ISP、驱动中断和共享内存行为。二进制翻译也会影响 signal、异常、调试器、性能采样和自修改代码等边界。若只报告“ART booted”或“translator initialized”，会掩盖 JNI 密集 workload、视频管线、相机预览、图形帧时间和长期热稳态中的问题。峰会演示应被视为问题发现和合作入口，而不是最终兼容性报告。

验证条件。 使用同一份版本化 workload 在 Cuttlefish、翻译路径、原生 riscv64 路径和最终 SoC 上运行；收集安装成功率、ART/JNI 崩溃、native bridge 命中、首次帧、P50/P99 时延、RSS、功耗代理、内核日志和 tombstone。对于每个翻译成功的库，还应在真正 riscv64 构建下进行数值/功能比对。CI 的关键产物是可比较的 trace 和失败最小复现，而不是单一启动截图。

成本与权衡。 虚拟化与翻译加速早期开发、提高设备可得性，却需要维护多路径一致性和额外回归矩阵；越晚接入实机验证，驱动和热问题越可能集中爆发。平台负责人应将 Cuttlefish 作为软件 gate，将实机作为体验和硬件 gate，并规定任何翻译结果都不能覆盖原生路径验收。

5.3 SoC、异构加速与产品化：把峰会路线变成可发布体验

接口与实现依据。 中国和欧洲峰会中频繁出现 Linux、AI、汽车、编译器和系统软件，说明 RISC-V 的落地日益是异构系统问题，而非孤立 CPU ISA 问题 [S11][S12][S14][S15]。对 Android 设备而言，CPU/RVV、GPU、NPU、DSP、ISP、内存控制器和电源管理需要通过内核、HAL、用户态驱动、编译器和应用 API 共同服务。RVA23 是 CPU 软件的前提之一，却不能描述 NPU 图受理率、GPU 驱动质量、相机同步或热设计。

失效边界。 TOPS、峰会 demo、Linux benchmark 或单核 RVV 吞吐不能推出 Android 的首帧、滚动流畅度、相机稳定性、端侧模型 token/s 或续航。动态频率、内存带宽竞争、驱动回退、设备温度和后台任务会使实验室短测失效。汽车议题也不能自动等同 Android Automotive；二者在系统许可、兼容性、功能安全、更新和集成边界上需要单独验证。

验证条件。 从目标用户任务定义 workload：启动、解锁、WebView、视频、相机、游戏、端侧 AI、弱网、低电量和长时间热稳态都要涵盖。记录芯片/固件/内核/驱动/Android build、CPU feature、实际加速后端、CPU/GPU/NPU 利用率、帧时间、端到端时延、RSS、温升、电量与错误率。将禁用加速器、强制回退和不同 ISA/翻译路径作为对照，防止把某一后端初始化日志当成体验改善。

成本与权衡。 更早统一 SoC 与 Android 版本矩阵可降低后期集成成本，但要求芯片、BSP、系统、AI、图形和应用团队共享设备与数据；只在发布末期联调看似节约资源，却会扩大问题定位面。最有效的投入不是扩大峰会 demo，而是为主设备、关键应用和固件建立可回归的性能、功耗、安全与兼容门禁。

6. 演进方向与情景

三个区域峰会的公开信号指向同一条演进路径：RISC-V Android 的竞争重心正在由“是否能为 RV64 编译”移向可治理的 ABI、运行时、系统软件和设备验证。北美 2024 的 Android 产品化与 Berberis 议题使跨 ISA 应用生态成为显性问题 [S02][S03]；RVA23 使 ISA 基线更清晰 [S04]；欧洲公开的 Linux、RISE、工具链和汽车协作强调上游基础设施 [S11][S12]；中国的系统软件、AI、HPC 和汽车议程则表明终端/边缘异构集成是重要需求 [S14][S15]。

见图 3，趋势雷达不是市场份额图，而是将这些峰会信号翻译为 Android 项目的验证方向。它尤其强调“公开演讲”和“公开 NDK ABI/认证/实机产品”之间仍有不可跳过的工程距离。

图 3：RISC-V 峰会 Android 趋势与验证。来源：根据 North America Android 议题、RVA23、AOSP/NDK 状态以及欧洲/中国软件议程综合绘制；各轴表示工程关注度，不表示商业成熟度或地区排名 [S02][S03][S04][S06][S07][S11][S14]。

6.1 对中国团队的机会

中国 RISC-V 生态在峰会中已展现系统软件、AI、汽车、芯片和终端协同的强动机。若目标是 Android，最稀缺的能力不是再做一个 RV64 启动 demo，而是让开放芯片、BSP、AOSP、原生应用、工具链和商业应用共同通过同一套跨版本验证。可以优先选择一个低风险目标形态，例如开发者设备、特定穿戴或受控行业终端，形成从 SoC feature、AOSP build、NDK/SDK、应用集、功耗和升级的完整样板，再逐步扩大应用与设备矩阵。

6.2 对全球合作的含义

RISC-V 的开放性并不会自动消除碎片化。北美峰会中暴露的 Android ABI/产品化问题、欧洲的软件上游协作和中国的端侧集成必须在公开 profile、测试标准、工具链版本和共同 workload 上会合。合作最应公开的是可复现实验：目标 ISA、模型/应用版本、编译参数、Cuttlefish/实机路径、性能和失败样本，而不是缺少上下文的“已支持 Android”表述。

7. 建议与验收

7.1 建立“峰会信号—产品证据”双账本

每项峰会信息应在进入路线图前被标记为：议程题名、公开代码、上游接口、原型、认证、量产设备或独立测试。以 2024 北美峰会为例，“Android 产品化探索”和 Berberis 可以进入问题/合作台账，但不能直接进入“已量产”台账 [S02][S03]。以 RVA23 为例，它可以进入架构基线台账，却不能代替 NDK ABI 或 CTS 数据 [S04][S07]。这一双账本可防止产品、市场和研发因证据等级不同而传递失真结论。

第二步是针对每个设备建立 release evidence bundle：SoC revision、RVA profile/扩展、bootloader、内核/GKI、vendor image、AOSP tag、ART、NDK/SDK、图形/相机/AI 驱动、测试版本、应用集合和性能/功耗 trace 必须绑定到同一个版本号。若某项结论仅在 Cuttlefish 或翻译路径成立，也必须显式标注，不能外推给真实设备。

能力成熟度对比矩阵

主张—证据矩阵

7.2 团队机制建议

1. 维护 区域峰会证据看板：按 North America、Europe、China 标注时间、议题、讲者、公开代码、影响层与证据等级；“未检索到”必须标记资料范围。
2. 维护 Android ABI 供应链表：列出每个 APK/AAB、JNI 库、SDK、构建插件、许可证和升级 owner，禁止只以 Java demo 判断可迁移性。
3. 固化 虚拟—翻译—实机三路径测试：Cuttlefish 用于系统回归，翻译路径用于兼容性定位，实机用于性能、功耗和外设体验；三者结果不可互相替代。
4. 建立 SoC 异构 workload 契约：将 CPU/RVV、GPU、NPU、ISP、内存和功耗放入统一 trace，记录实际加速路径与回退。
5. 建立 对外用语门禁：只有获得相应的公开 ABI、认证和实机证据，才可使用“开发者可分发”“兼容”“量产”等表述。

建议—验收矩阵

8. 不确定性与研究限制

1. 峰会页面、Sched 页面和部分演讲材料可能更新、下线或受访问限制；本文以本次可访问的官方页、公开仓库和搜索可核验元数据为界，不把无法稳定抓取的描述扩展为细节事实。
2. 欧洲和中国部分“未见 Android 专题”的结论仅针对列出的年份、可访问的公开议程/演讲库与检索条件，不代表组织、厂商或地区不存在未公开的 Android 研发。
3. Google 2023 文章、AOSP 项目仓库、RVA23 公告和 2026 NDK 文档覆盖的层级不同，可能在时间和接口状态上演进；发布设备前必须重新核验目标 Android 分支和当期 NDK/CTS 文档 [S04][S05][S06][S07]。
4. 本文不确认任何 RISC-V Android 设备已完成 CTS/VTS/GTS、获得某项商业服务资格或具备通用手机量产能力，因为本次来源未提供可审计的完整证据链。
5. AI、汽车、Linux、OpenHarmony 与 openEuler 的峰会内容在技术上可成为 Android 的上游输入，但不是 Android/AOSP/Android Automotive 的替代证据；本文刻意避免这种外推 [S11][S13][S14][S15]。
6. 性能、功耗、应用兼容率和安全性受具体核、SoC、驱动、Android 分支、编译参数、温度和 workload 影响；峰会演讲、TOPS 或单项 benchmark 不能代表终端用户体验。

参考来源

附录：研究方法

A. 资料采集与判定规则

1. 以峰会主办方、RISC-V International、Android Developers、AOSP/Google 项目仓库为优先来源；媒体或厂商材料只用于发现线索，未作为关键结论的唯一依据。
2. 对“Android 相关”按强度分级：题名直接含 Android/AOSP/NDK/Android Automotive 的为直接证据；RVA23、Linux、LLVM、Cuttlefish、AI、汽车和芯片系统为间接证据；没有可访问材料的为【?】。
3. 对“没有”的写法采用范围限定：仅说“本次可访问的某年公开议程/演讲库未见”，绝不从资料缺失推断研发缺失。
4. 对“已支持”的写法必须同时回答：支持对象是 AOSP 代码、模拟器、NDK ABI、第三方应用、CTS/VTS 还是量产设备；若对象未明确，结论降级。

B. 建议的复核清单

C. 可复现实验最小记录

每次试验至少归档：Android/AOSP tag、内核与固件、SoC revision、RISC-V feature/ISA 字符串、编译器与 NDK 版本、应用 hash、JNI 库清单、Cuttlefish/翻译/实机路径、输入 workload、测试次数、首帧/时延/RSS/功耗代理、错误日志和回退原因。只有这些上下文齐全，峰会信号才能被转换为可审计的产品决策。