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)
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)
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)
No good place in generated docs.
Bug: 124382459
Test: ./update-makefiles.sh
Change-Id: I7802d12c34b33be192c83fc46ffed5a6a7385a0a
Merged-In: I7802d12c34b33be192c83fc46ffed5a6a7385a0a
The spec of setLayerDataspace never specifies the types of layer it should be
call on, however, the spec has the implication that this method will only work
for layers with buffer, which is mis-leading. This patch changes the wording of
setLayerDataspace spec, removes the implication. Note that this change won't
break backward compatability.
BUG: 126713799
Test: N/A
Change-Id: I97f22469897cb687dcb64a3d419bcb48a3668e5a
subsysName, railName, powerEntityName, and powerEntityStateName are all
opaque to the Android framework. Emphasizing the opaque nature of these
members in the HAL definition will help developers more quickly
understand the intent of the interface.
Bug: 125380339
Test: make
Change-Id: I42ed1f3cc928726ae146b6be849947b631ae48e6
Modify the document for 'hasKnownUserIntentEmergency'.
In the scenarios that the 'address' in the 'dialInfo' field has other
functions besides the emergency number function, if the
'hasKnownUserIntentEmergency' field is true, the user's intent for this
dial request is emergency call, and the modem must treat this as an
actual emergency dial; if the 'hasKnownUserIntentEmergency' field is
false, Android does not know user's intent for this call.
Test: compile
Bug: 121345950
Change-Id: I3457e7519be564ac5043e06380e9450a1b12425f
(cherry picked from commit 7208840ec0148ad5a01bdf419170282cd1b32437)
When fields are inapplicable, they should not
be set to a clearly out-of-range value to signal
to the framework that those fields are not used.
In some cases, there is an in-range invalid value
that has been defined by the standards. The docs
are inconsistent in calling out INT_MAX as the
value to be used when something is inapplicable
vs the case when a measurement is simply not
reported. In all cases, INT_MAX can be used to
denote an invalid value, and in cases where the
field/structure is inapplicable, it is the correct
value. This CL updates all the docstrings for
SignalStrength-related fields to clarify that
INT_MAX is the correct "invalid" value for cases
when fields are inapplicable.
Bug: 123088652
Test: compilation (docstring-only change); CTS
naturally enforces this change on devices with
newer HALs; backwards compatibility is preserved
for existing HAL versions.
Change-Id: I5cfa917f504d15691ab3f2c298189bdd47794a42
If there are more than one metadata entities being passed
via FMQ, specify the framework read order.
Test: Build
Bug: 119575429
Change-Id: Ia34ac69ce670b1ebeda12d92af490c347f33c15b
Merged-In: Ia34ac69ce670b1ebeda12d92af490c347f33c15b
The former HAL documentation incorrectly documented (Geomag)-RV
sensor data as Vec4, although an accuracy field is expected according
to the Android sensor docs. Former default HAL implementation has set
the accuracy value to zero, preventing apps from getting this value.
This change guides OEMs to use the Vec4 + accuracy when converting
(Geomag)-RV sensor events. The default HAL implementation passes
this extra data now (ag/5224072), but clients of the former
implementation will still get the data it needs if assuming
the Vec4 sensor data format.
Bug: 116874058
Test: Compile only
Change-Id: I6a5c8a48dd372c3d4682ed5329f7f87862746cb9
These were either made at a time when the convention was not fully
formed or missed during review.
It is somewhat misleading since method overloading isn't supported
and method names need this kind of prefix, but nothing else does.
The reason for this is that everything is namespaced, but methods are
all in the same namespace. The reason method overloading is not supported
in HIDL is because the HIDL types may map to types that collide in the
target languages, and this would cause any sort of overloading rules
to require complicated machinery.
Bug: N/A
Test: hidl-gen -Lcheck android.hardware.usb@1.1 android.hardware.vibrator@1.1 && echo ":)"
:)
Change-Id: Iac23c9311925ed140ff1e15d1366829b078c8866
The type of mcc and mnc is String instead of Int now. They should be an
empty string if unknown. Also added a test case for their values.
Bug: 111703979
Test: Vts
Change-Id: Ie0426453dc426ccc6cf203b315806e78511ce14d
This was changed after this branch was released. The originally
released hash needs to be restored since that is what partners
are building with.
Bug: 112688384
Bug: 78104779
Test: m android.hardware.keymaster@4.0 (tests hashes)
Change-Id: I0f59a493d7f17a13402d992495d1a259f6257077
(cherry picked from commit ec720564db)
Add SIM_PUK2 for supplyIccPin2ForApp and changeIccPin2ForApp if sim
card is in the puk2 state.
Bug: 111211929
Test: sanity
Change-Id: I80d924cc4a61565887cbd2a65ee5927a42ad656e
Merged-In: I80d924cc4a61565887cbd2a65ee5927a42ad656e
(cherry picked from commit 4ed0a216ad)
Adds new EXPENSIVE_RENDERING power hint.
This adds a new library which does not affect any pre-existing
targets unless they create and add a new binary which uses this.
BUG: 110112323
Test: adb shell /data/nativetest/VtsHalPowerV1_3TargetTest/VtsHalPowerV1_3TargetTest
Change-Id: I5fb33abbbe4c4958882a106dfa400ad74013e40d
Because setSignalStrengthReportingCriteria only
supports a single measurement quantity, provide
further clarification on the applicability of the
API and how it may be used in various situations.
Bug: 110121199
Test: compilation - docstring-only change
Change-Id: If4236070fbc03368e5a78b0cf502cdc4a529a6ed
