对于Android驱动,批开复杂的Android系统框架,这里先提出一个简单的问题:
一:Android应用程序的编写使用的是Java,并且能够访问C库,而驱动程序的实现恰好是使用C语言来实现的,那么驱动程序就变得简单化了。
由此,引出了编写Android驱动的第一种方法:
通过JNI
Java 应用层------------------------->来访问C库
对应的Android 结构是:
通过JNI来打开C库,在C库里
面实现对设备驱动的各种操作
APP------------------------------------------------->C库(驱动程序被编译成SO文件)
比如提供对设备open、close、
Read、write、ioctl等
缺点:Java程序访问C库,意味着APP会去调用C库的open、close、ioctl等接口;也就意味着应用程序就要去打开设备驱动,直接对设备驱动进行操作。因而引入了一个问题:如果多个应用程序都同时来访问这个设备,那么N个应用程序就得都要打开这个设备一次吗?
比如:LCD屏,有很多个应用程序正在使用着,有电话在拨打,QQ在线,微信等,这样的话,这3个应用程序都来打开这个LCD设备/dev/fb不成?显然,这个会造成很多不必要的混乱,很不合理。
在这个背景下出现了另外一种方法:硬件访问服务
硬件访问服务是神马东西:这些APP应用程序不在是直接来访问硬件设备了,而是通过硬件访问服务来统一管理;APP1,2,3……把对硬件的访问请求都发给硬件访问服务,由硬件访问服务来统一管理和操作硬件,而硬件访问服务则通过JNI来访问设备驱动。
到处,得出一个结论:
Android驱动 == Linux驱动 + 封装
封装 == JNI
而Android驱动程序的重点就在于这个服务,对于不同的硬件设备,需要构建不一样的硬件访问服务。也就是在Android系统里面,怎么样来组织和管理者多个应用程序对硬件的访问,并怎么样提供应用程序访问所需要的结果。