如果某個硬體資源只能被某一個應用使用，可以使用下面的方法訪問硬體： JAVA APP--->JNI_OnLoad（）載入C庫---->將JAVA三個地方法與C庫函式進行關聯並註冊---->呼叫JAVA本地Native方法就可以訪問C庫的C介面------>進而訪問硬體驅動中的open, read, write，從進訪問硬體。 但是，以上場景僅限於只有一個APP使用這個硬體資源，如果有多個應用想要使用某個硬體時，如果還按上面方法，必須會造成硬體資源的衝突，所以此時需要有一種框架來解決這個問題。解決方案就是訪問硬體資源的程式只能並且只有一個，我們稱之為System Server, 其它要訪問這個硬體資源的APP必須要給Server發請求，由Server間接的操作硬體，從而實現資源的訪問。這個就稱之為硬體訪問服務。 關於硬體訪問服務需要注意以下幾點： 1 System Server是由JAVA編寫的，所以它要想訪問硬體，必須要載入JNI的C庫(Loadlibrary). 2 C庫的JNI_Onload函式裡要註冊本地方法，分別呼叫各個硬體的函式來註冊本地方法。比如LED，振動器，有串列埠。。。等等。。 3 System Server： (1)對每個硬體都要新增服務,add service  前提需要實現的是：對每個硬體構造service,使用本地Native方法 (2)對於(1)新增的服務就是向service_manager.c註冊，比如serialservice, vibratorservice, ledservice等。如果JAVA應用程式需要使用某些Service的時候，就需要通過這個Service_manager查詢及獲取相應的Service。 4 最終APP怎麼使用？ (1)APP使用之前需要獲得這個服務getService (2)最後就是使用這個服務了。執行Service的方法 以後修改硬體驅動的時候，把驅動檔案放在hal裡面,如hal_led.c，有幾個好處： (1)容易修改 (2)很多公司不願意開放其硬體操作，他們只提供so檔案，出於保密的目的。 試想一下，如果把硬體操作原始碼放到JNI檔案裡，如果要修改，需要編譯整個工程，此外，硬體原始碼暴露出來了,保密性不好。 分析一下： 以上操作涉及到三個程序，  1 SystemServer程序：它提供的功能如下： ---a: 它向service_manager.c註冊服務 ---b: 載入硬體Service JNI 的C庫 ---C: 接收其它app的硬體操作請求，訪問硬體資源 2 Service_Manager程序：負責硬體資源各種Service的註冊新增,以及接怍JAVA應用app的各種service查詢請求及資源的獲取。 3 JAVA應用APP程序，它其實是一個客戶端，它首先向Service_Manager查詢獲得某一個Service, 最後，把這個Service傳送給SystemServer程序以請求相應的服務，         而以上三個程序之間的內部通訊，主要依靠Android核心的Binder Driver系統進行內部程序間通訊。這個Binder並不是linux核心自帶的，是google公司對linux核心進行修改新增的一個驅動程式，可實現更加高效的程序間通訊。 ps:註冊Server與Service的區別，可以這麼理解，Server伺服器提供各種服務Services. 思考：如何實現一個硬體訪問服務。 1 編寫JNI和HAL,以led為例，先編寫com_android_server_ledservice.cpp，用於註冊JNI本地方法。再編寫hal_led.c，裡面就是實現open,read,write等硬體訪問介面。 2 修改onload.cpp,調它呼叫com_android_server_ledservice.cpp內實現的函式， 3 修改system server.java,     new ledservice()    add ledservice() 4 編寫LEDService.java,用於呼叫本地方法，實現硬體操作 5 編寫ILEDService.java介面給app使用。