We had no tests for quantized PAD in NNAPI 1.1 and think that vendors might have implemented different behaviors.
Bug: 122243484
Test: N/A
Change-Id: Ibfc0801ab746fc271dc5f8efc764b818c6d49df4
RESIZE_NEAREST_NEIGHBOR
- The CPU implementation always had the order of {width, height}.
- In P, the documentation was incorrectly changed to {height, width}.
Bug: 131623949
Bug: 130035110
Test: mm
Change-Id: I6c79459fa73347fb51fc34a76ad78d5ac207f210
This is causing C++ compiles of this interface to fail now that these
comments get copied into the output.
Bug: 130911129
Test: compilation now succeeds
Change-Id: Iaa3877620b032b7144e3bab114fbcd1e1483bc8e
Update the docs for ops:
- LOG_SOFTMAX
- LOCAL_RESPONSE_NORMALIZATION
The docs mentioned possibility to use float16 as an input type but
didn't specify that other inputs must be float16 as well in that case.
Fix: 123500722
Test: mma
Change-Id: I9028c4a109c80f0b8571fab45555818e9e4bc783
Merged-In: I9028c4a109c80f0b8571fab45555818e9e4bc783
(cherry picked from commit 6d13ba258b)
Brightness is already a per display capability, we don't need this API.
BUG: 130313275
Test: build
Change-Id: I0a669aca19a2873df41bee82bd0e5e2775af8101
Update the docs for ops:
- LOG_SOFTMAX
- LOCAL_RESPONSE_NORMALIZATION
The docs mentioned possibility to use float16 as an input type but
didn't specify that other inputs must be float16 as well in that case.
Fix: 123500722
Test: mma
Change-Id: I9028c4a109c80f0b8571fab45555818e9e4bc783
Torch API was mandated on legacy libhardware camera module 2.4.
We kept the option of not supporting this API because the first
HIDL legacy wrapper needs to also support libhardware camera
module 1.0 + HAL1.0. Now that HAL 1.0 is no longer supported,
we can reenforce the torch API being supported by camera HAL as
this is critical to power usage of flashlight usecase.
Test: adb shell VtsHalCameraProviderV2_4TargetTest
--hal_service_instance=android.hardware.camera.provider@2.4::ICameraProvider/legacy/0
Bug: 113336515
Change-Id: I0dcf2e7a5cddadcd097caf6913625d8a607065f8
Update IMapper to use usage and format from
android.hardware.graphics.common@1.2. This enables support for
the usage HW_IMAGE_ENCODER and the format HSV_888 which is
already being defined and used.
Test: IMapper VTS tests
Bug: 79465976
Change-Id: I680beb6e5b1cd246c28d17f855f5c76a5831ce06
In case of CIFG LSTM, input layer norm weights are not used in the
computation.
Bug: 129126572
Test: mma
Change-Id: I57bc578606132a2c44c71ab63dd7645dcc001302
Merged-In: I57bc578606132a2c44c71ab63dd7645dcc001302
(cherry picked from commit 0480af9aa8)
In the IGnssCallback.hal@2.0 introduced in Android Q, the
capability bits in IGnssCallback.hal@1.1 that represent sub-HAL
interfaces have been removed as they are derivable from the
existing getExtensionXXX() family of methods in the IGnss.hal
interface.
These need to be restored back as the synchronous nature of the
getExtensionXXX() methods called by the framework has an impact on
partner implementations that need to communicate with the modem to
get the capabilities.
Additionally, the capability bit MEASUREMENT_CORRECTIONS needs to be
added for the new optional measurement_corrections@1.0 sub-HAL
introduced in gnss@2.0.
Fixes: 129870126
Test: Verified through cuttlefish default implementation and VTS tests.
Change-Id: Ib4164c9501b8db9f09eb5429a077d477d0a4a7f9
Existing Android framework code (and transitively, CTS test) require
that an accessRegion of (0,0,0,0) is treated the same as an
accessRegion covering the entire buffer, when calling lock() or
lockYCbCr().
Document this so that there is no confusion about this going forward,
since this requirement pre-dates the HIDL HALs.
Bug: 119440345
Test: Builds
Change-Id: Id16831d3da4ec3dc74dbdca18447581a50ee1193
Extend "ERROR_RESULT" documentation and describe how Hal
must notify about physical device result failures and
logical device result failures.
Bug: 128835627
Test: Successful build
Change-Id: Iac5642f333634d9cc820eb727f8ff3534a47a583
In case of CIFG LSTM, input layer norm weights are not used in the
computation.
Bug: 129126572
Test: mma
Change-Id: I57bc578606132a2c44c71ab63dd7645dcc001302
Both framework BatteryService and all implementations (that uses
BatteryMonitor) uses millivolts for batteryVoltage.
maxChargingVoltage is microvolts and that is correct.
Fixes: 115881119
Test: treehugger
Change-Id: I64044489fe6d56e0d211085d9536fe5cfd95efc4
- Instead of isCachingSupport returning a single boolean, switch to
getNumberOfCacheFilesNeeded returning the number of cache files. This
is to support use cases when driver needs more than one cache file for
each type, or when driver does not need data cache.
- Instead of a separate saveToCache, pass cache info along with
prepareModel_1_2 to save into cache as well as perform compilation.
This is to avoid a potential additional copy of cache files.
Bug: 123780248
Test: VtsHalNeuralnetworksV1_xTargetTest with 1.2 sample driver
Test: VtsHalNeuralnetworksV1_xTargetTest with a test driver that can
read and write cache entries
Change-Id: I921b7b8ccc3c66af19f6589f7213c6870d6f07bf
Merged-In: I921b7b8ccc3c66af19f6589f7213c6870d6f07bf
(cherry picked from commit b61ba1ed0b)
Also updates documentation for this op and UnidirectionalSequenceLSTM
op.
Bug: 123644584
Test: in ag/6758764
Change-Id: I72d029fef6d890eb1771c21814b028b09af280c7
Merged-In: I72d029fef6d890eb1771c21814b028b09af280c7
(cherry picked from commit f404a1e894)
