Android接口和框架学习

缩写：

HAL：HardwareAbstraction Layer。硬件抽象层

CTS：CompatibilityTest Suite，兼容性測试套件

Android让你能够自由实现设备规格和驱动，HAL提供一套标准方法来在Android平台栈(platform stack)和硬件之间创建软件钩子(hook)。Android系统是开源的，你能够贡献自己的接口和添加功能。

为保证设备保持高质量和提供一直的用户体验，每一个设备必须通过CTS測试。CTS确保设备满足质量标准。保证APP的可靠执行和好的用户体验。

在移植Android到你的硬件平台上，花些时间从一定高度来理解Android系统框架。

由于你的驱动和HAL要和android交互，了解Android工作机制能够帮助你有效控制Android源码树的多层代码。

图1

1. 应用框架层(Applicationframework)

应用框架层主要是应用程序开发人员常常使用。作为硬件开发人员，你应该知道尽可能多的API，且要知道这些API和底层HAL接口的映射关系，这样能够提供关于实现驱动的实用信息。

2. IPC进程间通讯机制Binder(Binder IPC)

Binder机制同意应用框架层款过进程界限并訪问Android系统服务代码，这可使高层的框架API和Android系统服务交互，在应用框架层，这样的通讯对开发人员隐藏并表现为事情就好像是顺其自然完毕一样。

3. 系统服务(system services)

应用框架API提供的函数和系统服务通信以訪问底层硬件，服务是模块化的，比方比較重要的Windows Manager窗体管理器、Serarch Service搜索服务或是Notification Manager通知管理器。Android包括两组服务：系统(比方Windows Manager和Notification Manager)和多媒体服务(如录制和播放媒体服务)

4. HAL硬件抽象层(Hardware Abstraction Layer)

HAL定义一组标准接口来让设备厂商去实现。同意Android不必知道底层驱动的实现。

HAL同意你在不影响或是改动上层系统的前提下实现功能，HAL的实现被打包成为模块(.so文件)文件，而且在适当的时候被Android系统载入。

图2

你必须为产品的硬件实现相应的HAL(和驱动)。 HAL的实现典型的被编译成共享库模块(.so文件)，Android没有要求在HAL实现和设备驱动之间是标准的交互，所以你能够基于自己的情况做最适合的事情。可是，为了保证Android系统能够和硬件正确交互。你必须遵守每一个具有硬件特性的HAL接口协议。

5. 标准HAL结构体(Standare HAL structure)

每一个特定硬件HAL接口都有其特性，由hardware/libhardware/include/hardware/hardware.h的结构体hw_module_t定义，这样可保证HAL有个可预见的结构。HAL接口同意Android系统一致性的载入你的HAL模块的正确版本号。

HAL接口由两个通用的组件组成：一个模块(module)和一个设备(device)。

5.1 模块(module)

模块打包了HAL的实现。这些实现作为一个共享库.so文件体现。

它包括模块的version、name、author，这些成员帮助Android找到和载入模块，模块相应的结构体为hw_module_t，在hardware/libhardware/include/hardware/hardware.h定义。此结构体描写叙述一个模块和包括比方模块版本号、作者和名字。

除此之外。hw_module_t结构体还包括指向hw_module_methods_t结构体的指针methods，hw_module_methods_t结构体包括一个打开模块的函数指针open。这个open函数作为一个抽象服务发起和硬件的通信。每一个详细的硬件HAL通常要扩展通用的hw_module_t结构体，添加附加信息来更好的描写叙述详细的硬件。

比方摄像头HAL，

typedefstruct camera_module {
    hw_module_t common;
    int (*get_number_of_cameras)(void);//扩展部分
    int (*get_camera_info)(int camera_id,struct camera_info *info); //扩展部分
}camera_module_t;

当你实现一个HAL和创建模块结构体。你必须以HAL_MODULE_INFO_SYM来给name成员赋值，比方：

structaudio_module HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version =AUDIO_MODULE_API_VERSION_0_1,
        .hal_api_version =HARDWARE_HAL_API_VERSION,
        .id = AUDIO_HARDWARE_MODULE_ID,
        .name ="NVIDIA Tegra Audio HAL",
        .author = "The Android Open SourceProject",
        .methods = &hal_module_methods,
    },
};

5.2 设备(device)

设备抽象了产品实际的硬件。比方一个音频模块包括一个主要的音频设备、一个USB音频设备或一个蓝牙A2DP音频设备。一个设备由hw_device_t结构体描写叙述，像模块一样。每种类型的设备可在hw_device_t结构体的基础上定义很多其它细节信息，比方指向硬件特征的函数指针。audio_hw_device_t就包括指向音频设备操作的函数指针get_supported_devices。

struct audio_hw_device {
   struct hw_device_t common;
 
   /**
    * used by audio flinger to enumerate what devices are supported by
    * each audio_hw_device implementation.
    *
    * Return value is a bitmask of 1 or more values of audio_devices_t
    */
   uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
  ...
};
typedef struct audio_hw_deviceaudio_hw_device_t;

除了这些标准的属性，每一个详细硬件HALC接口能够定义多个硬件特有属性和需求

6. HAL模块

HAL的实现被编译成为模块(.so)文件和在Android合适的时候会动态链接它。你能够为你每一个HAL实现创建Android.mk文件来编译你的模块并指向你的源码文件。

通常。你的共享库必须以某种格式命名，这样它们才可能被找到和载入。从模块到模块的命名方案略有不同，可是一般遵循以下的形式：<module_type>.<device_name>

很重要，比方module_type能够是GPS。但假设採用不同的GPS外设，能够通过device_name来区分。

7. Linux内核

开发你的设备驱动相似于开发典型的linux设备驱动，Android使用一个版本号的Linux内核。在此内核基础上添加了一些Android特有的内容，比方唤醒锁(wave lock，一个内存管理器系统更积极主动去保护内存)、Binder IPC驱动和其它针对移动嵌入式平台的重要特征，这些特征是系统主要功能和不影响驱动开发。

你能够使用不论什么支持所须要特诊的版本号内核(比方binder驱动)，可是，我们推荐採用最新的Android内核版本号。

參考链接：

http://source.android.com/devices/index.html

posted @ 2018-02-16 17:27 llguanli 阅读(384) 评论(0) 编辑收藏举报

刷新页面返回顶部