Android Telephony涉及的框架結構如圖1所示。

圖1  Android Telephony框架結構

通過圖1可以發現Android Telephony框架結構的一些規律，具體如下。

• Android Telephony的業務應用跨越了AP和BP。AP與BP相互通訊，符合前面介紹的智慧手機硬體基本結構。
• Android系統在AP上執行，而Telephony執行在Linux Kernel之上的User Space空間。
• Android Telephony也採用了分層結構的設計，共跨越了三層Java Applications、Java Frameworks和User Libraries層，與Android作業系統整體分層結構保持一致。
• Android Telephony從上到下共分三層：Telephony應用、Telephony框架、RIL（Radio Interface Layer，無線通訊介面層，主要位於UserLibraries層中的HAL層，接下來詳細介紹HAL）。
• BP SoftWare在BP上執行，主要負責實際的無線通訊能力處理。

1　系統執行庫層的HAL層

HAL（Hardware Abstraction Layer，硬體抽象層）在Linux和Windows作業系統平臺下有不同的實現方式。

Windows下的HAL位於作業系統的最底層，它直接操作物理硬體裝置，使用抽象介面來隔離不同硬體的具體實現，為上層的作業系統和裝置驅動程式提供一個統一介面，起到對硬體的抽象作用。這樣更換硬體時，編寫硬體的驅動只要實現符合HAL定義的標準介面即可，而上層應用並不會受到影響，不必關心具體來實現的是什麼硬體。

Linux 下的HAL與Windows下的HAL不太一樣，HAL並不是位於作業系統的最底層直接操作硬體，相反，它位於作業系統核心層和驅動程式之上，是一個執行在User Space使用者空間中的服務程式。

2　簡析HAL結構

通過前面的學習，我們知道Android是基於Linux Kernel的開源智慧手機作業系統，所以在這裡重點介紹Linux下的HAL，就不單獨介紹Windows下的HAL結構了。

要想知道HAL結構，先看看來自於HAL 0.4.0 Specification的框架圖吧，如圖1-4所示（引用自http://people.redhat.com/davidz/hal-spec/hal-spec.html）。

圖2　HAL 0.4.0 Specification框架結構

HAL是一個位於作業系統和驅動程式之上，執行在使用者空間中的服務程式。其目的是為上層應用提供一個統一的查詢硬體裝置的介面。我們都知道，抽象就是為了隔離變化，那麼這裡的HAL可以帶給我們什麼？首先，有了HAL介面，可以提前開始應用的開發，而不必關心具體實現的是什麼硬體；其次，硬體廠家如果需要更改硬體裝置，只要按照HAL介面規範和標準提供對應的硬體驅動，而不需要改變應用；最後，HAL簡化了應用程式查詢硬體的邏輯，把這一部分的複雜性轉移給HAL統一處理，這樣當一些應用程式使用HAL時，可以把對不同硬體的實際操作的複雜性也交給不同硬體廠家提供的庫函式來處理。

總之，HAL所謂的抽象並不提供對硬體的實際操作，對硬體的操作仍然由具體的驅動程式來完成。

3　Android為什麼引入HAL

HAL的一些優勢在前面章節已經提到，這裡回顧一下。Android引入HAL不僅因為其自身的優勢，而且還有一個非常重要的原因，就是為了保障在Android平臺基於Linux開發的硬體驅動和應用程式不必遵循GPL（General Public License）許可而保持封閉，這保障了更多廠家的利益。我們都知道，Linux Kernel是開源的而且遵循GPL許可證，根據GPL許可證規定，對原始碼的任何修改都必須向社會開源。

那麼Android是如何做到的呢？Linux Kernel和Android的許可證不一樣，Linux Kernel是GPL許可證，Android是ASL（Apache Software License）許可證。ASL許可證規定，可以隨意使用原始碼，不必開源，所以建立在Android之上的硬體驅動和應用程式都可以保持封閉。也就是說，只要把關鍵的驅動處理相關的主要邏輯轉移到Android平臺內，在LinuxKernel中僅保留基礎的通訊功能，即使開源一部分程式碼，對廠家來講也不會有什麼損失。

Google選擇了這樣做，並且特意修改Kernel，原本應該包括在Linux Kernel中的某些驅動關鍵處理邏輯，被轉移到了HAL層之中而達到了不必開源的目的。

4　Android中HAL的執行結構

Android原始碼中實現了一部分HAL，包括Wi-Fi、GPS、RIL、Sensor等，這些程式碼主要儲存於以下目錄：

• Android_src/hardware/libhardware_legacy：老式HAL結構，採用直接呼叫so動態連結庫方式；
• Android_src/hardware/libhardware：新式HAL結構，採用Stub代理方式呼叫；
• Android_src/hardware/ril：RIL（Radio Interface Layer，無線通訊介面層），作為本書重點關注和學習的內容，後面將以獨立章節詳細講解。

在Android中，HAL的執行機制是什麼樣的呢？它有兩種執行機制，老式HAL和新式HAL，如圖3所示。

圖3　Android中HAL兩種執行結構

從圖3中不難看出，左邊是老的HAL結構，應用或框架通過so動態連結庫呼叫而達到對硬體驅動的訪問。在so動態連結庫裡，實現了對驅動的訪問邏輯處理。我們重點學習和理解HAL Stub方式， RIL也採用了此方式的設計思想。

HAL Stub 是一種Proxy代理概念，Stub雖然仍是以 *.so 的形式存在，但 HAL 已經將 *.so 的具體實現隱藏了起來。 Stub 向 HAL 提供operations方法，Runtime通過Stub提供的so獲取它的 operations方法，並告知Runtime的callback方法。這樣Runtime和Stub都有對方呼叫的方法，一個應用的請求通過Runtime呼叫Stub的operations方法，而Stub響應operations方法並完成後，再呼叫Runtime的callback方法進行返回。這裡可能有一點繞，根據前面的描述再結合圖4所示會更容易理解。

圖4   HAL Stub結構

上層通過HAL提供的functions呼叫底層硬體，而底層硬體處理完成上層請求後或硬體狀態發生變化後，HAL層通過Runtime提供的callback介面回撥上層應用。

HAL Stub 有一種包含關係，即 HAL 裡包含了很多的 Stub。 Runtime 只要說明請求型別，就可以取得並操作Stub對應的operations。其實現主要在 hardware.c 和 hardware.h 檔案中，實質也是通過dlopen方法載入 .so動態連結庫，從而呼叫 *.so 裡的符號( symbol )實現。

------------------------------

《深入理解Android : Telephony原理剖析與最佳實踐》從原始碼角度深入解析了Android Telephony的架構設計與實現原理，深刻揭示了Android系統的通訊機制。對於Android應用開發工程師和系統工程師而言，《深入理解Android:Telephony原理剖析與最佳實踐》都是難得的研究和學習資料。全書共13章，分為五部分：第一部分（1~3章），首先介紹了智慧手機的系統結構、Android系統的架構、Telephony框架的結構，然後詳細介紹了Android原始碼編譯環境和閱讀環境的搭建方法，以及閱讀《深入理解Android:Telephony原理剖析與最佳實踐》要做的技術準備；第二部分（4~6章），對Android的通話功能進行了深入的分析，包括對通話流程的分析、對主動撥號和來電流程的分析、對通話應用機制的分析，以及對手機通訊功能在框架層和應用層中的實現機制的分析；第三部分（7~9章），對Android的通訊功能進行了深入的分析，包括對網路服務狀態的執行機制的分析、對Android手機上網的實現機制的分析，以及對短息傳送和接收流程的分析；第四部分（10~12章），對Android RIL的工作機制進行了深入的分析，包括對框架層中的RILJ執行機制的分析、對RILC系統結構及LibRIL執行機制的分析，以及對Reference-RIL框架的原理的分析；第五部分（13章），分析了Telephony模組所提供的系統服務，包括系統服務的註冊入口以及呼叫系統服務介面的例項。