Android 个层次间调用关系

上一篇介绍了Android系统的启动过程，这里将介绍Android应用程序是如何按照层次关系来调用最底层的硬件和服务的，

在Android中运行的应用程序都是通过以下三种方式层层深入的：

App---->runtimeservice ---> lib

App--->runtimeservice --->native service ---->lib

App--->runtimeservice ---->native Daemon ---->lib

后面将具体分析这三种方式：

第一种方式

应用程序首先在应用程序层Binder IPC 调用应用程序框架层的RuntimeService ，然后在通过JNI与运行库中的原生服务绑定，并动态地加载Hal库，进而调用linux内核层的Kernel Driver。具体流程框图如下：

以上是第一种方式的调用过程，接下来将分析第二种方式

 

与第一种方式相比，第二种方式只多了一个通过IPC机制调用原生服务并进行动态装载的过程。现以播放音频（Audio）的例子说明这种方式。

从上面的框图可看出，应用程序调用了应用框架层的Runtime Service（这里是MediaPlayer），然后通过JNI调用与之绑定的Runtime Library （这里是MediaPlayer）。这时MediaPlayer又分别调用了MediaFramework通过Binder IPC 的方式调用AudioFlinger（原生服务），而后通过AudioFlinger调用指定的库（libaudio.so）,最后才调用Kernel Driver 。  

第三种方式，app---〉runtime service --ànative Daemon--àlib  这种方式通常用于守护进程的连接，这种方式比原生服务的调用更简单，他直接通过JNI绑定原生服务，再通过是sockets调用守护进程进行动态加载。具体见框图，

下一篇 

Android 系统开发（移植）