android HAL 分析文档格式.docx
- 文档编号:15121766
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:10
- 大小:313.58KB
android HAL 分析文档格式.docx
《android HAL 分析文档格式.docx》由会员分享,可在线阅读,更多相关《android HAL 分析文档格式.docx(10页珍藏版)》请在冰豆网上搜索。
2.libhardware/-新版的實作、調整為HALstub的觀念
3.ril/-RadioInterfaceLayer
在HAL的架構實作成熟前(即圖1的規劃),我們先就目前HAL現況做一個簡單的分析。
另外,目前Android的HAL實作,仍舊散佈在不同的地方,例如Camera、WiFi等,因此上述的目錄並不包含所有的HAL程式碼。
HAL的過去
圖2:
AndroidHAL/libhardware_legacy
過去的libhardware_legacy作法,比較是傳統的「module」方式,也就是將*.so檔案當做「sharedlibrary」來使用,在runtime(JNI部份)以directfunctioncall使用HALmodule。
透過直接函數呼叫的方式,來操作驅動程式。
當然,應用程式也可以不需要透過JNI的方式進行,直接以載入*.so檔(dlopen)的做法呼叫*.so裡的符號(symbol)也是一種方式。
HAL的現實狀況
圖3:
AndroidHAL/libhardware
現在的libhardware作法,就有「stub」的味道了。
HALstub是一種代理人(proxy)的概念,stub雖然仍是以*.so檔的形式存在,但HAL已經將*.so檔隱藏起來了。
Stub向HAL「提供」操作函數(operations),而runtime則是向HAL取得特定模組(stub)的operations,再callback這些操作函數。
這種以indirectfunctioncall的實作架構,讓HALstub變成是一種「包含」關係,即HAL裡包含了許許多多的stub(代理人)。
Runtime只要說明「類型」,即moduleID,就可以取得操作函數。
HAL的未來發展?
新的HAL做法,傾向全面採用JNI的方式進行。
也就是,在Android的架構中,修改Androidruntime實作(即「CoreLibrary」),在取得HAL模組的operations後再做callback操作。
將HAL模組完全放在HAL裡面。
採用Service架構方式
在上一篇日記裡,我們介紹了AndroidHAL的大概念。
接下來,將慢慢地進行細部的分析與研究。
首先,我們先針對HAL的現況先做討論,後續再針對HAL的設計提出觀念。
採用Service架構與不採用Service架構
如圖1,應用程式存取驅動程式的過程,可區分為以下二種:
∙採用Service架構方式
∙不採用Service架構方式
採用Service架構方式是比較標準的做法,即圖上藍色線的部份;
紅色線的部份為非Service架構式的做法。
先前,在「Android驅動開發關鍵技術:
HAL及移植要領」演講中最後所提出的一個LED範例,即是一種非架構式的做法,簡報上有一段範例程式碼,歡迎下載參考。
AndroidHALIntroduction:
libhardwareanditslegacy
ViewmoredocumentsfromJollenChen.
採取Service架構的方式,是建議的做法,當然因為這是標準架構,也應該採用。
Service在Android框架裡的角色是「存取底層硬體」,往上層的話,可以和應用程式溝通。
因此,採用標準的Service做法,好處是在資料存取(datacommunication)的處理較為系統化。
這方面,Android提供了標準的處理架構,後續再進行討論。
圖上的「corelibraries」即是Service程式碼的實作,也就是,Android應用程式透過JNI(Dalvik)來到Service這一層,再透過Service載入*.so檔;
而非標準做法則是讓應用程式直接透過JNI來載入*.so檔。
不使用Service架構
紅色的過程,因為不使用Service架構,因此「框架整合」的工作量比較小,甚致大部份的實作都不需要改動框架本身。
這樣的做法,就有點像是「跳過framework」的方式;
相對的,此時應用程式開發者需要考慮的設計議題就比較多。
例如,當遇到blockoperation時,是否需要獨立的Javathread來處理?
--jollen
Android的HAL技術,#3:
小探AndroidService與NativeService
jollen發表於November27,20091:
59AM
前二篇教學提到「採用Service架構整合HAL的做法」。
這裡再針對HAL如何採用Service架構與框架整合做一個概念的介紹。
Android的Service分為二種:
AndroidService與NativeService。
AndroidService
AndroidService又稱為JavaService,是實作在框架層(framework)裡的「Server」。
這裡所講的「Service」是SystemService,又稱為Server,與應用程式設計上所討論的Service(android.app.Service)不同。
AndroidService以Java撰寫。
NativeService
NativeService則是實作在Runtime層裡的Server。
架構設計上,我們有二個選擇,一個是實作AndroidService、再透過JNI與HALstub溝通;
另一個選擇是,跳過AndroidService,讓Application(ManagerAPI)直接與NativeService溝通。
未來的Android發展趨勢,應會以第二種做法為主,即ManagerAPI直接與NativeService溝通,以達到更好的效能表現。
Android的HAL技術,#4:
AndroidService與HALStub
jollen發表於November28,20099:
56PM
目前為止,我們提了「HALStub」的觀念,了解到stub是一種代理人的觀念,架構設計上,採取「provideoperations」與「callback」機制,而不是採用「module」即library的directfunctioncall做法。
接著,又提到「採取Service架構的方式」。
在講解HALstub的實作細節前,需要大略了解一下AndroidService與HALstub的關係;
因為,架構設計上是「透過AndroidService取得HALstub提供的operations」。
取得HALstuboperations的程式碼實際上是實作在NativeService裡,相關的實作細節留待後續再做說明。
AndroidService與HALstub的關係
應用程式(Application)使用了ManagerAPI,ManagerAPI經由AndroidService來到NativeService層,最後NativeService層再引用(invoke)HALstub。
這個過程,總共經過了以下3個介面,如下圖。
1.這是一個remoteinterface,應用程式與AndroidService在不同的process上執行。
2.這是Javanativeinterface,實作上透過JNItable來對應nativemethod與nativefunction。
3.理論上,這是HAL層,實作上則是使用HALAPI先取得stuboperations,再由nativeservicecallbackstub。
Android的HAL技術,#5:
繼承HAL的structhw_module_t
jollen發表於December1,200910:
09PM
撰寫HALstub除了要具備系統程式(systemssoftware)的觀念外(這是基礎),「思考方式的改變」也是重要的一堂課。
思考方式哪裡不同?
實作HALstub的首要工作是「繼承structhw_module_t抽象型別」。
Class(類別)屬於一種抽象型號(ADT)。
首先,引入最重要的標頭檔(headerfile):
#include<
hardware/hardware.h>
接著,再定義一個「MODULEID」。
這個mdouleID將會被HAL層用來尋找HALstub。
我們舉最簡單的裝置類型「LED」來做為範例:
#defineLED_HARDWARE_MODULE_ID"
led"
繼承HAL的structhw_module_t抽象型別(即baseclass的概念),並取名為structled_module_t(即derivedclass):
structled_module_t{
structhw_module_tcommon;
};
以資料結構的角度來看,這裡的做法只是宣告了一個抽象資料型別(AbstractDataType),以提升程式碼的結構化特性。
但是,這裡需要以架構的角度來解釋,「AndroidHAL規定不要直接使用structhw_module_t」,原文的意思是要我們做類別繼承。
實作繼承
在C語言裡實作繼承的方式,大致如下:
1.宣告一個datastructure將原始的基本結構包裝起來
2.將原始的基本結構放在第一個field
因此,可以思考如下:
/*Placeattributeshere.*/
/*Placemethodshere.*/
唯一,這裡的實作在OO特性上,缺乏像是public與private的封裝性。
但這裡的重心是,以OO的方式思考,會如何改變過去的C程式寫作習慣?
最明顯的地方是,程式碼的寫作風格有了很大的改變。
Android的HAL技術,#6:
小結HALstub實作步驟
jollen發
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- android HAL 分析