Android深度探索HAL與驅動開發-——第9章

本章主要學習了硬件抽象層：HAL。

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

  編寫支持HAL的Linux驅動程序通常步驟爲：第一步：編寫linux驅動，在爲Linux驅動添加HAL保護敏感數據時，Linux代碼須要簡潔將業務邏輯放到HAL Library中。第二步：編寫HAL Library，它是普通的Linux Library文件，Service Library經過在接口中定義的ID定位HAL。第三步：編寫Service Library。ServiceManager調用Service Library，APK程序調用ServiceManger類訪問Service Library。在編寫Linux驅動以及與驅動相關的程序過程當中應分段測試每一部分程序。
  編寫HAL模塊步驟和原理：第一步：定義結構體和宏，第二步：編寫HAL模塊open函數，第三步：定義hw_module_methods_t結構體變量，第四步：定義HAL_MODULE_INFO_SYM變量，第五步：編寫HAL模塊close函數，第六步：編寫控制LED函數。