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>
Currently there is no implementation for this api by vendor code.
So we should check only for REQUEST_NOT_SUPPPORTED or NONE
as error returned at present.
Test: run vts
Bug: 64073713
Change-Id: I27f544cf6521d2f913f97e1b8f662a05166ddc11
Modifying the interface used to lower the tx power level for meeting SAR
requirements based on recommendation from the nexus hardware team. The
previous interface passed in a single power value in dBm for meeting SAR
requirements. However, the SAR requirements are more complex than that.
Based on the connection mode (802.11 a,b,g,n,ac) and the number of
streams that are active (MIMO), the SAR power levels are very
different. Using the previous interface would mean that we will have to
use the lowest power level among all the connection modes to meet the SAR
requirements. This would however result in us lowering the power much
more than needed (~2 dBm) for many connection modes.
Instead, we're switching to a more generic interface where the framework
informs the wifi chip that we're entering a special tx power mode scenario
(today, there is only 1 for voice call). The chip can then lookup the
extensive table of power levels for different connection modes which are
pre-populated by the OEM's in the BDF file to set the power level (depending
on the scenario framework sends and the active connection mode).
Bug: 62437848
Test: Manual tests
Change-Id: I5ee3f0d2c130958dbeb352e3b5ad9407f432624f
Also fix wrong return values for processCaptureRequest in default
wrapper.
Test: running camera VTS
Bug: 64041692
Change-Id: I397390af7c85a776713f6287bef1c4d11c721c9a
Merged-In: I397390af7c85a776713f6287bef1c4d11c721c9a
Also fix wrong return values for processCaptureRequest in default
wrapper.
Test: running camera VTS
Bug: 64041692
Change-Id: I397390af7c85a776713f6287bef1c4d11c721c9a
Back port from master
Test: VTS test pass
Bug: 63570734
Change-Id: Ic0eecaf843b5c2e78f60325090ea652d43a74a0b
Merged-In: Ic0eecaf843b5c2e78f60325090ea652d43a74a0b
This includes:
- cover all AM/FM bands, not just first one
- fix flakiness on late callback dereference
- fix 1.0 tuneComplete check
- move utils includes into separate subdirectories
Bug: b/36864490
Test: VTS
Change-Id: I6e2427ac29abd6278c9783cf83b4df05195ac7ea
Since the new network scan API is only supported by some devices, we
should add the REQUEST_NOT_SUPPORTED to the possible returned errors.
Cherry-picked cleanly from:
https://googleplex-android-review.git.corp.google.com/#/c/2596051/
Test: Telephony sanity tests, run vts -m VtsHalRadioV1_1Target
Bug: 63914600
Merged-in: I965ee6422aaa5e02bf67466f5288b808183f1738
Change-Id: I965ee6422aaa5e02bf67466f5288b808183f1738
(cherry picked from commit 03c6b592c1)
Allow them to be static.
This is required for a couple of reasons:
- enabling HIDL passthrough in recovery
- enabling VTS tests to be static blobs
Bug: 32920003
Bug: 64040096
Test: update-all-google-makefiles.sh
Change-Id: I1b2401fb273ab80819e3870aa71fe742269674ba
It is possible that the current default consumer usage
flag may not be supported by some provider implementations.
Use either HW composer or some other flag that is appropriate
for the specific use case.
Merged-In: I04f89bf67166805191d6d40e5bd93c15ebc97ea6
Bug: 63913159
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --primary-abi-only --module
VtsHalCameraProviderV2_4Target -l INFO
Change-Id: I04f89bf67166805191d6d40e5bd93c15ebc97ea6
Rename the enums that contain a list of sensors and don't directly map to OBD2 to have a Diagnostic prefix
Test: clean build and flash, then
runtest -x packages/services/Car/tests/android_car_api_test/src/android/car/apitest/CarDiagnosticManagerTest.java
runtest -x packages/services/Car/tests/carservice_test/src/com/android/car/test/CarDiagnosticManagerTest.java
runtest -x packages/services/Car/tests/vehiclehal_test/src/com/android/car/vehiclehal/test/Obd2FreezeFrameTest.java
runtest -x packages/services/Car/tests/vehiclehal_test/src/com/android/car/vehiclehal/test/Obd2LiveFrameTest.java
Bug: 64024685
Change-Id: I9147bcd8f2972dee9f3d1e62f8978b595d88f606
