Android--hw_get_module解析

本文深入探讨了Android系统中HAL层的加载机制,详细解释了hw_get_module函数如何通过HAL_MODULE_INFO_SYM导出符号找到并加载正确的硬件模块。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们知道,google为了保护硬件厂商的信息,在Android中添加了一层,也就是大名鼎鼎的HAL层。

在看HAL的编写方法的过程中,会发现整个模块貌似没有一个入口。一般说来模块都要有个入口,比

如应用程序有main函数,可以为加载器进行加载执行,dll文件有dllmain,而对于我们自己写的动态

链接库,我们可以对库中导出的任何符号进行调用。
    问题来了,Android中的HAL是比较具有通用性的,需要上层的函数对其进行加载调用,Android的

HAL加载器是如何实现对不同的Hardware Module进行通用性的调用的呢?

    带着这个疑问查看Android源码,会发现Android中实现调用HAL是通过hw_get_module实现的。

int hw_get_module(const char *id, const struct hw_module_t **module); 
这是其函数原型,id会指定Hardware的id,这是一个字符串,比如我们比较熟悉的led的id是
#define SENSORS_HARDWARE_MODULE_ID “led”,如果找到了对应的hw_module_t结构体,

会将其指针放入*module中。看看它的实现。

124 int hw_get_module(const char *id, const struct hw_module_t **module)  
125 {  
126     int status;  
127     int i;                                                                                        
128     const struct hw_module_t *hmi = NULL;  
129     char prop[PATH_MAX];  
130     char path[PATH_MAX];  
131   
132     /* 
133      * Here we rely on the fact that calling dlopen multiple times on 
134      * the same .so will simply increment a refcount (and not load 
135      * a new copy of the library). 
136      * We also assume that dlopen() is thread-safe. 
137      */  
138   
139     /* Loop through the configuration variants looking for a module */  
140     for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {  
141         if (i < HAL_VARIANT_KEYS_COUNT) {  
142             if (property_get(variant_keys[i], prop, NULL) == 0) { //获取数组<span style="font-family:Arial,Helvetica,sans-serif">variant_keys里的属性值</span>  
  
143                 continue;  
144             }  
145             snprintf(path, sizeof(path), "%s/%s.%s.so",  
146                     HAL_LIBRARY_PATH, id, prop);//如果开发板叫做fs100,这里就加载system/lib/hw/led.fs100.so  
147         } else {  snprintf(path, sizeof(path), "%s/%s.default.so",  
149                     HAL_LIBRARY_PATH, id);//这里默认加载system/lib/hw/led.default.so  
150         }  
151         if (access(path, R_OK)) {  
152             continue;  
153         }  
154         /* we found a library matching this id/variant */  
155         break;  
156     }  
157   
158     status = -ENOENT;  
159     if (i < HAL_VARIANT_KEYS_COUNT+1) {  
160         /* load the module, if this fails, we're doomed, and we should not try 
161          * to load a different variant. */  
162         status = load(id, path, module);//load函数是关键,调用load函数打开动态链接库  
163     }  
164   
165     return status;  
166 } 
上述代码主要是获取动态链接库的路径,并调用load函数去打开指定路径下的库文件,load函数是关键所在。

好,那我们就来解开load函数的神秘面纱!!!

65 static int load(const char *id,  
 66         const char *path,  
 67         const struct hw_module_t **pHmi)  
 68 {  
 69     int status;  
 70     void *handle;  
 71     struct hw_module_t *hmi;  
 72   
 73     /* 
 74      * load the symbols resolving undefined symbols before 
 75      * dlopen returns. Since RTLD_GLOBAL is not or'd in with 
 76      * RTLD_NOW the external symbols will not be global 
 77      */  
 78     handle = dlopen(path, RTLD_NOW);  
 79     if (handle == NULL) {  
 80         char const *err_str = dlerror();  
 81         LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");  
 82         status = -EINVAL;  
 83         goto done;  
 84     }  
 85   
 86     /* Get the address of the struct hal_module_info. */  
 87     const char *sym = HAL_MODULE_INFO_SYM_AS_STR;  
 88     hmi = (struct hw_module_t *)dlsym(handle, sym);  
 89     if (hmi == NULL) {  
 90         LOGE("load: couldn't find symbol %s", sym);  
 91         status = -EINVAL;  
 92         goto done;  
 93     }  
 94   
 95     /* Check that the id matches */  
 96     if (strcmp(id, hmi->id) != 0) {  
 97         LOGE("load: id=%s != hmi->id=%s", id, hmi->id);  
 98         status = -EINVAL;  
 99         goto done;  
100     }  
101   
102     hmi->dso = handle;  
103   
104     /* success */  
105     status = 0;  
106   
 93     }  
 94   
 95     /* Check that the id matches */  
 96     if (strcmp(id, hmi->id) != 0) {  
 97         LOGE("load: id=%s != hmi->id=%s", id, hmi->id);  
 98         status = -EINVAL;  
 99         goto done;  
100     }  
101   
102     hmi->dso = handle;  
103   
104     /* success */  
105     status = 0;  
106   
107     done:  
108     if (status != 0) {  
109         hmi = NULL;  
110         if (handle != NULL) {  
111             dlclose(handle);  
112             handle = NULL;  
113         }  
114     } else {  
115         LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",  
116                 id, path, *pHmi, handle);  
117     }  
118   
119     *pHmi = hmi;  
120   
121     return status;  
122 } 
这里有一个宏HAL_MODULE_INFO_SYM_AS_STR需要注意:

#define HAL_MODULE_INFO_SYM_AS_STR  "HMI" 

其中 hmi = (struct hw_module_t *)dlsym(handle, sym);

这里是查找“HMI”这个导出符号,并获取其地址。

看到这里,我们不禁要问,为什么根据“HMI”这个导出符号,就可以从动态链接库中找到结构体hw_module_t呢??

  我们知道,ELF = Executable and Linkable Format,可执行连接格式,是UNIX系统实验室(USL)作为应用程序二进制接口(Application Binary Interface,ABI)而开发和发布的,扩展名为elf。一个ELF头在文件的开始,保存了路线图(road map),描述了该文件的组织情况。sections保存着object 文件的信息,从连接角度看:包括指令,数据,符号表,重定位信息等等。我们的led.default.so就是一个elf格式的文件。

linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ file led.default.so   
led.default.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped  
所以说,我们可以使用unix给我们提供的readelf命令去查看相应的符号信息,就一目了然了!

linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ readelf -s led.default.so   
  
Symbol table '.dynsym' contains 25 entries:  
   Num:    Value  Size Type    Bind   Vis      Ndx Name  
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND   
     1: 000004c8     0 SECTION LOCAL  DEFAULT    7   
     2: 00001000     0 SECTION LOCAL  DEFAULT   11   
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND ioctl  
     4: 000006d4     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end  
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr0  
     6: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS _bss_end__  
     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc  
     8: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start__  
     9: 00000000     0 FUNC    GLOBAL DEFAULT  UND __android_log_print  
    10: 000006ab     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start  
    11: 00001174     4 OBJECT  GLOBAL DEFAULT   15 fd  
    12: 000005d5    60 FUNC    GLOBAL DEFAULT    7 led_set_off  
    13: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_end__  
    14: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start  
    15: 00000000     0 FUNC    GLOBAL DEFAULT  UND memset  
    16: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS __end__  
    17: 00001174     0 NOTYPE  GLOBAL DEFAULT  ABS _edata  
    18: 00001178     0 NOTYPE  GLOBAL DEFAULT  ABS _end  
    19: 00000000     0 FUNC    GLOBAL DEFAULT  UND open  
    20: 00080000     0 NOTYPE  GLOBAL DEFAULT  ABS _stack  
    21: 00001000   128 OBJECT  GLOBAL DEFAULT   11 HMI  
    22: 00001170     0 NOTYPE  GLOBAL DEFAULT   14 __data_start  
    23: 00000000     0 FUNC    GLOBAL DEFAULT  UND close  
    24: 00000000     0 FUNC    GLOBAL DEFAULT  UND free
在21行我们发现,名字就是“HMI”,对应于hw_module_t结构体。再去对照一下HAL的代码。

const struct led_module_t HAL_MODULE_INFO_SYM = {  
    common: {  
        tag: HARDWARE_MODULE_TAG,  
        version_major: 1,  
        version_minor: 0,  
        id: LED_HARDWARE_MODULE_ID,   
        name: "led HAL module",  
        author: "farsight",               
        methods: &led_module_methods,   
    },   
      
};  
这里定义了一个名为HAL_MODULE_INFO_SYM的copybit_module_t的结构体,common成员为hw_module_t类型。注意这里的HAL_MODULE_INFO_SYM变量必须为这个名字,这样编译器才会将这个结构体的导出符号变为“HMI”,这样这个结构体才能被dlsym函数找到!


综上,我们知道了andriod HAL模块也有一个通用的入口地址,这个入口地址就是HAL_MODULE_INFO_SYM变量,通过它,我们可以访问到HAL模块中的所有想要外部访问到的方法。


static void adev_close_input_stream(struct audio_hw_device *dev, 608 struct audio_stream_in *stream) 609 { 610 struct legacy_audio_device *ladev = to_ladev(dev); 611 struct legacy_stream_in *in = 612 reinterpret_cast<struct legacy_stream_in *>(stream); 613 614 ladev->hwif->closeInputStream(in->legacy_in); 615 free(in); 616 } 617 618 static int adev_dump(const struct audio_hw_device *dev, int fd) 619 { 620 const struct legacy_audio_device *ladev = to_cladev(dev); 621 Vector<String16> args; 622 623 return ladev->hwif->dumpState(fd, args); 624 } 625 626 static int legacy_adev_close(hw_device_t* device) 627 { 628 struct audio_hw_device *hwdev = 629 reinterpret_cast<struct audio_hw_device *>(device); 630 struct legacy_audio_device *ladev = to_ladev(hwdev); 631 632 if (!ladev) 633 return 0; 634 635 if (ladev->hwif) 636 delete ladev->hwif; 637 638 free(ladev); 639 return 0; 640 } 641 642 static int legacy_adev_open(const hw_module_t* module, const char* name, 643 hw_device_t** device) 644 { 645 struct legacy_audio_device *ladev; 646 int ret; 647 648 if (strcmp(name, AUDIO_HARDWARE_INTERFACE) != 0) 649 return -EINVAL; 650 651 ladev = (struct legacy_audio_device *)calloc(1, sizeof(*ladev)); 652 if (!ladev) 653 return -ENOMEM; 654 655 ladev->device.common.tag = HARDWARE_DEVICE_TAG; 656 ladev->device.common.version = AUDIO_DEVICE_API_VERSION_2_0; 657 ladev->device.common.module = const_cast<hw_module_t*>(module); 658 ladev->device.common.close = legacy_adev_close; 659 660 ladev->device.init_check = adev_init_check; 661 ladev->device.set_voice_volume = adev_set_voice_volume; 662 ladev->device.set_master_volume = adev_set_master_volume; 663 ladev->device.get_master_volume = adev_get_master_volume; 664 ladev->device.set_mode = adev_set_mode; 665 ladev->device.set_mic_mute = adev_set_mic_mute; 666 ladev->device.get_mic_mute = adev_get_mic_mute; 667 ladev->device.set_parameters = adev_set_parameters; 668 ladev->device.get_parameters = adev_get_parameters; 669 ladev->device.get_input_buffer_size = adev_get_input_buffer_size; 670 ladev->device.open_output_stream = adev_open_output_stream; 671 ladev->device.close_output_stream = adev_close_output_stream; 672 ladev->device.open_input_stream = adev_open_input_stream; 673 ladev->device.close_input_stream = adev_close_input_stream; 674 ladev->device.dump = adev_dump; 675 676 ladev->hwif = createAudioHardware(); 677 if (!ladev->hwif) { 678 ret = -EIO; 679 goto err_create_audio_hw; 680 } 681 682 *device = &ladev->device.common; 683 684 return 0; 685 686 err_create_audio_hw: 687 free(ladev); 688 return ret; 689 } 690 691 static struct hw_module_methods_t legacy_audio_module_methods = { 692 open: legacy_adev_open 693 }; 694 695 struct legacy_audio_module HAL_MODULE_INFO_SYM = { 696 module: { 697 common: { 698 tag: HARDWARE_MODULE_TAG, 699 module_api_version: AUDIO_MODULE_API_VERSION_0_1, 700 hal_api_version: HARDWARE_HAL_API_VERSION, 701 id: AUDIO_HARDWARE_MODULE_ID, 702 name: "LEGACY Audio HW HAL", 703 author: "The Android Open Source Project", 704 methods: &legacy_audio_module_methods, 705 dso : NULL, 706 reserved : {0}, 707 }, 708 }, 709 }; 710 711 }; // extern "C" 712 713 }; // namespace android_audio_legacy 714
最新发布
07-15
<think>嗯,用户的问题是关于解析LegacyCameraProviderImpl_2_4类中的initialize方法,特别是hw_get_module和mModule->init的作用,以及err值的意义。我需要结合用户提供的引用内容来回答这个问题。 首先,用户提到了引用[1],里面有hw_get_module函数,参数是CAMERA_HARDWARE_MODULE_ID,这应该是获取相机硬件模块的入口结构体。这个函数的作用可能类似于动态加载硬件模块,获取模块的句柄或者结构体指针。根据Android HAL层的知识,hw_get_module通常用于加载硬件模块,比如相机、传感器等,返回对应的hw_module_t结构体。 接下来,用户提到mModule->init,这里可能是指hw_module_t结构体中的init函数指针。引用[1]中的step1可能指的是初始化步骤,所以init函数的作用应该是初始化硬件模块,比如分配资源、配置硬件参数等。 然后,关于err变量,用户提供的引用中没有直接提到,但通常在C/C++中,错误码err可能用于表示函数执行的结果,比如0表示成功,负数表示错误。需要结合具体的系统错误码来解释不同的err值含义,比如-ENOENT表示模块未找到,-EINVAL表示参数无效等。 用户还引用了其他几个代码片段,比如引用[2]中的函数指针初始化和循环调用,这可能与模块初始化时的函数调用流程有关。引用[3]提到了media_entity结构体,可能和相机模块中的媒体实体有关,但不确定是否直接相关。引用[4]中的线程栈初始化可能与模块初始化的上下文有关,但需要更多的上下文来确定。 需要确认LegacyCameraProviderImpl_2_4类在Android相机HAL中的角色。通常,CameraProvider负责管理相机的硬件模块,包括初始化和提供相机服务。initialize方法可能是在启动时加载相机硬件模块并初始化。 总结一下,hw_get_module的作用是加载相机硬件模块,获取其结构体;mModule->init则是调用该模块的初始化函数,进行硬件相关的设置。err变量用于捕获这两个步骤中的错误,不同的错误码对应不同的问题,比如模块加载失败或初始化失败。 可能需要进一步查阅Android HAL层关于相机模块的具体实现,确保hw_get_module和init函数的参数和返回值准确。另外,需要确认LegacyCameraProviderImpl_2_4的上下文,是否涉及多线程或资源管理,但根据现有引用,可能主要涉及模块加载和初始化。</think>### LegacyCameraProviderImpl_2_4::initialize方法解析 #### 1. **`hw_get_module`的作用** 该函数用于加载Android硬件抽象层(HAL)中的相机模块。通过参数`CAMERA_HARDWARE_MODULE_ID`(即字符串"camera")匹配目标模块,返回对应的`hw_module_t`结构体指针[^1]。 - **参数意义**:`CAMERA_HARDWARE_MODULE_ID`是硬件模块的唯一标识符,确保加载正确的相机驱动。 - **底层逻辑**:系统会在`/vendor/lib/hw/`等路径下搜索名为`camera.<device_name>.so`的动态库,并提取模块入口。 #### 2. **`mModule->init`的作用** `mModule`是`hw_module_t`类型的指针,`init`是其成员函数指针,负责初始化硬件模块的配置和资源分配。 - **典型行为**:可能包括打开设备节点、注册回调函数、初始化传感器参数等。 - **参数传递**:若`init`函数需要参数,通常为`hw_module_t`自身指针(即`mModule`),例如: ```c int (*init)(const struct hw_module_t* module); ``` #### 3. **`err`值的意义** `err`表示函数执行状态,遵循Linux错误码规范: - **`0`**:成功(无错误) - **`-ENOENT`**:模块未找到(如硬件驱动文件缺失) - **`-EINVAL`**:参数无效(例如传入空指针) - **`-EPERM`**:权限不足(如无法访问设备节点) #### 4. **initialize方法整体逻辑** 1. **加载模块**:通过`hw_get_module`获取相机硬件模块。 2. **初始化模块**:调用`mModule->init`完成硬件配置。 3. **错误处理**:若`err`非0,可能触发日志输出或回滚操作。 ```cpp // 伪代码示例 int LegacyCameraProviderImpl_2_4::initialize() { err = hw_get_module(CAMERA_HARDWARE_MODULE_ID, &mModule); if (err != 0) { ALOGE("Failed to load camera module"); return err; } err = mModule->init(mModule); // 传递模块自身指针 if (err != 0) { ALOGE("Module initialization failed"); } return err; } ``` #### 5. **与引用内容的关联** - 引用[1]解释了硬件模块加载机制,与`hw_get_module`直接相关。 - 引用[4]中线程栈初始化类似模块初始化的资源准备阶段。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值