C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: I387d30e993719014da50207c7114b0003b9450c5
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
NullOr now stores the references a pointers internally. This fixes UB
where the internal reference was initalized by dereferencing nullptr.
Test: Compiles
Bug: 121390225
Change-Id: I2073e5aeac401309aa63b08e05db3c467fab6b69
* changes:
Revert "Create NNAPI HAL v1.3 and add TENSOR_QUANT8_ASYMM_SIGNED OperandType"
Revert "Copy VTS tests from v1.2 to v1.3"
Revert "Modify NNAPI VTS tests to run on version 1.3"
* changes:
Increase neuralnetworks compatibility to 1.3
Modify NNAPI VTS tests to run on version 1.3
Copy VTS tests from v1.2 to v1.3
Create NNAPI HAL v1.3 and add TENSOR_QUANT8_ASYMM_SIGNED OperandType
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: Ifabf28bbcfa60f8c1786256ef44dff442af99989
Merged-In: I878a4d04e65ef13f3a0ebaf64177f673958d213c
Add the initialization of the incrementalResultsPeriodicity and
maxSearchTime in the networkScan request.
The incrementalResultsPeriodicity and maxSearchTime are not
initialized in the networkScan request. So the default value is 0.
But the incrementalResultsPeriodicity and maxSearchTime
are required not to be 0 in subsequent tests.
CL ported from pag/1433565
Bug:140451434
Test: make vts && vts-tradefed run commandAndExit vts -m \
VtsHalRadioV1_2Target -t RadioHidlTest_v1_2#startNetworkScan
Change-Id: I1b4e512a37d3d85ebc905a64987a40af801bce53
(cherry picked from commit f7894eb4d8c395add7c70a20520336057ae2656f)
So that it's easier to see what actually has changed in VTS tests for
version 1.3
Bug: 139120468
Test: m
Change-Id: Ief294d21349ca6531595612a16fa3ae3382f83ac
Merged-In: Ief294d21349ca6531595612a16fa3ae3382f83ac
(cherry picked from commit 3b13b55ac1)
There are certain pieces of NeuralNetworks.h and of our various *.hal
files that ought to be kept in sync -- most notably the operand type
and operation type definitions and descriptions in our
NeuralNetworks.h and types.hal files. To avoid having to do this
manually, a tool can be employed.
The old solution to this problem is sync_enums_to_hal.py, which parses
the existing NeuralNetworks.h and types.hal files, and then rewrites
the types.hal files: It identifies the operand type and operation type
portions of the files, and in the types.hal files replaces them with
transformed versions of the portions from NeuralNetworks.h. This
approach is brittle -- it is very sensitive to the structure of the
files, as was recognized when this tool was created. Changes to those
files since the script was last updated essentially broke the script,
as noted in http://b/140132458.
The new solution employs a new tool generate_api.py to combine a
single "specification file" with one "template file" per API file
(NeuralNetworks.h or types.hal) to produce that API file. The script
generate_api.sh invokes generate_api.py once per API file, passing
appropriate arguments. See frameworks/ml/nn/tools/api/README.md for
more details.
In the process of combining information from NeuralNetworks.h and
*/types.hal, some formatting, syntactic, and semantic changes have
been made to those files. For example:
- types.hal files no longer refer to API levels or (similarly)
to HAL versions other than earlier HAL versions
Bug: 130169064
Bug: 140132458
Test: cd neuralnetworks ; mma
Change-Id: Iceb38effc2c7e6c32344e49225b85256144c0945
Merged-In: Iceb38effc2c7e6c32344e49225b85256144c0945
(cherry picked from commit 2cae5c8b01)
![](/avatar/ef4a85532a29218c6b19b60e782b0746?size=56 "Harpreet \\"Eli\\" Sangha"){kind=small}
