# Android電話系統之-rild Rild是Init進程啟動的一個本地服務，這個本地服務并沒有使用Binder之類的通訊手段，而是采用了socket通訊這種方式。RIL(Radio Interface Layer) Android給出了一個ril實現框架。由于Android開發者使用的Modem是不一樣的，各種指令格式，初始化序列都可能不一樣，GSM和CDMA就差別更大了，所以為了消除這些差別，Android設計者將ril做了一個抽象，使用一個虛擬電話的概念。這個虛擬電話對象就是GSMPhone（CDMAPhone),Phon對象所提供的功能協議，以及要求下層的支撐環境都有一個統一的描述，這個底層描述的實現就是靠RIL來完成適配。 Andoid將RIL層分為兩個代碼空間：RILD管理框架，AT相關的xxxril.so動態鏈接庫。將ＲＩＬ獨立成一個動態鏈接庫的好處就是Ａｎｄｒｏｉｄ系統適應不同的Ｍｏｄｅｍ，不同的Mode可以有一個獨立的Ril與之對應。從這個層面上看，Rild更多是一個管理框架。 [](http://hi.csdn.net/attachment/201005/10/0_1273502394d94y.gif) 而ril是具體的AT指令合成者和應答解析者。從最基本的功能來講，ril建立了一個偵聽Socket，等待客戶端的連接，然后從該連接上讀取RIL-Java成傳遞來的命令并轉化成AT指令發送到Modem。并等待Modem的回應，然后將結果通過套接口傳回到Ril-Java層。下圖是Ril-D的基本框架： [](http://hi.csdn.net/attachment/201005/10/0_1273502396C9X1.gif) 下面的數據流傳遞描述圖表描述了RIL-JAVA層發出一個電話指令的5 步曲。 [](http://hi.csdn.net/attachment/201005/10/0_1273502399hSwI.gif) 在AT通訊的過程中有兩類響應：一種是請求后給出應答，一種是通知類，即為不請自來的，例如短信通知達到，我們稱該類通知為URC。在Rild中URC和一般的Response是分開處理的，概念上URC由handleUnsolicited@Atchannel.c處理，而Response由handleFinalResponse來處理。 ### 1 Event Loop Rild管理的真正精髓在ril.cpp,ril_event.cpp中，在研究的過程中，可以看到設計者在抽象上所下的功夫，設計得很優美。Event Loop的基本工作就是等待在事件端口（串口，Socket），一旦有數據到達就根據登記的Event回調函數進行處理。現在來看Ril設計者是如何建立一套管理框架來完成這些工作的？ ### 1.1 Event對象 Event對象構成：（fd,index,persist,func,param） | fd | 事件相關設備句柄。例如對于串口數據事件，fd就是相關串口的設備句柄 | |-----|-----| | index | ? | | persist | 如果是保持的，則不從watch_list中刪除。 | | func | 回調事件處理函數 | | param | 回調時參數 | 為了統一管理事件，Android使用了三個隊列：watch_list,timer_list,pending_list,并使用了一個設備句柄池readFDS。 readFDS：是Linux的fd_set，readFDS保存了Rild中所有的設備文件句柄，以便利用select函數統一的完成事件的偵聽。 watch_list：監測時間隊列。需要檢測的事件都放入到該隊列中。 timer_list：timer隊列 pending_list:待處理事件隊列，事件已經觸發，需要所回調處理的事件。 事件隊列隊列的操作：ril_event_add,ril_event_del, ril_timer_add [](http://hi.csdn.net/attachment/201005/10/0_12735024032eeO.gif) 在添加操作中，有兩個動作： (1) 加入到watch_list (2) 將句柄加入到readFDS事件句柄池。 ### 1.2 ril_event_loop() 我們知道對于Linux設備來講，我們可以使用select函數等待在FDS上,只要FDS中記錄的設備有數據到來，select就會設置相應的標志位并返回。readFDS記錄了所有的事件相關設備句柄。readFDS中句柄是在在AddEvent加入的。所有的事件偵聽都是建立在linux的select readFDS基礎上。[](http://hi.csdn.net/attachment/201005/10/0_1273502408D9MO.gif) ril_event_loop 利用select等待在readFDS（fd_set）上，當select設備有數據時，ril_event_loop會從select返回，在watch_list中相應的Event放置到pend_list，如果Event是持久性的則不從watch_list中刪除。然后ril_event_loop遍歷pengding_list處理Event事件，發起事件回調函數。 ### 1.3 幾個重要的Event 上面分析了ril-d的框架，在該框架上跑的事件有什么 （1）s_listen_event- （s_fdListen,listenCallback） listenCallback處理函數， 接收客戶端連接：s_fdCommand=accepte(..) 添加s_commands_event() 重新建立s_listen_event，等待下一次連接 （2） s_command_event(s_fdCommand,ProcessCommandsCallback) 從fdCommand? Socket連接中讀取StreamRecord 使用ProcessCommandBufer處理數據 s_listen_event在大的功能上處理客戶端連接（Ril-JAVA層發起的connect）,并建立s_commands_event去處理Socket連接發來的Ril命令。ProcessCommandBufer實際上包含了Ril指令的下行過程。 ### 1.4 下行命令翻譯及其組織@ProcessCommandBuffer RIL_JAVA傳遞的命令格式：Parcel ，由命令號，令牌，內容組成。RIL_JAVA到達RIL_C時轉為構建本地RequestInfo，并將被翻譯成具體的AT指令。由于每條AT命令的參數是不同的，所以對不同的AT指令，有不同的轉換函數，在此Android設計在這里做了一個抽象，做了一個分發框架，通過命令號，利用sCommand數組，獲得該命令的處理函數。 ~~~ sComand[]={ } sComand 存在于Ril_command.h中。 &sComand[]= {RIL_REQUEST_GET_IMEI, dispatchVoid, responseString}, {RIL_REQUEST_DIAL, dispatchDial, responseVoid}, {….} ~~~ dispatchXxx函數一般都放在在Reference-ril.c中，Reference-ril.c這個就是我們需要根據不同的Modem來修改的文件。 ### 1.5 send_at_command框架 send_at_command是同步的，命令發送后，send_at_command將等待在s_commandcond，直到有sp_response->finalResponse。 ### 2 read loop@Atchannel.c Read loop是解決的問題是：解析從Modem發過來的回應。如果遇到URC則通過handleUnsolicited上報的RIL_JAVA。如果是命令的應答，則通過handleFinalResponse通知send_at_command有應答結果。? [](http://hi.csdn.net/attachment/201005/10/0_1273502410mntq.gif) 對于URC，Rild同樣使用一個抽象數組@Ril.CPP. ~~~ static UnsolResponseInfo s_unsolResponses[] = { #include "ril_unsol_commands.h" }; ~~~ 并利用RIL_onUnsolicitedResponse將URC向上層發送。 ### 3 Ril-d的整體數據流及其控制流示意圖 [](http://hi.csdn.net/attachment/201005/10/0_1273502416R2rv.gif)