1. BP部分與AP部分的集成。
2. 傳統的功能手機只配備了出廠時預裝的應用軟件，而不允許用戶自主下載並安裝第三方應用軟件，而智能手機突破了這一限制，因此智能手機的AP部分，必須有相應的開放機制，方便第三方軟件的開發與安裝，同時儘可能降低第三方軟件造成對整個系統，包括其它軟件的惡意傷害。更進一步說，智能手機的開放機制，不僅針對第三方軟件，而且也針對手機生產廠家，允許手機生產廠家更換手機系統的部分硬件設備，或者增設其它外設硬件設備，做到一個通用平臺可以出貨多個手機型號，幫助手機生產廠家儘可能降低手機研發費用。
對於第一個問題，BP部分如何與AP部分集成，解決方案的思路很簡單。翻開任何一本操作系統教科書，都可以看到標準的分層結構，應用軟件 >> 操作系統 >> 驅動器 >> 硬件。不妨把BP與AP的集成，與操作系統中的文件系統的構成相比較。
文件系統通常包括虛擬文件系統（Virtual File System，VFS）與實際存儲設備（Storage Device）兩部分。實際存儲設備包括閃存或者硬盤等等存儲硬件，以及相應驅動器。虛擬文件系統通過驅動器操縱存儲硬件，在這個基礎上實現文件和文件夾的建立與刪除，文件讀寫等等功能。虛擬文件系統之所以被稱爲虛擬，是因爲應用軟件通過標準的接口（APIs），來調用虛擬文件系統實現的文件和文件夾的功能，而與實際存儲設備究竟用的是哪一家廠商出品的硬件和驅動器無關[1]。
如果把文件系統中的實際存儲系統類比成智能手機的BP部分，那麼虛擬文件系統相對應的是AP部分中的Telephony Stack。Telephony Stack提供三個功能，
1. 與BP部分的系統間通訊（Inter-Processor Communication，IPC），給BP部分下達指令，建立通信通道，發送及接受語音和數據信息。IPC的實現方式可以是通過傳遞AT-Command，也可以是利用共享內存來實現數據交換。
2. 圍繞BP部分提供的三大基礎功能，即語音通話，短信等數據通信，以及SIM卡管理，加上與之密切相關的電話本（Address Book），提供以下服務，
- 撥打電話：發起或接受語音電話。
- 短信管理：編輯短信，發送短信，接受短信，刪除，回覆或者轉發短信等等。
- 通話歷史。
- 電話本。
- 手機振鈴及振動設置。
- SIM卡管理。
3. 提供標準的調用接口（Telephony APIs， TAPI），方便應用軟件調用上述服務。
Figure 13-1描述的是WinMobile 6的AP系統中，Telephony Stack的內部結構。圖中紫色部分的模塊，嚴格來說，並不屬於Telephony Stack，它們是應用軟件，它們通過調用Telephony APIs來使用黃色部分模塊的功能。黃色部分的模塊，負責實現撥打電話，短信管理，SIM卡管理，通話歷史等等功能，稱作cellcore，由 cellcore.dll提供，手機設計廠家不可以更改cellcore。藍色部分模塊，主要是RIL（Radio Interface Layer），它負責AP部分與BP部分之間的系統間通訊。RIL部分是硬件相關的，由手機Design House或者BP部分生產廠家完成。
Figure 13-1. WinMobile Telephony Stack.
Courtesy http://farm5.static.flickr.com/4030/4461979382_a450147727_o.png
第一個問題，BP與AP的集成，比較容易解決。第二個問題，AP的開放機制，提供調用系統資源的標準接口，既方便第三方軟件的開發與安裝，同時也儘可能降低開放的風險，這個問題不太容易解決。什麼方式的調用接口才算方便，什麼程度的風險控制纔算安全，這兩個指標都缺乏公認的衡量準則。在當前情況下我們能做的，或許是比較幾個智能手機的AP部分的設計，分析一下誰更方便更安全。
Figure 13-2描述的是，Telephony Stack在整個WinMobile系統中的位置，由紅色方框界定。WinMobile爲第三方軟件提供了Win32 APIs，Win32 APIs不僅提供了分配內存，控制進程與線程，讀寫文件，連接網絡等等基本功能的調用接口（APIs），也提供了開啓和關閉窗口，以及控制窗口控件的GUI相關的APIs。
Figure 13-2. WinMobile Architecture.
Courtesy http://farm3.static.flickr.com/2756/4497998261_22aa6faf22_o.png
Win32 APIs功能全面，但是使用難度大。很多APIs附帶的參數很多，很多重複性的工作沒有被封裝，導致應用軟件的開發，不僅代碼量大，而且容易出錯。 有鑑於此，微軟把純C的Win32 APIs，用VC++重新包裝，形成MFC（Microsoft Foundation Classes）。作爲一種Object-Oriented語言，VC++具有封裝（Encapsulation），多態（Polymorphism）， 繼承（Inheritage）等等特性。MFC利用 VC++這些特性，大大簡化了對Win32 APIs的調用方式，程序員可以用更精簡的代碼，完成應用軟件的開發。
微軟把MFC稱爲一種Application Framework。Application Framework這個概念的興起，源於尋求降低GUI開發的難度。GUI的開發，涉及圖形，佈局，事件捕捉與響應，消息傳遞等等諸多技術，不僅入門難， 而且容易出錯。Application Framework藉助多種編程環境（IDE），工具集，和軟件系統定式，例如MVC定式，不僅簡化了編程的複雜度，而且通過規範編程方式，降低了出錯的風險[2]。
MFC中的Object，可以直接分配內存，所以當清除Object時，需要手工清除內存分配，不留殘餘。防範內存泄漏，不僅是應用軟件開發過程中的難點，也是容易出現bug。如果把MFC中的Object，稱爲原生態的Object（Native Object），那麼Jave和C#/.NET中的Object，是受管制的Object（Managed Object）。所謂受管制，主要體現在Virtual Machine中的垃圾收集器（Garbage Collector）負責管理它們佔用的內存空間，而不需要編程者手工分配內存，與清除內存。
Google的智能手機OS，Android，把Telephony功能封裝成Java Object，Telephony Manager。依此類推，把GPS功能也封裝成Java Object，Location Manager，此外還有Resource Manager等等。通過這些Manager Java Object，把外設硬件（peripheral）的功能封裝起來，提供簡單的調用接口，降低了應用軟件開發的難度，提高了程序員的生產力。同時，還提供 Activity Manager，Window Manager，Content Provider，View System，Notification Manager等等，簡化並規範GUI的開發[3,4]。
這些Java Object運行在Virtual Machine上，它們的內存佔用受Garbage Collector管制，從而降低了內存泄露的風險。另外，Android給每個應用軟件都分配了獨立的VM實體，如果某個應用軟件出錯，導致支撐其運行的VM實體崩潰，但是通常不會殃及運行其它應用軟件的VM實體，從而提高了系統的整體安全。
與MFC相比，Android的 Application Framework，更方便，更安全。當然也有代價，代價是損耗了運行速度。
Figure 13-3. Android Architecture [4].
Courtesy http://farm3.static.flickr.com/2713/4497986885_7b1f93c360_o.png
Android 的開放機制，不僅體現在Application Framework，而且還體現在Hardware Abstraction Layer（HAL）。關於設置HAL的意義，Google有三點說明[4]，
1. 爲各種硬件器件制訂標準的驅動器接口。
2. 由於Android的內核是開源的，服從GPL許可。而有些硬件器件廠商不願意開源他們的驅動器程序，有了HAL這個隔離帶，就可以解決開源的內核與不開 源的硬件驅動器之間的矛盾。
3. Android對於硬件驅動器有一定要求。
這三點說明涉及手機制造產業鏈上的三個參與者，
1. 如果有標準的驅動器接口，最大的受益者是手機生產廠商。只要硬件外設生產商按照標準接口提供相應的硬件驅動程序，手機生產商就可以自由選擇各種配件，大大簡化了手機的集成的難度和時間。
2. 不必開源的驅動器程序，受益者是硬件器件生產廠商，而且不給手機生產廠商製造困擾。
3. 比較難以理解的是Android對硬件驅動器會有哪些要求，Android爲什麼要提出這些要求。爲了理解這個問題，不妨分析一個實例，看看Android HAL是如何處理Telephony的。
Figure 13-4描述的是與Telephony相關的各個層次之間的協作關係。我們關心的HAL，在圖中以Libraries（User Space）命名，Telephony HAL的內部結構以綠色標註，包含兩個構件，Radio Daemon和Vendor RIL。
1. Radio Daemon，它是由Android提供的，不隨BP硬件的生產廠家和型號而改變。在Android啓動時，Radio Daemon就被激活，並一直處於運行狀態，直到Android關閉[4]。
2. Vendor RIL（Radio Interface Layer）。Vendor RIL由BP部分生產廠家提供，不同品牌的BP，以及不同型號的BP，綁定不同的Vendor RIL。Vendor RIL的存在形式是一個函數庫文件，文件命名必須服從約定的規範，libril-<companyname>-<RIL version>.so，方便Radio Daemon查找可用的Vendor RIL[5]。
在實時運行時，應用軟件調用Telephony Stack，而Telephony Stack指示Radio Daemon去發現當前可用的Vendor RIL，並動態載入相應的.so函數庫。也就是說，讓Radio Daemon去實現熱拔插（Plug-and-Play）的功能。Vendor RIL函數庫負責AP與BP之間的IPC。至此，從應用軟件，到Telephony Stack，到HAL中的Radio Daemon和Vendor RIL，到BP部分的硬件和驅動器，全線貫通。全線貫通後，應用軟件就可以處理撥打電話，發送短信等等通信業務了[4,5,6]。
雖然Figure 13-4僅僅描述了與Telephony相關的各個層次之間的協作關係，但是對於其它功能，各個層次之間的協作關係也大致相仿，例如音響控制，和電源管理等等。
Android HAL隱含的意義在於，允許Android手機外接其它硬件設備，例如溫度計，擴大手機的功能。
Figure 13-4. Android Telephony system architecture [5].
Courtesy http://farm5.static.flickr.com/4066/4498024565_4c10a45173_o.png
總結一下，智能手機AP部分與BP部分集成，類似於文件系統中通用的VFS與不同廠家提供的Storage Device的集成。BP部分提供基礎的通話，數據通信，和SIM卡功能。而AP部分圍繞這些基礎功能，提供豐富的服務，例如通話記錄，短信的編輯回覆和轉發等等。這些服務，囊括在Telephony Stack函數庫中。
爲了方便第三方軟件的安裝和運行，Android提供了Application Framework，它以Java Object的形式，封裝了Telephony Stack函數庫的功能，GUI功能，和其它外設硬件設備的功能。Application Framework不僅降低了第三方應用軟件的開發難度，而且降低了第三方應用軟件出錯的可能性，另外還降低了萬一第三方應用軟件出錯，所造成的對整個系統的破壞。
爲了方便集成來源廣泛的硬件設備，Android提供了Hardware Abstraction Layer。與文件系統中VFS與Storage Device的協作方式類似，一方面，HAL提煉出不同硬件廠商都必須提供的共同的功能，把它們囊括進通用的模塊，例如Radio Daemon，通用的模塊與硬件的品牌和型號無關。另一方面，HAL要求硬件廠商提供符合Android規範的IPC函數庫，例如Vendor RIL，以便建立起通用的模塊與不同品牌和型號的硬件設備之間的通訊渠道。
轉自：http://hi.baidu.com/idean/item/aa80bfecf114bf05570f1d25