Android HIDL概述与绑定模式的实现

2024-01-25 16:20
文章标签 实现 android 模式 概述 绑定 hidl

本文主要是介绍Android HIDL概述与绑定模式的实现，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

 一、前言

Android O(8.0) 版本之后，底层实现有了比较大的变化，最显著的一个方面就是 HIDL 机制的全面实施。本文对于理解系统源码中 Gnss、Usb、Camera 等模块的工作原理有极大帮助。

二、HIDL 设计目的

在 Android O(8.0) 之前系统的升级牵扯多方协作，极为麻烦，HIDL机制的推出就是将 framework 与 hal 层分开，使得框架部分可以直接被覆盖、更新，而不需要重新对 HAL 进行编译，这样在系统升级时，OEM 厂商 跳过 SoC 厂商，先对 framework 进行升级。

2.1、8.0 之前

framework 与 hal 紧紧耦合存在于 system.img 中，因此在版本升级时需要: OEM 厂商适配 framework ，SoC厂商 适配 hal， 之后将修改打包到 system.img，生成 OTA 升级包，推送到手机进行 OTA 升级

2.2、8.0 之后

framework 与 hal 进行了解耦， framework 存在于 system.img，hal 存在于vendor.img，进行版本升级时，分为两次升级:

  • framework升级 ： OEM 厂商适配 framework，将修改打包到 system.img， 生成OTA 升级包，推送到手机进行 OTA 升级(framework 发生改变，hal 层未变)。
  • hal升级 ：SoC 厂商适配 hal， 将修改打包到 vendor.img, 生成OTA 升级包，推送到手机进行OTA升级(framework发生改变，hal 层发生改变)。

三、HIDL机制演进

3.1 老版本 Framework 与 HAL 的通信框架

正如上述所言，旧版的系统架构中， Android Framework 层与 Hal 层是打包成一个 system.img 的，且 Framework 与 hal 层之间是紧密耦合的，通过链接的方式使用相应的硬件 so 库。它们之间的架构一般有如下两种方式：

3.2 HIDL 类型介绍

为了解决两者之间这种紧耦合所带来的弊端，google 引入 HIDL 来定义 Framework 与 HAL 之间的接口，可以用下图来描述：

事实上虽然 google 推出了这种机制，但是很多厂商没有很快的跟上节奏，因此为了向前兼容， google 定义了三种类型：

  • ① 是 Treble Project 之前使用的实现架构，使用的是传统 HAL 和旧版 HAL
  • ② 直通模式，passthrough mode。如图所示，Framework 和 HAL 层工作在同一个进程当中，下面的 HAL 是使用 HIDL 封装后的库，是直通式 HAL。这些库文件也可用于 ③ 绑定模式
  • ③ 绑定模式，binderized mode。是直通式 HAL binder 化，变为绑定式 HAL。Framework 和 HAL 层工作在不同的进程，之间通过 Binder 进行 IPC
  • ④ 纯绑定式。相对于 ③ 来说，绑定式 HAL 中并不包含直通式 HAL，因此称为纯绑定式

上述可总结为：

上述介绍参考此处

四、HIDL实现

绑定模式 是 google 为了向前兼容而定义的一种类型，且 Android 8.0 及后续版本的设备都必须只支持这种模式。这种模式下 Framework 与 Hal 分别位于不同的进程中，其实从具体实现来讲这种模式也更应该被称为 Binder 化的直通式。下面将通过这种方式实现一个具有加减乘除功能的 HIDL 服务，该服务的名称为 MyTest

4.1 创建IMyTest.hal文件

在系统源码中的 hardware/interfaces 目录下有很多的 HIDL，我们仿照其他 HIDL 来创建自己的目录，在源码根目录执行以下命令：

mkdir -p hardware/interfaces/my_test/1.0/default

之后创建 IMyTest.hal 文件：

touch hardware/interfaces/my_test/1.0/IMyTest.hal

这里定义了四种基本的运算：加、减、乘、除，这是上层调用 HAL 的入口，该文件内容如下：

package android.hardware.my_test@1.0;interface IMyTest{//加法add(uint32_t a,uint32_t b) generates (uint32_t result);//减法sub(uint32_t a,uint32_t b) generates (uint32_t result);//乘法mul(uint32_t a,uint32_t b) generates (uint32_t result);//除法div(uint32_t a,uint32_t b) generates (uint32_t result);};

4.2 使用hidl-gen生成HAL相关文件

Google帮我们提供了 hidl-gen 工具来生成 HAL 层相关的代码框架和代码实例，这样子我们只需要关心实现部分。在源码根目录执行以下命令：

source build/envsetup.sh
lunch xxx
PACKAGE=android.hardware.my_test@1.0
LOC=hardware/interfaces/my_test/1.0/default/
make hidl-gen
hidl-gen -o $LOC -Lc++-impl -randroid.hardware:hardware/interfaces -randroid.hidl:system/libhidl/transport $PACKAGE
hidl-gen -o $LOC -Landroidbp-impl -randroid.hardware:hardware/interfaces -randroid.hidl:system/libhidl/transport $PACKAGE

之后执行 update-makefiles.sh 脚本来为 HIDL 生成对应的 Android.bp 文件，源码根目录执行：

./hardware/interfaces/update-makefiles.sh

现在我们的工程目录结构如下：

接下来我们需要再创建两个文件：

touch hardware/interfaces/my_test/1.0/default/android.hardware.my_test@1.0-service.rc
touch hardware/interfaces/my_test/1.0/default/service.cpp

最终我们的工程目录结构如下：

4.3 调用流程分析

上述过程已经将 HIDL 服务所需要的文件创建完成，虽然其中很多文件还没有具体实现，我们先放在一边，先来对整体的调用流程及各个文件的作用略作说明：

Application上层应用
JNI指 framework 层，getService 获取 hal 层 service
android.hardware.my_test@1.0.so接口库，由hardware/interfaces/my_test/1.0/Android.bp 通过 IMyTest.hal 生成，这样只要这个接口库不变，那么 framework 的更新和 hal 层就隔绝开了
android.hardware.my_test@1.0-impl.so实现库，上层应用的最终调用
mytest-hal-serviceservice的名称
android.hardware.my_test@1.0-service.rc设备开机时通过解析 rc 文件启动此服务

 4.4 接口库生成

android.hardware.my_test@1.0.so 由hardware/interfaces/my_test/1.0/Android.bp 通过 IMyTest.hal 生成，该 Android.bp 文件是在上面一系列命令执行之后生成，而接口库是当我们最终执行编译模块时生成，可以说这个过程不需要我们手动参与。

4.5 实现库生成

由 hardware/interfaces/galaxy_one/1.0/default/Android.bp 在最后模块编译时通过 GalaxyOne.cpp 生成，

Android.bp 内容如下：

// FIXME: your file license if you have onecc_library_shared {// FIXME: this should only be -impl for a passthrough hal.// In most cases, to convert this to a binderized implementation, you should:// - change '-impl' to '-service' here and make it a cc_binary instead of a//   cc_library_shared.// - add a *.rc file for this module.// - delete HIDL_FETCH_I* functions.// - call configureRpcThreadpool and registerAsService on the instance.// You may also want to append '-impl/-service' with a specific identifier like// '-vendor' or '-<hardware identifier>' etc to distinguish it.name: "android.hardware.my_test@1.0-impl",relative_install_path: "hw",// FIXME: this should be 'vendor: true' for modules that will eventually be// on AOSP.proprietary: true,srcs: ["MyTest.cpp",],shared_libs: [    //可以添加需要的库"liblog","libhidlbase","libhidltransport","libhwbinder","libutils","android.hardware.my_test@1.0",],
}

4.6 MyTest.cpp的实现

实现库是通过 MyTest.cpp 编译生成的，现在完善 MyTest.h 和 MyTest.cpp

MyTest.h

Binder化直通式，同样需要将 HIDL_FETCH_XXX 打开

// FIXME: your file license if you have one#pragma once#include <android/hardware/my_test/1.0/IMyTest.h>
#include <hidl/MQDescriptor.h>
#include <hidl/Status.h>
#include <log/log.h>namespace android::hardware::my_test::V1_0::implementation {using ::android::hardware::hidl_array;
using ::android::hardware::hidl_memory;
using ::android::hardware::hidl_string;
using ::android::hardware::hidl_vec;
using ::android::hardware::Return;
using ::android::hardware::Void;
using ::android::sp;struct MyTest : public V1_0::IMyTest {// Methods from ::android::hardware::my_test::V1_0::IMyTest follow.Return<uint32_t> add(uint32_t a, uint32_t b) override;Return<uint32_t> sub(uint32_t a, uint32_t b) override;Return<uint32_t> mul(uint32_t a, uint32_t b) override;Return<uint32_t> div(uint32_t a, uint32_t b) override;// Methods from ::android::hidl::base::V1_0::IBase follow.};// FIXME: most likely delete, this is only for passthrough implementations
extern "C" IMyTest* HIDL_FETCH_IMyTest(const char* name);}  // namespace android::hardware::my_test::V1_0::implementation

注意，hidl-gen生成的 MyTest.h 的代码中，命名空间不对；将android::hardware::my_test::implementation 改成 android::hardware::my_test::V1_0::implementation

MyTest.cpp

// FIXME: your file license if you have one#include "MyTest.h"namespace android::hardware::my_test::V1_0::implementation {// Methods from ::android::hardware::my_test::V1_0::IMyTest follow.
Return<uint32_t> MyTest::add(uint32_t a, uint32_t b) {// TODO implementuint32_t result = a + b;ALOGE("MyTest::add  a = %d,b = %d,result = %d",a,b,result);return uint32_t {};
}Return<uint32_t> MyTest::sub(uint32_t a, uint32_t b) {// TODO implementuint32_t result = a - b;ALOGE("MyTest::sub  a = %d,b = %d,result = %d",a,b,result);return uint32_t {};
}Return<uint32_t> MyTest::mul(uint32_t a, uint32_t b) {// TODO implementuint32_t result = a * b;ALOGE("MyTest::mul  a = %d,b = %d,result = %d",a,b,result);return uint32_t {};
}Return<uint32_t> MyTest::div(uint32_t a, uint32_t b) {// TODO implementuint32_t result = a / b;ALOGE("MyTest::div  a = %d,b = %d,result = %d",a,b,result);return uint32_t {};
}// Methods from ::android::hidl::base::V1_0::IBase follow.IMyTest* HIDL_FETCH_IMyTest(const char* /* name */) {ALOGE("my_test service init success....");return new MyTest();
}
//
}  // namespace android::hardware::my_test::V1_0::implementation

同样需要更改命名空间

4.7 编译

现在除了需要的 rc 文件没有补充、mytest-hal-service 服务没有生成外其余均已配置好了，现在进行编译生成对应的库。进入根目录下执行如下命令：(注意是在刚刚执行过的 source build/envsetup.sh 和 lunch 的窗口下编译，若是新窗口则需要重新执行这两条命令)

mmm  hardware/interfaces/my_test/1.0

编译成功后会在 out\target\product\xxxxxxx\vendor\lib64\hw 下生成 android.hardware.my_test@1.0-impl.so；在 out\target\product\xxxxxxx\system\lib64 下生成 android.hardware.my_test@1.0.so；

4.8 生成Service

接下来我们需要生成对应的 service 可执行文件，这个过程一共分为三步：

1.在 /default 下的 Android.bp 文件中追加如下内容

cc_binary {name: "android.hardware.my_test@1.0-service",defaults: ["hidl_defaults"],relative_install_path: "hw",vendor: true,srcs: ["service.cpp"],init_rc: ["android.hardware.my_test@1.0-service.rc"],shared_libs: ["liblog","libhidlbase","libhidltransport","libhwbinder","libutils","android.hardware.my_test@1.0",],
}

2.补充 service.cpp 

defaultPassthroughServiceImplementation 会帮我们自动注册服务；

#define LOG_TAG "android.hardware.my_test@1.0-service"#include <android/hardware/my_test/1.0/IMyTest.h>
#include <hidl/LegacySupport.h>
#include "MyTest.h"// Generated HIDL files
using android::hardware::my_test::V1_0::IMyTest;
using android::hardware::my_test::V1_0::implementation::MyTest;using android::hardware::defaultPassthroughServiceImplementation;
using android::hardware::configureRpcThreadpool;
using android::hardware::joinRpcThreadpool;int main() {return defaultPassthroughServiceImplementation<IMyTest>();
}

3.补充 rc 文件

这里的 mytest-hal-service 相当于这个服务的别名

service mytest-hal-service /vendor/bin/hw/android.hardware.my_test@1.0-serviceclass haluser systemgroup system

再次在根目录执行如下命令：

mmm  hardware/interfaces/my_test/1.0

完成之后就会得到如下二进制可执行文件：

out\target\product\xxxxxxx\vendor\bin\hw\android.hardware.my_test@1.0-service

4.9 编写测试Client 

经过一系列过程之后，我们得到了三个产物：

1、android.hardware.my_test@1.0.so
2、android.hardware.my_test@1.0-impl.so
3、android.hardware.my_test@1.0-service

接下来模拟一个客户端来测试调用；在 default 目录下创建 test 目录，并新建 client.cpp、Android.bp 文件；创建好后工程目录如下：

client.cpp内容：

#include <android/hardware/my_test/1.0/IMyTest.h>
#include <hidl/Status.h>
#include <log/log.h>using android::sp;
using android::hardware::my_test::V1_0::IMyTest;
using android::hardware::Return;int main(){android::sp<IMyTest> service = IMyTest::getService();if (service == nullptr) {ALOGD("faile to get my_test service......");return -1;}ALOGE("success to get my_test service.....");uint32_t addResult = service->add(3,4);ALOGE("my_test service add: result = %d",(int)addResult);uint32_t subResult = service->sub(8,3);ALOGE("my_test service sub: result = %d",(int)subResult);uint32_t mulResult = service->mul(3,8);ALOGE("my_test service mul: result = %d",(int)mulResult);uint32_t divResult = service->div(8,2);ALOGE("my_test service div: result = %d",(int)divResult);return 0;
}

Android.bp内容：

cc_binary {name: "my_hidl_test",    //表示生成的 client 名称srcs: ["client.cpp"],shared_libs: ["liblog","android.hardware.my_test@1.0","libhidlbase","libhidltransport","libhwbinder","libutils",],
}

根目录执行 mmm  hardware/interfaces/my_test/1.0 编译工程，成功后可在 out\target\product\xxxxxxx\system\bin 目录下找到 my_hidl_test

五、验证

5.1 将产物推入机器

现在我们一共得到 4 个产物，使用 adb 命令将其 push 到车机对应目录下：

android.hardware.my_test@1.0.so             ====》     /vendor/lib64
android.hardware.my_test@1.0-impl.so     ====》     /vendor/lib64/hw
android.hardware.my_test@1.0-service     ====》     /vendor/bin/hw
my_hidl_test                                                ====》     /system/bin

5.2 修改manifest.xml

HIDL 想要被 framework 获取使用还需要在 manifest.xml 中注册，该文件在车机 /vendor/etc/vintf/ 目录下（不同厂商可能不同，以实际情况为准），添加下面的内容：

<hal format="hidl"><name>android.hardware.my_test</name><transport>hwbinder</transport><version>1.0</version><interface><name>IMyTest</name><instance>default</instance></interface><fqname>@1.0::IMyTest/default</fqname></hal>
<hal format="hidl">

5.3 运行Service

手动后台运行

adb root
adb remount
./vendor/bin/hw/android.hardware.my_test@1.0-service &

5.4 运行client

./system/bin/my_hidl_test &

运行后查看系统日志，有如下内容则成功：

01-01 00:01:58.127 13377 13377 E my_hidl_test: success to get my_test service.....
01-01 00:01:58.127 11110 11110 E android.hardware.my_test@1.0-service: MyTest::add  a = 3,b = 4,result = 7
01-01 00:01:58.128 13377 13377 E my_hidl_test: my_test service add: result = 0
01-01 00:01:58.128 11110 11110 E android.hardware.my_test@1.0-service: MyTest::sub  a = 8,b = 3,result = 5
01-01 00:01:58.128 13377 13377 E my_hidl_test: my_test service sub: result = 0
01-01 00:01:58.128 11110 11110 E android.hardware.my_test@1.0-service: MyTest::mul  a = 3,b = 8,result = 24
01-01 00:01:58.128 13377 13377 E my_hidl_test: my_test service mul: result = 0
01-01 00:01:58.129 11110 11110 E android.hardware.my_test@1.0-service: MyTest::div  a = 8,b = 2,result = 4
01-01 00:01:58.129 13377 13377 E my_hidl_test: my_test service div: result = 0

这篇关于Android HIDL概述与绑定模式的实现的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/643841。

相关文章

水位雨量在线监测系统概述及应用介绍

水位雨量在线监测系统概述及应用介绍

在当今社会，随着科技的飞速发展，各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中，水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术，其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成，形成了一个完整的闭环系统。 数据采集单元：这是系统的“眼睛”，
阅读更多...
hdu1043（八数码问题，广搜 + hash（实现状态压缩） ）

hdu1043（八数码问题，广搜 + hash（实现状态压缩） ）

利用康拓展开将一个排列映射成一个自然数，然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu
阅读更多...
【C++】_list常用方法解析及模拟实现

【C++】_list常用方法解析及模拟实现

相信自己的力量，只要对自己始终保持信心，尽自己最大努力去完成任何事，就算事情最终结果是失败了，努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一：什么是list？ •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二：list常用接口 •🌰1.默认成员函数 🔥构造函数（⭐） 🔥析构函数 •🌰2.list对象
阅读更多...
【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯，先赞后看哦~🎈🎈 🏆 作者简介：景天科技苑 🏆《头衔》：大厂架构师，华为云开发者社区专家博主，阿里云开发者社区专家博主，CSDN全栈领域优质创作者，掘金优秀博主，51CTO博客专家等。 🏆《博客》：Python全栈，前后端开发，小程序开发，人工智能，js逆向，App逆向，网络系统安全，数据分析，Django，fastapi
阅读更多...
让树莓派智能语音助手实现定时提醒功能

让树莓派智能语音助手实现定时提醒功能

最初的时候是想直接在rasa 的chatbot上实现，因为rasa本身是带有remindschedule模块的。不过经过一番折腾后，忽然发现，chatbot上实现的定时，语音助手不一定会有响应。因为，我目前语音助手的代码设置了长时间无应答会结束对话，这样一来，chatbot定时提醒的触发就不会被语音助手获悉。那怎么让语音助手也具有定时提醒功能呢？ 我最后选择的方法是用threading.Time
阅读更多...
Android实现任意版本设置默认的锁屏壁纸和桌面壁纸（两张壁纸可不一致）

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸（两张壁纸可不一致）

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸： 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  （注意不能是bmp格式） 替换默认锁屏壁纸： 将图片资源放入vendo
阅读更多...
在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式（Singleton Pattern） 确保一个类只有一个实例，并提供一个全局访问点。 示例代码： class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)
阅读更多...
C#实战|大乐透选号器[6]：实现实时显示已选择的红蓝球数量

C#实战|大乐透选号器[6]：实现实时显示已选择的红蓝球数量

哈喽，你好啊，我是雷工。 关于大乐透选号器在前面已经记录了5篇笔记，这是第6篇； 接下来实现实时显示当前选中红球数量，蓝球数量； 以下为练习笔记。 01 效果演示 当选择和取消选择红球或蓝球时，在对应的位置显示实时已选择的红球、蓝球的数量； 02 标签名称 分别设置Label标签名称为：lblRedCount、lblBlueCount
阅读更多...
Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

技术背景 好多开发者需要遴选Android平台RTSP直播播放器的时候，不知道如何选的好，本文针对常用的方案，做个大概的说明： 1. 使用VLC for Android VLC Media Player（VLC多媒体播放器），最初命名为VideoLAN客户端，是VideoLAN品牌产品，是VideoLAN计划的多媒体播放器。它支持众多音频与视频解码器及文件格式，并支持DVD影音光盘，VCD影
阅读更多...
Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注，收藏不迷路💖 Kubernetes的PodSecurityPolicy（PSP）是一个关键的安全特性，它在Pod创建之前实施安全策略，确保P
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2