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
Instead, implement it correctly.
This hack was a quick jury-rigging before O MR1 FC.
Bug: b/36864090
Test: VTS
Change-Id: Ia9caff9228518ec573a85437e9070db777057359
VTS tests for the initial implementaion of NATT
Keepalive support in the V1_1 HAL.
Bug:63530561
Test: this
Change-Id: Iafabd4b0f8a8f4da78f65bf4061d47f4bfd69a7a
Addition of a flag to the configuration for OBD2_FREEZE_FRAME_CLEAR
to indicate support for deletion of individual freeze frames.
Test: build
Bug: 64024685
Change-Id: I43cc448c801a5d59095be03d8056530364860ef5
Also fix wrong return values for processCaptureRequest in default
wrapper.
Test: running camera VTS
Bug: 64041692
Change-Id: I397390af7c85a776713f6287bef1c4d11c721c9a
Merged-In: I397390af7c85a776713f6287bef1c4d11c721c9a
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.
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
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
