Android 系统架构

1. 整体架构

2. Linux 内核

3. HAL 层

Android 的 HAL（Hardware Abstraction Layer，硬件抽象层）负责把 具体、各厂商不同的底层驱动 / 硬件实现 与上层 Android 框架解耦，向框架提供一组稳定、可版控的接口，使得框架可以在不改动的情况下支持不同厂商的硬件实现。 Android Open Source Project

在体系结构中的位置（简要图示）

应用层 → Framework（Java / System Server / native framework）→ HAL → Linux kernel / 驱动（内核）
HAL 运行在用户空间（user-space），作用在 framework 与内核驱动之间，承担“翻译器 / 适配器”的角色：把 framework 的请求转成硬件或驱动能处理的调用或协议。

3.1 现代 HAL 架构

HAL 在现代 Linux 系统中已经发生了根本性的演变​​。它不再是一个单一的、庞大的守护进程。传统的、被称为 ​​HALd​​ 的 “经典HAL” 早在几年前就被淘汰和取代了。

因此，要理解“目前的HAL架构”，我们需要分两部分来看：

• ​​传统HAL的架构（已被废弃）​​

• ​​现代Linux设备管理架构（取代HAL的当前方案）​

传统HAL的架构（已被废弃）

尽管已被废弃，但理解其架构有助于明白为什么现代系统要改变。

​​核心思想：​​ 传统HAL的目标是提供一个统一的、抽象的接口来枚举和操作硬件设备，而不论设备是何时加入系统的（开机时还是运行时）。

​​架构组件：​​

• ​​hald 守护进程：​​ 这是HAL的核心。它是一个一直运行在后台的守护进程。
• ​​信息合并点：​​ hald会从多个数据源收集硬件信息：

​​/proc 和 /sys：​​ 从Linux内核的sysfs（通常是/sys）文件系统中读取设备信息（如厂商ID、产品ID、设备类型等）。

​​udev：​​ 监听来自udev（设备管理器）的事件。当有设备插入或移除时，udev会通知hald。

​​外部程序调用：​​ hald会运行一系列位于/usr/lib/hal目录下的辅助程序（称为“callouts”），这些程序可以执行特定命令来获取更详细的设备信息（例如，调用lspci来获取PCI设备详情，或从fdisk -l获取存储容量）

​​设备对象存储：​​ hald将从各个来源收集到的信息合并成一个统一的 ​​设备对象​​。每个设备对象都有一组“键值对”属性，详细描述了该设备（如storage.size， pci.vendor_id等）。

​​D-Bus 接口：​​ 这是HAL对外提供服务的唯一方式。hald会将所有设备对象及其属性通过 ​​D-Bus 系统总线​​ 发布出去。应用程序、桌面环境（如GNOME、KDE）或其他服务可以通过向D-Bus发送方法调用或监听信号来查询和管理设备。

传统HAL架构的简化数据流：​​

内核/udev-> hald 守护进程-> 合并信息到设备对象-> 通过 D-Bus 发布

缺点（导致其被废弃的原因）：​​

• ​​重复劳动：​​ udev本身已经能很好地处理设备节点和基本属性，HAL在udev之上又构建了一层，造成了复杂性。
• ​​单一故障点：​​ hald守护进程如果崩溃，整个系统的设备管理都会瘫痪。
• ​​维护困难：​​ 代码庞大且复杂，难以维护和扩展。
• ​​权限问题：​​ 设备访问策略分散在HAL策略文件和udev规则中，管理混乱。

现代Linux设备管理架构图描述：

从大约 systemd 和 udev 版本 175 开始，HAL 的功能被分解为多个更专业、更现代化的组件。​​“目前的HAL”不再是一个单独的软件，而是一套由多个组件协同工作的架构。​​

其核心设计哲学是：​​“将功能下放”​​。让每个组件只做自己最擅长的事。

现代架构的核心组件：

• Linux 内核​​

​​角色：​​ 最底层，通过 sysfs(/sys), procfs(/proc), devtmpfs等虚拟文件系统暴露硬件和设备信息。

​​功能：​​ 提供设备的原始数据源。

• udev​​

​​角色：​​ 设备管理器，是现代架构的​​核心​​。它运行在用户空间，但紧密集成在系统启动过程中（现在是 ​​systemd-udevd​​ 服务）。

​​功能：​​

​​动态设备管理：​​ 监听内核的uevent，处理设备的热插拔。

​​创建设备节点：​​ 在 /dev目录下动态创建和管理设备文件。

​​设备命名：​​ 提供持久化的、有意义的设备名称（如 /dev/disk/by-label/）。

​​设备属性处理：​​ 通过内置功能或hwdb提供设备属性信息，取代了HAL需要调用外部程序的部分功能。

• D-Bus​​

​​角色：​​ 进程间通信总线。它取代了HAL作为“通信层”的角色，但方式更直接。

​​功能：​​ 允许服务和应用程序直接提供接口，而不是通过HAL这个“中间人”。

• 专用D-Bus服务（取代HAL的核心）​​

这是最关键的变化。HAL的“统一接口”被拆分成多个独立的、功能专一的D-Bus服务：

​​systemd-logind：​​ 管理会话、电源操作（关机、重启、休眠）和输入设备（键盘、鼠标）的访问。许多原来由HAL处理的登录和电源事件现在由它负责。

​​udisks：​​ 专门管理​​存储设备​​（硬盘、U盘、SD卡）。它提供D-Bus接口来查询磁盘信息、挂载/卸载文件系统、格式化等。应用程序（如文件管理器）直接与udisks2（当前版本）通信。

​​upower：​​ 专门管理​​电源​​（电池、AC适配器）。它提供电池状态、电量估计等信息的D-Bus接口。

​​NetworkManager：​​ 专门管理​​网络设备​​（有线、无线）。处理网络连接和配置。

​​bluez：​​ 专门管理​​蓝牙设备​​。

• 硬件数据库​​

​​hwdb：​​ 由udev管理的一个静态数据库，用于将设备的硬编码ID（如厂商ID、产品ID）映射到更友好的属性（如“这是一个笔记本电脑键盘”、“这个鼠标的滚动方向应该反转”）。这取代了HAL中一部分设备识别逻辑。

现代架构的简化数据流（以插入一个U盘为例）：

1. ​​内核​​ 检测到新的USB存储设备，在/sys中创建条目，并发送uevent。
2. ​​udev​​ 接收到uevent。

• 根据规则，在/dev下创建设备节点（如sdb1）。
• 查询hwdb并设置设备属性。
• 触发相应服务。

    3.​​udisks2​​ 服务被udev事件激活。

• udisks2探测该存储设备，获取其详细信息（文件系统类型、标签、容量等）。
• udisks2将这些信息通过 ​​D-Bus​​ 接口发布。

    ​​4. 文件管理器​​ 监听到D-Bus上来自udisks2的“设备添加”信号。

    5.文件管理器调用udisks2提供的D-Bus方法，请求​​挂载​​该设备。

    6.udisks2执行挂载操作，并通过D-Bus返回挂载点路径。

    7.文件管理器在图形界面中显示该U盘图标。

总结对比

特性	传统HAL架构	现代Linux设备管理架构
​​核心组件​​	单一的hald守护进程	udev + 多个专用的D-Bus服务（udisks2, upower, logind等）
​​通信方式​​	所有通信必须通过HAL的D-Bus接口	应用程序直接与专用的D-Bus服务通信
​​设计哲学​​	大一统的抽象层	模块化、功能分解、各司其职
​​健壮性​​	相对脆弱，hald崩溃则全部失效	更健壮，一个服务崩溃不影响其他功能
​​复杂性​​	集中在HAL内部，复杂但隐蔽	分布在组件间的交互中，更清晰、易于维护和调试

目前的HAL架构是一个模块化的、基于udev和一系列专用D-Bus服务的联合体。​​ 它摒弃了传统的单一守护进程模式，采用了“单一职责原则”，使得系统更加灵活、稳定和易于维护。当现在提到“Linux上的硬件抽象层”时，指的正是这套协同工作的现代架构。

4. Native C/C++ Libraries

Native C/C++ Libraries（原生 C/C++ 库）的作用

• 性能优化：C/C++ 语言编译后生成的机器码执行效率高，Native C/C++ Libraries 能为对性能要求苛刻的场景提供支持，比如游戏开发中复杂的图形渲染、多媒体应用里的音视频编解码等。以 3D 游戏为例，OpenGL ES 库能够快速处理图形数据，实现高帧率、高质量的 3D 画面渲染，让玩家获得流畅逼真的游戏体验。
• 底层功能支持：Libc 作为标准 C 库，提供了文件操作、进程管理、内存分配等基础功能，是 Android 系统底层运行的基石。其他如 Webkit、OpenMAX AL 等库则分别针对网页渲染、多媒体处理等领域，提供了特定的底层功能实现。比如 Webkit 能解析网页代码，将网页内容呈现给用户；OpenMAX AL 可对不同格式的多媒体数据进行编解码处理，确保音视频播放等功能的正常运行。
• 跨平台复用：许多 C/C++ 库具有跨平台特性，这使得开发者在不同操作系统上可以复用代码，减少开发成本。在 Android 开发中，使用这些成熟的 C/C++ 库，能够借助其在其他平台上积累的技术和经验，快速实现所需功能。

Android Runtime（安卓运行时环境）的作用

• 应用执行环境：ART 是 Android 应用运行的虚拟机，它负责加载、解析和执行应用的字节码文件。通过 AOT 预编译技术，ART 在应用安装阶段将字节码编译成机器码，大幅提升了应用的启动速度和执行效率。例如，在启动一款大型的社交应用时，ART 能够让应用更快地加载界面、读取数据，减少用户等待时间。
• 系统与应用交互桥梁：Core Libraries 包含了丰富的 API，为开发者提供了访问 Android 系统各种资源和功能的接口。应用开发者通过调用这些 API，能够实现与系统硬件（如摄像头、麦克风等）和软件资源（如文件系统、数据库等）的交互。比如，开发者利用 Core Libraries 中的传感器 API，可以获取手机加速度计、陀螺仪等传感器的数据，开发出运动监测类应用。

两者的关系

• 协作关系：Native C/C++ Libraries 为 Android 应用提供底层的功能支持，而 Android Runtime 则负责运行应用程序，两者相互协作以实现应用的完整功能。例如，在一个视频播放应用中，OpenMAX AL 库负责对视频流进行编解码等底层处理，ART 则运行应用程序的逻辑代码，协调用户界面的显示、用户操作的响应等，两者共同作用，让用户能够顺利播放视频。
• 依赖关系：Android Runtime 中的 Core Libraries 部分功能的实现可能依赖于 Native C/C++ Libraries。比如，Core Libraries 中涉及多媒体处理、图形渲染的 API，可能会调用 OpenMAX AL、OpenGL ES 等原生库来完成底层操作。这种依赖关系使得 Android 系统能够充分利用 C/C++ 库的高性能优势，同时为开发者提供更高级、更便捷的编程接口，便于快速开发出功能强大的应用程序。
• 层次关系：从系统架构层面来看，Native C/C++ Libraries 处于更底层，直接与硬件和操作系统内核交互，提供基础功能；Android Runtime 则建立在 Native C/C++ Libraries 之上，为应用程序提供运行环境和编程接口，属于应用层与底层之间的中间层，起到承上启下的作用。

5. framework 开发

va API Framework（框架层）处于 System Apps（系统应用）和 Native C/C++ Libraries（原生 C/C++ 库） 、Android Runtime（安卓运行时环境）之间，起到承上启下的关键作用，其详细作用如下：

为开发者提供丰富的 API 接口

• 构建用户界面：View System（视图系统）提供了各种 UI 组件，如按钮、文本框、列表等，开发者可以通过这些组件快速构建出美观、交互性强的用户界面。比如开发一个新闻阅读应用，使用 View System 可以方便地创建文章列表视图、详情页面视图等。
• 数据存储与共享：Content Providers（内容提供者）允许应用程序之间共享数据，例如联系人信息、短信数据等。开发者可以通过 Content Providers 来读取和写入这些共享数据，实现数据的统一管理。比如，一个第三方通讯录管理应用可以通过 Content Providers 获取系统中的联系人数据进行展示和编辑。

管理系统资源和组件

• Activity 管理：Activity Manager（活动管理器）负责管理应用程序中的 Activity（活动，即应用的界面组件），包括 Activity 的启动、暂停、销毁等生命周期管理。例如，当用户切换应用时，Activity Manager 会处理当前 Activity 的暂停和新 Activity 的启动，确保应用之间的切换流畅，并且合理管理系统资源。
• 位置管理：Location Manager（位置管理器）提供了获取设备地理位置信息的功能，开发者可以通过它获取设备的经纬度、海拔等信息，用于开发地图导航、基于位置的社交应用等。比如，外卖应用可以利用 Location Manager 获取用户的位置，以便准确地配送餐品。
• 包管理：Package Manager（包管理器）用于管理应用程序的安装、卸载、版本更新等操作。它能够读取应用程序的清单文件（AndroidManifest.xml），获取应用的权限、组件信息等，确保应用的正确安装和运行。
• 通知管理：Notification Manager（通知管理器）允许应用程序向用户发送通知，如消息提醒、系统更新提示等。开发者可以自定义通知的样式、内容和触发条件，及时向用户传达重要信息。例如，社交应用通过 Notification Manager 向用户推送新消息通知。
• 资源管理：Resource Manager（资源管理器）负责管理应用程序中的各种资源，如字符串、图片、布局文件等。它可以根据设备的语言、屏幕尺寸等不同配置，加载相应的资源，实现应用的国际化和适配不同设备。
• 电话管理：Telephony Manager（电话管理器）提供了与手机通话相关的功能，如获取手机号码、监听电话状态（通话中、挂断等）等。开发者可以利用这些功能开发电话助手类应用或实现与通话相关的特定业务逻辑。
• 窗口管理：Window Manager（窗口管理器）用于管理应用程序的窗口，包括窗口的创建、显示、隐藏、尺寸调整等。它能够协调多个窗口之间的层级关系，确保用户界面的正常显示和交互。

作为系统应用与底层交互的桥梁

• 衔接上层应用与底层库：Java API Framework 层一方面为 System Apps（系统应用）提供接口，使系统应用能够方便地调用各种功能；另一方面，它又可以调用 Native C/C++ Libraries 和 Android Runtime 中的功能。例如，系统相机应用通过 Java API Framework 层调用 Media Framework 等底层库，实现拍照、录像等功能，同时利用 ART 运行应用的逻辑代码，实现相机界面的操作响应和功能控制 。
• 屏蔽底层差异：它将底层硬件和系统的复杂性进行封装，向上层提供统一的接口，使得系统应用和第三方应用开发者无需关心底层硬件的具体实现细节，降低了开发难度，提高了应用开发的效率和可移植性。比如，无论设备使用何种芯片组和传感器，开发者都可以通过 Java API Framework 层的标准接口来访问传感器数据 。

总之，Java API Framework 层在 Android 系统中处于核心位置，通过提供丰富的 API 和管理功能，极大地便利了应用开发，同时协调了系统各部分之间的工作，保障了整个系统的稳定运行和良好的用户体验。