Android系统架构

没办法基础的东西还是要写一下的

Android架构及拓展图

贴一张官网上修改过后的图片（我会尽量精简内容 其实就是懒得写

总结

我自己写似乎不大好看，直接让ai帮我总结制表了，放前面方便比对看看
建议开电脑看

模块	交互对象	交互方式	稳定性	解释
Android Framework (AOSP/保护)	HAL Implementation (Vendor)	Binder IPC (橙色)	稳定	上层框架通过标准的 AIDL 接口，利用 Binder 机制调用 HAL 服务。这是 Android 跨进程、跨边界通信的标准方式。
Android Framework (AOSP/保护)	Generic Kernel (AOSP/保护)	Binder IPC (橙色)	稳定	Framework 通过 JNI 或系统调用（System Calls）间接或直接与内核交互，很多系统服务依赖 Binder 驱动。
HAL Implementation (Vendor)	Generic Kernel (AOSP/保护)	系统调用/驱动接口	稳定	HAL 进程通过标准 Linux 系统调用或 Binder IPC（调用内核驱动）与内核交互。这个接口必须稳定。
Generic Kernel (AOSP/保护)	GKI Modules (AOSP/保护)	内部内核 API (虚线)	不稳定	两者共同构成 GKI 内核，由 Google/AOSP 统一维护和发布，内部接口无需承诺稳定。
GKI Modules (AOSP/保护)	Vendor Modules (Vendor)	KMI (粗黑箭头)	稳定	GKI 架构的核心。GKI 内核对 Vendor Modules 暴露的二进制接口是稳定的，允许两者独立更新。
HAL Implementation (Vendor)	Vendor Modules (Vendor)	驱动调用 (虚线)	不稳定	HAL 运行时加载或直接调用 Vendor Modules (驱动程序) 提供的功能。这是厂商内部的实现细节，接口稳定性由厂商自行维护。

内核（ACK到GKI）

1.旧的内核版本中（5.4以前）

Android内核由LTS（Linux那家伙）打补丁而来，导致”一大坨“不一样的内核四处可见，即内核的碎片化
可以在图上看到

2.GKI统一了核心内核

将soc和板级支持等作为供应商模块加载

Binder

进程间的通信机制
基于引用实现，OOP设计，进程抽象为客户端 服务端 和 中间代理
如Android框架与HAL通信（图上）

KMI

可以看到，KMI接口 将 Vendor Modules 和 GKI Modules相连接
使得厂家可以不用频繁适配自己的vendor module

HAL

负责硬件和上层应用，无需调用硬件本身可以实现硬件功能

其他安全相关下次可以随便写写

Context--->SELinux
AVB 早期的DM(dm-verity)机制