C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Merged-In: I78d64ea2b7df3f2bd3b8503aa553a0523b20d711
Change-Id: I8a7ff4b025ac693398b79ad5f16687afe3a4c5a9
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
C++20 will require members in a designated initializer to be in order
unlike C99.
This snuck in because I haven't upgraded the platform toolchain yet.
Bug: 139945549
Test: mm
Change-Id: Id121ecd46b7e53f5dd7b4a32daae0594d851d0e5
Merged-in: Ica2844a213467e41d9b6a8955f1750692da8b444
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Bound the pending write events queue to a large amount of events in
total (100,000) so that we do not have out of memory crashes when the
sensors framework locks up. Events are 80B of memory each. So this
change caps are pending writes event queue to 8MB of memory.
Bug: 143302327
Test: atest android.hardware.sensors@2.0-halproxy-unit-tests &&
vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions --module VtsHalSensorsV2_0Target
Change-Id: I5d0a7f382e3f61fbbe2c74b5c9cf13560432b84c
The multihal framework is a HAL interface for the sensors framework that
allows multiple vendors to package their HAL implementation into a
subHAL dynamic library that will be loaded and used to pass on method
calls to the appropriate subHAL. The HalProxy object, that will act as
the main proxy sensors wrapper for the multiHAL handles writing sensor
events to the event FMQ and wakelock acquisition and releasing via a
callback object it passes to the subHALs.
In order to turn your HAL 2.0 executable into a subHAL to be used by the
multiHAL, implement the Return<Result> initialize(sp<HalProxyCallback>&
callback) method of the ISensorsSubHal derived class. Implement the
ISensorsSubHal* sensorsHalGetSubHal(uint32_t* version)method and have it
return a pointer to your subHAL object. Build this into a dynamic
library and list its filename under /vendor/etc/sensors/hals.conf.
Squashed commits:
07b442e96 (refs/published/mh2_2) MH2 | Write processedEvents instead of
original events.
b38f2e251 Merge "MH2 | Check that subhal index is in range"
d38f99474 Merge "MH2 | Implement debug method of HalProxy"
bf46132fe (refs/published/mh2_4, mh2_4) MH2 | Implement debug method of
HalProxy
1de5bb334 MH2 | Fix wakelock name
e07215347 (refs/published/mh2_3, mh2_3) MH2 | Check that subhal index is
in range
336c1c71e MH2 | Add restart logic in HalProxy::initialize method.
731d7125b MH2 | Change rc file to more appropriate settings
f09465d11 MH2 | Add makeFMQ helpers to HalProxy_test
75cc7bf2f MH2 | Implement wakelock processing thread
e93fdf9a4 MH2 | Implement dynamic sensors callbacks on HalProxy
82b84148c Remove libhwbinder/libhidltransport deps
d45e49b4b Merge "MH2 | Implement pending writes thread"
597142692 MH2 | Implement pending writes thread
db23aa825 MH2 | Implement direct channel and direct report methods
83e4370ae MH2 | Implement injectSensorData method of HalProxy
d0cd57d4c MH2 | Implement ScopeWakelock ctor and dtor
537c0274b MH2 | Add rough proxy callback postEvents method
f97a3f357 Multihal 2.0 - Small tweaks to sensorHandle handling
7a7235461 MultiHal 2.0 - setOperationMode and init direct channel flags
dc7a8e789 MultiHal 2.0 - Get sensors list from subhals
4b4c7b744 MultiHal 2.0 - activate, batch, flush methods of HalProxy
1638531df MultiHal 2.0 - proxying api calls helper methods
aacbf9485 Set up shell to use for unit tests
2879067dd Multihal 2.0 - Implement SubHal discovery
c34e6683b Add a sub-HAL implementation for testing multi-HAL
a689f8a65 Add skeleton for multihal 2.0
Bug: 136511617
Test: atest android.hardware.sensors@2.0-halproxy-unit-tests &&
vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions --module VtsHalSensorsV2_0Target
Change-Id: Ibe92d40c92b70848526b0e941bbcffbaf81ffaf2
Ensures it can access /dev/uinput in Android Q, sepolicy permitting.
Bug: 142105193
Test: confirm hall sensor works again on marlin
Change-Id: I585c32d4da4bdc0917068e4d81adeca43d257e56
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I075670b64eebbbbd6a6ae0e84ad51bf1c6f5ba36
VTS should ignore the reportToken returned by configDirectReport when it
passes in RateLevel::STOP.
Bug: 138758242
Test: run direct channel tests on device using 2.0 HAL
Change-Id: I07e789157e051ceab488a61e856f17d50f435072
If a sensor doesn't support a particular memory type for direct
reporting, then registerChannel will return an invalid channel handle.
When this handle is used in configureDirectReport, it will return
BAD_VALUE and when used in unregisterDirectReport, it will return OK.
Currently, the VTS tests assert it will return INVALID_OPERATION, but
that will only happen if the entire HAL doesn't support direct
reporting instead of a single sensor not supporting a certain memory
type.
Bug: 138758242
Test: Run VTS and verify DirectChannel* tests now pass
Change-Id: Ifba4262b68ec0c4ca6921dad40a03e0a52088d28
One Shot sensors have minDelay set to -1. Force the minDelay to be 0 in
the VTS test to avoid errors from invalid parameter
Bug: 138758242
Test: Run Batch test manually VtsHalSensorsV2_0TargetTest --gtest_filter=SensorsHidlTest.Batch
Change-Id: Ib2287f6f11502c10d346f5e7216c5f31d585edf9
This test was making a couple of false assumptions which were causing it
to fail. The fixes are related to the following assertions:
1. One-shot sensors do not report an initial event.
2. Special sensors may not report an initial event.
2. Some on-change sensors may not report an initial event.
The test now only checks for a stale event if the sensor reports an
initial event consistently.
Bug: 138758242
Test: ran on C2 DVT; only fails due to an improperly configured sensor
Change-Id: I83f0cb2f6e878244f3d94ae77f64bb8ed2f78e0b
As VTS connects to the IMapper and IAllocator HALs directly, it needs to
handle the case where the device only supports the newer HAL versions,
which includes IMapper 2.1 & 3.0 and IAllocator 3.0.
Since sensors VTS uses the same functionality from the different HAL
versions, condense the code into a common interface with HAL
version-specific template instantiation. Also remove the unused code
that came along with copying from the gralloc VTS reference source.
Bug: 138758242
Test: run gralloc-related sensors VTS on Pixel 2+
Change-Id: I1646d8f92546623594af8541bc8ac02955370694
Previously, NoStaleEvents was treating any timestamps it dealt with as
if they were in microseconds, but sensors.minDelay is in microseconds
and Event timestamps are in nanoseconds. This uses std::chrono helpers
to ensure the correct time is used when deciding how long to sleep
during the test so that if waitForEvents never passes, the test doesn't
time out.
Bug: 136736906
Test: Run VTS and verify VtsHalSensorsV2_0Target doesn't finish as an
incomplete module.
Change-Id: Ibba59dbf9312f97d7275e5aa8cd36547ab09e328
If HidlSetUp() bails before startPollingThread() is called (which can
happen if the HAL isn't implemented on the given device), mPollThread
will initialize with the default constructor resulting in joinable()
returning false which means calling detach() throws an exception.
Checking joinable() before detaching allows the test suite to be skipped
successfully.
Fixes: 136736906
Test: Run vts-tradefed on VtsHalSensorsV1_0Target and verify that it is
skipped successfully on a device that doesn't support HAL 1.0
Change-Id: Ie685ae2dc314edb8df2f3cc7112141a2f5e46008
The VTS flush test case was previously deactivating sensors before
waiting for flush events to be received causing any pending flush events
to be discarded per the HAL contract.
Bug: 136472044
Test: Run test and ensure it passes
Change-Id: I23b94e650c6dbbc33640768bee356a49565ba753
If the sensors HAL crashes or errors out during a test where we manually
re-run the environment setup function (e.g.
CleanupConnectionsOnInitialize), the pointer to the interface will
become null. Avoid dereferencing it by checking for nullness in the
per-test setup function and after each manual setup call. Also add a
death recipient to help identify instances where the HAL crashes during
a test.
Bug: 135638664
Test: run VTS on device where HAL crashes during above mentioned test
Change-Id: Iff7aa159c6b859272cfd18e7efb3ca431ea214fc
Avoid dereferencing null if mapper service is not available.
Bug: 135638664
Test: run VtsHalSensorsV2_0TargetTest
Change-Id: I3cf2a9f152d8f1737cb5a94356e252d54156c716
Define log tag at build level to ensure all libraries have a tag
defined.
Bug: 135638664
Test: run VtsHalSensorsV2_0TargetTest
Change-Id: I593055b59238e9fa8dead00a3dafa84c00e90ec4
As defined in the HAL specification, the client of the HAL (framework or
VTS) needs to set the EVENTS_READ flag when it fetches samples out of
the FMQ, to support blocking write mode.
Bug: 135442877
Test: run VTS on a device supporting HAL 2.0
Change-Id: Ic7755e869b999b638086275e4e579a84600be314
