基于安卓的非标准驱动程序设计解析

　Android系统是Google推出的基于Linux内核和Java架构的操作系统，在很短的时间内已成为主流的手机操作系统，并已逐步扩展应用到嵌入式系统、平板电脑和上网本上。它既有Linux系统所具有的硬件平台可移植性，也因使用Java语言开发应用程序带来了应用软件只编写一次即可在所有平台运行的巨大优势。Android虽然主要基于已有的技术，但在体系结构设计上有较大的创新。其主要设计目标之一就是要使应用程序和系统能独立于具体的计算机体系结构和硬件平台，表现在设备驱动程序设计上，对于已有的Linux标准设备驱动程序可以直接继续使用，只需为其增加应用层JNI接口。但对于Linux没有的非标准设备则提倡在Linux内核中驱动部分只做很少的接口工作，尽量把驱动程序的主要处理放在Android的上层架构中，即在应用层实现。本文对Android系统的底层实现技术进行深入的研究，包括Android的硬件抽象层和JNI技术实现等。并以S3C2440开发板上的LED灯设计显示驱动程序为例，提出了一种非标准硬件设备驱动程序的设计和实现方案。
　　1 Android系统驱动程序架构
　　1.1 驱动程序分层体系结构
　　Android是基于Linux的，它使用了Linux内核，但应用程序使用Java语言开发，所以应用程序在调用设备驱动时不能像一般的Linux应用程序那样直接使用系统调用，必须通过Java虚拟机的JNI的本地（Native）方法使用设备。另一方面，Android要成为一个通用性强的平台，必须加强它的可移植性。这也是在Android架构添加一个硬件抽象层（HAL）的原因，目的是为设备的调用提供一个更高级的封装图1所示为Android驱动程序架构。
　　HAL Stub是以Linux共享库（*.so）的形式存在，在整个驱动架构中，它是设备驱动程序运行在用户空间的一部分，它向上为Dalvik虚拟机提供硬件设备的抽象接口，向下通过系统调用与Linux内核中的驱动程序进行数据交互。在这个过程中HAL可以对驱动程序的数据进行处理，也就是说在Linux内核中的驱动程序部分只需要提供一个与硬件设备传输数据接口的功能，而其余具体的操作可以由HAL完成。
　　1.2 Android的硬件抽象层
　　Android的硬件抽象层HAL（Hardware Abstract Layer）在Android的架构中是在库这一层中，通过这一层，硬件厂商可以把部分设备的驱动源码封装在这一层而不公开源代码。
　　对图1分析，设计HAL就是为了把应用框架和Linux内核分离出来，让Android使用Linux内核而又不完全依赖Linux内核。当然，驱动程序并不是完全从Linux内核中分离出来，一些基本的处理必须由内核来完成，HAL只是分担了Linux设备驱动的部分功能，至于这部分的功能占驱动程序功能的比例目前并没有一个标准。
　　
　　在Android系统发展过程中，HAL的实现也逐步有了一些变化，旧的HAL是一种模块化的思想，通过共享库的形式由Runtime在JNI时以函数调用方法调用，这种做法并没有通过封装，即上层应用可以直接调用硬件。另外，这种方法可被多个进程使用，映射到多个进程空间中浪费内存资源。
　　现在HAL提出一种Stub的思想，HAL Stub是一种代理的概念，Stub同样是以共享库（*.so）格式存在，但上层应用并不像加载动态库那样调用Stub。这种HAL是由模块与Stub结合而成，Runtime通过模块提供的统一接口获取并操作Stub。Stub向HAL提供操作的回调函数，Runtime向HAL取得指定模块的操作函数后，调用这些回调函数。这是一种间接函数调用的方式，HAL里包含了多个Stub。图2为HAL Stib原理。