Writing the Android HAL code

It is important that the Android code is running on the Linux application layer, including the HAL layer code.

Hal's three structural bodies: 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 NA Med 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 is 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 have * 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 modul     E implementation. * For example, Surfaceflinger are responsible for making sure that * it knows what to manage different versions of the G     Ralloc-module API, * and Audioflinger must know how to does the same for Audio-module API. * * The module API VErsion should include a major and a minor component. * For example, version 1.0 could is represented as 0x0100.     This format * implies that versions 0x0100-0x01ff is all api-compatible. * In the future, Libhardware would expose a hw_get_module_version () * (or equivalent) function that would take min Imum/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 define S is supplied here for temporary * source code compatibility.     They'll is removed in the next version.     * All clients must convert to the new version format. *//** * The API version of the HAL module interface.     This was 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 in 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 $ 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 met Hods and attributes.    */typedef struct hw_device_t {/** tag must is initialized to Hardware_device_tag */uint32_t tag;   /**  * Version of the module-specific device API.     This value was 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 being useful when a device interface changes on an incompatible the-it is still necessary-support Older implementations at the same * time.     One such example is the Camera 2.0 API.     * * This field was interpreted by the module user and was 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;

The HAL source file defines a struct hw_module_t, which contains the hw_module_methods_t.

Hw_module_methods_t has only one member function open:

Int (*open) (const struct hw_module_t* module, const char* ID,
struct hw_device_t** device);

Inside the function, you need to return a hw_device_t struct.

Or define the hw_device_t of the extension, for example:

struct xxx_device_t {    struct hw_device_t common;        The following members are the interfaces provided by the HAL to the upper layer or some properties of the        int fd;    Int (*set_val) (struct xxx_device_t* dev, int val);    Int (*get_val) (struct xxx_device_t* dev, int* val);};

Returns a pointer to the XXX_DEVICE_T structure when the Open function returns a value to the device.

When defining a struct, the variable name must be Hal_module_info_sym, for example:

/* Module instance variable */struct xxx_module_t hal_module_info_sym = {                                                           common: {        tag:hardware_module_tag,        version_major: 1,        version_minor:0,        id:xxx_hardware_module_id,    //header files are defined in        name:module_name,        author:module_ AUTHOR,        methods: &xxx_module_methods,      }};

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Writing the Android HAL code