(轉)android系統開發 AP 和 BP 簡要說明
手機的AP和BP根據上下文可以指代硬件和軟件兩種意思.
1) 大多數的手機都含有兩個處理器。操作系統、用戶界面和應用程序都在Application Processor(AP)上執行，AP一般采用ARM芯片的CPU。而手機射頻通訊控制軟件，則運行在另一個分開的CPU上，這個CPU稱為Baseband Processor(BP)。
把射頻功能放在BP上執行的主要原因是：射頻控制函數（信號調制、編碼、射頻位移等）都是高度時間相關的。最好的辦法就是把這些函數放在一個主CPU上執行，並且這個主CPU是運行實時操作系統的。
另外一個使用BP的好處是一旦它被設計和認證為好了的，不管你采用的操作系統和應用軟件怎麽變化，它都可以正確的執行功能（它的通訊功能）。另外，操作系統和驅動的bug也不會導致設備發送災難性的數據到移動網絡中。（FCC要求的）
由於AP和BP是分開的設備，手機設計者可以更加自由的設計用戶界面和應用軟件。
2)手機開發商,比如摩托羅拉,會將開發的手機軟件包分為AP和BP兩部分, 運行在Application Processor(AP)的軟件包稱為AP包,包括操作系統、用戶界面和應用程序等; 與Baseband Processor(BP)相關的軟件包稱為BP包, 包括baseband modem的通信控制軟件等. 相應地, 所謂的刷新手機AP和BP文件即是將這兩個軟件包更新到手機上. 為方便刷機, 也有將AP,BP文件和flex文件(手機的參數配置文件)作在一起的一體包.
AP+BP二者之間通過共享內存來通信！！！！！
http://www.eoeandroid.com/thread-19996-1-1.html
從功能上講對於智能手機的一個粗略的概括是，智能手機 == 電腦 + 移動網卡，或者更準確地說，智能手機的硬件結構分為應用程序處理器AP，和基帶處理器BP兩個部分。這裏隱含著兩個問題，
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 
第一個問題，BP與AP的集成，比較容易解決。第二個問題，AP的開放機制，提供調用系統資源的標準接口，既方便第三方軟件的開發與安裝，同時也盡可能降低開放的風險，這個問題不太容易解決。什麽方式的調用接口才算方便，什麽程度的風險控制才算安全，這兩個指標都缺乏公認的衡量準則。在當前情況下我們能做的，或許是比較幾個智能手機的AP部分的設計，分析一下誰更方便更安全。
Figure 13-2描述的是，Telephony Stack在整個WinMobile系統中的位置，由紅色方框界定。WinMobile為第三方軟件提供了Win32 APIs，Win32 APIs不僅提供了分配內存，控制進程與線程，讀寫文件，連接網絡等等基本功能的調用接口（APIs），也提供了開啟和關閉窗口，以及控制窗口控件的GUI相關的APIs。
Figure 13-2. WinMobile Architecture.
Courtesy
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
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
總結一下，智能手機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，以便建立起通用的模塊與不同品牌和型號的硬件設備之間的通訊渠道。
(轉)android系統開發 AP 和 BP 簡要說明