[Description]
VTS StartFilterInDemux failed when configureMonitorEvent is called
[Root Cause]
Scrambling status event is not notified when configureMonitorEvent is called
so test case failed.
[Solution]
Scrambling status event is not notified because of no input data.
Add input setting and check event notified or not after data is input.
Test: Manual
bug: 288193021
Change-Id: If5875d064fd67b72f8299205a5e35b1a2bd61934
nvResetConfig takes some time to reset the modem, causing subsequent
tests to fail with a timeout since the modem is unavailabe.
Add a timeout after nvResetConfig to allow the modem to be up again
before running the next test.
Bug: 259674407
Test: atest VtsHalRadioTargetTest
Change-Id: Ic7188f9d8ccfcd90d844b45e3b370a3be3c515d6
Merged-In: Ic7188f9d8ccfcd90d844b45e3b370a3be3c515d6
(cherry picked from commit ddaea2e5a4)
We check SIM card status is PRESENT before running any VTS tests, so
ensure that it's enforced in the configs as well.
Test: atest VtsHalRadioTargetTest
Bug: 249143796
Change-Id: I1b2c317e21db118e4b957804feb76f266d887b20
Merged-In: I1b2c317e21db118e4b957804feb76f266d887b20
(cherry picked from commit 658fdaaa2a)
The code currently uses 'dsds' to detect dual-SIM configurations,
but it misses 'dsda' configurations, resulting in test failures.
Should use the detection mechanism by adding handling for 'dsda',
ensuring accurate detection of all dual-SIM configurations.
Bug: 277705768
Test: vts -m VtsHalRadioTargetTest -t PerInstance/RadioConfigTest#checkPortInfoExistsAndPortActive/0_android_hardware_radio_config_IRadioConfig_default
Change-Id: Ie73a958ff14e86f440831e18291b6599b6eac30b
Signed-off-by: Jia Jia <jia.jia@zte.com.cn>
If CEC DUT is a TV device type,we should reset logical address to tv,
and then set message.initiator to tv.
Bug: 277715429
Test: run VTS
Change-Id: If7f7b9ddce182e5de80c91a30c4ec18294459fbf
Signed-off-by: caijq <callen.cai@rock-chips.com>
am skip reason: Merged-In Id581e290740a3c00ba3719a339c9bc47d730f35c with SHA-1 afff851110 is already in history
Original change: https://android-review.googlesource.com/c/platform/hardware/interfaces/+/2544670
Change-Id: I19b2717ffdd82e13d379428bf4210f4b5ee79fef
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Id581e290740a3c00ba3719a339c9bc47d730f35c with SHA-1 afff851110 is already in history
Original change: https://android-review.googlesource.com/c/platform/hardware/interfaces/+/2544670
Change-Id: I7cc328378f38bb1918d6751797865a3b99de459e
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Id581e290740a3c00ba3719a339c9bc47d730f35c with SHA-1 afff851110 is already in history
Original change: https://android-review.googlesource.com/c/platform/hardware/interfaces/+/2544670
Change-Id: I50d081a0fbafc3e91a93cd1d36578a2b1b0693a7
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
There was a proposal for a backward-compatible XML schema change
(https://android-review.googlesource.com/q/I1bf31c6bf6c57c9b79f0d5751601aa77780f1f80)
which had a mistake. Express the change correctly to match
the implementation.
Bug: 231929160
Test: atest VtsHalAudioPolicyV1_0TargetTest
Change-Id: Id581e290740a3c00ba3719a339c9bc47d730f35c
Merged-In: Id581e290740a3c00ba3719a339c9bc47d730f35c
(cherry picked from commit e01186e117)
Fence fd is closed when processCaptureResult returns. In order to
wait for the release fence *after* processCaptureResult returns,
the fence fd needs to be duped.
Test: Vendor testing
Bug: 241281568
Change-Id: Ib74f9bb141802713b476a2ef48a2252125a7915d
If the device is depth-only, use threshold with Y16 format rather than
IMPLEMENTATION_DEFINED.
This fixes the regression introduced by the fix for b/265984260.
Bug: 276957901
Test: atest VtsAidlHalCameraProvider_TargetTest
Change-Id: If9023f1ed17bb761abbb9be36e567264f8bf0689
The camera HAL may signal release fence after processCaptureResult.
If the VTS test waits for the release fence in the context of the
capture result, there is possibility of deadlock.
Rather, we should wait for the releaseFence in a different thread
context to really emulate the real application behavior.
Test: atest VtsAidlHalCameraProvider_TargetTest
Bug: 241281568
Change-Id: Id1d92e901aae1cab084846d252ef090fcda182d7
Bad safe_union access is raised by calling the GET method of
eutranBands(), because in default ctor of safe_union RadioAccessSpecifier::Bands
hidl_d is assigned with hidl_discriminator::geranBands, which conflicts
with hidl_discriminator::eutranBands, and leads to crash.
Should use the SET method of eutranBands(&) for assignment purpose.
Fix: 275077563
Bug: 271642958
Change-Id: Ie241e8968eb7f9a1297203be2ab4e0a1bf738dea
Signed-off-by: Jia Jia <jia.jia@zte.com.cn>
