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>
Because on oc-dev the runtime image can not be modified and that this is
not a bug but a test and implementation misalignment,
allow prepareForWrite/Read(UINT32_MAX, UINT32_MAX) to succeed on oc-dev.
MR1 will have a better fix where the HAL will always reject > 1GiB
buffers independently of the architecture.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target
Bug: 67030516
Change-Id: I10a5ee3868c67c45ed5297d9c5c89129d762c7cd
Merged-In: I4cc3efda9bb66e6dae8b4e6785f52d9e51440aee
Signed-off-by: Kevin Rocard <krocard@google.com>
This patch only modifies the VTS tests.
O generic policy configuration fallback is incorrect
(see I2a39606cd820b5cd27a640248bf692204ec2cd71 for the fix).
Nevertheless, has no impact on products because this fallback
is only used in aosp builds and GSI.
Unfortunatly, this break the VTS test when run agains GSI.
Because it is too late to change GSI for Oc and DR,
relax the test to support current O GSI.
For P, ihis patch will not be part of VTS
and the fallback config will be fixed.
Bug: 65535343
Merged-In: I2a39606cd820b5cd27a640248bf692204ec2cd71
Test: Following script:
setup() {
BUILD_ID=$1
TARGET_PRODUCT=$2
TARGET_BUILD_TYPE=${3:-userdebug}
TARGET_ARCH=${4:-arm64}
set +x
echo "The following three variables can be overridden" \
"by setting the corresponding environment variable"
set -x
TEST_SUITES_TARGET=${VTS_TEST_SUITES_TARGET:-test_suites_${TARGET_ARCH}}
BASE_TARGET=${VTS_BASE_TARGET:-${TARGET_PRODUCT}-${TARGET_BUILD_TYPE}}
AOSP_TARGET=${VTS_AOSP_TARGET:-aosp_${TARGET_ARCH}_ab-${TARGET_BUILD_TYPE}}
set +x
download() {
local target=$1
local file=$2
test -f $file ||
/google/data/ro/projects/android/fetch_artifact --bid $BUILD_ID --target $target $file ||
{ local r=$?; rm $file; return $r; }
}
echo "Downloading"
download $TEST_SUITES_TARGET 'android-vts.zip'
download $BASE_TARGET "${TARGET_PRODUCT}-img-${BUILD_ID}.zip"
download $AOSP_TARGET "aosp_${TARGET_ARCH}_ab-img-${BUILD_ID}.zip"
echo "Unzipping"
rm -r system.img android-vts
unzip aosp_${TARGET_ARCH}_ab-img-$BUILD_ID.zip system.img
unzip android-vts.zip
echo "Building vbmeta without verity"
avbtool make_vbmeta_image --flag 2 --output vbmeta.img
set -x
adb reboot bootloader
fastboot update ${TARGET_PRODUCT}-img-$BUILD_ID.zip --skip-reboot
fastboot flash vbmeta vbmeta.img || echo "Warning: Device does not support vbmeta"
fastboot erase system
fastboot flash system system.img
fastboot erase metadata
fastboot -w
fastboot reboot
echo "Board setup"
echo "You may now start vts-tradefed with:"
echo '$ ANDROID_BUILD_TOP= PATH="$PWD:$PATH" vts-tradefed'
}
VTS_TEST_SUITES_TARGET=test_suites_arm64_fastbuild3d_linux setup 4327646 sailfish
vts-tradefed run commandAndExit vts --skip-all-system-status-check --primary-abi-only --skip-preconditions --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Change-Id: Ibe1feed41325a3e4fb25e959bd254156348aa584
Signed-off-by: Kevin Rocard <krocard@google.com>
The XML audio policy configuration is expected to be located in /vendor.
Additionally for AOSP builds (no vendor) and as a fallback in case of
missing vendor configuration, the system supports loading the XML from
/system.
This fallback config is not guaranty to be compatible with the phone HAL,
but probably does for a wide range of android phones
(at least for basic use cases).
In each of those cases, there is only one configuration file, either in
/vendor or /system.
As a result, the audio policy configuration VTS test was asserting that
only one audio_policy_configuration.xml could be found.
If multiple were found, one was useless and the platform integrator
should remove it.
But VTS are now run on phone with a /system partition from an AOSP
build and a /vendor partition from a device build.
In such scenario two audio policy config are now present on the device,
thus breaking the VTS expectation.
This is not a problem for the framework because it does not look for a /system
config if one was found in /vendor.
In the future, the /system XML might be removed as boards
specific config should be found in /vendor only as per treble
requirements.
Test: Compile
Bug: 65482614
Change-Id: I7cd7eb7284c0aa52782aa591411f8a9bf2a87a76
Signed-off-by: Kevin Rocard <krocard@google.com>
The audio policy configuration deserializer supports fully dynamic
profiles by not setting a profile in a port.
It also supports partially dynamic profile by
not setting @format, @samplingRates or @channelMasks
Nevertheless this last feature of partial dynamic profile
was mistakenly not allowed by the configuration xsd.
Bug: 63541622
Change-Id: I78f77a77a3c62bba28a7da5a0e3c8c608b5a01d9
Merged-In: I78f77a77a3c62bba28a7da5a0e3c8c608b5a01d9
Signed-off-by: Kevin Rocard <krocard@google.com>
(cherry picked from commit 43d25f2f26)
audio_policy_configuration.xml can be loaded from the following places:
- /system/etc/
- /vendor/etc
- /odm/etc
Nevertheless the config validation test was expecting it to be in
/vendor/etc exclusively.
This patch changes the test logic to:
- look for the config files in all 3 folders
- make sure the config is unique
Test: run the following script to check for regressions and test that
invalid config make the test fail.
(
set -xe
runVTS() { vts-tradefed run commandAndExit vts \
--skip-all-system-status-check --primary-abi-only \
--skip-preconditions --module VtsHalAudioV2_0Target \
-t CheckConfig.audioPolicyConfigurationValidation; }
echo "# Test valid config"
runVTS
echo "# Test multiple invalid match"
adb shell touch /system/etc/audio_policy_configuration.xml
! runVTS
adb shell rm /system/etc/audio_policy_configuration.xml
echo "# Test multiple valid match"
adb shell cp /{vendor,system}/etc/audio_policy_configuration.xml
! runVTS
adb shell rm /system/etc/audio_policy_configuration.xml
echo "# Test invalid config"
adb shell sed -i /defaultOutputDevice/p /vendor/etc/audio_policy_configuration.xml
! runVTS
adb shell sed -i '"/defaultOutputDevice/{p;N;d}"' /vendor/etc/audio_policy_configuration.xml
echo "# Test that the test did not break the config"
runVTS
)
Bug: 64881365
Change-Id: I9db5e6f727d19fd654a3cc543a2aaab196682001
Signed-off-by: Kevin Rocard <krocard@google.com>
No nexus/pixel device uses port gains and their configuration were taken
as reference for the xsd creation.
Gains in mixPort and devicePort are supported by the code and use by
oem. As a result the xsd should allow them.
For validation of this path, the xsd was run against the example xml in
the audiopolicy source. Several other misalignment were found. They will
be fix in an other patch.
The address is also an optional field that was forgotten for the same
reason.
Bug: b/63827061
Test: -noout xmllint --schema hardware/interfaces/audio/2.0/config/audio_policy_configuration.xsd frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml
Test: the above command fails for some other xml node unrelated to this bug
Test: this is tracked by b/38184704
Change-Id: I8dae15eb85a6a6d43c87aa747daf92a88d3fdcc0
Signed-off-by: Kevin Rocard <krocard@google.com>
Validate the audio_policy_configuration.xml supplied in /vendor against
the format schema.
Test: Run the VTS test on target
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check --primary-abi-only --skip-preconditions --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Bug: 35700978
Change-Id: I800e692a6ff4f64655007c33af7e34d879ee1132
Signed-off-by: Kevin Rocard <krocard@google.com>
To validate the audio_policy_configuration.xml against a schema,
libxml2 is used.
Unfortunately, libxml2 uses Android.mk in oc-dev thus can not be used
from the tests which uses Android.bp.
It has been deemed safer to transform the tests to use Android.mk rather
than backporting the Android.bp patch from master.
Test: Compile
Bug: 35700978
Merged-In: I800e692a6ff4f64655007c33af7e34d879ee1132
Change-Id: Ie3f2069d60be369b4c37c27e9c1cf9372323a19c
Signed-off-by: Kevin Rocard <krocard@google.com>
HAL may not support offloading, and a call to IEffect::offload
is allowed to return an error code.
Update the test to only check that the call to the method doesn't
crash.
Bug: 38437110
Test: still passes
Change-Id: I6cfd25998edb9c68d2e585e572ba8ba3a3427e98
get_presentation_position can return ENODATA if the stream
has stopped but the write is still querying the position.
Bug: 38376424
Change-Id: I9d516a19fb347843a8ec8e8e9a0f5eab0b0798e6
Test: no log messages from StreamHAL about get_presentation_position
(cherry picked from commit 96a3a19bed)
The schema describes the XML format for audio policy
configuration.
It will be enforced in a follow up vts test.
Bug: 35700978
Test: schema is parsed with xmllint with no errors
Test: xmllint --xinclude --noout --schema audio_policy_configuration.xsd out/target/product/sailfish/vendor/etc/audio_policy_configuration.xml
Change-Id: Ic6830446b54b3e02e4bca9b0a392523a8fb359e1
Signed-off-by: Kevin Rocard <krocard@google.com>
This reverts commit 6c0f76a684.
Since the root cause of the crash has been established, there is no need to keep this code around.
Bug: 36225019
Change-Id: I74e570e863a0cdec5d9029f1672e2e8066c246b5
HAL may not support offloading, and a call to IEffect::offload
is allowed to return an error code.
Update the test to accept either OK or NOT_SUPPORTED.
Bug: 38437110
Test: still passes
Change-Id: I1822010eed73f61bb0e0ae1852739b47fa72eade
Those tests are failing because their fix
(I0ea1a4bf952527ac0711ed3cdd31c6aa53db4d2e) is dangerous to merge in O
so close to the final release.
The fix implements a rejection feature for unsupported audio format.
This rejection is required by the hal interface
but was only partially implemented in the hal.
The problem is that the framework was never tested with a hal supporting
this behavior nor some calls implemented with this requirement.
As a result I do not feel confident in merging it in oc-dev,
it might complex, hard to detect bugs.
The fix will be merged in master thus will be part of mr1.
The current patch will be reverted in master after the fix is merged.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Ia9e1dcec5442e2755f0bcb13d8d502663f507dbe
Signed-off-by: Kevin Rocard <krocard@google.com>
Hals are supposed to received normalized volumes, between 0 and 1.
Previously volumes outside [0,1] were clamp to this range.
This clamping has the capability to hide bugs thus return an error if
such volume is received.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Iab70f9c651540ea2434d10939d28c1c842db19e0
Signed-off-by: Kevin Rocard <krocard@google.com>
Some mandatory methods were allowed to return NOT_SUPPORTED
although their implementations is mandatory.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Ibe4b3cf73257309975ed11269a38315051fa9064
Signed-off-by: Kevin Rocard <krocard@google.com>
* changes:
Audio HAL: A volume/gain outside of [0,1] is an error
Audio HAL VTS: Log test unexpected behaviour
Audio HAL VTS: Improve ASSERT of Result and Return
Audio HAL VTS: stopped stream state getters may return INVALID_STATE
Audio HAL VTS: setGain allow -0.0
Audio HAL VTS: Some methods are optional
Audio HAL VTS: GetPresentationPosition may return 0 on stop stream
Audio HAL VTS: getDevice() == NONE => not supported
Audio HAL VTS: Getter test assert logic was incorrect
Audio HAL VTS: debugDump can only test for crash
Audio HAL VTS: Sanitize prepareFor{Writing,Reading} input size
Audio HAL VTS: refactor prepareFor{Reading,Writing}
Audio HAL VTS: Sanitize setMode input
Audio HAL VTS: Allow OK when setting a non existing parameter
Audio HAL VTS: differentiate getParam success/failure/not_implemented
Audio HAL VTS: Fix style on modified files
Hals are supposed to received normalized volumes, between 0 and 1.
Previously volumes outside [0,1] were clamp to this range.
This clamping has the capability to hide bugs thus return an error if
such volume is received.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Ia4880bdff6111cbcdae6a4ebee921eddae141ee4
Signed-off-by: Kevin Rocard <krocard@google.com>
Some test output infos that are useful to understand how they run.
Unfortunately the xml report does not seem to be saved by VTS tradefed.
Thus output them in logcat.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I9a2cc10160c3b1c8f81db0464efbc6b26600cadc
Signed-off-by: Kevin Rocard <krocard@google.com>
Previously tests on Result and Return were using ASSERT_NO_FATAL_FAILURE
and helper methods.
This leaded to complex error messages were the error did not pointed to
the helper methods instead of the ASSERT_RESULT call.
Additionally SCOPE_TRACE messages are repeated
for each ASSERT_NO_FATAL_FAILURE level.
Use ::testing::AssertionResult to improve drastically the error messages.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: If705502546606d678df3f1966b0cd9f3ef8c2529
Signed-off-by: Kevin Rocard <krocard@google.com>
A never started stream should have its render position and next write
timestamp at 0 or indicate that the state is invalid.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I62e16066bb22101ee8f75154fc6c85a66be2f402
Signed-off-by: Kevin Rocard <krocard@google.com>
Previously -0.0 was consider an invalid value as not in the range [0,1].
But it is quite difficult in C++ to differentiate -0.0 and 0.0 as -0.0 == 0.0
and such difference has no impact in practice.
Thus leave the implementation support or not -0.0.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Ia0ebcb325f77adcf8471620f418da1cbe8995e36
Signed-off-by: Kevin Rocard <krocard@google.com>
Although the method documentation does not say it,
some HIDL interface methods are optional.
Update the tests to allow NOT_SUPPORTED to be returned.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: If31acc2dbdb6d1d563910e85c99401c48f4f3f86
Signed-off-by: Kevin Rocard <krocard@google.com>
GetPresentationPosition returns the last time a sample was written to
the hardware.
Calling it on a stop stream should return 0 sample written, but the
timestamps of that measure is of little importance.
Thus allow this timestamp to be 0 indicating that the measure was never
actually made.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I3c33b60f98e8cbea269a7739cc1889af932dcff5
Signed-off-by: Kevin Rocard <krocard@google.com>
getDevice does not return a Result, thus it can not return NOT_SUPPORTED.
Consider NONE as not supported.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I3b6f7a1fbc1d1535faf549f5b031461cb39d1722
Signed-off-by: Kevin Rocard <krocard@google.com>
DebugDump does not return an error code, thus the implementation can not
return not implemented.
As a result, the test can not expect any output from the function.
Only test that the call does not crash and add a log if the function is
probably not implemented in the test.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I2c18958bceb1eb638491f9afce9d8e8025ccd3ec
Signed-off-by: Kevin Rocard <krocard@google.com>
Return an error if framesCount or frameSize are null to avoid a division
by zero when calculating the buffer size.
The message queues are allocated with a buffer size but if two big they will
assert not return an error.
Thus take some margin on the buffer size check.
Note that both function should be refactored as 99% identical.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I0576e9016ef2e567c8d4e171c6237883d9865db9
Signed-off-by: Kevin Rocard <krocard@google.com>
Those functions had lots of copy paste on errors and
the following patch will even add more error detections.
Refactor the hidl_cb call to avoid all duplication.
Note that both function should be refactored as 99% identical.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I40d6926b4f9f5e3aba51e878f55fb013f4ca09c1
Signed-off-by: Kevin Rocard <krocard@google.com>
Some values of AudioMode are exposed although implementation detail.
Make sure the client can not use them.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: If513c2a06efa8a92459f0af80c63232fc63302b0
Signed-off-by: Kevin Rocard <krocard@google.com>
setHwAvSync and setParameters were implemented in the pre-hidl interface
as set_parameters.
Unfortunately set_parameters did not return an error if a key was not
implemented.
As most HIDL implementation will be a wrapper around the pre-hidl
interface, allow those functions to return OK on not implemented key.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Icfcaa02b7d63e03375fddc90dc5a803754c1874f
Signed-off-by: Kevin Rocard <krocard@google.com>
When sending parameters to the HAL (and some getters are implemented
with getParameters), the client expect a status consistent
with the other HIDL methods. Ie: not implemented or success and failure.
Unfortunately, the legacy get_parameter interface, which currently most
Audio HIDL implementation are a wrapper around, do not return such error
code.
Get parameters return a list of key values.
- If a requested key does not return a key value pair, consider it not
implemented
- If a requested key returns a key not followed by a correct value,
consider it a failure
- otherwise it is a success
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Id6711e9c1974fe5a336b6de83a9b6d14f74437c9
Signed-off-by: Kevin Rocard <krocard@google.com>
In order to avoid style inconsistency as well as non functional
modification in following patches,
fix the style of all files modified for the fix of the VTS tests.
Patch generated with:
$ clang-format -i --style file -- <file list>
Bug: 36311550
Test: compile
Change-Id: I53dbcdabf959a6100e34a2ee4d0f951d525049cb
This is intended to clarify whether surprising zeroing out of HAL
control structures happens to a particular HAL module, or to any
HAL module at random.
Unfortunately, the crash itself can't be prevented as
audioflinger can't work around a HAL outage, and needs to be
restarted anyway.
Bug: 36225019
Test: verified that the logged string contains the information
Change-Id: I5843d89b4e5385b4ce269f72b5891ccb646daeba
This reverts commit e4228e7aa6.
Further analysis of the bug has shown that the problem is not related
to the use of multiple inheritance.
Bug: 36225019
Change-Id: Icdcaf84061c0ecf29f891521bd961c3ee89f1cfc
We still not sure what causes crashes in Device::get|setParam*,
but it seems that it is somehow caused by the fact that the parameters
code is in a separate class with virtual methods, from which
Device class inherits along with IDevice interface.
The workaround is to substitute multiple inheritance with
delegation in Device class. Hopefully this will either eliminate
crashes or make the underlying reasons more clear.
Some of the code got reformatted by clang-format as a presubmit
requirement.
Bug: 36225019
Test: make
Change-Id: Id785c3565bbebd5acc26ca46472961698d9c6208
Fraunhofer's downmixer has additional buffering, this is incompatible
with how DownmixerBufferProvider used to process incomplete buffers.
Now the effects HIDL wrapper delivers frameCount updates in
audiobuffers to the server side. This fixes playback of multichannel
sound streams.
Bug: 36181621
Test: play 5.1 track from Play Music
Change-Id: Iffe3327c6eedef85151eec2b41e0aedfb7ffa6dc
Add checks for validity of the passed in native handle.
Bug: 37590777
Change-Id: If906f0086c3442819e1844cc521215d5b74af015
Test: VTS
(cherry picked from commit 7bae6a0b63)
