一年多前，「Android 的 HAL 技術」系列日記闡釋了 Android HAL 的觀念與基本設計方法；在小弟的「Android HAL & Framework: 軟硬整合實作訓練 」訓練規劃中，也對 Android Service 與 HAL 做了完整的介紹。

現在，再度回到 Android HAL 的主題；主要是 Android 2.3 在部份硬體單元（Component）做了一些架構調整。隨著 AOSP 程式碼的大幅進步，硬體廠需要加強對 Android HAL 的技術掌握度，這是十萬火急的工作了。因為，硬體廠唯有具備發展高品質軟硬整合程式碼的能力，才能在 Android 產品開發工作上具備競爭力。

「Native 化」

過去在「Android 的 HAL 技術, #3: 小探Android Service與Native Service」裡提及 Android 應用程式存取硬體的做法，大致分為二個路徑：Android Service 與 Native Service。在「Android HAL & Framework: 軟硬整合實作訓練 」裡，分別以「紅色路徑」與「綠色路徑」來表示。

在日記「Android 2.3 的更新：SensorService 的 Native 化」裡提到的「Native 化」會成為日後 Android 作業系統發展的趨勢之一。「也就是紅色路徑慢慢往綠色路徑移動」。

理想中的 Android HAL 架構

要了解這項發展趨勢，可以從理想中的 Android HAL 架構說起，先在腦海裡建立大方向圖（Big Picture）。根據 Android 各版本的發展，可以推測出 Android HAL 將朝向下圖的架構來發展。

這個架構不是憑空想像，事實上也不是 Android 作業系統的創舉。

研究作業系統的朋友可以知道，Hardware Abstraction Layer (HAL) 的觀念已經行之多年了，在許多重量級的 OS 裡都能看到。為什麼在過去的 Android OS 裡，HAL 的架構或程式碼如此陽春？簡單講，「就是還沒有發展成熟。」

圖一：理想且完整的 Android HAL 架構

根據我們的研究，理想中且完善的 Android HAL 架構包含四個部份：

• Service Layer 屬於 Application Framework 層，提供 Application 存取硬體的「服務」。理論上，這些服務是以 instance 的形式存在。
• Hardware Abstraction Layer 介於 Application Framework 與 Driver Framework 之間，以抽象形式存取硬體。理論上，HAL 層的存在形式有三種 - library (module) / server / communication bus。
• Native Servier 屬於整個 Android 作業系統最底層。理論上，它應該在 HAL 層之下，也是 HAL 不會是我們想像中「隔絕 kernel 的最下層」，存在形式為 daemon。
• Driver Framework 屬於 kernel-space 層，也就是包含在 Linux kernel 裡，「非常 long-term 來看」也可以是其它 OS。理論上，Driver Framework 是以 instance 的形式存在。

Service Layer 實作在 Application Framework 層，為了提供更上層（Application）存取硬體而設計，因此，在有些研究上，也稱之為「Application Service」；等同於過去我們所講的 Android Service。Application Service 最多就是提供 API 而已。

這個架構並非一種創新，因為在許多重量級的作業系統裡都能看到這樣的設計，例如：Mac OS X。統一架構，讓硬體存取一致化，實作整齊劃一。不過，以上的觀點都只是理論，目的是推測 Android 在這個部份的發展輪廓。

實務上，看到的程式碼與理論研究總是有點落差。現行的 AOSP 程式碼實作，還是與我們所討論的架構不一樣；至於未來如何發展，只能密切與 AOSP 同步。螢幕上的程式碼，背後總是有許多思惟邏輯，有些能從程式碼推敲一二，更多則是沒有文獻記載，技術研究的樂趣在於發覺這些內涵。