楊 倩，楊明趙

(1.重慶理工大學電子信息與自動化學院，重慶 400054;2.重郵信通信科技術(shù)有限公司，重慶 400065)

目前的智能設備在硬件上多采用雙cpu 的架構(gòu)，一個是基帶處理器，主要處理數(shù)字信號、語音信號的編碼解碼以及無線通信協(xié)議，另一個是應用處理器，運行操作系統(tǒng)和各種應用程序?；鶐幚砥?、射頻和其它外圍芯片作為一個模塊，成為無線通信modem，應用程序通過AT 命令接口與之交互［4］。

Modem 廠家AT 命令實現(xiàn)各不相同，RIL 正是為了解決適配問題而產(chǎn)生的。本文主要針對Android RIL，通過分析其設計思路，闡述各個modem 廠家在設計RIL 層如何保證兼容性，減少維護成本。

1 框架分析

圖1 Android Telephony 子系統(tǒng)

圖是Android Telephony 子系統(tǒng)的主要架構(gòu)，運行Phone APP 的Telephony 框架通過socket 與運行于RIL Daemon 進程的RIL 層進行通信，Android RIL 層是連接Telephony 應用框架和modem 之間的橋梁，將RIL 層更進一步劃分成RIL daemon 和vendor RIL 兩部分:

圖2 Android RIL 層框架

RIL daemon(簡稱RILD)包含了RIL 層的主要框架，主要功能包括:

1)根據(jù)參數(shù)，加載特定vendor RIL 庫;

2)監(jiān)聽來自Telephony 層的請求消息，分發(fā)到vendor RIL;

3)提供回調(diào)接口，vendor RIL 可以調(diào)用該接口發(fā)送結(jié)果或者主動上報消息到telephony 層。

vendor RIL 由modem 廠商根據(jù)各自的modem 的實際情況來實現(xiàn)，主要內(nèi)容包括:

1)廠商特有的設備初始化;

2)將AT 交互序列封裝成C 接口。

2 問題

從設計架構(gòu)來看，Android RIL 的設計初衷是modem 廠商只是進行Vendor RIL 實現(xiàn)，而不用去修改RILD，但實際情況是，由于Android 完全開源，很多廠商未遵循該“規(guī)則”而進行隨意定制，Android 目前除了運行在智能手機外，還被廣泛運用于平板電腦、車載系統(tǒng)等，在智能手機上，modem 一般情況下是內(nèi)置在設備內(nèi)，而在其他情況下，往往是將modem以外接模塊的形式通過USB 等接口接入系統(tǒng)。在智能手機上，因為一般出廠后不會更換modem，廠家尚且可以對RIL進行深度定制，比如支持雙卡雙待，必需對RIL 框架進行一定的修改;但在其他場景下，需要modem 容易更換，這就要求只能對vendor RIL 進行修改，這就需要RIL 在設計的時候考慮兼容性，終端廠商能夠通過根據(jù)需要加載不同vendor RIL 即與不同的modem 對接，達到額外的工作最小化目的，減少維護成本。

然而，modem 廠商既需要考慮像手機這樣的深度定制需求，又要考慮支持其他情況的一般接口需求，為了減少維護成本，這些定制需求最好能夠共享同一版本的vendor RIL，也就是說，需要保證未經(jīng)定制的RILD 和深度定制過的RILD能夠加載和使用同樣的vendor RIL 庫，保證二進制接口的兼容。要達到該目的，需要對RIL 層進行深入的分析。

3 接口分析

RILD 通過dlopen 加載vendor RIL，通過RIL_Init 接口，交換雙方互相訪問的回調(diào)接口，這些接口是保證雙方二進制兼容的重要部分:RIL_RadioFunctions * RIL_Init(const struct RIL_Env *，int，char ＊＊)

參數(shù)中，RIL_Env 結(jié)構(gòu)體包含了RILD 的提供調(diào)用接口，返回值RIL_RadioFunctions 結(jié)構(gòu)體包含了vendor RIL 提供的調(diào)用接口。這兩個結(jié)構(gòu)體是RILD 和Vendor RIL 之間僅有的橋梁，由于RILD 和Vendor RIL 庫是單獨編譯和鏈接，要保證所實現(xiàn)的Vendor RIL 與RILD 能夠良好的二進制接口兼容，能夠在不同的Android 平臺上讓modem 更加方便地與各種設備對接，需要保證以上這些二進制結(jié)構(gòu)類型不能做任何修改，包括RIL_Init 函數(shù)定義、RIL_Env、RIL_RadioFunctions 兩個結(jié)構(gòu)體的定義以及其內(nèi)部的函數(shù)指針類型和對應的參數(shù)和返回值類型的定義，因為這些結(jié)構(gòu)在RILD 和Vendor RIL 雙方共用，一旦這些結(jié)構(gòu)題被單獨一方修改，由于雙方是單獨編譯和鏈接，這個階段不會產(chǎn)生任何問題，在運行過程中就很可能產(chǎn)生“段錯誤”。

4 深度定制問題解決方案

前面介紹了一般情況的下的定制需要注意的問題，在實際開發(fā)過程中，會有一些特殊定制需求，比如說，目前市場上有一些“雙卡雙待”手機，modem 可以使用兩張sim 卡，使用不同的網(wǎng)絡，這要求具有RILD 可以對兩張卡進行單獨的控制并維護單獨的狀態(tài)機，下面是針對這樣需求繪制的簡單架構(gòu)圖:

圖3 Android 雙卡定制RIL 層

對比前面的圖2 可以看出，相比前面的普通的單卡情況各種通道數(shù)量都增長了一倍，設計過程面臨更多的兼容性問題，這種架構(gòu)需要:1)RILD 提供兩個socket，處理請求和response;2)vendor RIL 也需要能夠區(qū)分調(diào)用或者回調(diào)針對那一張卡的。

第一條由于socket 通信的雙方都是由同一廠家負責設計和實現(xiàn)，所以不會對Vendor RIL 產(chǎn)上兼容性影響。主要問題出現(xiàn)在第二條，因為Android 設計并沒有考慮雙卡架構(gòu)，通過前面的接口分析，不能修改RIL_Init、RIL_Env、RIL_RadioFunctions 相關(guān)函數(shù)的參數(shù)個數(shù)、類型等，因為這樣會影響兼容性，那么要如何做才能夠既保證Vendor RIL 的兼容性又保證完成定制需求呢?

在LISP 等函數(shù)式編程語言中，函數(shù)接口可以實現(xiàn)面向?qū)ο笳Z言中的對象的功能，即函數(shù)可以包含其創(chuàng)建環(huán)境的一些信息，在函數(shù)式編程中把這種功能稱為closure，C 語言不具備這樣的功能，但是可以借鑒這樣的思想。通過gcc 的擴展匿名函數(shù)__fn__關(guān)鍵字，在RIL_Init 動態(tài)創(chuàng)建所需要的函數(shù)，并且將其與有關(guān)數(shù)據(jù)結(jié)構(gòu)關(guān)聯(lián)，下面以RIL_RadioFunctions 中的onRequest 為例，描述其創(chuàng)建過程:

可以看到，前面的onRequestEx 函數(shù)并不是對外提供的接口，并且比對外接口多了context 參數(shù)，參數(shù)的類型可以根據(jù)需要進行修改，每次外部調(diào)用RIL_Init，都會創(chuàng)建符合對外接口類型的的一組類型相同的不同的接口實例，這些接口自身關(guān)聯(lián)了一組數(shù)據(jù)(context)，外部通過調(diào)用這些接口區(qū)分多個sim 卡，而不用修改接口破壞兼容性。當然，在實際情況中，可能不只兩組接口，可能還有音頻或者調(diào)試相關(guān)接口，通過MAX_CHANNEL 可以進行擴展，當然還可以通過一些宏的封裝使程序更加簡潔，不管怎樣，通過這種方式，就解決了“雙卡”功能的擴展和兼容性的問題。

5 結(jié)束語

通過對Android RIL 架構(gòu)進行分析，闡述了Android RIL帶來的一些兼容性問題，給出了Vendor RIL 在設計過程中的注意事項，并給出了在深度定制過程中保證兼容性的參考實現(xiàn)方式，為RIL 相關(guān)開發(fā)人員開發(fā)出具有良好兼容性和擴展性的產(chǎn)品提供參考。

［1］楊豐盛.Android 技術(shù)內(nèi)幕［M］.北京:機械工業(yè)出版社，2011.

［2］韓超，梁泉.Android 系統(tǒng)級深入開發(fā):移植與調(diào)試［M］.北京:電子工業(yè)出版社，2011.

［3］王家林.細說Android 4.0 NDK 編程［M］.北京:電子工業(yè)出版社，2012.

［4］董思博，周園園，王祿祿.基于android 平臺的通信系統(tǒng)設計與實現(xiàn)［J］.科技傳播，2011(7):226.

［5］M.Shen，J.Jiang.Design and Implementation of Radio Interface Layer in Android video Telephone System［G］.International Conference on Computer Science and Network Technology (ICCSNT)，Vol.3，2011.

［6］William von Hagen.The Definitive Guide to GCC［M］.2nd ed.Apress，2006.