1s should really be the max limit, but it requires time to investigate
the failures and optimize this
Bug: 327273567
Fix: 332815453
Test: atest VtsHalBluetoothTargetTest
Change-Id: I43767b5241d967cb643401711fd7b2e015e99455
This implementation of the HAL is used by pixel devices.
The implementation of GetProviderInfo is test only
Bug: 324570010
Test: TreeHugger
Change-Id: I67d17fb07c1288317290a0b1c4b07cd3be1e48c6
Previously, android.hardware.bluetooth.audio-impl was installed with no
use and the attached vintf was fulfilled by the
com.android.hardware.audio apex.
For cleanup, we no longer install android.hardware.bluetooth.audio-impl
separately (for cuttlefish) and install the VINTF inside the apex.
Bug: 312265159
Test: atest VtsHalBluetoothAudioTargetTest
Change-Id: I31e0ccd6a8c3c00565159f2be7fe3bf4d70e9ddf
This is needed to upgrade the android_logger crate from 0.12.0
to 0.13.3.
with_max_level provides the same functionality as with_min_level.
The renaming is admittedly confusing, but the new name is accurate
and it makes sense that they deprecated and then removed the
previously poorly named with_min_level.
See crate documentation [1] and code [2].
[1]: https://docs.rs/android_logger/0.12.0/android_logger/struct.Config.html#method.with_min_level
[2]: https://docs.rs/android_logger/0.12.0/src/android_logger/lib.rs.html#227
Bug: 322718401
Test: build and run CF with the change.
Test: m aosp_cf_x86_64_phone
Change-Id: I0ca9596433967be70e9d55acb6cfbf9322741bf8
Since finder/ranging/lmp_event HAL services are new and their interfaces
are not frozen yet, they can't register services in -next-
configuration.
Bug: 322204309
Bug: 319155748
Test: run CF in -next- build
Change-Id: I4729d8763842c719682ce0124bbaaed86164a7d5
Bug: 319669518
Test: m android.hardware.bluetooth.audio-update-api && make && m VtsHalBluetoothAudioTargetTest
Change-Id: Id128ed1eb09ada1e98b15351dc353fedc90fcbc8
GSI used mixed testing procedures, making some HFP session
and LE Audio related functions unavailable when testing with the
latest VTS. This fix enable HAL version checking when testing.
Bug: 315338603
Test: atest VtsHalBluetoothAudioTargetTest
Change-Id: Idb0a780a67857c76c93b13f7b3a64436f6fc647f
ParseFromLeAudioOffloadSettingFile() fails when `GetLeAudioCodecCapabilities()`
was already called in the past and `leAudioCodecCapabilities` vector is already
populated. That makes some of the VTS tests fail on
`IsOffloadOutputProviderInfoSupported()` and just return and PASS without
actually checking enything.
The doubtful checks check variables set at parsed content verification,
and should not prevent us from parsing the file again.
Bug: 319090769
Test: atest VtsHalBluetoothAudioTargetTest
Change-Id: Iab6235b5d265bb254ae6075b8c32d0eae0fc1829
When the xml file contains the "invalid" entry in the scenario record,
which do not refer to any valid config in the 'configurationList`
section, the invalid, default constructed codec configuration (a2dp codec)
was created.
Bug: 319090769
Test: atest VtsHalBluetoothAudioTargetTest
Change-Id: I19b7d1af81e5f2be3fb7261fba8781b3dc47fa12
Instead of silently passing the tests when some functionality is
not supported, mark these tests as skipped. This way, when we are sure
that some functionality should be verified in a particular test run,
we are not being falsely reported that all have passed successfully
while in reality, there's an actuall issue in the particular functionality
detection mechanism.
Bug: 319090769
Test: atest VtsHalBluetoothAudioTargetTest
Change-Id: I8589ef14abfb5af641bc98949de1e1acc21efe1a
Just like the returned data path configurations are split for each direction,
the function arguments should also have the directional context. The vendor
module might need to know which connection handles in the stream map are for
the sink and which are for the source direction, to provide the proper
data path configurations for each direction.
Bug: 308428217
Bug: 307258939
Test: m android.hardware.bluetooth.audio-update-api
Change-Id: I270b6f4631869e2180580c886f0b58bd777d2123
In order to align with legacy behavior, when opening a stream,
the module must suggest the current configuration of the BT session.
For that to work, the BT device proxy must be opened prior
to creating a stream, code moved to ModuleBluetooth.
Fix minor inconsistencies and bugs found during testing.
Bug: 301213930
Bug: 316027906
Test: atest pts-bot
Change-Id: I04ddaf73be82f872a3f32a789563c3cbd648eb61
