Android核心分析—Android電話系統-概述篇

Android電話系統之概述篇

    首先拋開Android的一切概念來研究一下電話系統的最基本的描述。我們的手機首先用來打電話的，隨後是需要一個電話本，隨後是PIM，隨後是網路應用，隨後是雲端運算，隨後是想我們的手機無所不能，替代PC。但是作為一個電話的準系統如下：

0)撥叫電話,電話中，掛斷電話,傳送簡訊，網路連接,PIM管理

1)由於電話電訊廠商為我們提供了插撥，電話會議等補充業務，所以我們的手機需要管理多路通話，如何管理?

2)來電時，我們要播出來電鈴聲，接通時我們需要切換語音通道，這個又跟多媒體系統打上了交道，例如有耳機插上了，有藍芽耳機連上了，系統該做如何的管理和切換？

3）上網的網路通路建立（例如GSM GPRS），如何PPP串連並串連到LinuxSocket通道上的？系統如何管理資料連線？

4）AP跟Modem通訊時通過AT指令的，如何將AT指令變成一個個具體的操作函數，如何管理Modem發給我們的回應，AT命令通道，資料通道如何管理？

5）sim卡的電話本如何管理？

上面的關於手機的基本問題，Android電話系統設計者必須要解答的問題。該設計如何的管理架構，提出什麼概念來表達？所以要分析Android的電話部分，還是需要理解電話實現的背景知識，通訊協議，大體架構。

    我們回到電話系統基本構成上，先從整體上去把握一下電話模組的大體架構，先從空中俯瞰。我給出的圖是一般的智能手機的架構圖，該架構基本能夠概括所有手機電話模組的構成，當然也包括Android的電話系統構成。

    智能機架構一般是應用處理器+Modem。應用處理器與Modem的串連使用串口或者USB。在一個硬體串口通路上實現為了要同時實現資料轉送並同時實現控制Modem,就需要實現多工協議（GSM TS07.10），在底層我們在多工基礎上虛擬了兩個串口，一個用於CMD通道，一個用於DATA通道。電話的所有控制通路都是在這連個通道上。

   RIL,Radio Interface Layer。本層為一個協議轉換層，手機架構需要適應多類型的Modem接入到系統中，而對於不同的Modem有不同的特性，AT指令的格式或者回應有所不同，但是這種特性在設計應用時不可能完全考慮和相容。所以設計者在設計電話系統時，建立了一個虛擬電話系統，為該虛擬電話系統規定了標準的功能，上層的電話管理都是建立在這些標準的功能基礎之上。而RIL則是將虛擬電話系統的標準功能轉換成實際的所使用的Modem的AT指令。

Android設計者將電話系統設計成了三部分。

    Andoird的Phone Service其實是PhoneApp。GSMPhone（CDMAPhone)是Phone Service核心的對象，他包含了如下的相關對象。

       我們的分析任務就是要把這些對象的相互關係，及其對象間資料傳遞關係弄清楚。首先我們給出以下的Android電話系統的架構，以便對Android電話系統有個概要的認識，然後從資料流的角度，以及對象的參考關聯性來分析系統。下面是android電話系統整體架構圖。

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更多是一個管理架構。

    而ril是具體的AT指令合成者和應答解析者。從最基本的功能來講，ril建立了一個偵聽Socket，等待用戶端的串連，然後從該串連上讀取RIL-Java成傳遞來的命令並轉化成AT指令發送到Modem。並等待Modem的回應，然後將結果通過套介面傳回到Ril-Java層。是Ril-D的基本架構：

下面的資料流傳遞描述圖表描述了RIL-JAVA層發出一個電話指令的5 步曲。

 

在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

在添加操作中，有兩個動作：

(1) 加入到watch_list

(2) 將控制代碼加入到readFDS事件控制代碼池。

1.2 ril_event_loop()

   我們知道對於Linux裝置來講，我們可以使用select函數等待在FDS上,只要FDS中記錄的裝置有資料到來，select就會設定相應的標誌位並返回。readFDS記錄了所有的事件相關裝置控制代碼。readFDS中控制代碼是在在AddEvent加入的。所有的事件偵聽都是建立在linux的select readFDS基礎上。

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有應答結果。 

 

對於URC，Rild同樣使用一個抽象數組@Ril.CPP.

static UnsolResponseInfo s_unsolResponses[] = {

#include "ril_unsol_commands.h"

};

並利用RIL_onUnsolicitedResponse將URC向上層發送。

Android電話系統之概述篇

    首先拋開Android的一切概念來研究一下電話系統的最基本的描述。我們的手機首先用來打電話的，隨後是需要一個電話本，隨後是PIM，隨後是網路應用，隨後是雲端運算，隨後是想我們的手機無所不能，替代PC。但是作為一個電話的準系統如下：

0)撥叫電話,電話中，掛斷電話,傳送簡訊，網路連接,PIM管理

1)由於電話電訊廠商為我們提供了插撥，電話會議等補充業務，所以我們的手機需要管理多路通話，如何管理?

2)來電時，我們要播出來電鈴聲，接通時我們需要切換語音通道，這個又跟多媒體系統打上了交道，例如有耳機插上了，有藍芽耳機連上了，系統該做如何的管理和切換？

3）上網的網路通路建立（例如GSM GPRS），如何PPP串連並串連到LinuxSocket通道上的？系統如何管理資料連線？

4）AP跟Modem通訊時通過AT指令的，如何將AT指令變成一個個具體的操作函數，如何管理Modem發給我們的回應，AT命令通道，資料通道如何管理？

5）sim卡的電話本如何管理？

上面的關於手機的基本問題，Android電話系統設計者必須要解答的問題。該設計如何的管理架構，提出什麼概念來表達？所以要分析Android的電話部分，還是需要理解電話實現的背景知識，通訊協議，大體架構。

    我們回到電話系統基本構成上，先從整體上去把握一下電話模組的大體架構，先從空中俯瞰。我給出的圖是一般的智能手機的架構圖，該架構基本能夠概括所有手機電話模組的構成，當然也包括Android的電話系統構成。

    智能機架構一般是應用處理器+Modem。應用處理器與Modem的串連使用串口或者USB。在一個硬體串口通路上實現為了要同時實現資料轉送並同時實現控制Modem,就需要實現多工協議（GSM TS07.10），在底層我們在多工基礎上虛擬了兩個串口，一個用於CMD通道，一個用於DATA通道。電話的所有控制通路都是在這連個通道上。

   RIL,Radio Interface Layer。本層為一個協議轉換層，手機架構需要適應多類型的Modem接入到系統中，而對於不同的Modem有不同的特性，AT指令的格式或者回應有所不同，但是這種特性在設計應用時不可能完全考慮和相容。所以設計者在設計電話系統時，建立了一個虛擬電話系統，為該虛擬電話系統規定了標準的功能，上層的電話管理都是建立在這些標準的功能基礎之上。而RIL則是將虛擬電話系統的標準功能轉換成實際的所使用的Modem的AT指令。

Android設計者將電話系統設計成了三部分。

    Andoird的Phone Service其實是PhoneApp。GSMPhone（CDMAPhone)是Phone Service核心的對象，他包含了如下的相關對象。

       我們的分析任務就是要把這些對象的相互關係，及其對象間資料傳遞關係弄清楚。首先我們給出以下的Android電話系統的架構，以便對Android電話系統有個概要的認識，然後從資料流的角度，以及對象的參考關聯性來分析系統。下面是android電話系統整體架構圖。