Android硬件抽象层(HAL)深入剖析(一)【转】

作为一个搞android驱动或者说搞底层的人,我觉得对于hal那是必须要掌握的,而且必须达到一定深度,于是我总结了一下,将整个自己的分析思路写下来。

主要是看android源代码,根据源代码得到的思路。(看源代码比看什么著作书籍都管用)

android HAL是什么?为什么有它?

硬件抽象层是介于android内核kernel和上层之间的抽象出来的一层结构。他是对linux驱动的一个封装,对上层提供统一接口,上层应用不必知道下层硬件具体怎么实现工作的,它屏蔽了底层的实现细节。

它在整个android架构中的位置如下图所示:

传统的linux对硬件的操作基本上在内核空间的linux驱动程序中实现了,那么现在为什么那么多此一举把对硬件的操作分为两部分,hal和linux驱动呢?

而且hal属于用户空间,linux驱动属于内核空间。其实并不多余。那么为什么要高出这么个东西,理由是很多的:

1.谷歌搭好了hal的框架,为上层framework打通过jni调用hal提供了统一的api,硬件开发商或者移植人员只需要按照框架开发即可,无需话费精力在与上层的交互上的实现上,将精力放在hal层本身的实现上即可。

2.从商业角度,许多硬件厂商不愿意将自己硬件相关一些核心的东西开源出去,假如将对自己硬件的驱动程序全部放入内核空间驱动程序实现,那么必须遵循GPL协议,是必需开源的。有了HAL层之后,他们可以把一些核心的算法之类的东西的实现放在HAL层,而hal层位于用户空间,不属于linux内核,和android源码一样遵循的是appache协议,这个是可以开源或者不开的。

搞清楚了hal的存在意义,下面来根据hal层源码分析一下hal到底是怎么样个架构和实现原理,深入剖析一下。

android hal层的代码主要位于/hardware/libhardware下面我们从上往下走。

在hal层中,各类硬件的都是以硬件模块的形式描述的hal层中是用hw_module_t结构体来描述的,而每一类硬件模块中又有各个独立的硬件,hal中是用hw_device_t结构体来描述的。

上层app通过jni调用硬件时,首先得获取到hw_module_t结构体,也即是硬件模块,有了这个才能再对硬件进行操作。那么我们来看看看看这两个结构体定义是什么样子的。

它们的定义在/hardware/libhardware/include/hardware/hardware.h里面。

a.  hw_module_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;  //tag,根据引文注释可以看到必须被初始化为HARDWARE_MODULE_TAG

    /** major version number for the module */
    uint16_t version_major;//主版本号

    /** minor version number of the module */
    uint16_t version_minor;//次版本号

    /** Identifier of module */
    const char *id;//模块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;

前面tag,name那几个成员属性就不说了,看了注释相信大家都知道了,下面看看hw_module_methods_t,这个指针methods它指向的是与本硬件模块相关的方法的结构体,里面不用看可以猜出肯定有一些函数指针,但是它里面只有一个函数指针。可以看看定义:

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;

我们可以看到确实只有一个函数指针,open它是打开硬件模块中硬件设备的函数。

然后是成员void* dso,它是打开硬件模块相关的额设备之后返回的句柄给它,这个在后面看hw_get_module函数源码的时候你就会明白。

b.  下面我们再来看看hw_device_t结构体,这个结构体主要是用来描述模块中硬件设备的属性信息什么的。一个硬件模块可能有多个硬件设备。

比如说,传感器模块,sensor_module,是一个硬件模块,但是手机中的传感器就对应的有好多种,比如加速度acc_sensor,磁传感器M_sensor等,那么他们都属于sensor_module,但是他们有都有自己的

hw_device_t结构体来描述。hw_device_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;   //设备tag

    /** version number for hw_device_t */
    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;

其中,第三个成员module指向的是这个设备归属的硬件模块结构体。

最后一个函数指针close指向的肯定是关闭设备的函数。

恩,到此,hal的主要的两个结构体讲完了,下次我们继续,将结合源码,看看hal层到底是怎么工作的,看看上层怎么获取到硬件模块,硬件设备的,到底是怎么加载解析动态共享库的。

原文地址:https://www.cnblogs.com/vijozsoft/p/10600902.html

时间: 2024-11-08 01:46:02

Android硬件抽象层(HAL)深入剖析(一)【转】的相关文章

Android硬件抽象层(HAL)深入剖析(二)

上一篇我们分析了android HAL层的主要的两个结构体hw_module_t(硬件模块)和hw_device_t(硬件设备)的成员,下面我们来具体看看上层app到底是怎么实现操作硬件的? 我们知道,一些硬件厂商不愿意将自己的一些核心代码开放出去,所以将这些代码放到HAL层,但是怎么保证它不开放呢?HAL层代码不是也让大家知道下载吗?其实硬件厂商的HAL核心代码是以共享库的形式出现的,每次在需要的时候,hal会自动加载调用相关共享库.那么是怎么加载找到某一硬件设备对应的共享库的呢?这也是我们这

[android底层] hal硬件抽象层编写

两个与hal有关的结构体 hw_module_t ,hw_device_t 一.jni和hal之间的关系 Tip:几种app,jni,hal,framework之间的关系框架     这篇文章用的框架是第二种框架的编写,他们的关系如下: 可以看出jni主要通过pModule和pdevice来获取hal中的变量来操作hal层 二.jni操作hal 获取hal层:1.jni获取hal层的module和device对象 操作hal层:2.jni操作hal层 jni操作hal完整代码参考[android

在Ubuntu为Android硬件抽象层(HAL)模块编写JNI方法提供Java访问硬件服务接口(老罗学习笔记4)

在上两篇文章中,我们介绍了如何为Android系统的硬件编写驱动程序,包括如何在Linux内核空间实现内核驱动程序和在用户空间实现硬件抽象层接口.实现这两者的目的是为了向更上一层提供硬件访问接口,即为Android的Application Frameworks层提供硬件服务.我们知道,Android系统的应用程序是用Java语言编写的,而硬件驱动程序是用C语言来实现的,那么,Java接口如何去访问C接口呢?众所周知,Java提供了JNI方法调用,同样,在Android系统中,Java应用程序通过

Android硬件抽象层(HAL)概要介绍和学习计划

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6567257 Android的硬件抽象层,简单来说,就是对Linux内核驱动程序的封装,向上提供接口,屏蔽低层的实现细节.也就是说,把对硬件的支持分成了两层,一层放在用户空间(User Space),一层放在内核空间(Kernel Space),其中,硬件抽象层运行在用户空间,而Linux内核驱动程序运行在内核空间.为什么要这样安排呢?把硬件抽象

第9章 Android硬件抽象层 学习心得

第9章 Android硬件抽象层 心得体会 这一章主要概括的介绍了安卓硬件抽象层的主要内容,对安卓的HAL做了一个总体的介绍.通过对第9章的学习,使我对HAL有了一个感性的认识. 首先我了解了Android的硬件抽象层的定义,简单来说,就是对Linux内核驱动程序的封装,向上提供接口,屏蔽低层的实现细节.也就是说,把对硬件的支持分成了两层,一层放在用户空间(User Space),一层放在内核空间(Kernel Space),其中,硬件抽象层运行在用户空间,而Linux内核驱动程序运行在内核空间

为Android添加HAL模块(转)

1.每个硬件抽象层模块在内核中都对应一个驱动程序,硬件抽象层模块就时通过这些驱动程序来访问硬件设备的,它们是通过读写设备文件来进行通信的. 硬件抽象层中的模块接口源文件一般保存在hardware/libhardware目录中,为了方便起见,我们将虚拟硬件设备freg在硬件抽象层中的模块名称定义为freg,目录结构如下: hardware/libhardware/include/hardware/freg.h hardware/libhardware/modules/freg/Android.mk

为Android添加HAL模块

1.每个硬件抽象层模块在内核中都对应一个驱动程序,硬件抽象层模块就时通过这些驱动程序来访问硬件设备的,它们是通过读写设备文件来进行通信的. 硬件抽象层中的模块接口源文件一般保存在hardware/libhardware目录中,为了方便起见,我们将虚拟硬件设备freg在硬件抽象层中的模块名称定义为freg,目录结构如下: hardware/libhardware/include/hardware/freg.h hardware/libhardware/modules/freg/Android.mk

Android:HAL向上层提供接口

研究Android的核心库框架,慢慢的想了解一写驱动开发,Android怎么和Linux打交道?下面介绍一个对Android核心框架的HAL(Hardware Abstraction Layer)的理解.Android核心框架如图: Android的HAL是为了保护一些硬件提供商的知识产权而提出的,是为了避开linux的GPL束缚.思路是把控制硬件的动作都放到了 Android HAL中,而linux driver仅仅完成一些简单的数据交互作用,甚至把硬件寄存器空间直接映射到user space

【转】【Android】HAL分析

原文网址:http://www.cnblogs.com/lcw/p/3335505.html HAL概述 以下是基于android4.0.3,对应其他低版本的代码,可能有所差异,但基本大同小异. Android的HAL是为了保护一些硬件提供商的知识产权而提出的,是为了避开linux的GPL束缚. 思路是把控制硬件的动作都放到了Android HAL中,而linux driver仅仅完成一些简单的数据交互作用,甚至把硬件寄存器空间直接映射到user space.而Android是基于Aparch的