Android非標準硬件驅動(dòng)程序的設計

Android系統是Google推出的基于Linux內核和Java架構的操作系統，在很短的時(shí)間內已成為主流的手機操作系統，并已逐步擴展應用到嵌入式系統、平板電腦和上網(wǎng)本上。它既有Linux系統所具有的硬件平臺可移植性，也因使用Java語(yǔ)言開(kāi)發(fā)應用程序帶來(lái)了應用軟件只編寫(xiě)一次即可在所有平臺運行的巨大優(yōu)勢。Android雖然主要基于已有的技術(shù)，但在體系結構設計上有較大的創(chuàng )新。其主要設計目標之一就是要使應用程序和系統能獨立于具體的計算機體系結構和硬件平臺，表現在設備驅動(dòng)程序設計上，對于已有的Linux標準設備驅動(dòng)程序可以直接繼續使用，只需為其增加應用層JNI接口。但對于Linux沒(méi)有的非標準設備則提倡在Linux內核中驅動(dòng)部分只做很少的接口工作，盡量把驅動(dòng)程序的主要處理放在Android的上層架構中，即在應用層實(shí)現。本文對Android系統的底層實(shí)現技術(shù)進(jìn)行深入的研究，包括Android的硬件抽象層和JNI技術(shù)實(shí)現等。并以S3C2440開(kāi)發(fā)板上的LED燈設計顯示驅動(dòng)程序為例，提出了一種非標準硬件設備驅動(dòng)程序的設計和實(shí)現方案。

1 Android系統驅動(dòng)程序架構

1.1 驅動(dòng)程序分層體系結構

Android是基于Linux的，它使用了Linux內核，但應用程序使用Java語(yǔ)言開(kāi)發(fā)，所以應用程序在調用設備驅動(dòng)時(shí)不能像一般的Linux應用程序那樣直接使用系統調用，必須通過(guò)Java虛擬機的JNI的本地（Native）方法使用設備。另一方面，Android要成為一個(gè)通用性強的平臺，必須加強它的可移植性。這也是在A(yíng)ndroid架構添加一個(gè)硬件抽象層（HAL）的原因，目的是為設備的調用提供一個(gè)更高級的封裝圖1所示為Android驅動(dòng)程序架構。

HAL Stub是以L(fǎng)inux共享庫(*.so)的形式存在，在整個(gè)驅動(dòng)架構中，它是設備驅動(dòng)程序運行在用戶(hù)空間的一部分，它向上為Dalvik虛擬機提供硬件設備的抽象接口，向下通過(guò)系統調用與Linux內核中的驅動(dòng)程序進(jìn)行數據交互。在這個(gè)過(guò)程中HAL可以對驅動(dòng)程序的數據進(jìn)行處理，也就是說(shuō)在Linux內核中的驅動(dòng)程序部分只需要提供一個(gè)與硬件設備傳輸數據接口的功能，而其余具體的操作可以由HAL完成。

1.2 Android的硬件抽象層

Android的硬件抽象層HAL(Hardware Abstract Layer)在A(yíng)ndroid的架構中是在庫這一層中，通過(guò)這一層，硬件廠(chǎng)商可以把部分設備的驅動(dòng)源碼封裝在這一層而不公開(kāi)源代碼。
對圖1分析，設計HAL就是為了把應用框架和Linux內核分離出來(lái)，讓Android使用Linux內核而又不完全依賴(lài)Linux內核。當然，驅動(dòng)程序并不是完全從Linux內核中分離出來(lái)，一些基本的處理必須由內核來(lái)完成，HAL只是分擔了Linux設備驅動(dòng)的部分功能，至于這部分的功能占驅動(dòng)程序功能的比例目前并沒(méi)有一個(gè)標準。

在A(yíng)ndroid系統發(fā)展過(guò)程中，HAL的實(shí)現也逐步有了一些變化，舊的HAL是一種模塊化的思想，通過(guò)共享庫的形式由Runtime在JNI時(shí)以函數調用方法調用，這種做法并沒(méi)有通過(guò)封裝，即上層應用可以直接調用硬件。另外，這種方法可被多個(gè)進(jìn)程使用，映射到多個(gè)進(jìn)程空間中浪費內存資源。

現在HAL提出一種Stub的思想，HAL Stub是一種代理的概念，Stub同樣是以共享庫(*.so)格式存在，但上層應用并不像加載動(dòng)態(tài)庫那樣調用Stub。這種HAL是由模塊與Stub結合而成，Runtime通過(guò)模塊提供的統一接口獲取并操作Stub。Stub向HAL提供操作的回調函數，Runtime向HAL取得指定模塊的操作函數后，調用這些回調函數。這是一種間接函數調用的方式，HAL里包含了多個(gè)Stub。圖2為HAL Stib原理。


1.3 Android的JNI實(shí)現原理

JNI是Java Native Interface的縮寫(xiě)，是在Sun的Java平臺中首先定義出來(lái)的，它允許Java代碼與其他語(yǔ)言代碼進(jìn)行交互。Android中JNI的設計目的也是一樣：

(1) 應用程序需要與硬件平臺交互時(shí)，Java庫中的類(lèi)不可能支持；
(2) 本地已經(jīng)使用其他語(yǔ)言編寫(xiě)的庫允許Java程序訪(fǎng)問(wèn)；
(3) 某些功能用較低級的語(yǔ)言實(shí)現的執行效率較高，讓Java程序調用這些函數。
在A(yíng)ndroid應用層中的程序或組件都是用Java語(yǔ)言開(kāi)發(fā)的，這些Java代碼編譯后變成Dex格式的字節碼，由Dalvik虛擬機執行，在執行過(guò)程中需要調用本地庫時(shí)，由虛擬機載入這些本地庫，然后讓Java函數調用庫中的函數，虛擬機相當于一座橋梁，讓Java與本地庫能夠透過(guò)標準的JNI界面互相溝通。

應用程序在虛擬機里執行，通過(guò)函數System.loadLibrary( )通知虛擬機載入指定的庫，例如在Java代碼中包含代碼如：
… …
System.loadLibrary(“sample_jni”);
… …
虛擬機就會(huì )在A(yíng)ndroid文件系統的“/system/lib/”目錄中查找libsample_jni.so庫文件,虛擬機載入libsample_jni.so后，Java代碼就可以與庫文件結合起來(lái)一起執行。

這些用C語(yǔ)言編寫(xiě)的本地庫必須遵循規范，當虛擬機執行System.loadLibrary()函數時(shí)，首先執行本地庫里的JNI_OnLoad()函數，這個(gè)函數需要實(shí)現的功能是：返回給虛擬機此本地庫使用的JNI版本；對庫進(jìn)行初始化。如果本地庫里沒(méi)有實(shí)現JNI_OnLoad()函數，虛擬機就會(huì )默認本地庫使用最老的JNI 1.1版本。

JNI_OnUnload()函數與裝入函數相對應，在虛擬機釋放該本地庫時(shí)，會(huì )調用JNI_OnUnload()函數進(jìn)行資源回收動(dòng)作。

在應用層的Java代碼通過(guò)虛擬機調用本地函數，一般要依賴(lài)于虛擬機查找庫里的本地函數，如果需要調用比較頻繁，每次都要尋找一遍，就會(huì )花費較多的時(shí)間影響效率，在這里可以通過(guò)registerNativeMethods()函數把gMethods[]表格所含的本地函數注冊到虛擬機里。

2 Android硬件驅動(dòng)程序設計

Android是一個(gè)開(kāi)放平臺,在嵌入式移動(dòng)設備領(lǐng)域里具有很好的應用前景，但在不同的設備上往往有不同的硬件支持，要在A(yíng)ndroid中添加這些硬件應用，不是單純地在Linux內核中添加驅動(dòng)模塊，還必須在用戶(hù)空間和應用框架中添加對應的支持。下面以給S3C2440開(kāi)發(fā)板添加一個(gè)LED顯示控制驅動(dòng)功能為例展示Android平臺添加新硬件支持的過(guò)程。

2.1 硬件驅動(dòng)程序的框架

LED控制功能通過(guò)應用程序來(lái)開(kāi)關(guān)開(kāi)發(fā)板上的LED燈。在應用層中LED控制程序調用LED控制服務(wù)(Android Service)，應用層中的LED控制服務(wù)通過(guò)JNI讓虛擬機加載LED控制的本地庫,然后向HAL獲取LED Stub，由Stub調用在Linux內核中的LED驅動(dòng)。圖3為L(cháng)ED控制功能的架構設計。

從LED控制功能的架構來(lái)分，整個(gè)功能可以分成五個(gè)模塊：LED驅動(dòng)模塊、LED Stub模塊、LED本地服務(wù)模塊、LED服務(wù)管理模塊和LED應用模塊。

2.2 HAL中的Stub的設計與實(shí)現

圖4是LED Stub的實(shí)現過(guò)程。LED Stub是硬件抽象層中LED控制的代理，當LED控制的本地服務(wù)需要調用LED Stub時(shí),通過(guò)函數hw_get_module( )結合LED Stub的模塊ID向HAL申請LED Stub，本地服務(wù)獲得Stub對象后，可以把Stub看作一個(gè)抽象硬件進(jìn)行操作。

下面是定義LED Stub的HAL結構體：

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);
}

將結構體led_module_t初始化一個(gè)實(shí)例名為HAL_MODULE_INFO_SYM，這個(gè)名稱(chēng)不能修改，實(shí)例里包含了Stub的模塊信息，主要包括：

tag：標記了結構體的類(lèi)型，這里的值為HARDWARE_MODULE_TAG；

id：LED Stub的模塊ID，在本地服務(wù)向HAL獲取Stub時(shí)調用的函數hw_get_module()中，通過(guò)這里的id查找LED Stub；

methods：是結構體hw_module_methods_t的實(shí)例，為HAL定義回調函數open()。
這里的open()函數是一個(gè)必須實(shí)現的回調函數接口，在本地服務(wù)獲得Stub對象后調用，它負責申請結構體led_control_device_t的空間，填充信息，注冊具體操作的回調函數接口并打開(kāi)LED驅動(dòng)。

結構體led_control_device_t繼承了hw_device_t，在open()函數調用時(shí)填充的主要信息包括：

tag：結構體的類(lèi)型，這里的值為HARDWARE_DEVICE_TAG；

module：Stub的模塊,也就是實(shí)例HAL_MODULE_INFO_SYM中的hw_module_t部分；

close：釋放LED Stub的回調函數；
fd：打開(kāi)設備驅動(dòng)文件返回的文件描述符；
ns_set_on：打開(kāi)LED燈的回調函數指針；
ns_set_off：關(guān)閉LED燈的回調函數指針。

回調函數指針“*ns_set_on”和“*ns_set_off”分別指向實(shí)現函數hal_ led_on()和hal_led_off()，在實(shí)現函數中通過(guò)系統調用ioctl()對LED燈進(jìn)行開(kāi)關(guān)控制。

2.3 硬件控制服務(wù)的JNI實(shí)現

LED控制本地庫編譯后為“libled.so”保存在A(yíng)ndroid文件系統的“/sysem/lib/”目錄下面，LED控制服務(wù)的Android進(jìn)程運行后由虛擬機實(shí)例裝入本地庫，具體實(shí)現過(guò)程如圖5所示。

LED控制服務(wù)調用System.load()函數，它的虛擬機實(shí)例就會(huì )裝入LED控制本地庫，虛擬機會(huì )首先調用 JNI_OnLoad()函數完成：

(1) 把虛擬機環(huán)境信息保存到本地庫的一個(gè)結構體“JNIEnv”的實(shí)例中；
(2) 建立一個(gè)應用層中的LED控制服務(wù)與本地庫的JNI函數表；
(3) 返回虛擬機本地庫使用的JNI版本。

加載完后，應用層中的LED控制服務(wù)就可以通過(guò)虛擬機中的JNI函數表把運行的Java函數轉換為本地函數執行。在LED控制服務(wù)類(lèi)中定義有JNI函數的方式,例如下面的代碼段：

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開(kāi)發(fā)板上進(jìn)行的，以給開(kāi)發(fā)板上的LED燈增加驅動(dòng)程序為例，展示了一種為Android平臺非標準硬件增加驅動(dòng)程序的設計方案，對于實(shí)現其他設備的驅動(dòng)具有一定的借鑒意義。由于各種硬件設備及其接口差異較大，本文著(zhù)重于驅動(dòng)程序的設計方案，沒(méi)有討論相關(guān)的硬件接口驅動(dòng)細節。隨著(zhù)Android平臺日漸成熟以及應用數量的增加,它在嵌入式領(lǐng)域的應用范圍將會(huì )更加廣泛。為Android設備編寫(xiě)不同于標準Linux系統的設備驅動(dòng)程序會(huì )變得越來(lái)越多。