Creates a fake sub-HAL using the default implementation for sensors HAL
2.0 with some small modifications to support the multi-HAL interface.
This sub-HAL can be configured to support two different sets of sensors
making it easier to build and load two different sub-HAL implementations
onto device and verify the multihal implementation works.
Bug: 136511617
Test: compile only. Once multihal can load in sub-HALs, then this can be
accurately tested.
Change-Id: I9b136506bdbc8a3b196fd363748bddfcdd564daf
Creates a basic set of structures needed to implement multihal 2.0.
Descriptions of each are as follows:
HalProxy - Main point of contact from the sensors framework. Implements
the ISensors interface and will implement several callbacks passed to
sub-HALs in the future
SubHal - Contains interface that sub-HALs are expected to implement in
order to be loaded properly by the HalProxy. Also contains definitions
for various callbacks and classes that will be fully implemented by the
HalProxy.
service.cpp - contains the main function that is reponsible for
initializing the HalProxy and starting the thread pool that will handle
communication between the HalProxy and sensors framework.
Bug: 136511617
Test: compile for now. Stubbed out sub-HAL to be added in a followup CL
to facilitate testing before a vendor implements the subHAL
interface.
Change-Id: If663159d444d721a0a65ebe49dd92e8924bbb3a3
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
Resize the event queue before starting the polling thread to avoid
potential concurrent access.
Test: run VtsHalSensorsV2_0TargetTest
Change-Id: I71af46169e7731df4135639644665365b3714e1f
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
