MTK平台camera bsp学习之android平台架构篇

android平台架构(简单了解，都是csdn上看其他博客摘抄下来)

 

从上到下：分为

APP层

framework层

native层

hal层

kernel层

 

camera bsp侧重点:kernel hal native层 framework层

 

app层: 系统应用层

• 所有的应用程序都是使用JAVA语言调用Framework的接口编写的
• 使用Java通过JNI（Java Native Interface）的方式，配合Android NDK来开发原生程序

 

framework层：JAVA应用程序架构层

• 隐藏在每个应用后面的是一系列的服务和系统
• 应用框架层为应用开发者提供了用以访问核心功能的API框架及各种服务和管理工具，包括界面管理、数据访问、应用层的消息传递、应用包的管理、电话管理、定位管理等功能

 

native层: 原c/c++库和android运行时环境（native c/c++ library & android runtime ）

• native c/c++ library 开发者可在自己的应用中使用C、C++本地库中的接口来方便地实现官方API未实现的功能 
• Android Runtime（Android运行时环境 ）提供了核心链接库和 Dalvik VM虚拟系统，采用 Java开发的应用程序编译成apk程序代码后，交给 Android操作环境来执行。
  • • ART 编写为通过执行 DEX 文件在低内存设备上运行多个虚拟机，DEX 文件是一种专为 Android 设计的字节码格式，经过优化，使用的内存很少。编译工具链（例如 Jack）将 Java 源代码编译为 DEX 字节码，使其可在 Android 平台上运行。
    • 每个Android 应用都运行在自己的进程上， Dalvik 虚拟机为它分配自有的实例。 Dalvik 使一台设备能运行多个虚拟机程序但消耗较少的资源

 

hal层：hardware abstract layer 硬件抽象层

• 向下屏蔽了硬件驱动模块的实现细节，并向上提供硬件访问服务。
• 这一层的存在，实际上主要是为了保护移动设备厂商的商业利益：
  • • Linux 内核源码遵循 GPL 协议，基于它所修改的源码需要完全公开，如果设备厂商通过修改内核源码来提供服务，就需要公开对应的代码，这就暴露了很多硬件相关的参数和实现的细节。
    • 为了保证商业利益，在 Android 架构中提供一个硬件抽象层给设备厂商对硬件做出具体实现，而 Linux 内核仅提供简单的硬件访问通道。由于 Android 源码遵循商业友好的Apache License 协议，这样设备厂商的利益就得到了保障

 

kernel层: 内核层

• Android 平台的基础是 Linux 内核。例如，Android Runtime (ART) 依靠 Linux 内核来执行底层功能，例如线程和低层内存管理。

 

• Android Binder，基于OpenBinder框架的一个驱动，用于提供Android平台的进程间通讯（IPC，inter-process communication）。Android中每个应用都是一个独立的系统进程，而资源的管理和分配是以进程为单位进行的，通常情况下一个进程不能直接访问另一个进程的资源．为了实现进程通信， Android系统引入了 Binder机制．这种通信基于 Client/Server模型，通信的双方都必须创建一个 IBinder接口，进行通信时， Client首先通过系统的 ServiceManager获取目标 Service的代理对象，并通过这个代理对象调用Service提供的功能接口，调用请求会通过 Binder驱动发送给Service，而Service的处理结果也会通过 Binder驱动发送给 Client。

       源代码位于drivers/staging/android/binder.c