1.3 Android Telephony框架結構

通過前面對Android手機操作系統整體框架結構及每一層的簡單分析和說明，相信大家對Android智能手機操作系統已經有了一些基本的了解和認識。結合Android手機操作系統的整體框架，我們接著學習Android Telephony涉及的框架結構，首先看圖1-3。

通過圖1-3不難發現Android Telephony框架結構的一些規律，總結如下：

? Android Telephony的業務應用跨越AP和BP，AP與BP相互通信，符合前面介紹的智能手機的硬件基本結構。

? Android系統在AP上運行，而Telephony運行在Linux Kernel之上的用戶空間。

? Android Telephony也采用了分層結構的設計，共跨越了三層：應用層、應用框架層和系統運行庫層，與Android操作系統整體分層結構保持一致；

? Android Telephony從上到下共分三層：Telephony應用、Telephony框架、RIL（Radio Interface Layer，無線通信接口層，主要位于系統運行庫層的HAL中，什么是HAL，接下來會詳細介紹）。

? BP SoftWare在BP上運行，主要負責實際的無線通信能力處理，不在本書討論的范圍。

1.3.1 系統運行庫層的HAL

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

Windows下的HAL位于操作系統的最底層，它直接操作物理硬件設備，用來隔離與不同硬件相關的信息，為上層的操作系統和設備驅動程序提供一個統一接口，起到對硬件的抽象作用。這樣更換硬件后編寫硬件的驅動時，只要實現符合HAL定義的標準接口即可，而上層應用并不會受到影響，也不必關心具體實現的是什么硬件。

Linux下的HAL與Windows下的HAL不太一樣，HAL并不是位于操作系統的最底層，直接操作硬件；相反，它位于操作系統核心層和驅動程序之上，是一個運行在用戶空間中的服務程序。

1.3.2 簡析HAL結構

通過前面的學習，我們知道Android是基于Linux Kernel的開源智能手機操作系統，所以這里重點介紹基于Linux下的HAL結構，就不再單獨介紹Windows下的HAL結構。

要想知道HAL結構，先看看來源于HAL 0.4.0 Specification的框圖，如圖1-4所示。

HAL是一個位于操作系統和驅動程序之上，運行在用戶空間中的服務程序。其目的是對上層應用提供一個統一的查詢硬件設備的接口。我們都知道，抽象就是為了隔離變化，那么這里的HAL可以帶給我們什么？首先，有了HAL接口，可以提前開始應用的開發，而不必關心具體實現的是什么硬件；其次，硬件廠家需要更改硬件設備，只要按照HAL接口規范和標準提供對應的硬件驅動，而不需要改變應用；最后，HAL簡化了應用程序查詢硬件的邏輯，把這一部分的復雜性轉移到由HAL統一處理，這樣當一些應用程序使用HAL的時候，可以把對不同硬件的實際操作的復雜性也交給不同硬件廠家提供的庫函數來處理。

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

1.3.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平臺內，在Linux Kernel中僅保留基礎的通信功能，即使開源一部分代碼，對廠家來講也不會有什么損失。

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

1.3.4 Android中HAL的運行結構

由圖1-2中可以知道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，如圖1-5所示。

從圖中不難看出，左邊是老式HAL結構。如圖中所示，應用或框架通過so動態鏈接庫調用從而達到對硬件驅動的訪問。在so動態鏈接庫里，實現了對驅動的訪問邏輯處理。我們重點學習和理解HAL Stub方式，RIL也采用了此方式的設計思想。

HAL Stub是一種代理概念，雖然Stub仍是以*.so的形式存在，但HAL已經將*.so的具體實現隱藏了起來。Stub向HAL提供operations方法，Runtime通過Stub提供的so獲取它的operations方法，并告知Runtime的callback方法。這樣Runtime和Stub都有對方調用的方法，一個應用的請求通過Runtime調用Stub的operations方法，而Stub響應operations方法并完成后，再調用Runtime的callback方法返回。根據前面的描述再結合圖1-6會更容易理解。

上層調用底層，通過底層HAL提供的函數，而底層在處理完上層請求后或硬件狀態發生變化時回調上層，則通過Runtime提供的callback接口完成。

HAL Stub有一種包含關系，即HAL里包含了很多的Stub。Runtime只要說明請求類型，就可以取得并操作Stub對應的operations方法。其實現主要在hardware.c和hardware.h文件中。實質也是通過dlopen方法加載.so動態鏈接庫，從而調用*.so里的符號（symbol）實現。