Android中AP和BP概念

Tavi_

于 2022-12-18 15:55:15 发布

阅读量3.3k

点赞数 3

分类专栏： Android 文章标签： android java android studio

本文链接：https://blog.csdn.net/Ternence_zq/article/details/128362974

版权

Android 专栏收录该内容

10 篇文章

订阅专栏

AP和BP

大多数的手机都含有两个处理器。操作系统、用户界面和应用程序都在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二者之间通过共享内存来通信！

BP的源代码路径通常在：vendor/qcom/non-hlos/

从功能上讲对于智能手机的一个粗略的概括是，智能手机 == 电脑 + 移动网卡，或者更准确地说，智能手机的硬件结构分为应用程序处理器AP，和基带处理器BP两个部分。这里隐含着两个问题：

BP部分与AP部分的集成。

传统的功能手机只配备了出厂时预装的应用软件，而不允许用户自主下载并安装第三方应用软件，而智能手机突破了这一限制，因此智能手机的AP部分，必须有相应的开放机制，方便第三方软件的开发与安装，同时尽可能降低第三方软件造成对整个系统，包括其它软件的恶意伤害。更进一步说，智能手机的开放机制，不仅针对第三方软件，而且也针对手机生产厂家，允许手机生产厂家更换手机系统的部分硬件设备，或者增设其它外设硬件设备，做到一个通用平台可以出货多个手机型号，帮助手机生产厂家尽可能降低手机研发费用。

对于第一个问题，BP部分如何与AP部分集成，解决方案的思路很简单。翻开任何一本操作系统教科书，都可以看到标准的分层结构，应用软件 >> 操作系统 >> 驱动器 >> 硬件。不妨把BP与AP的集成，与操作系统中的文件系统的构成相比较。

文件系统通常包括虚拟文件系统（Virtual File System，VFS）与实际存储设备（Storage Device）两部分。实际存储设备包括闪存或者硬盘等等存储硬件，以及相应驱动器。虚拟文件系统通过驱动器操纵存储硬件，在这个基础上实现文件和文件夹的建立与删除，文件读写等等功能。虚拟文件系统之所以被称为虚拟，是因为应用软件通过标准的接口（APIs），来调用虚拟文件系统实现的文件和文件夹的功能，而与实际存储设备究竟用的是哪一家厂商出品的硬件和驱动器无关[1]。

如果把文件系统中的实际存储系统类比成智能手机的BP部分，那么虚拟文件系统相对应的是AP部分中的Telephony Stack。Telephony Stack提供三个功能：

与BP部分的系统间通讯（Inter-Processor Communication，IPC），给BP部分下达指令，建立通信通道，发送及接受语音和数据信息。IPC的实现方式可以是通过传递AT-Command，也可以是利用共享内存来实现数据交换。
围绕BP部分提供的三大基础功能，即语音通话，短信等数据通信，以及SIM卡管理，加上与之密切相关的电话本（Address Book），提供以下服务，

拨打电话：发起或接受语音电话。
短信管理：编辑短信，发送短信，接受短信，删除，回复或者转发短信等等。
通话历史。
电话本。
手机振铃及振动设置。
SIM卡管理。

提供标准的调用接口（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部分生产厂家完成

第一个问题，BP与AP的集成，比较容易解决。

第二个问题，AP的开放机制，提供调用系统资源的标准接口，既方便第三方软件的开发与安装，同时也尽可能降低开放的风险，这个问题不太容易解决。什么方式的调用接口才算方便，什么程度的风险控制才算安全，这两个指标都缺乏公认的衡量准则。在当前情况下我们能做的，或许是比较几个智能手机的AP部分的设计，分析一下谁更方便更安全。

(原文档缺少图片）

Figure 13-2描述的是，Telephony Stack在整个WinMobile系统中的位置，由红色方框界定。WinMobile为第三方软件提供了Win32 APIs，Win32 APIs不仅提供了分配内存，控制进程与线程，读写文件，连接网络等等基本功能的调用接口（APIs），也提供了开启和关闭窗口，以及控制窗口控件的GUI相关的APIs。

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]：

为各种硬件器件制订标准的驱动器接口。
由于Android的内核是开源的，服从GPL许可。而有些硬件器件厂商不愿意开源他们的驱动器程序，有了HAL这个隔离带，就可以解决开源的内核与不开源的硬件驱动器之间的矛盾。
Android对于硬件驱动器有一定要求。

这三点说明涉及手机制造产业链上的三个参与者：

如果有标准的驱动器接口，最大的受益者是手机生产厂商。只要硬件外设生产商按照标准接口提供相应的硬件驱动程序，手机生产商就可以自由选择各种配件，大大简化了手机的集成的难度和时间。
不必开源的驱动器程序，受益者是硬件器件生产厂商，而且不给手机生产厂商制造困扰。
比较难以理解的是Android对硬件驱动器会有哪些要求，Android为什么要提出这些要求。为了理解这个问题，不妨分析一个实例，看看Android HAL是如何处理Telephony的。
Figure 13-4描述的是与Telephony相关的各个层次之间的协作关系。

我们关心的HAL，在图中以Libraries（User Space）命名，Telephony HAL的内部结构以绿色标注，包含两个构件，Radio Daemon和Vendor RIL。

Radio Daemon，它是由Android提供的，不随BP硬件的生产厂家和型号而改变。在Android启动时，Radio Daemon就被激活，并一直处于运行状态，直到Android关闭[4]。

Vendor RIL（Radio Interface Layer）。Vendor RIL由BP部分生产厂家提供，不同品牌的BP，以及不同型号的BP，绑定不同的Vendor RIL。Vendor RIL的存在形式是一个函数库文件，文件命名必须服从约定的规范，libril--.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，以便建立起通用的模块与不同品牌和型号的硬件设备之间的通讯渠道。

AP和 BP的工作原理

bp是baseband processor，ap是application processor。逻辑上是相互独立的系统，有各自的cpu和dsp！两者共享电池和audio模块，通过高效的IPC进行通信。简单的理解的话，bp就是你电脑的modem，而ap就是你的电脑！没有modem，你无法与外界通信。

1.BP工作原理

BP主要的作用就是负责发送和接受各种数据。按照gsm或者3g的协议，BP中dsp实现了协议的算法，对数据进行编解码，而BP中的cpu则负责协调控制与基站和AP的通信。通常，协议栈的代码有2MB-8MB，需要2MB的ram来运行协议栈；因为voice通信是实时的，一个gsm frame很短，需要实时的对这些frame进行处理。

BP中的电源管理对手机的待机时间有很大影响，大多数时间，cpu都应该处于idle状态，每隔一段时间才打开查看paging channel上是否有呼叫进入。cdma有专门的paging信道，所以高通最开始宣称cdma系统的手机待机时间长。不过gsm现在也优化过来了，具体的是2s吗？

语音通信时，voice模块直接有data bus和BP相连接，这样可以快速且省电的把voice数据传递给BP，绕过AP这样就可以省电。

SIM模块直接和BP相连接，BP可以从中获得和无线系统通信的数据，这些数据也是在协议中规定使用的。所以，对sim卡的操作是通过BP进行的。

如果为了降低成本，采用单芯片方案，则协议栈和symbian os公用一个cpu和memory！

2.AP工作原理

AP是一个SoC( System on Chip的缩写，称为系统级芯片,也有称片上系统,意指它是一个产品,是一个有专用目标的集成电路,其中包含完整系统并有嵌入软件的全部内容。)，不像通用计算机这样，硬件和系统可以分开由厂家来设计！AP的硬件都继承在一块芯片上，各模块逻辑上互相独立，均通过总线连接起来。每个模块都有强势的厂商进行研发，如cpu是arm公司，usb是cypress，nand flash有toshiba，samsung等！SoC主要包括cpu，dsp用以进行多媒体的编解码，memory controller，LCD controller，串行通信设备控制器(uart,ir,i/o)，并行通信设备控制器(usb, ipc, nand flash)等。

通过system bus controller，把SoC上器件的可寻址地址映射到cpu的线性地址空间中去，如usb controller的可寻址芯片地址映射到0x60030000----0x6003FFFF，那么cpu可以通过这个地址来对usb的寄存器和data进行读写。

参考连接：

https://blog.csdn.net/weijory/article/details/69388934

https://blog.csdn.net/goyoung/article/details/7226759?spm=1001.2014.3001.5502