Android-Audio-为啥不移到packages/module

Audio 为何没有完全迁移到packages/modules

这是一个非常专业且深刻的问题。Audio 系统的模块化确实是 Android 架构演进中的一个特殊案例。

一、Audio 系统的现状

当前分布

• 大部分在frameworks/av/：

  frameworks/av/ ├── services/audiopolicy/ # 音频策略服务 ├── media/ # 媒体框架 └── camera/ # 摄像头（共用部分基础设施）

• 部分在hardware/：

  hardware/interfaces/audio/ └── HIDL/AIDL 接口定义

• 少量在packages/modules/：

  packages/modules/Bluetooth/audio/ # 蓝牙音频相关

二、未完全迁移的核心原因

1.性能和延迟的硬性要求⏱️

• 实时性要求：音频处理需要极低延迟（<10ms）
• 硬件直通：许多编解码器需要直接访问硬件
• 中断处理：音频 DMA 需要高效中断响应
• 模块化开销：APEX 包的抽象层会引入额外延迟

对比示例：

2.硬件碎片化严重🎚️

• 编解码器多样性：高通/联发科/三星各有私有音频 DSP
• 音频 HAL 差异：

  // 不同厂商的 HAL 差异巨大// 高通：audio.primary.msm8996.so// 三星：audio.primary.exynos.so// 联发科：audio.primary.mtk.so

• 定制 DSP 算法：噪声消除、空间音频等厂商定制功能

3.复杂的依赖关系🔗

Audio 系统依赖网络： ├── 电源管理 (Power HAL) ├── 设备管理器 (DeviceManager) ├── 传感器 (Sensor HAL) # 用于自动音量调整 ├── 相机 (Camera HAL) # 视频录制同步 ├── 蓝牙 (Bluetooth) # A2DP/HFP ├── USB (USB HAL) # USB 音频 └── DRM 框架 # 受保护内容播放

4.系统启动时序要求🚀

• 早期启动：开机声音、TTS 需要极早可用
• 模块加载顺序：音频需要在 UI 前启动
• 恢复模式：需要在不完整系统中工作

三、部分模块化的尝试

已模块化的部分

渐进式演进策略

1. Android 10-12：定义稳定的 Audio HAL 接口
2. Android 13+：尝试将音频后处理链模块化
3. 未来：可能将非实时路径模块化

四、技术挑战详解

挑战 1：实时性保证

// 当前的直接调用路径app → AudioFlinger → HAL → Driver// 延迟：~5ms// 模块化后的路径app →AudioService(APEX)→ AudioFlinger → HAL → Driver// 增加延迟：+3-5ms

挑战 2：内存共享

// 当前：直接内存共享audio_buffer=malloc_shared(SHARED_BUFFER);// 模块化：需要进程间复制audio_buffer=binder_allocate_copy(SHARED_BUFFER);// 额外开销：内存复制 + 同步延迟

挑战 3：硬件抽象层兼容性

# 当前：直接链接 LOCAL_SHARED_LIBRARIES := libaudiohal # 模块化：版本化管理 LOCAL_APEX_LIBRARIES := \ com.android.audio@1.0 \ com.android.audio@2.0 # 问题：旧版 HAL 需要新版模块支持

五、Google 的折中方案

1.接口标准化而非实现模块化

• 保持 AudioFlinger 在系统镜像中
• 但定义稳定的 HIDL/AIDL 接口
• 允许第三方替代部分功能

2.选择性模块化

3.增量改进

• Android 12：改进音频 HAL 稳定性
• Android 13：音频设备枚举模块化
• Android 14：蓝牙 LE Audio 完全模块化

六、行业对比

七、实际影响

开发者角度

// 好消息：API 保持稳定AudioManageram=(AudioManager)getSystemService(AUDIO_SERVICE);am.setStreamVolume(...);// 接口不变// 坏消息：底层差异仍需处理if(Build.VERSION.SDK_INT>=Build.VERSION_CODES.TIRAMISU){// 新音频功能可能依赖系统版本}

OEM 厂商角度

• 优势：仍可深度定制音频体验
• 劣势：音频安全更新仍需自行 backport
• 责任：需维护音频 HAL 驱动

用户角度

• ✅ 获得厂商调音特色
• ❌ 安全更新可能延迟
• ⚠️ 音频质量因设备而异

八、未来可能性

可能模块化的部分

1. 音频效果器框架（可独立更新算法）
2. 音频策略引擎（路由逻辑）
3. 格式转换库（非实时编解码）
4. MIDI 子系统（专业音频）

技术前提

• 实时 Linux 改进：PREEMPT_RT 更成熟
• 硬件虚拟化：音频 DSP 虚拟化支持
• 新总线标准：更低延迟的模块间通信

九、总结

Audio 没有完全移到packages/modules是权衡的结果，而非技术不足：

根本矛盾：模块化的解耦优势vs 音频系统的集成需求

目前 Google 采取的是渐进式、选择性模块化策略，优先模块化那些：

1. 非实时路径
2. 相对独立的子系统
3. 安全敏感组件
4. 新硬件支持

这种务实做法确保了 Android 音频在保持性能的同时，逐步获得模块化的部分好处。