This allows NNAPI users to pass in model data from the asset folder.
Bug: 184880878
Test: nnapi demo app with model data from asset file
Test: NNAPI benchmark CTS
Change-Id: I79ded4e9f35eb15e1f9f0d91308840e8b318d218
This is a shared part that all NN HAL users otherwise would have to
define themselves.
Bug: 172922059
Test: m
Test: VtsHalNeuralnetworksTest on master (locally)
Change-Id: I3616d0afbb115bc0feaed00488855646633da915
All NNAPI drivers are expected to be able to read BLOB mode AHWBs
allocated by the client.
Bug: 147677855
Bug: 149870344
Test: m
Test: NNT_static
Change-Id: I3e4f32d039e1f229a477eb9bca613c554cc35b93
Property is NNAPI client-readable and writeable only by init/build.prop.
Bug: 129666983
Bug: 120483623
Test: flashed crosshatch/Cts tests for NNAPI
Change-Id: Ic4c0f176440610a2c54c078863f3d5382323cc65
Currently all NN services include this, so making it a default will
reduce NN service configuration.
Change-Id: I18531e57a7069076a208aefac4a545ba6c4379b0
Fixes: 120283437
Test: mma
Test: NeuralNetworksTest_static
Test: VtsHalNeuralnetworksV1_*TargetTest
Since this attribute just associates a hal_attribute
with a given hwservice in the standard way.
Bug: 80319537
Test: boot + sanity + test for denials
Change-Id: I545de165515387317e6920ce8f5e8c491f9ab24e
For sanity, this makes 'hal_attribute_hwservice_client'
be associated with a specific hwservice thus making things
consistent.
After this change, only configstore, hal_allocator, and the
fwk_* services are inconsistent with all other HALs.
Bug: 80319537
Test: boot device, sanity tests, check for denials
Change-Id: Ibffc65c9567a429e07a3dc4dd41117738459dc2a
Before, it was possible to access a hwservice without declaring
that you were a client.
This introduces the following macro:
hal_attribute_hwservice_client(hal_foo, hal_foo_hwservice)
which makes sure the above implication holds using a neverallow rule.
Bug: 80319537
Test: boot + sanity
Change-Id: Iededae68f14f0f3bd412c1205aa3b650a54d55c6
