android HAL介绍.docxVIP

Android HAL介绍/??2010年04月20日 23:36??收藏本页　　HAL 介绍　　Android 的 HAL (硬件抽像层)是 Google 因应厂商「希望不公开源码」的要求下，所推出的新观念，其架构如下图。虽然 HAL 现在的「抽象程度」还不足，现阶段实作还不是全面符合 HAL 的架构规划，不过也确实给了我们很好的思考空间。　　图 1 ： Android HAL 架构规划　　这是 Patrick Brady (Google) 在 2008 Google I/O 所发表的演讲「 Anatomy Physiology of an Android 」中，所提出的 Android HAL 架构图。从这张架构图我们知道， HAL 的目的是为了把 Android framework 与 Linux kernel 完整「隔开」。让 Android 不至过度依赖 Linux kernel ，有点像是「 kernel independent 」的意思，让 Android framework 的开发能在不考虑驱动程序的前提下进行发展。　　在 Android 原始码里， HAL 主要的实作储存于以下目录：　　1. libhardware_legacy/ - 过去的实作、采取链接库模块的观念进行　　2. libhardware/ - 新版的实作、调整为 HAL stub 的观念　　3. ril/ - Radio Interface Layer　　在 HAL 的架构实作成熟前(即图 1 的规划)，我们先就目前 HAL 现况做一个简单的分析。另外，目前 Android 的 HAL 实作，仍旧散布在不同的地方，例如 Camera 、 WiFi 等，因此上述的目录并不包含所有的 HAL 程序代码。　　HAL 的过去　　图 2 ： Android HAL / libhardware_legacy　　过去的 libhardware_legacy 作法，比较是传统的「 module 」方式，也就是将 *.so 档案当做「 shared library 」来使用，在 runtime ( JNI 部份)以 direct function call 使用 HAL module 。透过直接函数呼叫的方式，来操作驱动程序。　　当然，应用程序也可以不需要透过 JNI 的方式进行，直接以加载 *.so ?( dlopen )的做法呼叫 *.so 里的符号( symbol )也是一种方式。　　HAL 的现实状况　　图 3 ： Android HAL / libhardware现在的libhardware作法，就有「 stub 」的味道了。 HAL stub 是一种代理人( proxy )的概念， stub 虽然仍是以 *.so ?的形式存在，但 HAL 已经将 *.so 档隐藏起来了。 Stub 向 HAL 「提供」操作函数( operations )，而 runtime 则是向 HAL 取得特定模块( stub )的 operations ，再 callback 这些操作函数。这种以 indirect function call 的实作架构，让 HAL stub 变成是一种「包含」关系，即 HAL 里包含了许许多多的 stub (代理人)。 Runtime 只要说明「类型」，即 module ID ，就可以取得操作函数。 HAL 的实现主要在hardware.c和hardware.h文件中。实质也是通过加载 *.so 档( dlopen )从而呼叫 *.so 里的符号( symbol )实现。这里所谓的代理，我感觉不过是 Android 统一定义了三个结构体，然后通过几个“必须”从而统一了调用接口　　HAL 的未来发展?　　新的 HAL 做法，倾向全面采用 JNI 的方式进行。也就是，在 Android 的架构中，修改 Android runtime 实作(即「 Core Library 」)，在取得 HAL 模块的 operations 后再做 callback 操作。将 HAL 模块完全放在 HAL 里面。以上我想应该是针对 framework 开发来说的。如果仅是使用hal访问硬件，完全可以不修改 core library 。　　一、 HAL 使用步骤：　　(1)Java AP 初始化一个 java service ，然后根据需求组合调用 java service 提供的接口。　　(2)Java Service 设置 Native Interface 声明，并在初始化时加载 Native Service 所在的库 .Native Service 实际上是一个动态链接库，通过 JNI 和 Java Service 交互。　　(3) 通过OnLoad方法注