This CL demonstrates how IVehicleHardware layer can batch property
update events for all continuous properties subscribed
at the same interval. For example, previously, 4 areas for tire
pressure, despite subscribed with the same interval, will generate
4 property update events through 4 binder calls. Since they are
updated at the same time, all the 4 events can be sent through one
binder call.
Note that this is different from the batching done at DefaultVehicleHal
side where the property events are put into a queue for batching. If
IVehicleHardware layer can provides batching, then we can avoid the
extra latency introduced by batching in DefaultVehicleHal layer.
In order to achieve batching, this CL adds several functions to
VehiclePropertyStore that operates on a list of values. Note that
VehiclePropertyStore is still backward compatible with this CL,
meaning that old APIs are not affected. But in order to achieve
better performance, caller can migrate to the newer APIs.
Test: atest FakeVehicleHardwareTest VehicleHalVehicleUtilsTest
Bug: 314850840
Change-Id: I94a13d3ed2b90aede4d627f73ce2f2828bb3e740
Introduce VehiclePropertyStore.getPropConfig that returns a copy of
the config instead of a constant pointer. If the internal map is updated,
the pointer might become invalid, so it is safer to just return a copy.
We do not modify the existing API for backward compatibility.
Test: atest VehiclePropertyStoreTest
Bug: 308202443
Change-Id: I769866a09577cc69d25276349b7688cabcbc0c20
Previously the timestamp in property events might come from two
different sources. For property update events, the timestamp is
generated from VehicleHalServer. For getProperty request, the
timestamp is generated from EmulatedVehicleHal. This might cause
a getProperty request which returns an older value to have a newer
timestamp compared to the newer property update event. As a result,
the new property update event will be ignored by the client, which
should not be the case since the property is actually updated and
the client should get the update.
This causes flaky test cases if the client is try to subscribe, which
will cause a get property request for the initial value and the client
is changing the value, which will cause a new property update event at
the same time.
Test: atest android.hardware.automotive.vehicle@2.0-default-impl-unit-tests
Bug: 311219830
Change-Id: I78613b1de30624011bd90a5d0da244f0e3d67337
We should update the config count in the unit test for
ag/25331307.
Test: atest android.hardware.automotive.vehicle@2.0-default-impl-unit-tests
Bug: 310035422
Change-Id: I821e43ec7fda31007457821186cce7fd0bc4f9b6
We need to use a more accurate ratio of celsius to fahrenheit along
with better min/max temperature conversions so if a client sets the
value using standard conversion or using this table, they will produce
the same result.
Bug: 313720524
Test: atest CtsCarTestCases:CarPropertyManagerTest
Change-Id: I80a45962e7025c9c529381fd3522839f78bf413f
Make refreshTimestamp atomic in VehiclePropertyStore so that we
are sure the property value will not be updated after we read
the value out, but before we put the value with the new timestamp back.
Otherwise there is a slight chance that a property update will be
overwritten by the timestamp refresh operation.
Test: atest FakeVehicleHardwareTest
Bug: 308552957
Change-Id: I789257b4c75d8a4d19edeec31d01dc23776233ec
Backport Location Characterization property to ref HIDL VHAL. Define
a new backported property helper library for the backported constants.
Test: Build and verify the backported property can be accessed.
Bug: 310035422
Change-Id: I2b53f82707a45cd3a761d295e3fd2444ff5c82c8
Previously RecurrentTimer might not exit correctly if the mStopRequested
is set to true after we check for the value in the loop, but before
we start the wait. We will notify before we start waiting, causing the
wait never to return until timeout.
This CL guards updating mStopRequested with lock to make sure that it
must not change between our check and the wait.
After the fix we see no more flaky tests and decreased test execution
time since we will not wait for the next event to come before we end
the timer.
Test: atest android.hardware.automotive.vehicle@2.0-default-impl-unit-tests
Bug: 311757267
Change-Id: Iab1d72b954b4b02aa68e6fbbabcb97b572614d35
Guard the logic to update property value timestamp with lock so that
they will not overlap. Otherwise, it is possible that another op will
update the timestamp to a newer value, which causes this op to fail
the timestamp freshness check.
Test: atest --iterations 10 FakeVehicleHardwareTest#testSubscribe_enableVUR
Bug: 308552957
Change-Id: I8f7a6356ba65e4470e851e59c20bb1f678c2d467
