Android R(11)为客户端添加HIDL服务的死亡通知( Death recipients)回调(九)

  一般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作为该场景的实例。

flagstaff@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::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来释放之前注册的死亡回调。

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中会收到相应的通知，并且试图恢复。

serviceModelClient source code

https://gitee.com/solo-king/android-rhidl-about/tree/master/hardware/interfaces/custom_hardware/1.0/serviceModelClient

  另外如果有问题，欢迎留言或者email(836190520@qq.com)我，技术升级在于交流~~