The tight loop of HAL start/stop exposes a race condition within the HAL.
Adding a fix for preventing this race would need a fix which would be
pretty risky at this point of the release. The issue itself is unlikely
to happen in real use cases because wifi toggles (user initiated or test
scripts initiated) via framework goes through a series of processing
before it invokes the HAL start/stop.
Bug: 64195190
Test: `make vts -j30 BUILD_GOOGLE_VTS=true TARGET_PRODUCT=aosp_arm64 &&
vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions --module VtsHalWifiV1_0Target -l
INFO`
Change-Id: I4e4d65f8b6e2e423a3a5f26e5a97a78b7e99c3e8
When IWifi.stop() is invoked back to back (happens in the ConfigureChip
vts test), the HAL would return ERROR_NOT_AVAILABLE if the previous stop
is still being processed. This is not an error that needs to fail the test,
but a legitimate status for stop. We have a retry mechanism to handle
this in both the VTS test and framework for the case where IWifi.start()
is invoked while the previous stop is being processed.
While there, corrected a few log messages emitted by the HAL to debug
such startup/stop issues better.
Bug: 63971806
Test: `vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions --module VtsHalWifiV1_0Target -l
INFO`
Change-Id: I5e3470ac97541a6ea10aceec9b737e5d03ed5206
These tests now statically link to libs not guaranteed to be on the
device, which include HAL definition libs.
Also, remove global include paths.
Bug: 64040096
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalMediaOmxV1_0Host
Change-Id: Iea1dc549704f61b1416357d72dc1bf26864978d4
Add IThermalCallback and IThermal::registerThermalCallback() method.
Frameworks code calls this method to register a callback used by the
IThermal HAL implementation to send thermal events to the framework
ThermalService.
Bug: 30982366
Test: VtsHalThermalV1_1Target on marlin
manual test on marlin using marlin 1.1 HAL with modified
thermal-engine.conf and temporary debug code for notification
Change-Id: Ib49ad93a9495e3af515fced4e46f20186661fe07
(cherry picked from commit cf964d79c1)
OMX_EventBufferFlag event is sent when the component has processed a buffer
with its EOS flag set. This event is not sent by soft omx components.
Vendor components can send this. From IOMX point of view, this event is
not sent for processing
bug:64102197
Merged-In: I3a978a885b1e4446f82f2356ae677f70ea6f8150
Change-Id: I3a978a885b1e4446f82f2356ae677f70ea6f8150
This test now statically links to libs not guaranteed to be on the
device.
Bug: 64040096
Test: compiles
Change-Id: I986e61835e641e15bdad0ff9571ee8ffa59b2a46
As a VNDK module, Android.bp must have 'vndk' tag as well as
'vendor_available: true'.
The 'vndk' tag for VNDK module is formated as below:
vndk: {
enabled: true,
},
VNDK modules will be installed both in system/lib(64) as normal and
in system/lib(64)/vndk as a vendor variant.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Change-Id: If0eb0c1bddfa5bdc7ea0ca4635d4e53b59836582
vndk-sp is not automatically tagged by hidl-gen.
For vndk-sp libs, "support_system_process: true" is manually added
in "vndk" property.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Change-Id: I2b18d691411e58dc55bcdfa39ecb3659242c8437
Update the Android.bp generated with hidl-gen.
Test: build with and without BOARD_VNDK_VERSION=current
Bug: 63866913
Change-Id: I1a9db1df49e0f13c5790da2b118ae9ec63ba34a7
