Android系统架构概览

在软件工程里面，没有一个中间层解决不了的问题。换句话说，就是"任何软件工程遇到的问题都可以通过增加一个中间层来解决"。Android系统基于这样一个分层的理念，自上而下将系统架构划分成了App Framework、Android System Service、HAL、Kernel这四个层次。如下图所示：

(1) Application Framework

这一层直接面向Android应用程序开发者，开发者不需要知道具体的硬件细节，只需要了解这一层所提供的API，即可开发出通用的，不依赖具体厂商的应用程序。
这一层的代码都是用java编写的，运行在虚拟机上。

(2) Android System Services

System Services是模块化的，包含具体功能的组件。Application Framework API通过与System Service的交互来对具体的硬件进行操作。Application Framework不需要关心具体的实现，只需要调用指定的api，System Services会返回对应的结果。以Camera Service为例，当一个Camera应用程序执行一个拍照的动作时，会调用一个 capture() 的api，这个api会将拍照请求封装到一个request中，并将它submit到Camera Service，Camera Serivce会返回一个result的回调，将图像数据返回到应用。

这一层都是Native code，是C++代码。
那么问题来了，Application Framework是java代码，Android System Services是C++代码，它们是如何互相调用的？

目前Android框架提供了两种方式，可以让C++和java代码之间互相调用：
方式一：JNI（Java Native Interface）即java本地调用。JNI是一套双向接口，通过它可以让Java代码和C/C++等Native代码进行交互。
方式二：Binder IPC（IPC全称是 Inter-Process communication）。Binder是Android框架提供的一种进程间通信机制，由Client、Server、Service Manager和Binder Driver组成。其中，Binder Driver作为核心，ServiceManager提供辅助管理，Client和Server则是在此基础之上进行C/S通信。

简单概述下Binder通信的基本思想，Server在启动时会向Service Manager注册服务。Client在想Server端发起进程间通信连接前，会先去Service Manager中找到对应的Server，然后发起连接。其中，所有IPC的数据传输都是通过Binder Driver实现的。
在这里，Application Framework可以看做是Client端，Android System Sevice则是Server端。

(3) HAL

HAL的全称是Hardware abstraction layer，即硬件抽象层。从名字可以看出来，这一层是和硬件打交道的，它完全可以放到Kernel实现，为什么还要单独抽出来一个HAL层？

GPL协议，全称是General Public License，即通用性公开许可证。通俗一点的解释是”如果你使用并且修改了我的GPL软件，那么你的软件也必须要开源，否则就不能使用我的软件，你是否把你的软件商用和我没关系“。
Linux kernel就是采用了GPL协议的一个开源软件，任何改在Linux Kernel的代码也是要开源的。为了维护硬件厂商的技术专利或者商业秘密，Android剥离出来了一个HAL层，将硬件交互的具体业务逻辑放到HAL层，而简单读写寄存器的的动作放到驱动实现。

HAL为硬件厂商定义了一套必须要实现的标准接口，所以Android能够不受底层驱动的影响。说白了就是Android只需要各硬件厂商实现其提供的HAL接口就成，具体是怎么实现的就随便各硬件厂商去折腾，Android并不关心HAL的实现细节。

(4) Linux Kernel

Android使用了Linux内核的某一个版本，只是在里面添加了一些特殊功能，包括上文提到的Binder Driver等。所以在Android上写驱动，和在Linux设备上面写驱动没啥差别。