硬件抽象层

正如我在第 2 章解释的，Android 依赖硬件抽象层（HAL）来与硬件接口。实际上，系统服务几乎从不通过 /dev 条目直接与设备交互。相反，它们通过 HAL 模块（通常是共享库）与硬件对话，如表 2-1 中详细介绍的那样。

Android 的 HAL 实现位于 hardware/ 中。最重要的是，你会在 hardware/libhardware/include/hardware/ 和 hardware/libhardware_legacy/include/hardware_legacy/ 的头文件中找到框架层与 HAL 模块之间接口的定义。这些头文件提供了每种类型的硬件在 Android 下支持所需的确切 API。你还会在 device/ 中主要设备的源码中找到一些 HAL 模块的示例实现。

理想情况下，你应该避免为现有系统服务实现自己的 HAL 模块。相反，你应该向你的 SoC 或主板供应商查询此类模块。HAL 模块编写需要对与模块必须与之交互的系统服务器的内部结构以及与硬件交互所需的特定 Linux 设备驱动程序有深入的了解。学习如何正确做到这一点可能是一个非常耗时的过程，特别是因为 HAL 接口往往随着每个新版本的 Android 而发展。因此，我强烈建议你使用组件/主板——供应商或 SoC 供应商已经为它们准备好了大部分 HAL 模块。

一般来说，鉴于 Android 的市场成功，组件和 SoC 供应商付出了巨大努力来确保 Android 与他们的产品配合良好。这意味着他们要么为你提供用于评估板上的完整功能性 AOSP 和 Android 就绪内核，和/或 HAL 模块和 Linux 驱动程序。因此，冒着听起来多余的风险，只有作为最后的手段，才为你已经认识的硬件类型实现你自己的 HAL 模块。相反，与你的 SoC 或组件供应商交谈，获取运行你的硬件所需的 HAL 模块和驱动程序（或内核）。

所有主要的 SoC 供应商都以某种方式提供对可用于在评估板上运行的现成 AOSP 和内核的访问。TI、Qualcomm、Freescale、Samsung 和许多其他公司都是如此。如果你基于他们的设计构建自己的定制主板，我建议你获取这些参考 AOSP 树并为你自己的用途进行定制。尝试从 Google 直接提供的 AOSP 树开始，从头开始移植 Android 到你的硬件，可能不是对你的时间或上市时间要求的好利用。

如果你绝对必须为现有系统服务实现自己的 HAL 模块，那么请参考我之前提到的定义每个 HAL 模块类型所需 API 的头文件，并尽可能从 device/ 目录中为主要设备提供的参考 HAL 实现中获取灵感。例如，对于 2.3/Gingerbread，请查看 device/samsung/crespo/ 中的各个 lib*/ 目录。对于 4.2/Jelly Bean，请查看 device/asus/grouper/ 和 device/samsung/tuna/。

图片