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