Android接口和架構學習

Android接口和架構學習

縮寫：

HAL：HardwareAbstraction Layer。硬體抽象層

CTS：CompatibilityTest Suite，相容性測試套件

Android讓你能夠自由實作裝置規格和驅動，HAL提供一套标準方法來在Android平台棧(platform stack)和硬體之間建立軟體鈎子(hook)。Android系統是開源的，你能夠貢獻自己的接口和添加功能。

為保證裝置保持高品質和提供一直的使用者體驗，每一個裝置必須通過CTS測試。CTS確定裝置滿足品質标準。保證APP的可靠執行和好的使用者體驗。

在移植Android到你的硬體平台上，花些時間從一定高度來了解Android系統架構。

由于你的驅動和HAL要和android互動，了解Android工作機制能夠幫助你有效控制Android源碼樹的多層代碼。

圖1

1.     應用架構層(Applicationframework)

應用架構層主要是應用程式開發人員常常使用。作為硬體開發人員，你應該知道盡可能多的API，且要知道這些API和底層HAL接口的映射關系，這樣能夠提供關于實作驅動的實用資訊。

2.     IPC程序間通訊機制Binder(Binder IPC)

Binder機制同意應用架構層款過程序界限并訪問Android系統服務代碼，這可使高層的架構API和Android系統服務互動，在應用架構層，這樣的通訊對開發人員隐藏并表現為事情就好像是順其自然完畢一樣。

3.     系統服務(system services)

應用架構API提供的函數和系統服務通信以訪問底層硬體，服務是子產品化的，比方比較重要的Windows Manager窗體管理器、Serarch Service搜尋服務或是Notification Manager通知管理器。Android包括兩組服務：系統(比方Windows Manager和Notification Manager)和多媒體服務(如錄制和播放媒體服務)

4.     HAL硬體抽象層(Hardware Abstraction Layer)

HAL定義一組标準接口來讓裝置廠商去實作。同意Android不必知道底層驅動的實作。

HAL同意你在不影響或是改動上層系統的前提下實作功能，HAL的實作被打包成為子產品(.so檔案)檔案，而且在适當的時候被Android系統載入。

圖2

你必須為産品的硬體實作相應的HAL(和驅動)。 HAL的實作典型的被編譯成共享庫子產品(.so檔案)，Android沒有要求在HAL實作和裝置驅動之間是标準的互動，是以你能夠基于自己的情況做最适合的事情。可是，為了保證Android系統能夠和硬體正确互動。你必須遵守每一個具有硬體特性的HAL接口協定。

5.     标準HAL結構體(Standare HAL structure)

每一個特定硬體HAL接口都有其特性，由hardware/libhardware/include/hardware/hardware.h的結構體hw_module_t定義，這樣可保證HAL有個可預見的結構。HAL接口同意Android系統一緻性的載入你的HAL子產品的正确版本号。

HAL接口由兩個通用的元件組成：一個子產品(module)和一個裝置(device)。

5.1   子產品(module)

子產品打包了HAL的實作。這些實作作為一個共享庫.so檔案展現。

它包括子產品的version、name、author，這些成員幫助Android找到和載入子產品，子產品相應的結構體為hw_module_t，在hardware/libhardware/include/hardware/hardware.h定義。此結構體描寫叙述一個子產品和包括比方子產品版本号、作者和名字。

除此之外。hw_module_t結構體還包括指向hw_module_methods_t結構體的指針methods，hw_module_methods_t結構體包括一個打開子產品的函數指針open。這個open函數作為一個抽象服務發起和硬體的通信。每一個詳細的硬體HAL通常要擴充通用的hw_module_t結構體，添加附加資訊來更好的描寫叙述詳細的硬體。

比方攝像頭HAL，

typedefstruct camera_module {
    hw_module_t common;
    int (*get_number_of_cameras)(void);//擴充部分
    int (*get_camera_info)(int camera_id,struct camera_info *info); //擴充部分
}camera_module_t;      

當你實作一個HAL和建立子產品結構體。你必須以HAL_MODULE_INFO_SYM來給name成員指派，比方：

structaudio_module HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version =AUDIO_MODULE_API_VERSION_0_1,
        .hal_api_version =HARDWARE_HAL_API_VERSION,
        .id = AUDIO_HARDWARE_MODULE_ID,
        .name ="NVIDIA Tegra Audio HAL",
        .author = "The Android Open SourceProject",
        .methods = &hal_module_methods,
    },
};      

5.2   裝置(device)

裝置抽象了産品實際的硬體。比方一個音頻子產品包括一個主要的音頻裝置、一個USB音頻裝置或一個藍牙A2DP音頻裝置。一個裝置由hw_device_t結構體描寫叙述，像子產品一樣。每種類型的裝置可在hw_device_t結構體的基礎上定義很多其它細節資訊，比方指向硬體特征的函數指針。audio_hw_device_t就包括指向音頻裝置操作的函數指針get_supported_devices。

struct audio_hw_device {
   struct hw_device_t common;
 
   /**
    * used by audio flinger to enumerate what devices are supported by
    * each audio_hw_device implementation.
    *
    * Return value is a bitmask of 1 or more values of audio_devices_t
    */
   uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
  ...
};
typedef struct audio_hw_deviceaudio_hw_device_t;      

除了這些标準的屬性，每一個詳細硬體HALC接口能夠定義多個硬體特有屬性和需求

6.     HAL子產品

HAL的實作被編譯成為子產品(.so)檔案和在Android合适的時候會動态連結它。你能夠為你每一個HAL實作建立Android.mk檔案來編譯你的子產品并指向你的源碼檔案。

通常。你的共享庫必須以某種格式命名，這樣它們才可能被找到和載入。從子產品到子產品的命名方案略有不同，可是一般遵循以下的形式：<module_type>.<device_name>

很重要，比方module_type能夠是GPS。但假設採用不同的GPS外設，能夠通過device_name來區分。

7.     Linux核心

開發你的裝置驅動相似于開發典型的linux裝置驅動，Android使用一個版本号的Linux核心。在此核心基礎上添加了一些Android特有的内容，比方喚醒鎖(wave lock，一個記憶體管理器系統更積極主動去保護記憶體)、Binder IPC驅動和其它針對移動嵌入式平台的重要特征，這些特征是系統主要功能和不影響驅動開發。

你能夠使用不論什麼支援所須要特診的版本号核心(比方binder驅動)，可是，我們推薦採用最新的Android核心版本号。

參考連結：