你好,游客 登录 注册 搜索

背景:
阅读内容

一种为Android平台非标准硬件增加驱动程序的设计方案

[日期:2012-05-12] 来源:  作者: [字体: ]

 

  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驱动程序架构。

Android驱动程序架构

图1 Android驱动程序架构

  HALSTub是以Linux共享库(*.so)的形式存在,在整个驱动架构中,它是设备驱动程序运行在用户空间的一部分,它向上为Dalvik虚拟机提供硬件设备的抽象接口,向下通过系统调用与Linux内核中的驱动程序进行数据交互。在这个过程中HAL可以对驱动程序的数据进行处理,也就是说在Linux内核中的驱动程序部分只需要提供一个与硬件设备传输数据接口的功能,而其余具体的操作可以由HAL完成。

  1.2 Android的硬件抽象层

  Android的硬件抽象层HAL(HardwareAbstractLayer)在Android的架构中是在库这一层中,通过这一层,硬件厂商可以把部分设备的驱动源码封装在这一层而不公开源代码。

  对图1分析,设计HAL就是为了把应用框架和Linux内核分离出来,让Android使用Linux内核而又不完全依赖Linux内核。当然,驱动程序并不是完全从Linux内核中分离出来,一些基本的处理必须由内核来完成,HAL只是分担了Linux设备驱动的部分功能,至于这部分的功能占驱动程序功能的比例目前并没有一个标准。

  在Android系统发展过程中,HAL的实现也逐步有了一些变化,旧的HAL是一种模块化的思想,通过共享库的形式由Runtime在JNI时以函数调用方法调用,这种做法并没有通过封装,即上层应用可以直接调用硬件。另外,这种方法可被多个进程使用,映射到多个进程空间中浪费内存资源。

  现在HAL提出一种Stub的思想,HALStub是一种代理的概念,Stub同样是以共享库(*.so)格式存在,但上层应用并不像加载动态库那样调用Stub。这种HAL是由模块与Stub结合而成,Runtime通过模块提供的统一接口获取并操作Stub。Stub向HAL提供操作的回调函数,Runtime向HAL取得指定模块的操作函数后,调用这些回调函数。这是一种间接函数调用的方式,HAL里包含了多个Stub。图2为HALStib原理。

HALStub原理

图2 HALStub原理

  1.3 ndroid的JNI实现原理

  JNI是JavaNativeInterface的缩写,是在Sun的Java平台中首先定义出来的,它允许Java代码与其他语言代码进行交互。Android中JNI的设计目的也是一样:

  (1)应用程序需要与硬件平台交互时,Java库中的类不可能支持;

  (2)本地已经使用其他语言编写的库允许Java程序访问;

  (3)某些功能用较低级的语言实现的执行效率较高,让Java程序调用这些函数。

  在Android应用层中的程序或组件都是用Java语言开发的,这些Java代码编译后变成Dex格式的字节码,由Dalvik虚拟机执行,在执行过程中需要调用本地库时,由虚拟机载入这些本地库,然后让Java函数调用库中的函数,虚拟机相当于一座桥梁,让Java与本地库能够透过标准的JNI界面互相沟通。

  应用程序在虚拟机里执行,通过函数System.loadLibrary()通知虚拟机载入指定的库,例如在Java代码中包含代码如:

  虚拟机就会在Android文件系统的“/system/lib/”目录中查找libsample_jni.so库文件,虚拟机载入libsample_jni.so后,Java代码就可以与库文件结合起来一起执行。

  这些用C语言编写的本地库必须遵循规范,当虚拟机执行System.loadLibrary()函数时,首先执行本地库里的JNI_ONLoad()函数,这个函数需要实现的功能是:返回给虚拟机此本地库使用的JNI版本;对库进行初始化。如果本地库里没有实现JNI_OnLoad()函数,虚拟机就会默认本地库使用最老的JNI1.1版本。

  JNI_OnUnload()函数与装入函数相对应,在虚拟机释放该本地库时,会调用JNI_OnUnload()函数进行资源回收动作。

  在应用层的Java代码通过虚拟机调用本地函数,一般要依赖于虚拟机查找库里的本地函数,如果需要调用比较频繁,每次都要寻找一遍,就会花费较多的时间影响效率,在这里可以通过registerNativeMethods()函数把gMethods[]表格所含的本地函数注册到虚拟机里。


     往下看有更多相关资料

推荐文章 收藏 推荐 打印 | 整理:gddq | 阅读:
查看相关资料       Android  Android平台  驱动程序 
本文评论   查看全部评论 (0)
表情: 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款
专题文章
热门评论