第9章 硬件抽象層：HAL

Android的硬件抽象層，簡單來講，就是對Linux內核驅動程序的封裝，向上提供接口，屏蔽低層的實現細節。也就是說，把對硬件的支持分紅了兩層，一層放在用戶空間（User Space），一層放在內核空間（Kernel Space），其中，硬件抽象層運行在用戶空間，而Linux內核驅動程序運行在內核空間。爲何要這樣安排呢？把硬件抽象層和內核驅動整合在一塊兒放在內核空間不可行嗎？從技術實現的角度來看，是能夠的，然而從商業的角度來看，把對硬件的支持邏輯都放在內核空間，可能會損害廠家的利益。咱們知道，Linux內核源代碼版權遵循GNU License，而Android源代碼版權遵循Apache License，前者在發佈產品時，必須公佈源代碼，然後者無須發佈源代碼。若是把對硬件支持的全部代碼都放在Linux驅動層，那就意味着發佈時要公開驅動程序的源代碼，而公開源代碼就意味着把硬件的相關參數和實現都公開了，在手機市場競爭激烈的今天，這對廠家來講，損害是很是大的。所以，Android纔會想到把對硬件的支持分紅硬件抽象層和內核驅動層，內核驅動層只提供簡單的訪問硬件邏輯，例如讀寫硬件寄存器的通道，至於從硬件中讀到了什麼值或者寫了什麼值到硬件中的邏輯，都放在硬件抽象層中去了，這樣就能夠把商業祕密隱藏起來了。也正是因爲這個分層的緣由，Android被踢出了Linux內核主線代碼樹中。你們想一想，Android放在內核空間的驅動程序對硬件的支持是不完整的，把Linux內核移植到別的機器上去時，因爲缺少硬件抽象層的支持，硬件就徹底不能用了，這也是爲何說Android是開放系統而不是開源系統的緣由。

撇開這些爭論，學習Android硬件抽象層，對理解整個Android整個系統，都是極其有用的，由於它從下到上涉及到了Android系統的硬件驅動層、硬件抽象層、運行時庫和應用程序框架層等等，下面這個圖闡述了硬件抽象層在Android系統中的位置，以及它和其它層的關係：

Android加入HAL主要有以下的目的:

1.統一硬件的調用接口。因爲HAL 有標準的調用接口，因此能夠利用HAL:屏蔽Linux 驅動
複雜、不統一的接口。
2.解決了GPL版權問題。因爲Linux 內核基於GPL協議，而Android 基於Apache Licence 2.0 協議．所以Google 玩了個「穿越「。將本來位於Linux驅動中的敏感代碼向上移了一個層次。這樣這些敏感代碼就擺脫了GPL 協議的束縛， 那些不想開源的Linux驅動做者也就不必開源了。
3.針對一些特殊的要求。對於有些硬件，可能須要訪問一些用戶空間的資源，或在內核空間不方便完成的工做以及特殊需求。在這種狀況下，能夠利用位於用戶空間的HAL 代碼來輔助Linux驅動完成一些工做。

編寫一款支持HAL 的Linux 驅動程序的步驟

第1 步：編寫Linux 驅動

第2 步：編寫HAL Library

第3 步：編寫Service Library

編寫HAL 模塊的步驟和原理

第1步：定義結構體和宏

編寫HAL 模塊須要使用到3 個很是重要的結構體（ hw_module_t 、hw_device_t 和hw _ module_ methods_t ）， 在第1步須要定義兩個新的結構體， 這兩個結構體的第1個變量的數據類型必須是hw_module_t 和hw_device_t。除此以外， 還須要爲HAL 模塊定義一個ID。

第2步：編寫HAL 模塊的open函數

open 函數是HAL 模塊的入口點。

第3步：定義hw_module_methods_ t 結構體變量

HAL 模塊須要hw_module_methods_t 結構體的open 函數指針交量指定open 入口函數。

第4步： 定義HAL_MODULE_INFO_SYM 變量

全部的HAL 模塊都必須有一個HAL_MODULE_INFO_SYM 變量。

第5步：編寫HAL 模塊的close 函數

當HAL 模塊被卸載後會調用close 函數。

第6步:編寫控制LED 的函數

根據設備類型和功能的不一樣，這一步編寫的函數也有所不一樣。