Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Driver Neural Networks API

Halaman ini memberikan ringkasan tentang cara menerapkan driver Neural Networks API (NNAPI). Untuk mengetahui detail selengkapnya, lihat dokumentasi yang ada di file definisi HAL di hardware/interfaces/neuralnetworks. Contoh penerapan driver ada di frameworks/ml/nn/driver/sample.

Untuk mengetahui informasi selengkapnya tentang Neural Networks API, lihat Neural Networks API.

HAL Jaringan Neural

HAL Jaringan Neural (NN) mendefinisikan abstraksi berbagai perangkat, seperti unit pemrosesan grafis (GPU) dan prosesor sinyal digital (DSP), yang ada dalam produk (misalnya, ponsel atau tablet). Driver untuk perangkat ini harus sesuai dengan NN HAL. Antarmuka ditentukan dalam file definisi HAL di hardware/interfaces/neuralnetworks.

Alur umum antarmuka antara framework dan driver digambarkan pada gambar 1.

Alur Jaringan Neural

Gambar 1. Alur Jaringan Neural

Inisialisasi

Saat inisialisasi, framework mengkueri kemampuan driver menggunakan IDevice::getCapabilities_1_3. Struktur @1.3::Capabilities mencakup semua jenis data dan merepresentasikan performa yang tidak dioptimalkan menggunakan vektor.

Untuk menentukan cara mengalokasikan komputasi ke perangkat yang tersedia, framework menggunakan kemampuan untuk memahami seberapa cepat dan seberapa hemat energi setiap driver dapat melakukan eksekusi. Untuk memberikan informasi ini, pengemudi harus memberikan angka performa standar berdasarkan eksekusi beban kerja referensi.

Untuk menentukan nilai yang ditampilkan driver sebagai respons terhadap IDevice::getCapabilities_1_3, gunakan aplikasi tolok ukur NNAPI untuk mengukur performa untuk jenis data yang sesuai. Model MobileNet v1 dan v2, asr_float, dan tts_float direkomendasikan untuk mengukur performa nilai floating point 32-bit dan model terkuantisasi MobileNet v1 dan v2 direkomendasikan untuk nilai terkuantisasi 8-bit. Untuk mengetahui informasi selengkapnya, lihat Android Machine Learning Test Suite.

Di Android 9 dan yang lebih lama, struktur Capabilities hanya mencakup informasi performa driver untuk tensor floating point dan terkuantisasi, serta tidak mencakup jenis data skalar.

Sebagai bagian dari proses inisialisasi, framework dapat meminta informasi lebih lanjut, menggunakan IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, dan IDevice::getNumberOfCacheFilesNeeded.

Di antara reboot produk, framework mengharapkan semua kueri yang dijelaskan di bagian ini selalu melaporkan nilai yang sama untuk driver tertentu. Jika tidak, aplikasi yang menggunakan driver tersebut mungkin menunjukkan penurunan performa atau perilaku yang salah.

Kompilasi

Framework menentukan perangkat mana yang akan digunakan saat menerima permintaan dari aplikasi. Di Android 10, aplikasi dapat menemukan dan menentukan perangkat yang dipilih oleh framework. Untuk mengetahui informasi selengkapnya, lihat Penemuan dan Penugasan Perangkat.

Pada waktu kompilasi model, framework mengirimkan model ke setiap driver kandidat dengan memanggil IDevice::getSupportedOperations_1_3. Setiap driver menampilkan array boolean yang menunjukkan operasi model mana yang didukung. Driver dapat menentukan bahwa driver tidak dapat mendukung operasi tertentu karena sejumlah alasan. Contoh:

Driver tidak mendukung jenis data.
Driver hanya mendukung operasi dengan parameter input tertentu. Misalnya, driver mungkin mendukung operasi konvolusi 3x3 dan 5x5, tetapi tidak mendukung operasi konvolusi 7x7.
Driver memiliki batasan memori yang mencegahnya menangani grafik atau input yang besar.

Selama kompilasi, input, output, dan operand internal model, seperti yang dijelaskan dalam OperandLifeTime, dapat memiliki dimensi atau urutan yang tidak diketahui. Untuk mengetahui informasi selengkapnya, lihat Bentuk output.

Framework menginstruksikan setiap driver yang dipilih untuk bersiap mengeksekusi subset model dengan memanggil IDevice::prepareModel_1_3. Setiap driver kemudian mengompilasi subsetnya. Misalnya, driver dapat membuat kode atau membuat salinan bobot yang diurutkan ulang. Karena ada jangka waktu yang cukup lama antara kompilasi model dan eksekusi permintaan, resource seperti potongan besar memori perangkat tidak boleh ditetapkan selama kompilasi.

Jika berhasil, driver akan menampilkan handle @1.3::IPreparedModel. Jika driver menampilkan kode kegagalan saat menyiapkan subset modelnya, framework akan menjalankan seluruh model di CPU.

Untuk mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat meng-cache artefak kompilasi. Untuk mengetahui informasi selengkapnya, lihat Caching Kompilasi.

Eksekusi

Saat aplikasi meminta framework untuk mengeksekusi permintaan, framework akan memanggil metode HAL IPreparedModel::executeSynchronously_1_3 secara default untuk melakukan eksekusi sinkron pada model yang telah disiapkan. Permintaan juga dapat dieksekusi secara asinkron menggunakan metode execute_1_3, metode executeFenced (lihat Eksekusi tertutup), atau dieksekusi menggunakan eksekusi burst.

Panggilan eksekusi sinkron meningkatkan performa dan mengurangi overhead threading dibandingkan dengan panggilan asinkron karena kontrol dikembalikan ke proses aplikasi hanya setelah eksekusi selesai. Artinya, driver tidak memerlukan mekanisme terpisah untuk memberi tahu proses aplikasi bahwa eksekusi telah selesai.

Dengan metode execute_1_3 asinkron, kontrol kembali ke proses aplikasi setelah eksekusi dimulai, dan driver harus memberi tahu framework saat eksekusi selesai, menggunakan @1.3::IExecutionCallback.

Parameter Request yang diteruskan ke metode eksekusi mencantumkan operand input dan output yang digunakan untuk eksekusi. Memori yang menyimpan data operand harus menggunakan urutan baris-utama dengan dimensi pertama yang beriterasi paling lambat dan tidak memiliki padding di akhir baris mana pun. Untuk mengetahui informasi selengkapnya tentang jenis operand, lihat Operand.

Untuk driver NN HAL 1.2 atau yang lebih tinggi, saat permintaan selesai, status error, bentuk output, dan informasi waktu akan ditampilkan ke framework. Selama eksekusi, output atau operand internal model dapat memiliki satu atau beberapa dimensi yang tidak diketahui atau urutan yang tidak diketahui. Jika setidaknya satu operand output memiliki dimensi atau peringkat yang tidak diketahui, driver harus menampilkan informasi output berukuran dinamis.

Untuk driver dengan NN HAL 1.1 atau yang lebih rendah, hanya status error yang ditampilkan saat permintaan selesai. Dimensi untuk operand input dan output harus ditentukan sepenuhnya agar eksekusi berhasil diselesaikan. Operand internal dapat memiliki satu atau beberapa dimensi yang tidak diketahui, tetapi harus memiliki urutan yang ditentukan.

Untuk permintaan pengguna yang mencakup beberapa driver, framework bertanggung jawab untuk memesan memori perantara dan untuk mengurutkan panggilan ke setiap driver.

Beberapa permintaan dapat dimulai secara paralel pada @1.3::IPreparedModel yang sama. Driver dapat menjalankan permintaan secara paralel atau melakukan serialisasi eksekusi.

Framework dapat meminta driver untuk menyimpan lebih dari satu model yang disiapkan. Misalnya, siapkan model m1, siapkan m2, jalankan permintaan r1 di m1, jalankan r2 di m2, jalankan r3 di m1, jalankan r4 di m2, lepaskan (dijelaskan di Pembersihan) m1, dan lepaskan m2.

Untuk menghindari eksekusi pertama yang lambat yang dapat menyebabkan pengalaman pengguna yang buruk (misalnya, frame pertama tersendat-sendat), driver harus melakukan sebagian besar inisialisasi pada fase kompilasi. Inisialisasi pada eksekusi pertama harus dibatasi pada tindakan yang berdampak negatif pada kesehatan sistem jika dilakukan lebih awal, seperti mencadangkan buffer sementara yang besar atau meningkatkan kecepatan clock perangkat. Driver yang hanya dapat menyiapkan sejumlah model serentak yang terbatas mungkin harus melakukan inisialisasi pada eksekusi pertama.

Di Android 10 atau yang lebih tinggi, jika beberapa eksekusi dengan model yang sama yang telah disiapkan dieksekusi secara berurutan dengan cepat, klien dapat memilih untuk menggunakan objek burst eksekusi untuk berkomunikasi antara proses aplikasi dan driver. Untuk mengetahui informasi selengkapnya, lihat Eksekusi Burst dan Antrean Pesan Cepat.

Untuk meningkatkan performa beberapa eksekusi yang berurutan dengan cepat, driver dapat menyimpan buffer sementara atau meningkatkan kecepatan clock. Membuat thread watchdog direkomendasikan untuk melepaskan resource jika tidak ada permintaan baru yang dibuat setelah jangka waktu tetap.

Bentuk output

Untuk permintaan yang satu atau beberapa operan outputnya tidak memiliki semua dimensi yang ditentukan, driver harus memberikan daftar bentuk output yang berisi informasi dimensi untuk setiap operan output setelah eksekusi. Untuk mengetahui informasi selengkapnya tentang dimensi, lihat OutputShape.

Jika eksekusi gagal karena buffer output yang terlalu kecil, driver harus menunjukkan operand output mana yang memiliki ukuran buffer tidak memadai dalam daftar bentuk output, dan harus melaporkan informasi dimensi sebanyak mungkin, menggunakan nol untuk dimensi yang tidak diketahui.

Waktu

Di Android 10, aplikasi dapat meminta waktu eksekusi jika aplikasi telah menentukan satu perangkat untuk digunakan selama proses kompilasi. Untuk mengetahui detailnya, lihat MeasureTiming dan Penemuan dan Penetapan Perangkat. Dalam hal ini, driver NN HAL 1.2 harus mengukur durasi eksekusi atau melaporkan UINT64_MAX (untuk menunjukkan bahwa durasi tidak tersedia) saat mengeksekusi permintaan. Driver harus meminimalkan penalti performa yang diakibatkan oleh pengukuran durasi eksekusi.

Driver melaporkan durasi berikut dalam mikrodetik dalam struktur Timing:

Waktu eksekusi di perangkat: Tidak termasuk waktu eksekusi di driver, yang berjalan di prosesor host.
Waktu eksekusi di driver: Mencakup waktu eksekusi di perangkat.

Durasi ini harus mencakup waktu saat eksekusi ditangguhkan, misalnya, saat eksekusi telah didahului oleh tugas lain atau saat menunggu resource tersedia.

Jika driver belum diminta untuk mengukur durasi eksekusi, atau jika terjadi error eksekusi, driver harus melaporkan durasi sebagai UINT64_MAX. Meskipun driver telah diminta untuk mengukur durasi eksekusi, driver dapat melaporkan UINT64_MAX untuk waktu di perangkat, waktu di driver, atau keduanya. Jika driver melaporkan kedua durasi sebagai nilai selain UINT64_MAX, waktu eksekusi di driver harus sama dengan atau melebihi waktu di perangkat.

Eksekusi yang dibatasi

Di Android 11, NNAPI memungkinkan eksekusi menunggu daftar handle sync_fence dan secara opsional menampilkan objek sync_fence, yang diberi sinyal saat eksekusi selesai. Hal ini mengurangi overhead untuk model urutan kecil dan kasus penggunaan streaming. Eksekusi yang dibatasi juga memungkinkan interoperabilitas yang lebih efisien dengan komponen lain yang dapat memberi sinyal atau menunggu sync_fence. Untuk mengetahui informasi selengkapnya tentang sync_fence, lihat Framework sinkronisasi.

Dalam eksekusi dengan fence, framework memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron dengan fence pada model yang disiapkan dengan vektor fence sinkronisasi untuk ditunggu. Jika tugas asinkron selesai sebelum panggilan ditampilkan, handle kosong dapat ditampilkan untuk sync_fence. Objek IFencedExecutionCallback juga harus ditampilkan agar framework dapat mengkueri informasi status dan durasi error.

Setelah eksekusi selesai, dua nilai waktu berikut yang mengukur durasi eksekusi dapat dikueri melalui IFencedExecutionCallback::getExecutionInfo.

timingLaunched: Durasi dari saat executeFenced dipanggil hingga saat executeFenced memberi sinyal syncFence yang ditampilkan.
timingFenced: Durasi sejak semua penghalang sinkronisasi yang ditunggu eksekusi diberi sinyal hingga executeFenced memberi sinyal syncFence yang ditampilkan.

Alur kontrol

Untuk perangkat yang menjalankan Android 11 atau yang lebih tinggi, NNAPI menyertakan dua operasi alur kontrol, IF dan WHILE, yang menggunakan model lain sebagai argumen dan mengeksekusinya secara bersyarat (IF) atau berulang kali (WHILE). Untuk mengetahui informasi selengkapnya tentang cara mengimplementasikannya, lihat Alur kontrol.

Kualitas layanan

Di Android 11, NNAPI menyertakan kualitas layanan (QoS) yang ditingkatkan dengan memungkinkan aplikasi menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diperkirakan untuk menyiapkan model, dan jumlah waktu maksimum yang diperkirakan untuk menyelesaikan eksekusi. Untuk mengetahui informasi selengkapnya, lihat Quality of Service.

Pembersihan

Setelah aplikasi selesai menggunakan model yang disiapkan, framework akan melepaskan referensinya ke objek @1.3::IPreparedModel. Jika objek IPreparedModel tidak lagi dirujuk, objek tersebut akan dihancurkan secara otomatis di layanan driver yang membuatnya. Resource khusus model dapat diklaim kembali saat ini dalam implementasi destruktor driver. Jika layanan driver ingin objek IPreparedModel dihancurkan secara otomatis saat tidak lagi diperlukan oleh klien, layanan tersebut tidak boleh menyimpan referensi apa pun ke objek IPreparedModel setelah objek IPreparedeModel ditampilkan melalui IPreparedModelCallback::notify_1_3.

Penggunaan CPU

Driver diharapkan menggunakan CPU untuk menyiapkan komputasi. Driver tidak boleh menggunakan CPU untuk melakukan komputasi grafik karena hal itu mengganggu kemampuan framework untuk mengalokasikan tugas dengan benar. Driver harus melaporkan bagian yang tidak dapat ditanganinya ke framework dan membiarkan framework menangani sisanya.

Framework ini menyediakan implementasi CPU untuk semua operasi NNAPI, kecuali untuk operasi yang ditentukan vendor. Untuk mengetahui informasi selengkapnya, lihat Ekstensi Vendor.

Operasi yang diperkenalkan di Android 10 (level API 29) hanya memiliki implementasi CPU referensi untuk memverifikasi bahwa pengujian CTS dan VTS sudah benar. Implementasi yang dioptimalkan yang disertakan dalam framework machine learning seluler lebih disukai daripada implementasi CPU NNAPI.

Fungsi utilitas

Kode dasar NNAPI mencakup fungsi utilitas yang dapat digunakan oleh layanan driver.

File frameworks/ml/nn/common/include/Utils.h berisi berbagai fungsi utilitas, seperti yang digunakan untuk logging dan untuk mengonversi antara berbagai versi NN HAL.

VLogging: VLOG adalah makro wrapper di sekitar LOG Android yang hanya mencatat pesan jika tag yang sesuai ditetapkan dalam properti debug.nn.vlog. initVLogMask() harus dipanggil sebelum panggilan ke VLOG. Makro VLOG_IS_ON dapat digunakan untuk memeriksa apakah VLOG saat ini diaktifkan, sehingga kode logging yang rumit dapat dilewati jika tidak diperlukan. Nilai properti harus berupa salah satu dari berikut:
- String kosong, yang menunjukkan bahwa tidak ada logging yang akan dilakukan.
- Token 1 atau all, yang menunjukkan bahwa semua logging harus dilakukan.
- Daftar tag, yang dipisahkan dengan spasi, koma, atau titik dua, yang menunjukkan logging mana yang akan dilakukan. Tagnya adalah compilation, cpuexe, driver, execution, manager, dan model.
compliantWithV1_*: Menampilkan true jika objek NN HAL dapat dikonversi ke jenis yang sama dari versi HAL yang berbeda tanpa kehilangan informasi. Misalnya, memanggil compliantWithV1_0 pada V1_2::Model akan menampilkan false jika model menyertakan jenis operasi yang diperkenalkan di NN HAL 1.1 atau NN HAL 1.2.
convertToV1_*: Mengonversi objek NN HAL dari satu versi ke versi lainnya. Peringatan dicatat jika konversi menyebabkan hilangnya informasi (yaitu, jika versi baru jenis tidak dapat sepenuhnya merepresentasikan nilai).
Kemampuan: Fungsi nonExtensionOperandPerformance dan update dapat digunakan untuk membantu membuat kolom Capabilities::operandPerformance.
Mengueri properti jenis: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData, nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

File frameworks/ml/nn/common/include/ValidateHal.h berisi fungsi utilitas untuk memvalidasi bahwa objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya.

validate*: Menampilkan true jika objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya. Jenis OEM dan jenis ekstensi tidak divalidasi. Misalnya, validateModel menampilkan false jika model berisi operasi yang mereferensikan indeks operand yang tidak ada, atau operasi yang tidak didukung pada versi HAL tersebut.

File frameworks/ml/nn/common/include/Tracing.h berisi makro untuk menyederhanakan penambahan informasi systracing ke kode Jaringan Neural. Sebagai contoh, lihat pemanggilan makro NNTRACE_* di driver contoh.

File frameworks/ml/nn/common/include/GraphDump.h berisi fungsi utilitas untuk menampilkan konten Model dalam bentuk grafis untuk tujuan proses debug.

graphDump: Menulis representasi model dalam format Graphviz (.dot) ke stream yang ditentukan (jika disediakan) atau ke logcat (jika tidak ada stream yang disediakan).

Validasi

Untuk menguji penerapan NNAPI Anda, gunakan pengujian VTS dan CTS yang disertakan dalam framework Android. VTS melatih driver Anda secara langsung (tanpa menggunakan framework), sedangkan CTS melatihnya secara tidak langsung melalui framework. Pengujian ini menguji setiap metode API dan memverifikasi bahwa semua operasi yang didukung oleh driver berfungsi dengan benar dan memberikan hasil yang memenuhi persyaratan presisi.

Persyaratan presisi di CTS dan VTS untuk NNAPI adalah sebagai berikut:

Floating point: abs(expected - actual) <= atol + rtol * abs(expected); dengan:
- Untuk fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
- Untuk fp16, atol = rtol = 5.0f * 0.0009765625f
Dikuantisasi: selisih satu (kecuali mobilenet_quantized, yang selisih tiga)
Boolean: pencocokan persis

Salah satu cara CTS menguji NNAPI adalah dengan membuat grafik pseudorandom tetap yang digunakan untuk menguji dan membandingkan hasil eksekusi dari setiap driver dengan implementasi referensi NNAPI. Untuk driver dengan NN HAL 1.2 atau yang lebih tinggi, jika hasilnya tidak memenuhi kriteria presisi, CTS akan melaporkan error dan mengekspor file spesifikasi untuk model yang gagal di /data/local/tmp untuk proses debug. Untuk mengetahui detail selengkapnya tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h.

Uji kegagalan (fuzz testing)

Tujuan pengujian fuzz adalah untuk menemukan error, pernyataan, pelanggaran memori, atau perilaku tidak terdefinisi umum dalam kode yang sedang diuji karena faktor-faktor seperti input yang tidak terduga. Untuk pengujian fuzz NNAPI, Android menggunakan pengujian berdasarkan libFuzzer, yang efisien dalam melakukan fuzzing karena menggunakan cakupan baris kasus pengujian sebelumnya untuk membuat input acak baru. Misalnya, libFuzzer lebih memilih kasus pengujian yang berjalan di baris kode baru. Hal ini sangat mengurangi waktu yang diperlukan pengujian untuk menemukan kode bermasalah.

Untuk melakukan pengujian fuzz guna memvalidasi penerapan driver, ubah frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp di utilitas pengujian libneuralnetworks_driver_fuzzer yang ada di AOSP untuk menyertakan kode driver Anda. Untuk mengetahui informasi selengkapnya tentang pengujian fuzz NNAPI, lihat frameworks/ml/nn/runtime/test/android_fuzzing/README.md.

Keamanan

Karena proses aplikasi berkomunikasi langsung dengan proses driver, driver harus memvalidasi argumen panggilan yang mereka terima. Validasi ini diverifikasi oleh VTS. Kode validasi ada di frameworks/ml/nn/common/include/ValidateHal.h.

Driver juga harus memastikan bahwa aplikasi tidak dapat mengganggu aplikasi lain saat menggunakan perangkat yang sama.

Android Machine Learning Test Suite

Android Machine Learning Test Suite (MLTS) adalah tolok ukur NNAPI yang disertakan dalam CTS dan VTS untuk memvalidasi akurasi model nyata di perangkat vendor. Tolok ukur mengevaluasi latensi dan akurasi, serta membandingkan hasil driver dengan hasil menggunakan TF Lite yang berjalan di CPU, untuk model dan set data yang sama. Hal ini memastikan bahwa akurasi driver tidak lebih buruk daripada penerapan referensi CPU.

Developer platform Android juga menggunakan MLTS untuk mengevaluasi latensi dan akurasi driver.

Tolok ukur NNAPI dapat ditemukan di dua project di AOSP:

platform/test/mlts/benchmark (aplikasi benchmark)
platform/test/mlts/models (model dan set data)

Model dan set data

Tolok ukur NNAPI menggunakan model dan set data berikut.

MobileNetV1 float dan u8 yang dikuantisasi dalam berbagai ukuran, dijalankan terhadap subkumpulan kecil (1.500 gambar) Open Images Dataset v4.
MobileNetV2 float dan u8 yang dikuantisasi dalam berbagai ukuran, dijalankan terhadap subset kecil (1.500 gambar) Open Images Dataset v4.
Model akustik berbasis long short-term memory (LSTM) untuk text-to-speech, dijalankan terhadap subset kecil dari set CMU Arctic.
Model akustik berbasis LSTM untuk pengenalan ucapan otomatis, dijalankan terhadap subset kecil dari set data LibriSpeech.

Untuk mengetahui informasi selengkapnya, lihat platform/test/mlts/models.

Pengujian daya tahan

Android Machine Learning Test Suite mencakup serangkaian uji crash untuk memvalidasi ketahanan driver dalam kondisi penggunaan berat atau dalam kasus ekstrem perilaku klien.

Semua uji error menyediakan fitur berikut:

Deteksi hang: Jika klien NNAPI mengalami hang selama pengujian, pengujian akan gagal dengan alasan kegagalan HANG dan rangkaian pengujian akan beralih ke pengujian berikutnya.
Deteksi error klien NNAPI: Pengujian tetap berjalan saat klien mengalami error dan pengujian gagal dengan alasan kegagalan CRASH.
Deteksi kecelakaan pengemudi: Pengujian dapat mendeteksi kecelakaan pengemudi yang menyebabkan kegagalan pada panggilan NNAPI. Perhatikan bahwa mungkin ada error dalam proses driver yang tidak menyebabkan kegagalan NNAPI dan tidak menyebabkan kegagalan pengujian. Untuk mengatasi kegagalan semacam ini, sebaiknya jalankan perintah tail pada log sistem untuk error atau kerusakan terkait driver.
Penargetan semua akselerator yang tersedia: Pengujian dijalankan terhadap semua driver yang tersedia.

Semua uji tabrakan memiliki empat kemungkinan hasil berikut:

SUCCESS: Eksekusi selesai tanpa error.
FAILURE: Eksekusi gagal. Biasanya disebabkan oleh kegagalan saat menguji model, yang menunjukkan bahwa driver gagal mengompilasi atau mengeksekusi model.
HANG: Proses pengujian menjadi tidak responsif.
CRASH: Proses pengujian mengalami error.

Untuk mengetahui informasi selengkapnya tentang pengujian beban dan daftar lengkap pengujian error, lihat platform/test/mlts/benchmark/README.txt.

Menggunakan MLTS

Untuk menggunakan MLTS:

Hubungkan perangkat target ke workstation dan pastikan perangkat dapat dijangkau melalui adb. Ekspor variabel lingkungan ANDROID_SERIAL perangkat target jika ada lebih dari satu perangkat yang terhubung.
cd ke direktori sumber level teratas Android.
```
source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh
```
Di akhir proses tolok ukur, hasilnya akan disajikan sebagai halaman HTML dan diteruskan ke xdg-open.

Untuk mengetahui informasi selengkapnya, lihat platform/test/mlts/benchmark/README.txt.

Versi HAL Jaringan Neural

Bagian ini menjelaskan perubahan yang diperkenalkan di versi HAL Android dan Neural Network.

Android 11

Android 11 memperkenalkan NN HAL 1.3, yang mencakup perubahan penting berikut.

Dukungan untuk kuantisasi 8-bit bertanda tangan di NNAPI. Menambahkan jenis operand TENSOR_QUANT8_ASYMM_SIGNED. Driver dengan NN HAL 1.3 yang mendukung operasi dengan kuantisasi yang tidak bertanda juga harus mendukung varian bertanda dari operasi tersebut. Saat menjalankan versi bertanda tangan dan tidak bertanda tangan dari sebagian besar operasi terkuantisasi, driver harus menghasilkan hasil yang sama hingga offset 128. Ada lima pengecualian untuk persyaratan ini: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2, dan QUANTIZED_16BIT_LSTM. Operasi QUANTIZED_16BIT_LSTM tidak mendukung operand bertanda dan empat operasi lainnya mendukung kuantisasi bertanda, tetapi tidak mengharuskan hasilnya sama.
Dukungan untuk eksekusi dengan fence saat framework memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron dengan fence pada model yang disiapkan dengan vektor fence sinkronisasi untuk ditunggu. Untuk mengetahui informasi selengkapnya, lihat Eksekusi yang dibatasi.
Dukungan untuk alur kontrol. Menambahkan operasi IF dan WHILE, yang menggunakan model lain sebagai argumen dan mengeksekusinya secara kondisional (IF) atau berulang kali (WHILE). Untuk mengetahui informasi selengkapnya, lihat Alur kontrol.
Kualitas layanan (QoS) yang ditingkatkan karena aplikasi dapat menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diperkirakan untuk menyiapkan model, dan jumlah waktu maksimum yang diperkirakan untuk menyelesaikan eksekusi. Untuk mengetahui informasi selengkapnya, lihat Quality of Service.
Dukungan untuk domain memori yang menyediakan antarmuka pengalokasi untuk buffer yang dikelola driver. Hal ini memungkinkan penerusan memori native perangkat di seluruh eksekusi, sehingga tidak perlu menyalin dan mengubah data yang tidak perlu di antara eksekusi berurutan pada driver yang sama. Untuk mengetahui informasi selengkapnya, lihat Domain memori.

Android 10

Android 10 memperkenalkan NN HAL 1.2, yang mencakup perubahan penting berikut.

Struktur Capabilities mencakup semua jenis data, termasuk jenis data skalar, dan merepresentasikan performa yang tidak dioptimalkan menggunakan vektor, bukan kolom bernama.
Metode getVersionString dan getType memungkinkan framework mengambil informasi jenis perangkat (DeviceType) dan versi. Lihat Penemuan dan Penetapan Perangkat.
Metode executeSynchronously dipanggil secara default untuk melakukan eksekusi secara sinkron. Metode execute_1_2 memberi tahu framework untuk melakukan eksekusi secara asinkron. Lihat Eksekusi.
Parameter MeasureTiming ke executeSynchronously, execute_1_2, dan eksekusi burst menentukan apakah driver akan mengukur durasi eksekusi. Hasilnya dilaporkan dalam struktur Timing. Lihat Waktu.
Dukungan untuk eksekusi saat satu atau beberapa operan output memiliki dimensi atau peringkat yang tidak diketahui. Lihat Bentuk output.
Dukungan untuk ekstensi vendor, yang merupakan kumpulan operasi dan jenis data yang ditentukan vendor. Driver melaporkan ekstensi yang didukung melalui metode IDevice::getSupportedExtensions. Lihat Ekstensi Vendor.
Kemampuan objek burst untuk mengontrol serangkaian eksekusi burst menggunakan antrean pesan cepat (FMQ) untuk berkomunikasi antara proses aplikasi dan driver, sehingga mengurangi latensi. Lihat Eksekusi Burst dan Antrean Pesan Cepat.
Dukungan untuk AHardwareBuffer agar driver dapat melakukan eksekusi tanpa menyalin data. Lihat AHardwareBuffer.
Peningkatan dukungan untuk menyimpan artefak kompilasi dalam cache guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai. Lihat Caching Kompilasi.

Android 10 memperkenalkan jenis dan operasi operand berikut.

Jenis operand
- ANEURALNETWORKS_BOOL
- ANEURALNETWORKS_FLOAT16
- ANEURALNETWORKS_TENSOR_BOOL8
- ANEURALNETWORKS_TENSOR_FLOAT16
- ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
- ANEURALNETWORKS_TENSOR_QUANT16_SYMM
- ANEURALNETWORKS_TENSOR_QUANT8_SYMM
- ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL
Operasi
- ANEURALNETWORKS_ABS
- ANEURALNETWORKS_ARGMAX
- ANEURALNETWORKS_ARGMIN
- ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
- ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
- ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
- ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
- ANEURALNETWORKS_CAST
- ANEURALNETWORKS_CHANNEL_SHUFFLE
- ANEURALNETWORKS_DETECTION_POSTPROCESSING
- ANEURALNETWORKS_EQUAL
- ANEURALNETWORKS_EXP
- ANEURALNETWORKS_EXPAND_DIMS
- ANEURALNETWORKS_GATHER
- ANEURALNETWORKS_GENERATE_PROPOSALS
- ANEURALNETWORKS_GREATER
- ANEURALNETWORKS_GREATER_EQUAL
- ANEURALNETWORKS_GROUPED_CONV_2D
- ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
- ANEURALNETWORKS_INSTANCE_NORMALIZATION
- ANEURALNETWORKS_LESS
- ANEURALNETWORKS_LESS_EQUAL
- ANEURALNETWORKS_LOG
- ANEURALNETWORKS_LOGICAL_AND
- ANEURALNETWORKS_LOGICAL_NOT
- ANEURALNETWORKS_LOGICAL_OR
- ANEURALNETWORKS_LOG_SOFTMAX
- ANEURALNETWORKS_MAXIMUM
- ANEURALNETWORKS_MINIMUM
- ANEURALNETWORKS_NEG
- ANEURALNETWORKS_NOT_EQUAL
- ANEURALNETWORKS_PAD_V2
- ANEURALNETWORKS_POW
- ANEURALNETWORKS_PRELU
- ANEURALNETWORKS_QUANTIZE
- ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
- ANEURALNETWORKS_RANDOM_MULTINOMIAL
- ANEURALNETWORKS_REDUCE_ALL
- ANEURALNETWORKS_REDUCE_ANY
- ANEURALNETWORKS_REDUCE_MAX
- ANEURALNETWORKS_REDUCE_MIN
- ANEURALNETWORKS_REDUCE_PROD
- ANEURALNETWORKS_REDUCE_SUM
- ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
- ANEURALNETWORKS_ROI_ALIGN
- ANEURALNETWORKS_ROI_POOLING
- ANEURALNETWORKS_RSQRT
- ANEURALNETWORKS_SELECT
- ANEURALNETWORKS_SIN
- ANEURALNETWORKS_SLICE
- ANEURALNETWORKS_SPLIT
- ANEURALNETWORKS_SQRT
- ANEURALNETWORKS_TILE
- ANEURALNETWORKS_TOPK_V2
- ANEURALNETWORKS_TRANSPOSE_CONV_2D
- ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
- ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

Android 10 memperkenalkan update pada banyak operasi yang ada. Pembaruan ini terutama terkait dengan hal berikut:

Dukungan untuk tata letak memori NCHW
Dukungan untuk tensor dengan peringkat yang berbeda dari 4 dalam operasi softmax dan normalisasi
Dukungan untuk konvolusi yang diperluas
Dukungan untuk input dengan kuantisasi campuran di ANEURALNETWORKS_CONCATENATION

Daftar di bawah menunjukkan operasi yang diubah di Android 10. Untuk mengetahui detail lengkap perubahan, lihat OperationCode dalam dokumentasi referensi NNAPI.

ANEURALNETWORKS_ADD
ANEURALNETWORKS_AVERAGE_POOL_2D
ANEURALNETWORKS_BATCH_TO_SPACE_ND
ANEURALNETWORKS_CONCATENATION
ANEURALNETWORKS_CONV_2D
ANEURALNETWORKS_DEPTHWISE_CONV_2D
ANEURALNETWORKS_DEPTH_TO_SPACE
ANEURALNETWORKS_DEQUANTIZE
ANEURALNETWORKS_DIV
ANEURALNETWORKS_FLOOR
ANEURALNETWORKS_FULLY_CONNECTED
ANEURALNETWORKS_L2_NORMALIZATION
ANEURALNETWORKS_L2_POOL_2D
ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
ANEURALNETWORKS_LOGISTIC
ANEURALNETWORKS_LSH_PROJECTION
ANEURALNETWORKS_LSTM
ANEURALNETWORKS_MAX_POOL_2D
ANEURALNETWORKS_MEAN
ANEURALNETWORKS_MUL
ANEURALNETWORKS_PAD
ANEURALNETWORKS_RELU
ANEURALNETWORKS_RELU1
ANEURALNETWORKS_RELU6
ANEURALNETWORKS_RESHAPE
ANEURALNETWORKS_RESIZE_BILINEAR
ANEURALNETWORKS_RNN
ANEURALNETWORKS_ROI_ALIGN
ANEURALNETWORKS_SOFTMAX
ANEURALNETWORKS_SPACE_TO_BATCH_ND
ANEURALNETWORKS_SPACE_TO_DEPTH
ANEURALNETWORKS_SQUEEZE
ANEURALNETWORKS_STRIDED_SLICE
ANEURALNETWORKS_SUB
ANEURALNETWORKS_SVDF
ANEURALNETWORKS_TANH
ANEURALNETWORKS_TRANSPOSE

Android 9

NN HAL 1.1 diperkenalkan di Android 9 dan mencakup perubahan penting berikut.

IDevice::prepareModel_1_1 menyertakan parameter ExecutionPreference. Driver dapat menggunakan ini untuk menyesuaikan persiapannya, dengan mengetahui bahwa aplikasi lebih memilih untuk menghemat daya baterai atau akan menjalankan model dalam panggilan berurutan yang cepat.
Sembilan operasi baru telah ditambahkan: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE.
Aplikasi dapat menentukan bahwa komputasi float 32-bit dapat dijalankan menggunakan rentang dan/atau presisi float 16-bit dengan menyetel Model.relaxComputationFloat32toFloat16 ke true. Struktur Capabilities memiliki kolom tambahan relaxedFloat32toFloat16Performance sehingga driver dapat melaporkan performa yang lebih ringan ke framework.

Android 8.1

HAL Jaringan Neural (1.0) awal dirilis di Android 8.1. Untuk mengetahui informasi selengkapnya, lihat /neuralnetworks/1.0/.