Android HAL详解(一)

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;