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 演進