关于后端:Android-HAL-开发-1

最近开始看Android的HAL开发方面的东东，发现当初国内钻研这个的并不多，来自台湾的Jollen可能是走在Android HAL钻研的最前沿，这也和他以前专一做嵌入式linux（openmoko）的工作经验无关，毕竟Android的application开发是基于Java的，而之前Jollen做的更多的还是C/C++开发，因而抉择从HAL作为进入Android的shortcut还是很理智的，我以前也次要是做linux kernel以及基于C/C++的app开发，当初转作Android，发现它的HAL比拟有意思，也是能够钻研的一个很好的方向。

因为本人并没有加入Jollen的HAL整合培训，不过手头有这个培训的资料，以及从 http://code.google.com/p/mokoid/ 下载了mokoid 工程的代码，花了一段时间钻研了Android的HAL，也有一些心得，上面总结一下：

首先，Android的HAL是为了一些硬件提供商提出的“爱护proprietary”的驱动程序而产生的东东，简而言之，就是为了避开linux kernel的GPL license的解放。Android把管制硬件的动作都放到了user space中，而再kernel driver外面只有最简略的读写寄存器的操作，而齐全去掉了各种功能性的操作（比方管制逻辑等），这些可能体现硬件个性的操作都放到了Android的HAL层，而Android是基于Aparch的license，因而硬件厂商能够只提供二进制代码，所以说Android只是一个凋谢的平台，并不是一个开源的平台。

而后，Android的HAL的实现须要通过JNI(Java Native Interface)，JNI简略来说就是java程序能够调用C/C++写的动态链接库，这样的话，HAL能够应用C/C++语言编写，效率更高。而Android的app能够间接调用.so，也能够通过app->app_manager->service(java)->service(jni)->HAL来调用。第二种办法看上去很简单，然而更加合乎android的框架结构。我这里也着重介绍第二种办法。根本的框架如下所示：

Mokiod工程代码树如下所示：

1. .
2. |– apps — 测试应用程序
3. | |– LedClient — 间接调用service管制硬件
4. | | |– AndroidManifest.xml
5. | | `– src
6. | | `– com
7. | | `– mokoid
8. | | `– LedClient
9. | | `– LedClient.java
10. | `– LedTest — 通过manager来管制硬件
11. | |– AndroidManifest.xml
12. | `– src
13. | `– com
14. | `– mokoid
15. | `– LedTest
16. | |– LedSystemServer.java
17. | `– LedTest.java
18. |– frameworks — 框架代码
19. | `– base
20. | |– core
21. | | `– java
22. | | `– mokoid
23. | | `– hardware
24. | | |– ILedService.aidl — Android Interface Definition Language 代码，提供LedService的接口
25. | | `– LedManager.java — LedManager实现代码
26. | `– service
27. | |– com.mokoid.server.xml
28. | |– java
29. | | `– com
30. | | `– mokoid
31. | | `– server
32. | | `– LedService.java — LedService的java实现代码
33. | `– jni
34. | `– com_mokoid_server_LedService.cpp — LedService的jni实现代码
35. |– hardware
36. `– modules
37. |– include
38. | `– mokoid
39. | `– led.h
40. `– led
41. `– led.c — led理论管制硬件的代码
    介绍Android的HAL的时候，我打算从底层往下层介绍。

Kernel Driver
这里的kernel driver绝对于linux真正的driver模式上是一样的，也提供open，read，write，ioctl，mmap等接口，然而，一般来说，只通过这些代码，你并不能理解到硬件的个性，比方write接口，就能够只作成往寄存器写操作，至于如何写，为什么要写，这些工作都会再HAL层进行，而个别用户是看不到这些代码的。这也是为什么linux mainstream把android的kernel踢出去的起因，因为这些driver根本无法用在其余的linux平台上。
HAL层
这一层就位于kernel之上的user space了，一般来说这里须要波及的是两个构造体：hw_module_t和hw_device_t， 第一个构造体是当这个hardware stub被load的时候(hw_get_module())提供的初始化操作，比方提供stub的open(module->methods->open())操作，而第二个构造体是提供该硬件stub具备的操作硬件的接口，再jollen的mokoid工程里，次要提供关上和敞开led的操作，相干的代码如下：
led.h

1. struct led_module_t {
2. struct hw_module_t common;
3. };
   4.
4. struct led_control_device_t {
5. struct hw_device_t common;
   7.
6. / attributes /
7. int fd;
   10.
8. / supporting control APIs go here /
9. / 关上led操作/
10. int (set_on)(struct led_control_device_t dev, int32_t led);
11. / 敞开led操作 /
12. int (set_off)(struct led_control_device_t dev, int32_t led);
13. };
    led.c
14. / 关上led操作 /
15. int led_on(struct led_control_device_t *dev, int32_t led)
16. {
17. LOGI(“LED Stub: set %d on.”, led);
18. return 0;
19. }
20. / 敞开led操作 /
21. int led_off(struct led_control_device_t *dev, int32_t led)
22. {
23. LOGI(“LED Stub: set %d off.”, led);
24. return 0;
25. }
26. / 关上led硬件时候的操作 /
27. static int led_device_open(const struct hw_module_t module, const char name,
28. struct hw_device_t** device)
29. {
30. struct led_control_device_t *dev;
    18.
31. dev = (struct led_control_device_t )malloc(sizeof(dev));
32. memset(dev, 0, sizeof(*dev));
33. …
34. / 提供给service可用的硬件操作接口 /
35. dev->set_on = led_on;
36. dev->set_off = led_off;
37. *device = &dev->common;
38. success:
39. return 0;
40. }
    29.
41. static struct hw_module_methods_t led_module_methods = {
42. open: led_device_open
43. };
    33.
44. const struct led_module_t HAL_MODULE_INFO_SYM = {
45. common: {
46. tag: HARDWARE_MODULE_TAG,
47. version_major: 1,
48. version_minor: 0,
49. id: LED_HARDWARE_MODULE_ID,
50. name: “Sample LED Stub”,
51. author: “The Mokoid Open Source Project”,
52. methods: &led_module_methods,
53. }
54. / supporting APIs go here /
55. };
    以上代码最初会被编译成动态链接库，比方libled.so放到/system/libs/hw/, 当service调用hw_get_module(hardware/libhardware/hardware.c)时候，会在/system/libs/hw/外面寻找对应的动态链接库，而后提供给service对应的操作接口。