Instead, implement it correctly.
This hack was a quick jury-rigging before O MR1 FC.
Bug: b/36864090
Test: VTS
Change-Id: Ia9caff9228518ec573a85437e9070db777057359
The neuralnetworks hal was placed in
frameworks/ml/nn/hardware/interfaces while VTS tests were being
developed.
This CL moves it to hardware/interfaces and another CL removes
it from frameworks/ml/nn/hardware/interfaces.
VTS tests included in a sibling CL in this topic.
Bug: 63905942
Test: mm -j40
Change-Id: I0e6c84de72a763edbaef3e9b3063c3ecca216337
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
OMX_EventBufferFlag event is sent when the component has processed a buffer
with its EOS flag set. This event is not sent by soft omx components.
Vendor components can send this. From IOMX point of view, this event is
not sent for processing
bug:64102197
Merged-In: I3a978a885b1e4446f82f2356ae677f70ea6f8150
Change-Id: I3a978a885b1e4446f82f2356ae677f70ea6f8150
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
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
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
