编写android HAL代码

    很重要的一点，android代码是运行在linux应用层的，包括HAL层的代码。

    HAL的三个结构体：hw_module_t, hw_module_methods_t, hw_device_t。

    hardware\libhardware\include\hardware\Hardware.h：

struct hw_module_t;struct hw_module_methods_t;struct hw_device_t;/** * 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;typedef struct hw_module_methods_t {    /** Open a specific device */    int (*open)(const struct hw_module_t* module, const char* id,            struct hw_device_t** device);} hw_module_methods_t;/** * Every device data structure must begin with hw_device_t * followed by module specific public methods and attributes. */typedef struct hw_device_t {    /** tag must be initialized to HARDWARE_DEVICE_TAG */    uint32_t tag;    /**     * Version of the module-specific device API. This value is used by     * the derived-module user to manage different device implementations.     *     * The module user is responsible for checking the module_api_version     * and device version fields to ensure that the user is capable of     * communicating with the specific module implementation.     *     * One module can support multiple devices with different versions. This     * can be useful when a device interface changes in an incompatible way     * but it is still necessary to support older implementations at the same     * time. One such example is the Camera 2.0 API.     *     * This field is interpreted by the module user and is ignored by the     * HAL interface itself.     */    uint32_t version;    /** reference to the module this device belongs to */    struct hw_module_t* module;    /** padding reserved for future use */    uint32_t reserved[12];    /** Close this device */    int (*close)(struct hw_device_t* device);} hw_device_t;

HAL源文件中要定义一个结构体hw_module_t, 它里面包含了hw_module_methods_t。

hw_module_methods_t只有一个成员函数open：

int (*open)(const struct hw_module_t* module, const char* id,
            struct hw_device_t** device);

在函数内部，需要返回一个hw_device_t结构体。

或者定义扩展的hw_device_t，例如：

struct xxx_device_t {    struct hw_device_t common;        //以下成员是HAL对上层提供的接口或一些属性        int fd;    int (*set_val)(struct xxx_device_t* dev, int val);    int (*get_val)(struct xxx_device_t* dev, int* val);};

在open函数给device返回值的时候，返回指向xxx_device_t结构指针。

定义结构体时，变量名必须为HAL_MODULE_INFO_SYM，例如：

/*模块实例变量*/struct xxx_module_t HAL_MODULE_INFO_SYM = {                                                           common: {        tag: HARDWARE_MODULE_TAG,        version_major: 1,        version_minor: 0,        id: XXX_HARDWARE_MODULE_ID,    //头文件中有定义        name: MODULE_NAME,        author: MODULE_AUTHOR,        methods: &xxx_module_methods,      }};