android的hal层

Ⅰ android的hal层用什么语言实现

Android的硬件抽象层，简单来说，就是对linux内核驱动程序的封装，向上提供接口，屏蔽低层的实现细节。也就是说，把对硬件的支持分成了两层，一层放在用户空间（User Space），一层放在内核空间（Kernel Space），其中，硬件抽象层运行在用户空间，而Linux内核驱动程序运行在内核空间。为什么要这样安排呢？把硬件抽象层和内核驱动整合在一起放在内核空间不可行吗？从技术实现的角度来看，是可以的，然而从商业的角度来看，把对硬件的支持逻辑都放在内核空间，可能会损害厂家的利益。我们知道，Linux内核源代码版权遵循GNU License，而Android源代码版权遵循Apache License，前者在发布产品时，必须公布源代码，而后者无须发布源代码。如果把对硬件支持的所有代码都放在Linux驱动层，那就意味着发布时要公开驱动程序的源代码，而公开源代码就意味着把硬件的相关参数和实现都公开了，在手机市场竞争激烈的今天，这对厂家来说，损害是非常大的。因此，Android才会想到把对硬件的支持分成硬件抽象层和内核驱动层，内核驱动层只提供简单的访问硬件逻辑，例如读写硬件寄存器的通道，至于从硬件中读到了什么值或者写了什么值到硬件中的逻辑，都放在硬件抽象层中去了，这样就可以把商业秘密隐藏起来了。也正是由于这个分层的原因，Android被踢出了Linux内核主线代码树中。大家想想，Android放在内核空间的驱动程序对硬件的支持是不完整的，把Linux内核移植到别的机器上去时，由于缺乏硬件抽象层的支持，硬件就完全不能用了，这也是为什么说Android是开放系统而不是开源系统的原因。
撇开这些争论，学习Android硬件抽象层，对理解整个A

Ⅱ Android图形系统系统篇之HWC

HWC （hwcomposer）是Android中进行窗口（ Layer ）合成和显示的HAL层模块，其实现是特定于设备的，而且通常由显示设备制造商 (OEM)完成，为 SurfaceFlinger 服务提供硬件支持。

SurfaceFlinger 可以使用 OpenGL ES 合成 Layer ，这需要占用并消耗GPU资源。大多数GPU都没有针对图层合成进行优化，当 SurfaceFlinger 通过GPU合成图层时，应用程序无法使用GPU进行自己的渲染。而 HWC 通过硬件设备进行图层合成，可以减轻GPU的合成压力。

显示设备的能力千差万别，很难直接用API表示硬件设备支持合成的 Layer 数量， Layer 是否可以进行旋转和混合模式操作，以及对图层定位和硬件合成的限制等。因此HWC描述上述信息的流程是这样的：

虽然每个显示设备的能力不同，但是官方要求每个 HWC 硬件模块都应该支持以下能力：

但是并非所有情况下 HWC 都比GPU更高效，例如：当屏幕上没有任何变化时，尤其是叠加层有透明像素并且需要进行图层透明像素混合时。在这种情况下， HWC 可以要求部分或者全部叠加层都进行GPU合成，然后 HWC 持有合成的结果Buffer，如果 SurfaceFlinger 要求合成相同的叠加图层列表， HWC 可以直接显示之前合成的结果Buffer，这有助于提高待机设备的电池寿命。

HWC 也提供了 VSync 事件，用于管理渲染和图层合成时机，后续文章会进行介绍。

Android7.0提供了HWC和HWC2两个版本，默认使用HWC，但是手机厂商也可以选择HWC2，如下所示：

SurfaceFlinger 通过 HWComposer 使用 HWC 硬件能力， HWComposer 构造函数通过 loadHwcMole 方法加载HWC模块，并封装成 HWC2::Device 结构，如下所示：

上述通过 hw_get_mole 方法（hardware\libhardware\hardware.c）加载 hwcomposer 模块，此模块由硬件厂商提供实现，例如：hardware\libhardware\moles\hwcomposer\hwcomposer.cpp是 hwcomposer 模块基于HWC1的default实现，对应的共享库是 hwcomposer.default.so ；hardware\qcom\display\msm8994\libhwcomposer\hwc.cpp是高通MSM8994基于HWC1的实现，对应的共享库是 hwcomposer.msm8994.so 。
如果是基于HWC2协议实现，则需要实现hwcomposer2.h中定义的 hwc2_device_t 接口，例如： class VendorComposer : public hwc2_device_t 。Android7.0的 hwcomposer 模块默认都是基于HWC1协议实现的。
每个HAL层模块实现都要定义一个 HAL_MODULE_INFO_SYM 数据结构，并且该结构的第一个字段必须是 hw_mole_t ，下面是高通MSM8994 hwcomposer 模块的定义：

frameworks\native\services\surfaceflinger\DisplayHardware\HWC2.h主要定义了以下三个结构体：

它们是对 HWC 硬件模块的进一步封装，方便进行调用。 HWC2::Device 持有一个 hwc2_device_t ，用于连接硬件设备，它包含了很多HWC2_PFN开头的函数指针变量，这些函数指针定义在 hwcomposer2.h 。
在 HWC2::Device 的构造函数中，会通过 Device::loadFunctionPointers -> loadFunctionPointer(FunctionDescriptor desc, PFN& outPFN) -> hwc2_device_t::getFunction 的调用链从硬件设备中获取具体的函数指针实现。关键模板函数如下所示：

这些函数指针主要分为三类：

通过上述函数指针可以与 hwc2_device_t 表示的硬件合成模块进行交互。三类指针分别选取了一个示例：

可以通过类图，直观感受下引用关系。

HWC2::Device 构造函数除了完成获取函数指针实现以外，还会通过 Device::registerCallbacks 向硬件设备注册三个 Display 的回调：热插拔，刷新和VSync信号，如下所示：

总结一下， HWC2::Device 构造函数向硬件设备注册三个 Display 回调：热插拔，刷新和VSync信号。当 HWC2::Device 收到这些回调时，会通过监听器向外回调到对应的HWComposer函数： HWComposer::hotplug / HWComposer::invalidate / HWComposer::vsync 。HWComposer再通过这些信息驱动对应工作，后续文章进行介绍。

上文提到 HWC2::Device 中的函数指针是hardware\libhardware\include\hardware\hwcomposer2.h中定义的，除此之外，该头文件还定义了一些重要的结构体，这里介绍两个比较重要的：

DisplayType 表示显示屏类型，上面注释已经介绍，重点看下Layer合成类型：

那么一个 Layer 的合成方式是怎么确定的那？大致流程如下所示：

本篇文章只是简单介绍了HWC模块的相关类： HWComposer 、 HWC2::Device 、 HWC2::Display 和 HWC2::Layer ，以及它们的关系。此外，还着重介绍了Layer的合成方式和合成流程。后续文章会更加全面的介绍 SurfaceFlinger 是如何通过HWC模块完成Layer合成和上屏的（虚拟屏幕是到离屏缓冲区）。

Ⅲ 有没有那本书介绍android hal层

书到没见过，只有一些资料而已：
Android HAL层即硬件抽象层是Google响应厂家“希望不公开源码”的要求推出的概念
1，源代码和目标位置
源代码： /hardware/libhardware目录,该目录的目录结构如下：
/hardware/libhardware/hardware.c编译成libhardware.so，目标位置为/system/lib目录
Android.mk中lib文件默认使用LOCAL_MODULE_PATH是等于TARGET_OUT_SHARED_LIBRARIES的。
/hardware/libhardware/include/hardware目录下包含如下头文件：
hardware.h 通用硬件模块头文件hw_mole_t和hw_get_mole_by_class的定义
bit.h bit模块头文件
gralloc.h gralloc模块头文件
lights.h 背光模块头文件
overlay.h overlay模块头文件
qemud.h qemud模块头文件
sensors.h 传感器模块头文件
/hardware/libhardware/moles目录下定义了很多硬件模块
这些硬件模块都编译成xxx.xxx.so，目标位置为/system/lib/hw目录

Ⅳ Android中HAL层与内核驱动之间的关系

hal通过linux的用户空间接口去间接的使用内核驱动，内核驱动再去控制实际的硬件。

Ⅳ Android HIDL概述(一)

Android O(8.0) 版本之后，底层实现有了比较大的变化，最显着的一个方面就是 HIDL 机制的全面实施。本文及接下来的几篇博文将从 HIDL的基本概念 、 HIDL服务模拟 、 framework层aidl服务 、 应用层程序 这四个方面来全面的阐述 HIDL 工作全过程，这对于理解系统源码中 Gnss 、 Usb 、 Camera 等正大歼模块的工作原理有极大帮助。

在 Android O(8.0) 之前系统的升级牵扯多方协作，极为麻烦， HIDL 机制的推出就是将 framework 与 hal 层分开，使得框架部分可以直接被覆盖、更新，而不需要重新对 HAL 进行编译，这样在系统升级时， OEM 厂商 跳过 SoC 厂商，先对 framework 进行升级。

framework 与 hal 紧紧耦合存在于 system.img 中，因此在版本升级时需要: OEM 厂商适配 framework ， SoC厂商 适配 hal ， 之后将修改打包到 system.img ，生成仿灶 OTA 升举冲级包，推送到手机进行 OTA 升级

framework 与 hal 进行了解耦， framework 存在于 system.img ， hal 存在于 vendor.img ，进行版本升级时，分为两次升级:

正如上述所言，旧版的系统架构中， Android Framework 层与 Hal 层是打包成一个 system.img 的，且 Framework 与 hal 层之间是紧密耦合的，通过链接的方式使用相应的硬件 so 库。它们之间的架构一般有如下两种方式：

为了解决两者之间这种紧耦合所带来的弊端，google 引入 HIDL 来定义 Framework 与 HAL 之间的接口，可以用下图来描述：

事实上虽然 google 推出了这种机制，但是很多厂商没有很快的跟上节奏，因此为了向前兼容， google 定义了三种类型：

上述可总结为 ：

[ 1 ] hidl
[ 2 ] hidl trebl 演进