前二篇教學提到「採用Service架構整合HAL的做法」。這裡再針對HAL如何採用Service架構與框架整合做一個概念的介紹。

Android的Service分為二種：Android Service與Native Service。

Android Service

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

Native Service

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

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

延伸閱讀

* 2009.10.14: Android 的 HAL 技術, #2: 採用Service架構方式
* 2009.10.08: Android 的 HAL 技術, #1: 簡介與發展現況

目前為止，我們提了「HAL Stub」的觀念，了解到 stub 是一種代理人的觀念，架構設計上，採取「provide operations」與「callback」機制，而不是採用「module」即 library 的 direct function call 做法。

接著，又提到「採取Service架構的方式」。在講解HAL stub的實作細節前，需要大略了解一下Android Service與HAL stub的關係；因為，架構設計上是「透過Android Service取得HAL stub提供的operations」。

取得HAL stub operations的程式碼實際上是實作在Native Service裡，相關的實作細節留待後續再做說明。

Android Service與HAL stub的關係

應用程式（Application）使用了Manager API，Manager API經由Android Service來到Native Service層，最後Native Service層再引用（invoke）HAL stub。這個過程，總共經過了以下3個介面，如下圖。

1. 這是一個 remote interface，應用程式與Android Service在不同的 process 上執行。

2. 這是 Java native interface，實作上透過 JNI table 來對應 native method 與 native function。

3. 理論上，這是 HAL 層，實作上則是使用 HAL API 先取得 stub operations，再由 native service callback stub。

HAL stub是與硬體關係最密切的軟體

HAL stub因為是以獨立的*.so檔形式，佈署於/system/lib/hw目錄下，同時，執行時期（runtime）是以提供操作（provide operations）的方式來運作，所以可以達到HAL的目的之一，即界面（interface）的設計。

再加上HAL stub是與硬體關係最密切的軟體，所以讓我們有了不同的思考。

Android分支(branch)工廠

定義好界面再實作stub，這樣的架構讓stub，也就是*.so檔，可以元件化（component）。HAL以物件導向的思考方式設計與實作。元件可以抽換或重用，再配合過去提到的「Android分支建立」觀念，「HAL stub 服務工廠」的想法便油然而生。

提供HAL(與*.so)代工服務與解決方案

由驅動程式專業公司進行設計與開發，即軟體服務的一種想法，基於：

1. HAL stub軟體可封閉源碼，因此也較利於商業模式推展
2. 提供關鍵IC零組件封閉原始碼的HAL stub軟體
(Proprietary software)
3. 不但是「軟硬整合」，也是Android綁定硬體平臺的一種策略

當然，想法往往都是「有感而發」，現實面能不能執行又是一回事了。 ;-)