在 Linux for Devices 上的一則新聞「Embedded development kits link up to Amazon cloud」，開發板也趕流行，跑上雲端。

這是以 Debian Linux 為基礎的 Embedded Linux 開發套件，並且可以連接 Amazon 的 S3 cloud service。有趣的地方是，文中以「Embedded Cloud Computing」的方式來形容，令人有不同的發想空間。「Embedded Cloud Computing」是「連上雲端的嵌入式硬體模組」的概念。「自動化裝置」是一種嵌入式系統，讀了這篇新聞後，讓人有另外一種像想。

如果能把雲端服務，嵌入到一些自動化裝置裡，因為這類型的裝置通常不經由人類操作，所以等於進入了「設備自動連結雲端」的時代。自動化裝置可以主動將擷取的裝置，送上雲端、儲存、分析並加以應用。例如，設計一個可隨時發送座標的隨身模組。

Android 的 HAL（硬體抽像層）是 Google 因應廠商「希望不公開源碼」的要求下，所推出的新觀念，其架構如下圖。雖然 HAL 現在的「抽象程度」還不足，現階段實作還不是全面符合 HAL 的架構規劃，不過也確實給了我們很好的思考空間。

圖1：Android HAL 架構規劃

這是 Patrick Brady (Google) 在2008 Google I/O 所發表的演講「Anatomy & Physiology of an Android」中，所提出的 Android HAL 架構圖。從這張架構圖我們知道，HAL 的目的是為了把 Android framework 與 Linux kernel 完整「隔開」。讓 Android 不至過度依賴 Linux kernel，有點像是「kernel independent」的意思，讓 Android framework 的開發能在不考量驅動程式的前提下進行發展。

在 Android 原始碼裡，HAL 主要的實作儲存於以下目錄：

1. libhardware_legacy/ - 過去的實作、採取程式庫模組的觀念進行
2. libhardware/ - 新版的實作、調整為 HAL stub 的觀念
3. ril/ - Radio Interface Layer

在 HAL 的架構實作成熟前（即圖1的規劃），我們先就目前 HAL 現況做一個簡單的分析。另外，目前 Android 的 HAL 實作，仍舊散佈在不同的地方，例如 Camera、WiFi 等，因此上述的目錄並不包含所有的 HAL 程式碼。

HAL 的過去

圖2：Android HAL / libhardware_legacy

過去的 libhardware_legacy 作法，比較是傳統的「module」方式，也就是將 *.so 檔案當做「shared library」來使用，在 runtime（JNI 部份）以 direct function call 使用 HAL module。透過直接函數呼叫的方式，來操作驅動程式。

當然，應用程式也可以不需要透過 JNI 的方式進行，直接以載入 *.so 檔（dlopen）的做法呼叫 *.so 裡的符號（symbol）也是一種方式。

HAL 的現實狀況

圖3：Android HAL / libhardware

現在的 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，就可以取得操作函數。

HAL 的未來發展？

新的 HAL 做法，傾向全面採用 JNI 的方式進行。也就是，在 Android 的架構中，修改 Android runtime 實作（即「Core Library」），在取得 HAL 模組的 operations 後再做 callback 操作。將 HAL 模組完全放在 HAL 裡面。

在上一篇日記裡，我們介紹了Android HAL的大概念。接下來，將慢慢地進行細部的分析與研究。首先，我們先針對HAL的現況先做討論，後續再針對HAL的設計提出觀念。

圖1：採用Service架構與不採用Service架構

如圖1，應用程式存取驅動程式的過程，可區分為以下二種：

• 採用Service架構方式
• 不採用Service架構方式

採用Service架構方式是比較標準的做法，即圖上藍色線的部份；紅色線的部份為非Service架構式的做法。先前，在「Android 驅動開發關鍵技術：HAL及移植要領」演講中最後所提出的一個LED範例，即是一種非架構式的做法，簡報上有一段範例程式碼，歡迎下載參考。

採取Service架構的方式，是建議的做法，當然因為這是標準架構，也應該採用。

Service在Android框架裡的角色是「存取底層硬體」，往上層的話，可以和應用程式溝通。因此，採用標準的Service做法，好處是在資料存取（data communication）的處理較為系統化。這方面，Android提供了標準的處理架構，後續再進行討論。

圖上的「core libraries」即是Service程式碼的實作，也就是，Android應用程式透過JNI（Dalvik）來到Service這一層，再透過Service載入*.so檔；而非標準做法則是讓應用程式直接透過JNI來載入*.so檔。

不使用Service架構

紅色的過程，因為不使用Service架構，因此「框架整合」的工作量比較小，甚致大部份的實作都不需要改動框架本身。這樣的做法，就有點像是「跳過framework」的方式；相對的，此時應用程式開發者需要考慮的設計議題就比較多。

例如，當遇到block operation時，是否需要獨立的Java thread來處理？

今天重要事，與開放手機有關，但不是Android的新聞，「Symbian」幾天前發佈的新聞稿指出「EPL RELEASE OF MICROKERNEL DEMONSTRATES PROGRESS TOWARDS OPEN SOURCE GOAL」。

自從Nokia收購Symbian其餘股權後，便開始計畫將Symbian開放、成為一個開放手機平臺，經過一段時間，Symbian Foundation幾天前達成一個重要的里程碑。如上述新聞稿所述，Symbian的microkernel（EKA2）以EPL（Eclipse Public License）釋出部份套件的原始碼，其中包含了Hardware Services套件。

開發者現在可以由[developer.symbian.org]下載原始碼，並且可使用模擬器（Qemu）進行試驗。

一個比較有趣的地方是，在眾多的FOSS授權裡，Symbian Foundation選擇以EPL授權釋出原始程式碼。EPL與GPLv2或v3授權都是不相容的，其中一點是，只有該軟體的擁有人（owner）或是已經得到了owner的許可，其他人（指contributors）才能將程式碼放到其它FOSS授權的軟體裡使用。也就是說，我們不能自已把EKA2的程式碼，放進Linux kernel或BSD kernel裡使用。此外，貢獻者（contributors）也不能暱名發佈程式碼，在EPL的條款裡，貢獻者需要具名。

另外一個EPL與現有其它FOSS授權不同的地方是「衍生著作（derivative work）」的定義。EPL不以程式庫的連結（linking）來定義衍生著作，而是以美國著作權法上的說明來定義。也就是，以獨立形式（例如module）實做了一個EPL軟體上所沒有的功能時，這個module就不算是一個衍生著作。

是否為衍生著作關係到授權條款，只要是衍生著作都必須是EPL授權。也就是，自已設計的獨立模組可以隨意授權。