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
For the chip level operations, the actual interface itself does not
matter. So, instead of hard-coding these operations to wlan0 interface,
find the first active interface to use. This will still return wlan0 if
it's active, but if only AP is up (& pinned to wlan1), then it will use
wlan1 instead.
Bug: 129358937
Test: ./data/android.hardware.wifi@1.0-service-tests
Test: Verified manually that SAR commands are now correctly sent down.
Change-Id: I5a6175579027cbb45c09d32633ed81b9f72224dd
The primary STA iface will always be pinned to wlan0.
The primary AP iface will be pinned to wlan0 for devices not supporting
STA + AP concurrency & wlan1 for devices supporting STA + AP concurrency.
All secondary STA or AP ifaces will be allocated on a first come first
service basis (the current logic).
Also, refactored/renamed some of the iface combo selection logic methods
to help check whether concurrency is allowed in the current mode.
Bug: 128946563
Test: ./data/android.hardware.wifi@1.0-service-tests
Test: Will send for full regression tests.
Test: On crosshatch, ensured that STA always comes up on wlan0 & AP
comes up on wlan1 regardless of the sequence of toggle followed.
Change-Id: Idca8de42ce819240bf0fac2a9039d15ed4bcaf90
Devices are allowed to expose multiple AP or STA interfaces, fix the VTS
tests to allow this.
Bug: 112123615
Test: Compiles
Change-Id: I6cf60b3cb0429ca78fe5a54d9e42ba144d7609e9
Test importing of an Elliptic Curve P-256 key, encoded using the RFC5915
specification (which requires the curve OID in key in addition to the
wrapper) and the same key encoded using SEC1 (which allows omitting the
OID if it's known from the wrapper).
Test: atest VtsHalKeymasterV4_0TargetTest ImportKeyTest
Bug: 124437839
Bug: 127799174
Change-Id: I5f5df86e55a758ed739403d830baa5c7308813a3
ag/6722341 caused some unit test failures. Fixing them.
Bug: 127715974
Test: ./data/android.hardware.wifi@1.0-service-tests
Change-Id: Ib504cf55b9990dba081eb1b07bc32508e09ad0a6
am: e076865454 -s ours
am skip reason: change_id I358686e7c4330bb180dec4a9cce3bc1cf5475260 with SHA1 eed0040e21 is in history
Change-Id: I4a4e4131abd1e0297beb87099fc6bd464e61452e
am: a8c6a9c87c -s ours
am skip reason: change_id I921b7b8ccc3c66af19f6589f7213c6870d6f07bf with SHA1 b61ba1ed0b is in history
Change-Id: I3067372c437a1df7600f0a2e8fcd2ef54e97647f
am: 889b52c305 -s ours
am skip reason: change_id I72d029fef6d890eb1771c21814b028b09af280c7 with SHA1 f404a1e894 is in history
Change-Id: I8f702728d68a9dd5999ef53686b17bbccb68fe1a
am: 397361141f -s ours
am skip reason: change_id I83fb5920c1c75afbd7750d793a0b8f3e72a0552c with SHA1 632b4bd9b0 is in history
Change-Id: I403622d9292d84e075d93db31bc1792a4702e876
- 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)
Performance information in Capabilities is used by the runtime when
it selects the appropriate processor to distribute work to. Prior to
this CL, Capabilities can only distinguish between float and non-float
data types -- so, for example, float16 and float32 performance is
considered to be the same, and performance for all non-float data types is
considered to be the same.
Bug: 124041010
Test: NeuralNetworksTest_static
Test: VtsHalNeuralnetworksV1_2TargetTest --hal_service_instance=android.hardware.neuralnetworks@1.2::IDevice/sample-all
Change-Id: I83fb5920c1c75afbd7750d793a0b8f3e72a0552c
Merged-In: I83fb5920c1c75afbd7750d793a0b8f3e72a0552c
(cherry picked from commit 632b4bd9b0)