setSampleRate, setChannelMask, setFormat
may not be implemented by the HAL, although this is not documented in
the HAL API.
Currently the VTS test requires their implementation if the respective
getSupported{SampleRate,ChannelMask,Format} are supported.
Relax this requirement as the framework never calls those setters.
Note that the optionality of those functions will be documented
in the next HAL API version.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Bug: 69811500
Change-Id: I3a390ae925cabd99e7f1ed4a627e71ad87b1b437
Signed-off-by: Kevin Rocard <krocard@google.com>
getSupportedSampleRate should return the native sampling rates,
(IE. the sampling rates that can be played without resampling)
but other sampling rates can be supported by the HAL.
The test was too strict as it was failing if HALs were supporting more
sample rates than there native (optimized) ones.
For example, a HAL might have its best performance (no resampling)
on 48kHz but still support 16kHz through resampling.
Note: getSupportedSampleRate might be renamed to getNativeSampleRate in
the next major HAL revision to avoid ambiguity.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Bug: 69811500
Change-Id: I1ec1ce422bc5039637463c6641060508f4ee892b
Signed-off-by: Kevin Rocard <krocard@google.com>
This constraint was added due to an incorrect assumption
that device ports were identified by names whereas
they are by the (module,type,address) triplet.
Bug: 69442986
Test: xmllint validates an XML with two identically named devices in
different modules.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Change-Id: I66d890d3c967bead4f2a287202c259009217996a
Signed-off-by: Kevin Rocard <krocard@google.com>
Device port are not identified by names but by their type and address
and the module they are in.
As a result, enforce this constraint in the XSD. Violating it results in
a policy parsing crash.
Bug: 69442986
Test: xmllint invalidates an XML with two devices of the same type
and address
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Change-Id: I84245f0fa80fef786a002c98073c166b6aaf2be4
Signed-off-by: Kevin Rocard <krocard@google.com>
Vendor are currently not allowed to extend the XML format.
As some enumeration are allowed to be extended, this mean that
the format must allow some extension mechanism.
This patch relaxes the definition of the module name field.
AOSP names are still allowed, but a vendor can add its own name
if prefixed with "vx_". Eg:
<module name="vx_google_vr" halVersion="3.0">
Test: xmllint --xinclude --noout --schema hardware/interfaces/audio/2.0/config/audio_policy_configuration.xsd audio_policy_configuration.xml
with audio_policy_configuration.xml containing a module named vx_google_vr
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
on Pixel 2
Bug: 69442986
Signed-off-by: Kevin Rocard <krocard@google.com>
Change-Id: I4ead38535cce89bb8fe44cf23fa1146acd1271d6
OpenSSL changes error code of large RSA data from
KM_ERROR_INVALID_INPUT_LENGTH to KM_ERROR_INVALID_ARGUMENT which causes
HidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge and
HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLarge tests failed.
Fix keymaster VTS to accept both the error codes.
Bug: 68289922
Test: HidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge and
HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLargeHidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge
and HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLarge are
passed after applying this modification and other Keymaster 3.0
VTS test cases are not affected.
Change-Id: I493bfa1c6e4b69560dfae3585a416b5c3d33e215
Merged-In: I493bfa1c6e4b69560dfae3585a416b5c3d33e215
(cherry picked from 890d3dfe27)
The stop may fail if the interface down operation takes too long on some
devices. This is not fatal as long as we're able to bring up the
interfae for the next HAL start.
Bug: 68303248
Test: VTS tests
Change-Id: I93943f9d0cfb83cf07253c6f9b3866d6d137028f
As it is often found in a short integration
window with very high Doppler uncertainty.
Bug: 67877519
Merged-In: Ia05359f572f4ea7be81f9d5fe30bd619322bebd3
Test: Verified Pixel still passes VTS
Change-Id: Ia05359f572f4ea7be81f9d5fe30bd619322bebd3
Analysis: VtsHalRadioV1_0Target's timeout is too short for
getAvailableNetworks, because this request duration depends on NW
environment or frequency.
Suggested solution: Add a timeout parameter to wait() and default
timeout value is 5 minutes in order to avoid timeout fail due to NW
environment.
Bug: 68834032
Test: getAvailableNetworks can be passed after we apply this patch and
test result for all other telephony 1.0 and 1.1 test cases are not
changed.
Change-Id: Iaae71e0abacd28275d86a19264813ff209ddb79c
Merged-In: Iaae71e0abacd28275d86a19264813ff209ddb79c
(cherry picked from commit 6429f0677f)
The NAN-specific VTS tests check whether the device supports NAN.
However, the tests did not abort early enough.
Bug: 68302113
Test: builds
Change-Id: Ie6fb0e2b0bd12840ce6bc52fab1b6d4e8c5a571e
Resource files for avc and mpeg4 are at higher resolutions than what the
CDD requires. This CL corrects the issue.
Test: make vts -j123 && vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--skip-preconditions -m VtsHalMediaOmxV1_0Host \
-l INFO
Bug: 68828675
Change-Id: I5a32bccae1b14a72ae0db2ffafd4a0e86cced74b
As it is often found in a short integration
window with very high Doppler uncertainty.
Bug: 67877519
Test: Verified Pixel still passes VTS
Change-Id: Ia05359f572f4ea7be81f9d5fe30bd619322bebd3
(cherry picked from commit adca98d590)
