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