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;
- Android HAL详解(一)
- Android sensor hal 详解
- Android HAL开发详解
- Android HAL技术详解
- Android GPS HAL详解
- android HAL 详解
- Android Graphic HAL&Driver(一)
- (转载)Android HAL 详解
- Android O 学习(一)之HAL类型
- Android HAL
- android HAL
- android HAL
- Android Hal
- Android HAL
- Android HAL
- android hal
- Android HAL
- Android HAL
- Helix Streaming Server 简单配置
- 权限管理 (一) 设计思路分析和实现授权、认证
- Parallel Computing with MATLAB
- serialVersionUID 的作用
- 使用UITextFieldDelegate来隐藏键盘
- Android HAL详解(一)
- android通过webservice进行网络编程,使用工具类实现
- 程序员技术练级
- Effective C++ 条款5——了解C++默默编写并调用哪些函数
- 修改tomcat默认路径
- 利用js简单实现图片的放大缩小功能
- UIButton使用方法汇总
- UITextField用法总汇 (转载)
- 把tomcat中的webapps移走