【AOSP 的分层设计理念与命名规范】
AOSP 的分层设计理念与命名规范
Android Open Source Project(AOSP)是一个庞大的操作系统工程,为了保证可维护性、可扩展性和跨设备适配性,它采用了 严格的分层架构设计。在不同层之间,AOSP 通过统一的 命名规范 和 接口设计 来维持清晰的边界。
一、AOSP 的分层设计理念
AOSP 典型的分层模型可以分为以下几层:
1. 应用层(Application Layer)
-
提供给第三方 App 或系统应用使用的公共 API。
-
主要由 Java/Kotlin Manager 类 组成,例如:
-
AudioManager
-
CarAudioManager
-
BluetoothManager
-
这些类运行在应用进程中,本质是 Binder Client,调用会被转发到 System Server 层。
2. 系统服务层(System Server Layer)
-
在 system_server 进程 中运行的核心服务。
-
由 Java Service 类 实现,例如:
-
AudioService
-
CarAudioService
-
BluetoothService
-
这一层负责:
-
权限校验(例如控制哪些 App 可以修改系统音量)
-
策略调度(例如不同场景下音频路由规则)
-
对接 JNI,调用 native 层服务
3. JNI/中间层(JNI Bridge Layer)
-
通过 JNI(Java Native Interface)将 Java Service 层 的调用桥接到 native 层。
-
典型的命名方式为
XXXSystem
,例如:AudioSystem
(Java ↔ native 之间的桥梁)
职责:
-
将 Java 方法调用转换为 Binder IPC
-
与 native 层的服务(如 AudioFlinger)交互
4. Native Daemon 层(Native Daemon Layer)
-
由独立进程运行的 native 服务,通常进程名以 -server 结尾。
-
例如:
-
audioserver
-
cameraserver
-
drmserver
-
这些进程负责与 HAL 和硬件交互,保证性能与稳定性。
5. Native Service 层(C++ Service Layer)
-
运行在 Daemon 进程中的 C++ 类,一般命名为 XXXService。
-
例如:
-
AudioFlinger
(负责音频混音和播放) -
AudioPolicyService
(负责音频策略和路由)
-
它们通过 Binder 向上层暴露接口,供 AudioSystem
调用。
6. HAL 层(Hardware Abstraction Layer)
-
提供硬件抽象接口,通常遵循 HIDL/AIDL 规范。
-
例如:
-
audio HAL
→ 控制 DSP、Codec 芯片 -
camera HAL
→ 驱动摄像头传感器
-
7. 内核层(Linux Kernel Layer)
-
提供设备驱动、调度、内存和进程管理等基础功能。
-
HAL 通过内核驱动与真实硬件交互。
二、AOSP 的命名规范
Android 在不同层之间有明确的命名规则:
层级 | 命名后缀 | 示例 | 特点 |
---|---|---|---|
应用 API 层 | Manager | AudioManager , CarAudioManager | 面向 App 的公共接口 |
System Server 层 | Service (Java) | AudioService , CarAudioService | 在 system_server 中运行,提供核心逻辑 |
JNI 桥接层 | System | AudioSystem | Java ↔ native 的桥梁 |
Native Daemon 进程 | xxxserver | audioserver , cameraserver | 独立进程,运行多个 native Service |
Native Service (C++) | Service | AudioFlinger , AudioPolicyService | 真正的资源管理与硬件交互 |
HAL 层接口 | HAL / HIDL/AIDL 接口 | audio HAL , camera HAL | 硬件抽象层 |
内核驱动 | Linux 驱动名 | snd_soc_xxx , camera_xxx | 最底层,驱动硬件 |
三、以 Audio 为例的完整调用链
App 层│▼
AudioManager (App API)│ Binder 调用▼
AudioService (System Server)│ JNI 调用▼
AudioSystem (JNI 桥接)│ Binder IPC▼
audioserver (native daemon)├── AudioFlinger (音频混音/播放/录音)└── AudioPolicyService (音频路由/策略)│▼
Audio HAL (HIDL/AIDL 接口)│▼
Linux Kernel Driver → 硬件 Codec/DSP
四、车载扩展 (Car Audio)
车载系统在标准 Android Audio 体系上扩展了 CarAudio
模块:
-
CarAudioManager
→ 提供给车载应用的 API -
CarAudioService
→ 在 system_server 中运行,管理多音区、多音源策略 -
底层依然复用标准的
AudioManager
/AudioService
→audioserver
这样保证了 车载需求(多区域音频、乘员区控制) 与 Android 标准框架 的兼容性。
五、总结
-
分层设计理念:AOSP 采用 Manager → Service → System → xxxserver → HAL → Kernel 的清晰分层,保证模块解耦和跨设备可扩展性。
-
命名规范:
-
Manager
→ API 层 -
Service
(Java) → System Server 层 -
System
→ JNI 桥接层 -
xxxserver
→ Native Daemon 进程 -
Service
(C++) → Native Service -
HAL
→ 硬件抽象层
-
这种分层和命名方式,使 Android 可以 统一对外 API,同时 灵活适配不同硬件平台,尤其在车载系统中,可以扩展 CarAudio 但不破坏整体框架。