This document describes how to integrate the Arm NN Android NNAPI driver into an Android source tree.
<ANDROID_ROOT>
<ANDROID_ROOT>
<ANDROID_ROOT>
<ANDROID_ROOT>/vendor/arm/android-nn-driver
system/vendor/bin/hw
directory in the Android image. To update the build environment, add to the contents of the variable PRODUCT_PACKAGES
within the device-specific makefile that is located in the <ANDROID_ROOT>/device/<manufacturer>/<product>
directory. This file is normally called device.mk
:Android.mk
contains the module definition of all versions (1.0, 1.1, 1.2 and 1.3) of the Arm NN driver. For Android P, a new version of NN API is available (1.1), thus the following should be added to device.mk
instead:
For Android Q, a new version of the NN API is available (1.2), thus the following should be added to device.mk
instead:
For Android R, new version of the NN API is available (1.3), thus the following should be added to device.mk
instead:
Similarly, the Neon, CL or Reference backend can be enabled/disabled by setting ARMNN_COMPUTE_CL_ENABLE, ARMNN_COMPUTE_NEON_ENABLE or ARMNN_REF_ENABLE in device.mk
:
For Android P, Q and R the vendor manifest.xml requires the Neural Network HAL information. For Android P use HAL version 1.1 as below. For Android Q substitute 1.2 where necessary. For Android R substitute 1.3 where necessary.
<hal format="hidl"> <name>android.hardware.neuralnetworks</name> <transport>hwbinder</transport> <version>1.1</version> <interface> <name>IDevice</name> <instance>armnn</instance> </interface> <fqname>@1.1::IDevice/armnn</fqname> </hal>
make
in <ANDROID_ROOT>
Android P
For example, if the Arm NN driver has been built with the NN API 1.1, check for the following file:
Android Q and later has a different path:
NeuralNetworksTest
unit tests (note this is an optional component that must be built).ArmnnDriver
tag. Please note that you need to add ARMNN_DRIVER_DEBUG := 1 to the 'device-vendor.mk' for the logcat to be visible.The GPU tuner is a feature of the Compute Library that finds optimum values for GPU acceleration tuning parameters. There are three levels of tuning: exhaustive, normal and rapid. Exhaustive means that all lws values are tested. Normal means that a reduced number of lws values are tested, but that generally is sufficient to have a performance close enough to the exhaustive approach. Rapid means that only 3 lws values should be tested for each kernel. The recommended way of using it with Arm NN is to generate the tuning data during development of the Android image for a device, and use it in read-only mode during normal operation: