何為定製Android系統？就是在特定的硬體上，移植上Android作業系統，並修改原生Android系統以提供給定製的APP操作定製硬體的方法。

所以，定製Android的主要工作有以下三部分：

1. 適配硬體；
2. 製作介面；
3. 定製APP；

一般而言，定製的硬體會採用方案商提供的穩定方案，例如全至的a20方案、a31s方案、r16方案、飛思卡爾的i.MX6方案等等。這些方案拿過來，是一個類似於平板的開發板，在其上Android系統是能夠跑起來的。然後就要根據自身的需求，把一些外圍硬體適配上去，例如你要做一個音箱類的產品，你可能需要適配上牛掰的DSP，PA等等，如果你要做一個車機類的產品，你可能要適配上一個MCU，適配上倒車攝像頭，如果是要做一個電視盒子，紅外或者2.4g是必須的。這就是適配硬體所要做的工作。

定製的硬體產品一般都會應用於一些特殊的場景下，那麼肯定會需要定製一個APP來和使用者進行互動，完成使用者所需要的功能。因為硬體是定製的，很多功能原生的Android系統並沒有提供介面來操作，這就需要開發人員對Android進行修改，把操作硬體的方法暴露給APP。這就是我所做的工作。這部分的工作處於應用開發和驅動開發之間，我姑且稱之為Android中介軟體的開發。

開發驅動的同事一般會提供給我一些裝置節點，通過讀寫這些裝置節點就可以操作外設。一般來說，操作裝置節點的操作會用C/C++來實現。但是對於製作APP的同事，他們會習慣於使用Java這類高階語言，所以對於Android中介軟體的開發者，就要藉助於JNI這一工具，構建連線C/C++和Java的橋樑。

在我的開發過程中，我使用過以下幾種方法來提供操作硬體的介面：

1. 提供JNI原始碼；

提供JNI原始碼是最裸的一種方式。一般在除錯一個硬體功能的時候，我會編寫一個簡單的Demo APP。除錯成功之後，我曾直接把Demo APP的原始碼提供給APP開發者。這樣，我的工作是最少的，只要除錯完，就算是大功告成了。但是對於開發APP的同事來說，這種提供介面的方式需要他們具備一定的JNI開發知識，這就無形中增加了他們的工作量。在我看來，APP開發應該講經歷集中於與使用者的互動上，而不是具體的功能的實現細節上。所以這種方法並不好。

另外一方面，因為介面的原始碼檔案肯定不止一個，那麼原始碼的版本控制也是一個問題。

1. 提供JNI編譯的庫檔案；

具體來說，提供庫檔案有兩種方式。一種是給APP提供JNI編譯之後的庫檔案，由他們整合到APP中。這種方式只是簡化了版本控制的問題（因為只有一個庫檔案），對APP開發者的要求沒有減少。另一種是把JNI在原始碼的環境中編譯，編譯完之後庫檔案就在/system/lib/下面了。APP只需執行在特定韌體中就行了。這種方式的版本控制問題更嚴重。因為採用這種方式，在庫函式載入的時候會檢查APP中宣告的介面函式是否和當前庫中的函式一一對應，不對應會直接崩掉。所以，如果在某個版本之後，APP新增了一個介面，那麼這個新的APP就不能執行在老的韌體中了。

1. 編寫後臺執行的服務；

為了解決上面的問題，可以編寫一個Service。由這個Service來和APP進行互動。因為Service是內建在韌體內部的，所以這個Service和JNI不會有版本匹配的問題。而且互動的過程全部都是通過Java實現的（APP開發者最開心了）。APP和Service是執行與不同程序中的，Android的IPC一般有兩種方式，一種是通過系統廣播，一種是通過AIDL。前者的優點是使用簡單，呼叫不同的介面只需傳送不同的廣播就行了，返回值則通過接收廣播來獲取。它的缺點通過廣播調介面的實時性不能保證。後者則編寫難度較大。各位可以找一下遠端服務的程式碼看看，為了調一個介面，需要編寫很多行的程式碼，這個也是APP的開發人員不想看到的。

其實IPC還有另外一種方式，就是通過socket。這種方式我沒有用過，因為其程式碼編寫的量也不少。

1. 增加系統服務；

這種方式在我目前看來，是最好的方法。為什麼好呢？下次再說。已經快一點了，明天還要上班。