Android AOSP 架构和各层次开发内容介绍

一、系统架构总况​​​​

官方文档：架构概览  |  Android Open Source Project (google.cn)https://source.android.google.cn/docs/core/architecture?hl=zh-cnhttps://source.android.google.cn/docs/core/architecture?hl=zh-cn

下面是Google Android 提供的最新架构层次图：

图. AOSP 的软件堆栈层次

System API 表示仅供合作伙伴和 OEM 纳入捆绑应用的 Android API。这些 API 在源代码中被标记为 @SystemApi。

Android API 是面向第三方 Android 应用开发者的公开 API。详情请参阅 Android API 参考文档。

层次（自上而下）

Layer	Comment
Apps 应用层	通过 Android API 或 System API 与FW交互。 - Android Apps：仅使用Android API来开发的应用。 - Privileged Apps：特权应用，使用Android和系统API组合创建的应用，必须预安装在设备上。 - Device Manufacturer Apps：设备制造商应用，使用Android和系统API并直接访问Android框架实现而创建的应用（此类APP可以之间跟FW交互，不一定有中间层API，可能会直接访问Android FW中不稳定的API），必须原装在设备上，并且只能在设备的系统软件更新时进行更新。
Android Framework 框架层	构建应用所依据的一组 Java 类、接口和其他预编译代码。 框架的某些部分可通过使用 Android API 公开访问。 框架的其他部分只能由 OEM 通过系统 API 来访问。 Android 框架代码在应用进程内运行。
System Service 系统服务	系统服务是重点突出的模块化组件，例如 system_server、SurfaceFlinger 和 MediaService。 Android 框架 API 提供的功能可以与系统服务进行通信，以访问底层硬件。
Android Runtime 系统运行库层（ART）	AOSP 提供的 Java 运行时环境。 ART 会将应用的字节码转换为由设备运行时环境执行的处理器专有指令。 执行应用的字节码，管理 Java 虚拟机。
HAL 硬件抽象层	HAL 是一个抽象层，其中包含硬件供应商要实现的标准接口。 HAL 让 Android 无需关注较低级别的驱动程序实现。 借助 HAL，可以顺利实现相关功能，而不会影响或更改更高级别的系统。详情参阅 HAL 概览。
System Service and Daemons 系统服务和守护进程	Daemons 守护进程。 该层中的原生守护程序包括 init、healthd、logd 和 storaged。这些守护程序直接与内核或其他接口进行交互，并且不依赖于基于用户空间的 HAL 实现。 该层中的原生库包括 libc、liblog、libutils、libbinder 和 libselinux。这些原生库直接与内核或其他接口进行交互，并且不依赖于基于用户空间的 HAL 实现。
Linux Kernel 内核层	抽象层，存在软硬件之间。驱动。 内核是任何操作系统的中心部分，并与设备上的底层硬件进行通信。尽可能将 AOSP 内核拆分为与硬件无关的模块和特定于供应商的模块。 AOSP 内核组件的说明（包括其定义）详情请参阅内核概览。

Android 大致可以分为四层架构：（2020年《第一行代码（第3版）》 ，比Google少了硬件抽象层的描述）

1. Linux内核层
2. 系统运行库层
3. 应用框架层
4. 应用层

按照Google 之前提供，Android 系统架构分为五层：（自上而下）

1. 应用层（Application Layer）
2. 应用框架层（Framework Layer）
3. 系统运行库层（Libraries & Android Runtime）
   1. ART（Android Runtime）

   2. Native 层（C/C++ Libraries）

4. 硬件抽象层（HAL, Hardware Abstraction Layer）
5. Linux内核层（Kernel Layer）</