摘 要: 在深入研究Android硬件抽象層HAL和Java本地接口JNI技術原理的基礎上,,提出了一個Android非標準硬件驅(qū)動程序的設計方案,。以一個非標準設備的驅(qū)動程式的實現(xiàn)為例介紹了驅(qū)動程序的功能模塊分層設計,討論了使用HAL Stub技術對硬件抽象層HAL模塊進行優(yōu)化的方法,。
關鍵詞: Android; 設備驅(qū)動程序; 硬件抽象層; JNI
Android系統(tǒng)是Google推出的基于Linux內(nèi)核和Java架構的操作系統(tǒng),,在很短的時間內(nèi)已成為主流的手機操作系統(tǒng),并已逐步擴展應用到嵌入式系統(tǒng),、平板電腦和上網(wǎng)本上,。它既有Linux系統(tǒng)所具有的硬件平臺可移植性,也因使用Java語言開發(fā)應用程序帶來了應用軟件只編寫一次即可在所有平臺運行的巨大優(yōu)勢,。Android雖然主要基于已有的技術,,但在體系結(jié)構設計上有較大的創(chuàng)新。其主要設計目標之一就是要使應用程序和系統(tǒng)能獨立于具體的計算機體系結(jié)構和硬件平臺,,表現(xiàn)在設備驅(qū)動程序設計上,,對于已有的Linux標準設備驅(qū)動程序可以直接繼續(xù)使用,只需為其增加應用層JNI接口,。但對于Linux沒有的非標準設備則提倡在Linux內(nèi)核中驅(qū)動部分只做很少的接口工作,,盡量把驅(qū)動程序的主要處理放在Android的上層架構中,即在應用層實現(xiàn),。本文對Android系統(tǒng)的底層實現(xiàn)技術進行深入的研究,,包括Android的硬件抽象層和JNI技術實現(xiàn)等,。并以S3C2440開發(fā)板上的LED燈設計顯示驅(qū)動程序為例,,提出了一種非標準硬件設備驅(qū)動程序的設計和實現(xiàn)方案。
1 Android系統(tǒng)驅(qū)動程序架構
1.1 驅(qū)動程序分層體系結(jié)構
Android是基于Linux的,,它使用了Linux內(nèi)核,,但應用程序使用Java語言開發(fā),所以應用程序在調(diào)用設備驅(qū)動時不能像一般的Linux應用程序那樣直接使用系統(tǒng)調(diào)用,必須通過Java虛擬機的JNI的本地(Native)方法使用設備,。另一方面,,Android要成為一個通用性強的平臺,必須加強它的可移植性,。這也是在Android架構添加一個硬件抽象層(HAL)的原因,,目的是為設備的調(diào)用提供一個更高級的封裝圖1所示為Android驅(qū)動程序架構。
HAL Stub是以Linux共享庫(*.so)的形式存在,,在整個驅(qū)動架構中,,它是設備驅(qū)動程序運行在用戶空間的一部分,它向上為Dalvik虛擬機提供硬件設備的抽象接口,,向下通過系統(tǒng)調(diào)用與Linux內(nèi)核中的驅(qū)動程序進行數(shù)據(jù)交互,。在這個過程中HAL可以對驅(qū)動程序的數(shù)據(jù)進行處理,也就是說在Linux內(nèi)核中的驅(qū)動程序部分只需要提供一個與硬件設備傳輸數(shù)據(jù)接口的功能,,而其余具體的操作可以由HAL完成,。
1.2 Android的硬件抽象層
Android的硬件抽象層HAL(Hardware Abstract Layer)在Android的架構中是在庫這一層中,通過這一層,,硬件廠商可以把部分設備的驅(qū)動源碼封裝在這一層而不公開源代碼,。
對圖1分析,設計HAL就是為了把應用框架和Linux內(nèi)核分離出來,,讓Android使用Linux內(nèi)核而又不完全依賴Linux內(nèi)核,。當然,驅(qū)動程序并不是完全從Linux內(nèi)核中分離出來,,一些基本的處理必須由內(nèi)核來完成,,HAL只是分擔了Linux設備驅(qū)動的部分功能,至于這部分的功能占驅(qū)動程序功能的比例目前并沒有一個標準,。
在Android系統(tǒng)發(fā)展過程中,,HAL的實現(xiàn)也逐步有了一些變化,舊的HAL是一種模塊化的思想,,通過共享庫的形式由Runtime在JNI時以函數(shù)調(diào)用方法調(diào)用,,這種做法并沒有通過封裝,即上層應用可以直接調(diào)用硬件,。另外,,這種方法可被多個進程使用,映射到多個進程空間中浪費內(nèi)存資源,。
現(xiàn)在HAL提出一種Stub的思想,,HAL Stub是一種代理的概念,Stub同樣是以共享庫(*.so)格式存在,,但上層應用并不像加載動態(tài)庫那樣調(diào)用Stub,。這種HAL是由模塊與Stub結(jié)合而成,,Runtime通過模塊提供的統(tǒng)一接口獲取并操作Stub。Stub向HAL提供操作的回調(diào)函數(shù),,Runtime向HAL取得指定模塊的操作函數(shù)后,,調(diào)用這些回調(diào)函數(shù)。這是一種間接函數(shù)調(diào)用的方式,,HAL里包含了多個Stub,。圖2為HAL Stib原理。
1.3 Android的JNI實現(xiàn)原理
JNI是Java Native Interface的縮寫,,是在Sun的Java平臺中首先定義出來的,,它允許Java代碼與其他語言代碼進行交互。Android中JNI的設計目的也是一樣:
(1) 應用程序需要與硬件平臺交互時,,Java庫中的類不可能支持,;
(2) 本地已經(jīng)使用其他語言編寫的庫允許Java程序訪問;
(3) 某些功能用較低級的語言實現(xiàn)的執(zhí)行效率較高,,讓Java程序調(diào)用這些函數(shù),。
在Android應用層中的程序或組件都是用Java語言開發(fā)的,這些Java代碼編譯后變成Dex格式的字節(jié)碼,,由Dalvik虛擬機執(zhí)行,,在執(zhí)行過程中需要調(diào)用本地庫時,由虛擬機載入這些本地庫,,然后讓Java函數(shù)調(diào)用庫中的函數(shù),,虛擬機相當于一座橋梁,讓Java與本地庫能夠透過標準的JNI界面互相溝通,。
應用程序在虛擬機里執(zhí)行,,通過函數(shù)System.loadLibrary( )通知虛擬機載入指定的庫,例如在Java代碼中包含代碼如:
… …
System.loadLibrary(“sample_jni”);
… …
虛擬機就會在Android文件系統(tǒng)的“/system/lib/”目錄中查找libsample_jni.so庫文件,虛擬機載入libsample_jni.so后,,Java代碼就可以與庫文件結(jié)合起來一起執(zhí)行,。
這些用C語言編寫的本地庫必須遵循規(guī)范,當虛擬機執(zhí)行System.loadLibrary()函數(shù)時,,首先執(zhí)行本地庫里的JNI_OnLoad()函數(shù),,這個函數(shù)需要實現(xiàn)的功能是:返回給虛擬機此本地庫使用的JNI版本;對庫進行初始化,。如果本地庫里沒有實現(xiàn)JNI_OnLoad()函數(shù),,虛擬機就會默認本地庫使用最老的JNI 1.1版本。
JNI_OnUnload()函數(shù)與裝入函數(shù)相對應,,在虛擬機釋放該本地庫時,,會調(diào)用JNI_OnUnload()函數(shù)進行資源回收動作。
在應用層的Java代碼通過虛擬機調(diào)用本地函數(shù),,一般要依賴于虛擬機查找?guī)炖锏谋镜睾瘮?shù),,如果需要調(diào)用比較頻繁,每次都要尋找一遍,,就會花費較多的時間影響效率,,在這里可以通過registerNativeMethods()函數(shù)把gMethods[]表格所含的本地函數(shù)注冊到虛擬機里。
2 Android硬件驅(qū)動程序設計
Android是一個開放平臺,在嵌入式移動設備領域里具有很好的應用前景,,但在不同的設備上往往有不同的硬件支持,,要在Android中添加這些硬件應用,不是單純地在Linux內(nèi)核中添加驅(qū)動模塊,,還必須在用戶空間和應用框架中添加對應的支持,。下面以給S3C2440開發(fā)板添加一個LED顯示控制驅(qū)動功能為例展示Android平臺添加新硬件支持的過程。
2.1 硬件驅(qū)動程序的框架
LED控制功能通過應用程序來開關開發(fā)板上的LED燈,。在應用層中LED控制程序調(diào)用LED控制服務(Android Service),,應用層中的LED控制服務通過JNI讓虛擬機加載LED控制的本地庫,然后向HAL獲取LED Stub,由Stub調(diào)用在Linux內(nèi)核中的LED驅(qū)動,。圖3為LED控制功能的架構設計,。
從LED控制功能的架構來分,整個功能可以分成五個模塊:LED驅(qū)動模塊,、LED Stub模塊,、LED本地服務模塊、LED服務管理模塊和LED應用模塊,。
2.2 HAL中的Stub的設計與實現(xiàn)
圖4是LED Stub的實現(xiàn)過程,。LED Stub是硬件抽象層中LED控制的代理,當LED控制的本地服務需要調(diào)用LED Stub時,通過函數(shù)hw_get_module( )結(jié)合LED Stub的模塊ID向HAL申請LED Stub,,本地服務獲得Stub對象后,,可以把Stub看作一個抽象硬件進行操作。
下面是定義LED Stub的HAL結(jié)構體:
struct led_module_t {
struct hw_module_t common;
}
struct led_module_t {
struct hw_module_t common;
int fd;
int(*ns_set_on)(struct led_control_device_t*dev,int32_t led);
int(*ns_set_off)(struct led_control_device_t*dev,int32_t led);
}
將結(jié)構體led_module_t初始化一個實例名為HAL_MODULE_INFO_SYM,,這個名稱不能修改,,實例里包含了Stub的模塊信息,主要包括:
tag:標記了結(jié)構體的類型,,這里的值為HARDWARE_MODULE_TAG,;
id:LED Stub的模塊ID,在本地服務向HAL獲取Stub時調(diào)用的函數(shù)hw_get_module()中,,通過這里的id查找LED Stub,;
methods:是結(jié)構體hw_module_methods_t的實例,為HAL定義回調(diào)函數(shù)open(),。
這里的open()函數(shù)是一個必須實現(xiàn)的回調(diào)函數(shù)接口,,在本地服務獲得Stub對象后調(diào)用,它負責申請結(jié)構體led_control_device_t的空間,,填充信息,,注冊具體操作的回調(diào)函數(shù)接口并打開LED驅(qū)動,。
結(jié)構體led_control_device_t繼承了hw_device_t,在open()函數(shù)調(diào)用時填充的主要信息包括:
tag:結(jié)構體的類型,,這里的值為HARDWARE_DEVICE_TAG,;
module:Stub的模塊,也就是實例HAL_MODULE_INFO_SYM中的hw_module_t部分;
close:釋放LED Stub的回調(diào)函數(shù),;
fd:打開設備驅(qū)動文件返回的文件描述符,;
ns_set_on:打開LED燈的回調(diào)函數(shù)指針;
ns_set_off:關閉LED燈的回調(diào)函數(shù)指針,。
回調(diào)函數(shù)指針“*ns_set_on”和“*ns_set_off”分別指向?qū)崿F(xiàn)函數(shù)hal_ led_on()和hal_led_off(),,在實現(xiàn)函數(shù)中通過系統(tǒng)調(diào)用ioctl()對LED燈進行開關控制。
2.3 硬件控制服務的JNI實現(xiàn)
LED控制本地庫編譯后為“libled.so”保存在Android文件系統(tǒng)的“/sysem/lib/”目錄下面,,LED控制服務的Android進程運行后由虛擬機實例裝入本地庫,,具體實現(xiàn)過程如圖5所示。
LED控制服務調(diào)用System.load()函數(shù),,它的虛擬機實例就會裝入LED控制本地庫,,虛擬機會首先調(diào)用 JNI_OnLoad()函數(shù)完成:
(1) 把虛擬機環(huán)境信息保存到本地庫的一個結(jié)構體“JNIEnv”的實例中;
(2) 建立一個應用層中的LED控制服務與本地庫的JNI函數(shù)表,;
(3) 返回虛擬機本地庫使用的JNI版本,。
加載完后,應用層中的LED控制服務就可以通過虛擬機中的JNI函數(shù)表把運行的Java函數(shù)轉(zhuǎn)換為本地函數(shù)執(zhí)行,。在LED控制服務類中定義有JNI函數(shù)的方式,例如下面的代碼段:
public final class LedService extends IledService.Stub {
…….
static {
System.load(“/system/lib/libled.so”);
}
……
private static native boolean as_init();
private static native boolean as_set_on(int led);
private static native boolean as_set_off(int led);
}
本文的研究工作是在S3C2440開發(fā)板上進行的,,以給開發(fā)板上的LED燈增加驅(qū)動程序為例,展示了一種為Android平臺非標準硬件增加驅(qū)動程序的設計方案,,對于實現(xiàn)其他設備的驅(qū)動具有一定的借鑒意義,。由于各種硬件設備及其接口差異較大,本文著重于驅(qū)動程序的設計方案,,沒有討論相關的硬件接口驅(qū)動細節(jié),。隨著Android平臺日漸成熟以及應用數(shù)量的增加,它在嵌入式領域的應用范圍將會更加廣泛。為Android設備編寫不同于標準Linux系統(tǒng)的設備驅(qū)動程序會變得越來越多,。
參考文獻
[1] BRADY P. Anatomy & physiology of an android[EB/OL].2008[2009-03-24].http://sites.google.com/site/io/anatomyphysiology-of-an-android.
[2] GREG K H. Android and the linux kernel community[EB/OL].[2010-02-02], http://www.kroah.com/log/linux/androidkernel-problems.html.
[3] 葉炳發(fā), 孟小華. Android圖形系統(tǒng)的分析與移植[J]. 電信科學,2010(02):65-68.
[4] 李俊.嵌入式Linux設備驅(qū)動程序開發(fā)詳解[M]. 北京:人民郵電出版社,,2008.
[5] 胡希明,毛德操. Linux內(nèi)核源代碼情景分析[M]. 杭州:浙江大學出版社,,2004.
[6] 姚昱旻, 劉衛(wèi)國. Android的架構與應用開發(fā)研究 [D].長沙:中南大學,2008.