AndroidR为客户端添加HIDL服务的死亡通知回调

  一般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.bp

flagstaff@flagstaff-pc:~/aosp_r.lns/test/flagstaffTest$ cat hardware/interfaces/custom_hardware/1.0/serviceModelClient/Android.bpcc_binary { name: "serviceModelClient", vendor: true, srcs: [ "*.cpp", "src, char** ) { ...android::sp mService = 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来释放之前注册的死亡回调。

4.运行结果

generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service02-05 18:08:57.245 2112 2112 E serviceModelClient: CustomHardwareDeath:[cookie]0generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service02-05 18:08:59.371 2112 2112 E serviceModelClient: CustomHardwareDeath:[cookie]1generic_x86_64:/ # killall flagstaff.hardware.custom_hardware@1.0-service02-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)我，技术升级在于交流~~