Android HAL详解(一)

来源:互联网 发布:mac dance with me 编辑:程序博客网 时间:2024/06/06 20:48

1,HAL定义

  HAL(hardware abstraction layer)从字面意思理解,称为硬件抽象层。它是Android framework层运行的基石,android系统上层所需要的所有有关硬件的操作都需要调用HAL相关的API,如GPS,BT,输入设备,Graphocs,Camera,Audio等。每种硬件设备Android系统都规范了一些功能,各个设备的HAL就是实现这些功能(调用对应的驱动程序)的集合。如果vendor不想open source自己的driver,可以将部分设备功能实现在HAL层。

2,HAL框架

  目前android系统中共有两种HAL框架形式,代码分别在:
      1)hardware/libhardware_legacy/
      2)hardware/libhardware/
  1)是旧版本的实现方式,是将所有HAL层的功能放在一个*.so文件中,然后在runtime阶段通过函数直接调用各个module来操作驱动程序。2)是将所有的HAL module提供的API进行统一的封装,统一了上层访问HAL的接口。
  重要数据结构:   
/** * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM * and the fields of this data structure must begin with hw_module_t * followed by module specific information. */typedef struct hw_module_t {    /** tag must be initialized to HARDWARE_MODULE_TAG */    uint32_t tag;    /**     * The API version of the implemented module. The module owner is     * responsible for updating the version when a module interface has     * changed.     *     * The derived modules such as gralloc and audio own and manage this field.     * The module user must interpret the version field to decide whether or     * not to inter-operate with the supplied module implementation.     * For example, SurfaceFlinger is responsible for making sure that     * it knows how to manage different versions of the gralloc-module API,     * and AudioFlinger must know how to do the same for audio-module API.     *     * The module API version should include a major and a minor component.     * For example, version 1.0 could be represented as 0x0100. This format     * implies that versions 0x0100-0x01ff are all API-compatible.     *     * In the future, libhardware will expose a hw_get_module_version()     * (or equivalent) function that will take minimum/maximum supported     * versions as arguments and would be able to reject modules with     * versions outside of the supplied range.     */    uint16_t module_api_version;#define version_major module_api_version    /**     * version_major/version_minor defines are supplied here for temporary     * source code compatibility. They will be removed in the next version.     * ALL clients must convert to the new version format.     */    /**     * The API version of the HAL module interface. This is meant to     * version the hw_module_t, hw_module_methods_t, and hw_device_t     * structures and definitions.     *     * The HAL interface owns this field. Module users/implementations     * must NOT rely on this value for version information.     *     * Presently, 0 is the only valid value.     */    uint16_t hal_api_version;#define version_minor hal_api_version    /** Identifier of module */    const char *id;    /** Name of this module */    const char *name;    /** Author/owner/implementor of the module */    const char *author;    /** Modules methods */    struct hw_module_methods_t* methods;    /** module's dso */    void* dso;    /** padding to 128 bytes, reserved for future use */    uint32_t reserved[32-7];} hw_module_t;

3,HAL API

   int hw_get_module_by_class(const char *class_id, const char *inst,                           const struct hw_module_t **module);
   int hw_get_module(const char *id, const struct hw_module_t **module);
   这两个函数都是通过设备ID来找到HAL module的callback函数

module id:

   #define  AUDIO_HARDWARE_MODULE_ID               "aduio"   #define AUDIO_HARDWARE_MODULE_ID_PRIMARY        "primary"   #define AUDIO_HARDWARE_MODULE_ID_A2DP           "a2do"   #define AUDIO_HARDWARE_MODULE_ID_USB            "usb"   #define AUDIO_HARDWARE_MODULE_ID_REMOTE_SUBMIX  "r_submix"   #define BT_HARDWARE_MODULE_ID                   "bluetooth"   #define BT_STACK_TEST_MODULE_ID                 "bluetooth_test"   #define AUDIO_POLICY_HARDWARE_MODULE_ID          "audio_policy"   #define GPS_HARDWARE_MODULE_ID                   "gps"   #define LOCAL_TIME_HARDWARE_MODULE_ID            "local_time"   #define KEYSTORE_HARDWARE_MODULE_ID              "keystore"   #define POWER_HARDWARE_MODULE_ID                 "power"   #define SENSORS_HARDWARE_MODULE_ID               "sensors"   #define CAMERA_HARDWARE_MODULE_ID                "camera"   #define LIGHTS_HARDWARE_MODULE_ID                "lights"   #define GRALLOC_HARDWARE_MODULE_ID               "gralloc"   #define NFC_NCI_HARDWARE_MODULE_ID               "nfc_nci"   #define NFC_HARDWARE_MODULE_ID                   "nfc"   #defien HWC_HARDWARE_MODULE_ID                   "hwcomposer"

4,HAL Hardware Modules

1) audio
   2) audio_remote_submix
   3) camera
   4) consumerir
   5) gralloc
   6) hnwcomposer
   7) local_time
   8) nfc
   9) nfc-nci
   10)power   
   11)usbaudio

没一个module都用一个数据结构来描述,这个数据结构必须包含hw_module_t,如power module的数据结构定义如下:

/** * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM * and the fields of this data structure must begin with hw_module_t * followed by module specific information. */typedef struct power_module {    struct hw_module_t common;    /*     * (*init)() performs power management setup actions at runtime     * startup, such as to set default cpufreq parameters.  This is     * called only by the Power HAL instance loaded by     * PowerManagerService.     */    void (*init)(struct power_module *module);    /*     * (*setInteractive)() performs power management actions upon the     * system entering interactive state (that is, the system is awake     * and ready for interaction, often with UI devices such as     * display and touchscreen enabled) or non-interactive state (the     * system appears asleep, display usually turned off).  The     * non-interactive state is usually entered after a period of     * inactivity, in order to conserve battery power during     * such inactive periods.     *     * Typical actions are to turn on or off devices and adjust     * cpufreq parameters.  This function may also call the     * appropriate interfaces to allow the kernel to suspend the     * system to low-power sleep state when entering non-interactive     * state, and to disallow low-power suspend when the system is in     * interactive state.  When low-power suspend state is allowed, the     * kernel may suspend the system whenever no wakelocks are held.     *     * on is non-zero when the system is transitioning to an     * interactive / awake state, and zero when transitioning to a     * non-interactive / asleep state.     *     * This function is called to enter non-interactive state after     * turning off the screen (if present), and called to enter     * interactive state prior to turning on the screen.     */    void (*setInteractive)(struct power_module *module, int on);    /*     * (*powerHint) is called to pass hints on power requirements, which     * may result in adjustment of power/performance parameters of the     * cpufreq governor and other controls.  The possible hints are:     *     * POWER_HINT_VSYNC     *     *     Foreground app has started or stopped requesting a VSYNC pulse     *     from SurfaceFlinger.  If the app has started requesting VSYNC     *     then CPU and GPU load is expected soon, and it may be appropriate     *     to raise speeds of CPU, memory bus, etc.  The data parameter is     *     non-zero to indicate VSYNC pulse is now requested, or zero for     *     VSYNC pulse no longer requested.     *     * POWER_HINT_INTERACTION     *     *     User is interacting with the device, for example, touchscreen     *     events are incoming.  CPU and GPU load may be expected soon,     *     and it may be appropriate to raise speeds of CPU, memory bus,     *     etc.  The data parameter is unused.     *     * A particular platform may choose to ignore any hint.     *     * availability: version 0.2     *     */    void (*powerHint)(struct power_module *module, power_hint_t hint,                      void *data);} power_module_t;