[Android]HAL

HAL的body在G:\hardware\libhardware\hardware.c
裡面有
int hw_get_module(const char *id, const struct hw_module_t **module)
裡面的load()的dlopen()去load stub [xxx(id).xx(prop).so]

HAL module的路徑有兩個地方，這是run time的時候才放在這邊
/** Base path of the hal modules */
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

HAL body會給妳一個variant key，然後利用這個key去data base裡面搜尋
data base有兩種，一個是\system\core\rootdir\init.rc

HAL stub
是Android user space driver
它是用來取代kernel space driver
以避開GNU license(人家跟你要source code，妳一定要給)
它在user mode有個license叫做apache license(人家跟你要source code，妳可以決定要不要給)
HAL stub
是透過PMEM來access hardware

HAL 的目的是為了把 Android framework 與 Linux kernel 完整「隔開」
目前 Android 的 HAL 實作，仍舊散佈在不同的地方
HAL 主要的實作儲存於以下目錄：
1. libhardware_legacy/ - 過去的實作、採取程式庫模組的觀念進行
過去的 libhardware_legacy 作法，比較是傳統的「module」方式，
也就是將 *.so 檔案當做「shared library」來使用，在 runtime（JNI 部份）
以 direct function call 使用 HAL module。透過直接函數呼叫的方式，來操作驅動程式。

2. libhardware/ - 新版的實作、調整為 HAL stub 的觀念
現在的 libhardware 作法，就有「stub」的味道了。
HAL stub 是一種代理人（proxy）的概念，stub 雖然仍是以 *.so 檔的形式存在，
但 HAL 已經將 *.so 檔隱藏起來了。Stub 向 HAL「提供」操作函數（operations），
而 runtime 則是向 HAL 取得特定模組（stub）的 operations，
再 callback 這些操作函數。這種以 indirect function call 的實作架構，
讓 HAL stub 變成是一種「包含」關係，即 HAL 裡包含了許許多多的 stub（代理人）。
Runtime 只要說明「類型」，即 module ID，就可以取得操作函數。

3. ril/ - Radio Interface Layer
RIL的stub是另外獨立拉出去變成一個process
傳統的是body+stub是一個process

core libraries即是Service程式碼的實作，
也就是，Android應用程式透過JNI（Dalvik）來到Service這一層，再透過Service載入*.so檔

Android的Service分為二種：Android Service與Native Service。
Android Service又稱為Java Service，是實作在框架層（framework）裡的「Server」。
這裡所講的「Service」是System Service，又稱為Server，
與應用程式設計上所討論的Service（android.app.Service）不同。Android Service以Java撰寫。

Native Service則是實作在Runtime層裡的Server。
架構設計上，我們有二個選擇，一個是實作Android Service、再透過JNI與HAL stub溝通；
另一個選擇是，跳過Android Service，讓Application（Manager API）直接與Native Service溝通。

未來的Android發展趨勢，應會以第二種做法為主，即Manager API直接與Native Service溝通，以達到更好的效能表現。