It's possible to get an onBinderDied callback after a call to
AIBinder_unlinkToDeath() so we can't delete the objects in callbacks_
until we are done using the void* cookie.
Handling the cleanup in onBinderUnlinked will handle the case where we
manually unlink it as well as the case where it's unlinked due to death.
Test: atest VtsHalHealthTargetTest
Bug: 319210610
Change-Id: Iee4783217cc88134af6de0fe66128684ca984dba
If LinkedCallback::Make returns nullptr, do not put it
in Health::callback_. Otherwise, OnHealthInfoChanged
crashes later because the linked callback objects are
not null checked before accessing.
Test: android.hardware.health-service.aidl_fuzzer (with
a special corpus)
Fixes: 289599278
Change-Id: I8bad41dbcfbefeb54744059baffd4eef1ae7ec42
Compared to the HIDL HAL implementation,
- libhealthloop (and the HealthLoop class) is kept
- Create libhealthaidlimpl that replaces libhealth2impl. Fork the implementation because
libhealth2impl is highly coupled with HIDL’s design rationale. This includes forking:
- HalHealthLoop
- Health implementation
- Combine the passthrough Health and hwbinder BinderHealth classes into the AIDL
implementation of Health. This is because AIDL does not support passthrough transport.
Separating the implementation for the two transports in HIDL does not make sense for AIDL.
- In HIDL, a BinderHealth is a HalHealthLoop which is composed of a (passthrough)
Health implementation. As a result of this change, in AIDL, a Health implementation
is a HalHealthLoop, which associates with the Health implementation itself with a raw
pointer.
- hidl_death_recipient becomes ScopedAIBinder_DeathRecipient
- Callback becomes LinkedCallback
Test: manual
Bug: 177269435
Change-Id: I76e914117ce09b218cdb9d655f2135d29bb629ae
