承日記「Android 的 HAL 技術, #6: 小結 HAL stub 實作步驟」與「Android 的 HAL 技術, #7: 取得 Proxy Object」。在了解基本的觀念，以及重要的架構觀念後，接著就可以開始實作 HAL Stub 了。以下是 LED Stub 的實作範例，將程式碼儲存為 led.c： static struct hw_module_methods_t led_module_methods = { open: led_device_open }; 　 const struct led_module_t HAL_MODULE_INFO_SYM = { common:...(more)

新的一年，祝福大家心想事成。開放源碼(Open Source)與開放平臺(Open Devices)是相當有意思的二個主題，今年，二零一零年，希望可以認識更多志同道合的朋友；也祝福大家，技術進步、研究豐碩。 今年，需要投注更多心力到Android相關的技術研究工作，以及產品規劃。去年，確實是頗為有趣的一年，自已也投入了相當多時間在技術研究、廠商交流以及教育訓練工作上。七個月多的時間，不斷巡迴台北、上海、深圳、北京四大城市，在這些城市進行Android以及Embedded Linux的培訓工作，其間，也和許多技術人員，以及廠商有許多交流，甚致深入的合作。 這段過程中，令人感受最深的，便是「快速成長」四個大字。 「二零零九年，大陸總計賣出一千三百萬輛台汽車。」有一天在前往北京首都國際機場的出租車上，所聽到的一段新聞。大陸目前約有一百家汽車廠，一般消費者，從下訂到取車，可能需要長達三個月的時間。在一些主要城市，整條路上的汽車經銷商，甚致沒有一家有「現貨」可供銷售。 若以每年中國經濟成長率超越美國約5%來計算，中國的GDP在二零二零年，將超過美國。以每年8%來計算，到時生產總額也將再翻一番。今年，二零一零年，中國也要做好GDP超越日本的準備。不過，畢竟經濟這件事也不是做為技術工作者的我，能通盤了解的，除了平日讀讀新聞、看看發佈數據外，還是專注在技術本業上更實際一些，所以，在這裡分享一個技術工作上的看法，供大家參考指教。 有關BAE的應用，今年可能得到大幅度的份額增長。BAE的全名是Browser based Application Engine。這並非很新潮的技術，在另外二大手機作業系統：Windows Mobile與Symbian上，也都有這樣的應用。BAE其實不只是在手持裝置上，在Web Service或是個人電腦上，也都能看到它的踪跡。 重視開放平臺的BAE應用，把它加入產品設計與規劃的要項，是過去我給一家廠商提出的建議。過去，Android Market是個棘手問題，但現在開始，情況會有所改變。這是獨立應用軟體開發商或獨立品牌的好機會。Android Market的發展看起來將有很大的突破； 目前，在我所參與的一個技術工作上，已經將資源的分配由框架與底層的驅動程式，部份轉換到應用(Applications)的開發與研究工作上，就是希望在應用開發上加重比重。 上述提到的BAE技術，因為改變應用軟體開發的模式，也要多加的重視。 去年十二月，在教育部嵌入式軟體聯盟的一場開放手機研討會上，我邀請了北京的eoeAndroid社群做了一次遠端視訊連線，為現場同學做了一些Android方面的介紹。「社群是開放平臺的靈魂。」因為Android技術，出現了許多技術社群，「熱情」是他們的共通點。從eoeAndrod的談話中，可以感受到這點，以及技術研究的精神「自身投入、明確務實」。台灣的0xlab也是一個典範，我們看見了追求技術卓越的熱情與貢獻，還有務實的精神。 因為Android的出現，eoeAndroid團隊一些人辭去他們原本的工作，一起為建立社群而努力。在周遭所認識的朋友裡，他們並不是唯一有這種堅定決心的工作者。 回顧過去的工作，深刻感受到不同城市間的工作文化、技術發展重點或是想法，都有很不一樣的特色；技術研究是個有趣的工作，給自已的期許是，當一個稱職的執行者，努力並有效率地完成專案。...(more)

延續上一則日記的介紹，在完成HAL Stub的實作後，緊接著的工作就是撰寫Native Service。 談了許多「Android Service」以及「HAL Stub」，這裡再補充一點。Android作業系統啟動時，會執行一個process稱為servicemanager。Servicemanager process負責管理、提供並保存「Android Service」。Android Service為Java層，因此接下來會透過JNI來呼叫C/C++層的Native Service。 廣義來說，Native Service也提供Runtime的功能，即Core Library層。Runtime的重要工作之一為「取得HAL Stub所提供的API」，因此這是撰寫完整Native Service的前哨站。 什麼是 Proxy Object？ Native Service呼叫HAL的hw_get_module() API取得stub物件，即HAL_MODULE_INFO_SYM。 HAL會去尋找HAL Stub檔案，HAL Stub是以*.so檔的形式存在，並佈署於/system/lib/hw目錄下。HAL會根據module ID以及”ro.product.board”去尋找相對應的*.so檔，以我們的LED範例來說，HAL會回傳回led_module_t結構的物件（an instance of led_module_t class）給Native Service。 我們把HAL回傳給Native Service的資料稱為「Stub Object」或是「Proxy Object」，即先前所提及的「代理人」觀念。Native Service透過代理人與 Linux 驅動程式溝通。這個過程的觀念如圖1所示。 圖1：取得Proxy Object hw_get_module()，這是HAL所提供的API，也是實作HAL...(more)

在討論了不少基本概念後，在這裡小結一下 HAL stub 的實作步驟。HAL stub 的起頭是「繼承 HAL 的 struct hw_module_t」，這是 HAL stub 的設計理念，除了讓架構的條理分明外，也容易做後續擴充與維護。以下改用實用上的習慣用語，小結一下 HAL stub 實作步驟，並提供一段例。 HAL Stub 實作步驟(Implementation) 1. 設計自已的wrapper data structure * 編寫led.h * 定義 struct led_module_t * 框架提供的 struct hw_module_t 必須放在第一個 field、並取名為 common * 請參考 hardware/hardware.h 2....(more)