Sporadically, the odm_vhal or webrtc_vhal failed in
- modifying the vehicle property value
- accessing the vehicle property value
even if the the VMAL service implements Anbox-specific HIDL interface.
See the following log
```
11-28 05:08:28.936 185 185 I vhal-adapter: main: Starting VHAL adapter
11-28 05:08:28.936 35 35 I servicemanager: Could not find android.hardware.automotive.vehicle.IVehicle/default in the VINTF manifest.
11-28 05:08:28.936 185 185 D vendor.canonical.vhal.adapter-service: AIDL VHAL service, descriptor: android.hardware.automotive.vehicle.IVehicle/default is not declared, maybe HIDL VHAL is used instead?
11-28 05:08:28.937 185 185 E cutils-trace: Error opening container trace socket: No such file or directory (2)
11-28 05:08:28.937 36 36 I hwservicemanager: Since device.canonical.numbat.hal.vehicle@1.0::IVehicle/default is not registered, trying to start it as a lazy HAL.
11-28 05:08:28.937 185 185 I vendor.canonical.vhal.adapter-service: a non-writable vehicle property value cannot be modified due to unimplemented Anbox VHAL interfaces
11-28 05:08:28.941 182 182 I HidlServiceManagement: Registered android.hardware.automotive.vehicle@2.0::IVehicle/default
11-28 05:08:28.941 148 148 I ServiceManager: Waiting for service 'media.metrics' on '/dev/binder'...
11-28 05:08:28.943 182 182 I HidlServiceManagement: Registered device.canonical.numbat.hal.vehicle@1.0::IVehicle/default
11-28 05:08:28.943 182 182 I vendor.canonical.vehicle@2.0-service: Ready
11-28 05:08:28.954 106 106 I Zygote : Preloading classes...
```
The service `device.canonical.numbat.hal.vehicle@1.0::IVehicle/default` was registered immediately after the VHAL adapter detected the presence of a VHAL service implementing the Anbox-specific HIDL interface. This caused the VHAL adapter to use the default VHAL client obtained from IVhalClient::tryCreate() (a vendor-available VHAL client) rather than the hidl client.