Android的Framework分析---4硬件抽象HAL

大家都知道android是基于linux的kernel上的。android可以 运行在intel,高通,nvidia等硬件平台。但是涉及到一些GPU,显卡和一些设备的驱动问题,因为这些驱动都不是开源的,google位了兼容这些设备厂商的驱动源码,提出了硬件抽象层HAL的概念。HAL层对上为framework和native开发提供统一的API接口,为下层驱动的代码提供统一的调用接口。本文主要讲解HAL是如何实现的。

1.HAL的数据结构

HAL的通用写法里面有两个重要的结构体:

1.1 hw_module_t 硬件模块结构体

typedef struct hw_module_t {
    /** tag must be initialized to HARDWARE_MODULE_TAG */
    uint32_t tag;

    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;

模块方法的结构体,open的函数指针,用于打开一个硬件设备hw_device_t。开发者需要实现这个open函数。

1.2硬件设备结构体

typedef struct hw_device_t {
    /** tag must be initialized to HARDWARE_DEVICE_TAG */
    uint32_t tag;

    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;

表示一个硬件抽象设备。这是通用的结构体,开发者可以继承这个结构体添加自己需要的接口。

1.3 获取一个hw_model_t模块

HAL层提供一个方法用户获取一个model,进而同过open方法打开设备device

/**
 * Get the module info associated with a module by id.
 *
 * @return: 0 == success, <0 == error and *module == NULL
 */
int hw_get_module(const char *id, const struct hw_module_t **module);

定义一个全局变量

const struct hw_module_t   HAL_MODULE_INFO_SYM={ ...};

用于在hw_get_modules通过解析so时,得到该全局变量。

2.硬件模块库的装载于解析

装载和解析有hw_get_module 完成,它会安按照一定的规则去查找so库,然后解析出全局变量名,得到硬件设备的open函数,最后通过参数返回一个device的指针给调用者。

2.1搜索so的规则;

/** Base path of the hal modules */
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

/**
 * There are a set of variant filename for modules. The form of the filename
 * is "<MODULE_ID>.variant.so" so for the led module the Dream variants
 * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
 *
 * led.trout.so
 * led.msm7k.so
 * led.ARMV6.so
 * led.default.so
 */

static const char *variant_keys[] = {
    "ro.hardware",  /* This goes first so that it can pick up a different
                       file on the emulator. */
    "ro.product.board",
    "ro.board.platform",
    "ro.arch"
};

搜索规则就是按照上面的说明进行。

2.2函数加载解析的过程

(1)调用hw_get_module,通过传给他一个module_id 字符串例如“camera”等。调用hw_get_module_by_class(id, NULL, module);

(2)搜索对应的so并调用load去解析so

int hw_get_module_by_class(const char *class_id, const char *inst,
                           const struct hw_module_t **module)
{
    int status = -EINVAL;
    int i = 0;
    char prop[PATH_MAX] = {0};
    char path[PATH_MAX] = {0};
    char name[PATH_MAX] = {0};

    if (inst)
        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
    else
        strlcpy(name, class_id, PATH_MAX);

    /*
     * Here we rely on the fact that calling dlopen multiple times on
     * the same .so will simply increment a refcount (and not load
     * a new copy of the library).
     * We also assume that dlopen() is thread-safe.
     */

    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
        if (i < HAL_VARIANT_KEYS_COUNT) {
            if (property_get(variant_keys[i], prop, NULL) == 0) {
                continue;
            }
            snprintf(path, sizeof(path), "%s/%s.%s.so",
                     HAL_LIBRARY_PATH2, name, prop);
            if (access(path, R_OK) == 0) break;

            snprintf(path, sizeof(path), "%s/%s.%s.so",
                     HAL_LIBRARY_PATH1, name, prop);
            if (access(path, R_OK) == 0) break;
        } else {
            snprintf(path, sizeof(path), "%s/%s.default.so",
                     HAL_LIBRARY_PATH2, name);
            if (access(path, R_OK) == 0) break;

            snprintf(path, sizeof(path), "%s/%s.default.so",
                     HAL_LIBRARY_PATH1, name);
            if (access(path, R_OK) == 0) break;
        }
    }

    status = -ENOENT;
    if (i < HAL_VARIANT_KEYS_COUNT+1) {
        /* load the module, if this fails, we're doomed, and we should not try
         * to load a different variant. */
        status = load(class_id, path, module);
    }

    return status;
}

(3)load函数解析so,得到hw_module_t的hw_device_t的函数指针。

/**
 * Load the file defined by the variant and if successful
 * return the dlopen handle and the hmi.
 * @return 0 = success, !0 = failure.
 */
static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi)
{
    int status = -EINVAL;
    void *handle = NULL;
    struct hw_module_t *hmi = NULL;

    /*
     * load the symbols resolving undefined symbols before
     * dlopen returns. Since RTLD_GLOBAL is not or'd in with
     * RTLD_NOW the external symbols will not be global
     */
    handle = dlopen(path, RTLD_NOW);
    if (handle == NULL) {
        char const *err_str = dlerror();
        ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
        status = -EINVAL;
        goto done;
    }

    /* Get the address of the struct hal_module_info. */
    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
    hmi = (struct hw_module_t *)dlsym(handle, sym);
    if (hmi == NULL) {
        ALOGE("load: couldn't find symbol %s", sym);
        status = -EINVAL;
        goto done;
    }

    /* Check that the id matches */
    if (strcmp(id, hmi->id) != 0) {
        ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
        status = -EINVAL;
        goto done;
    }

    hmi->dso = handle;

    /* success */
    status = 0;

    done:
    if (status != 0) {
        hmi = NULL;
        if (handle != NULL) {
            dlclose(handle);
            handle = NULL;
        }
    } else {
        ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                id, path, *pHmi, handle);
    }

    *pHmi = hmi;

    return status;
}

Android的Framework分析---4硬件抽象HAL

时间: 2024-10-31 14:09:32

Android的Framework分析---4硬件抽象HAL的相关文章

Android的Framework分析---5 ActivityManager分析

ActivityManager是android框架的一个重要部分,它负责一新ActivityThread进程创建,Activity生命周期的维护,管理系统中的Acitvity的状态切换. 这边内容还有更多内容,详细请参看ActivityManager.java ,ActivityMangaerNative.java 和SystemServcer.java 文件. 这几个的类的关系如下: 上图很清楚地描述了ActivityManager框架的几个主要类之间的关系,我们做应用开发接触很多的其实就是A

Android application framework 分析[in process]

application activity application service application UI system application sdk tool JVM 1 activity the first JVM instance => zygote app_main ->AndroidRuntime(now start jvm instance,and start to load zyogteinit class and execute main method) ->zyg

Android架构设计和软硬整合:HAL&amp;Framework&amp;Native Service&amp;Android Service&amp;Best Practice

如何理解Android架构设计的初心并开发出搭载Android系统并且具备深度定制和软硬整合能力特色产品,是本课程解决的问题. 课程以Android的五大核心:HAL.Binder.Native Service.Android Service(并以AMS和WMS为例).View System为主轴,一次性彻底掌握Android的精髓. 之所以是开发Android产品的必修课,缘起于: 1, HAL是Android Framework&Application与底层硬件整合的关键技术和必修技术: 2

Android Framework 分析---消息机制Native层

在Android的消息机制中,不仅提供了供Application 开发使用的java的消息循环.其实java的机制最终还是靠native来实现的.在native不仅提供一套消息传递和处理的机制,还提供了自定义文件描述符的I/O时间的监听机制.下面我们从具体代码中分析一下. Native层的关键类: Looper.cpp.该类中提供了pollOnce 和wake的休眠和唤醒机制.同时在构造函数中也创建 管道 并加入epoll的机制中,来监听其状态变化. Looper::Looper(bool al

Android Framework 分析---PackageManager 分析

在windowphone,ios和android中到目前为止,还是android的市场份额最大.个人认为除了google开源外,广大开发者早就了android的霸主地位.各位兄弟姐妹开发出各种各样的apk,才组成android的广阔天下.本篇主要分析一下android系统是针对处理这些apk的,主要涉及到pm这块的代码.分析这种底层服务,最好从android的开启启动流程中开始分析.因为这样才能更清楚的了解服务的启动流程. 1.在SystemServer.java 中启动PM android 开

Android4.4 Framework分析——Android默认Home应用Launcher3的加载过程分析

本文主要介绍Android4.4默认Home应用Launcher3的启动过程和Launcher3的数据加载过程.Launcher的启动是开机时,ActivityManagerService准备好后开始的,下图是它的启动序列图: step1,SystemServer中,ActivityManagerService准备好了. step3, boolean resumeTopActivitiesLocked(ActivityStack targetStack, ActivityRecord targe

Qualcomm Android display架构分析

Android display架构分析(一) http://blog.csdn.net/BonderWu/archive/2010/08/12/5805961.aspx http://hi.baidu.com/leowenj/blog/item/429c2dd6ac1480c851da4b95.html 高通7系列硬件架构分析 如上图,高通7系列 Display的硬件部分主要由下面几个部分组成: A.MDP 高通MSM7200A内部模块,主要负责显示数据的转换和部分图像处理功能理,如YUV转RG

Android—Camera Framework C/S架构服务请求

在前一篇文章Camera Client/Server的binder IPC机制中阐述了Android进程间通信binder IPC机制基础,Android Camera基于这个基础设计了Camera Framework Client/Server架构,文中给出了其类图设计.本文从Android 4.4 版本源码入手,分析Camera App向Camera Service请求服务与返回的过程.服务请求的过程从上到下依次要经过三个大的过程:1. Camera App调用Framework Camer

Android源码分析之模板方法模式

模式的定义 定义一个操作中的算法的框架,而将一些步骤延迟到子类中.使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 使用场景 1.多个子类有公有的方法,并且逻辑基本相同时. 2.重要.复杂的算法,可以把核心算法设计为模板方法,周边的相关细节功能则由各个子类实现. 3.重构时,模板方法模式是一个经常使用的模式,把相同的代码抽取到父类中,然后通过钩子函数约束其行为. UML类图 角色介绍 AbstractClass : 抽象类,定义了一套算法框架. ConcreteClass1 :