一般HIDL服务的调用者(client)和其是不在同一个进程中(process)中的,HIDL service一般提供的是硬件功能,而调用者(client)则是基于此硬件功能来实现特色功能的。此处假设HIDL-light service只提供控制具体led的开和关的硬件功能,client 则是实现led每1秒进行闪烁的特色功能。从上面的假设可知client需要连续调用HIDL-light service所提供的led控制接口,并且其间隔为1秒。如果HIDL-light service意外退出了,那么client也就无法实现该特色功能了,因此在client中是需要知道HIDL-light service的运行状态的。在HIDL框架中,像client这种常驻的调用者会注册死亡接收器(Death recipients),来解释该状态的。此处使用serviceModelClient作为该场景的实例。
1.Android.bpflagstaff@flagstaff-pc:~/aosp_r.lns/test/flagstaffTest$ cat hardware/interfaces/custom_hardware/1.0/serviceModelClient/Android.bp cc_binary { name: "serviceModelClient", vendor: true, srcs: [ "*.cpp", "src, char** ) { ... android::spmService = ICustomHardware::getService(); if (mService == nullptr) { LOG(ERROR)<<"Failed to get ICustomHardware instance of default"; return -1; } mChd = new CustomHardwareDeath(); Return ret = mService->linkToDeath(mChd, 0); joinRpcThreadpool(); mService->unlinkToDeath(mChd); return 1; }
实现步骤如下
a)获取ICustomHardware服务。
b)实例化 CustomHardwareDeath。
c)调用HIDL 接口linkToDeath注册CustomHardwareDeath。一个死亡接收器是支持处理多个HIDL-service的,其中cookie则是用来区分HIDL-service的,此处则用来计数死亡次数。
d)在client退出后,则要主动调用接口unlinkToDeath来释放之前注册的死亡回调。
generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service 02-05 18:08:57.245 2112 2112 E serviceModelClient: CustomHardwareDeath:[cookie]0 generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service 02-05 18:08:59.371 2112 2112 E serviceModelClient: CustomHardwareDeath:[cookie]1 generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service 02-05 18:09:02.917 2112 2112 E serviceModelClient: CustomHardwareDeath:[cookie]2
从上面实验结果可见在每一次HIDL-service死亡后,client中会收到相应的通知,并且试图恢复。
5.完整代码serviceModelClient source code
https://gitee.com/solo-king/android-rhidl-about/tree/master/hardware/interfaces/custom_hardware/1.0/serviceModelClient
另外如果有问题,欢迎留言或者email(836190520@qq.com)我,技术升级在于交流~~
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)