Gambar di bawah mewakili tumpukan sensor Android. Setiap komponen hanya berkomunikasi dengan komponen yang berada tepat di atas dan di bawahnya, meskipun beberapa sensor dapat melewati hub sensor jika ada. Kontrol mengalir dari aplikasi ke sensor, dan data mengalir dari sensor ke aplikasi.
Gambar 1. Lapisan tumpukan sensor Android dan pemiliknya masing-masing
SDK
Aplikasi mengakses sensor melalui Sensors SDK (Software Development Kit) API . SDK berisi fungsi untuk membuat daftar sensor yang tersedia dan untuk mendaftar ke suatu sensor.
Saat mendaftar ke sensor, aplikasi menentukan frekuensi pengambilan sampel yang diinginkan dan persyaratan latensinya.
- Misalnya, sebuah aplikasi mungkin mendaftar ke akselerometer default, meminta kejadian pada 100Hz, dan mengizinkan kejadian dilaporkan dengan latensi 1 detik.
- Aplikasi akan menerima kejadian dari akselerometer dengan kecepatan minimal 100Hz, dan mungkin tertunda hingga 1 detik.
Lihat dokumentasi pengembang untuk informasi lebih lanjut tentang SDK.
Kerangka
Framework ini bertugas menghubungkan beberapa aplikasi ke HAL . HAL itu sendiri adalah klien tunggal. Tanpa terjadinya multiplexing pada tingkat kerangka kerja, hanya satu aplikasi yang dapat mengakses setiap sensor pada waktu tertentu.
- Ketika aplikasi pertama mendaftar ke sensor, kerangka kerja mengirimkan permintaan ke HAL untuk mengaktifkan sensor.
- Ketika aplikasi tambahan mendaftar ke sensor yang sama, kerangka kerja memperhitungkan persyaratan dari setiap aplikasi dan mengirimkan parameter yang diminta diperbarui ke HAL.
- Frekuensi pengambilan sampel akan menjadi frekuensi pengambilan sampel maksimum yang diminta, artinya beberapa aplikasi akan menerima peristiwa pada frekuensi yang lebih tinggi daripada yang diminta.
- Latensi pelaporan maksimum akan menjadi minimum yang diminta. Jika satu aplikasi meminta satu sensor dengan latensi pelaporan maksimum 0, semua aplikasi akan menerima peristiwa dari sensor ini dalam mode berkelanjutan meskipun beberapa aplikasi meminta sensor dengan latensi pelaporan maksimum bukan nol. Lihat Pengelompokan untuk lebih jelasnya.
- Ketika aplikasi terakhir yang terdaftar pada satu sensor dibatalkan pendaftarannya, kerangka kerja mengirimkan permintaan ke HAL untuk menonaktifkan sensor sehingga daya tidak dikonsumsi secara tidak perlu.
Dampak multipleksing
Kebutuhan akan lapisan multiplexing dalam kerangka ini menjelaskan beberapa keputusan desain.
- Saat aplikasi meminta frekuensi pengambilan sampel tertentu, tidak ada jaminan bahwa peristiwa tidak akan terjadi dengan kecepatan yang lebih cepat. Jika aplikasi lain meminta sensor yang sama dengan kecepatan lebih cepat, aplikasi pertama juga akan menerimanya dengan kecepatan lebih tinggi.
- Kurangnya jaminan yang sama juga berlaku pada latensi pelaporan maksimum yang diminta: aplikasi mungkin menerima kejadian dengan latensi yang jauh lebih kecil daripada yang diminta.
- Selain frekuensi pengambilan sampel dan latensi pelaporan maksimum, aplikasi tidak dapat mengonfigurasi parameter sensor.
- Misalnya, bayangkan sebuah sensor fisik yang dapat berfungsi dalam mode “akurasi tinggi” dan “daya rendah”.
- Hanya satu dari dua mode tersebut yang dapat digunakan pada perangkat Android, karena jika tidak, aplikasi dapat meminta mode akurasi tinggi, dan satu lagi mode daya rendah; tidak akan ada cara bagi kerangka kerja untuk memenuhi kedua aplikasi tersebut. Kerangka kerja tersebut harus selalu dapat memuaskan semua kliennya, jadi ini bukanlah suatu pilihan.
- Tidak ada mekanisme untuk mengirimkan data dari aplikasi ke sensor atau drivernya. Hal ini memastikan satu aplikasi tidak dapat mengubah perilaku sensor, sehingga merusak aplikasi lain.
Fusi sensor
Framework Android menyediakan implementasi default untuk beberapa sensor komposit. Jika giroskop , akselerometer , dan magnetometer ada di perangkat, namun tidak ada sensor vektor rotasi , gravitasi , dan percepatan linier , kerangka kerja akan mengimplementasikan sensor tersebut sehingga aplikasi masih dapat menggunakannya.
Implementasi default tidak memiliki akses ke semua data yang dapat diakses oleh implementasi lain, dan harus dijalankan di SoC, sehingga tidak seakurat dan seefisien implementasi lainnya. Sebisa mungkin, produsen perangkat harus menentukan sensor gabungannya sendiri (vektor rotasi, gravitasi, dan percepatan linier, serta sensor komposit yang lebih baru seperti vektor rotasi game ) daripada mengandalkan implementasi default ini. Produsen perangkat juga dapat meminta vendor chip sensor untuk menyediakan implementasinya.
Implementasi fusi sensor default tidak dipertahankan dan mungkin menyebabkan perangkat yang mengandalkannya gagal dalam CTS.
Dibawah tenda
Bagian ini disediakan sebagai informasi latar belakang bagi mereka yang memelihara kode kerangka kerja Android Open Source Project (AOSP). Hal ini tidak relevan bagi produsen perangkat keras.
JNI
Framework ini menggunakan Java Native Interface (JNI) yang dikaitkan dengan android.hardware dan terletak di direktori frameworks/base/core/jni/ . Kode ini memanggil kode asli tingkat bawah untuk mendapatkan akses ke perangkat keras sensor.
Kerangka asli
Framework native didefinisikan dalam frameworks/native/ dan menyediakan paket native yang setara dengan paket android.hardware . Kerangka kerja asli memanggil proxy Binder IPC untuk mendapatkan akses ke layanan khusus sensor.
Pengikat IPC
Proksi Binder IPC memfasilitasi komunikasi melalui batasan proses.
HAL
API Lapisan Abstraksi Perangkat Keras Sensor (HAL) adalah antarmuka antara driver perangkat keras dan kerangka kerja Android. Ini terdiri dari satu antarmuka HAL sensor.h dan satu implementasi HAL yang kami sebut sebagai sensor.cpp.
Antarmukanya ditentukan oleh kontributor Android dan AOSP, dan implementasinya disediakan oleh produsen perangkat.
Antarmuka sensor HAL terletak di hardware/libhardware/include/hardware . Lihat sensor.h untuk detail tambahan.
Siklus rilis
Implementasi HAL menentukan versi antarmuka HAL yang diimplementasikan dengan menyetel your_poll_device.common.version . Versi antarmuka HAL yang ada ditentukan di sensor.h, dan fungsionalitas terkait dengan versi tersebut.
Kerangka kerja Android saat ini mendukung versi 1.0 dan 1.3, namun versi 1.0 tidak akan didukung lagi dalam waktu dekat. Dokumentasi ini menjelaskan perilaku versi 1.3, yang harus diupgrade oleh semua perangkat. Untuk detail tentang cara meningkatkan ke 1.3, lihat penghentian versi HAL .
Pengemudi kernel
Driver sensor berinteraksi dengan perangkat fisik. Dalam beberapa kasus, implementasi HAL dan drivernya merupakan entitas perangkat lunak yang sama. Dalam kasus lain, integrator perangkat keras meminta produsen chip sensor untuk menyediakan driver, namun merekalah yang menulis implementasi HAL.
Dalam semua kasus, implementasi HAL dan driver kernel adalah tanggung jawab produsen perangkat keras, dan Android tidak menyediakan pendekatan pilihan untuk menulisnya.
Pusat sensor
Tumpukan sensor suatu perangkat secara opsional dapat menyertakan hub sensor, berguna untuk melakukan beberapa komputasi tingkat rendah dengan daya rendah sementara SoC dapat berada dalam mode penangguhan. Misalnya, penghitungan langkah atau fusi sensor dapat dilakukan pada chip tersebut. Ini juga merupakan tempat yang baik untuk mengimplementasikan pengelompokan sensor, menambahkan FIFO perangkat keras untuk kejadian sensor. Lihat Pengelompokan untuk informasi lebih lanjut.
Catatan: Untuk mengembangkan fitur ContextHub baru yang menggunakan sensor atau LED baru, Anda juga dapat menggunakan Neonkey SensorHub yang terhubung ke papan pengembangan Hikey atau Hikey960.
Bagaimana hub sensor terwujud bergantung pada arsitekturnya. Terkadang merupakan chip terpisah, dan terkadang disertakan dalam chip yang sama dengan SoC. Karakteristik penting dari hub sensor adalah hub tersebut harus berisi memori yang cukup untuk batching dan mengonsumsi daya yang sangat sedikit untuk memungkinkan penerapan sensor Android berdaya rendah. Beberapa hub sensor berisi mikrokontroler untuk komputasi umum, dan akselerator perangkat keras untuk memungkinkan komputasi daya sangat rendah untuk sensor berdaya rendah.
Bagaimana hub sensor dirancang dan bagaimana berkomunikasi dengan sensor dan SoC (bus I2C, bus SPI,…) tidak ditentukan oleh Android, namun harus bertujuan untuk meminimalkan penggunaan daya secara keseluruhan.
Salah satu opsi yang tampaknya memiliki dampak signifikan terhadap kesederhanaan implementasi adalah memiliki dua jalur interupsi dari hub sensor ke SoC: satu untuk interupsi bangun (untuk sensor bangun), dan yang lainnya untuk interupsi non-bangun. (untuk sensor non-bangun).
Sensor
Itu adalah chip MEM fisik yang melakukan pengukuran. Dalam banyak kasus, beberapa sensor fisik terdapat pada chip yang sama. Misalnya, beberapa chip menyertakan akselerometer, giroskop, dan magnetometer. (Chip seperti ini sering disebut chip 9-sumbu, karena setiap sensor menyediakan data melalui 3 sumbu.)
Beberapa chip tersebut juga berisi beberapa logika untuk melakukan komputasi biasa seperti deteksi gerakan, deteksi langkah, dan fusi sensor 9 sumbu.
Meskipun persyaratan dan rekomendasi daya dan akurasi CDD menargetkan sensor Android dan bukan sensor fisik, persyaratan tersebut memengaruhi pilihan sensor fisik. Misalnya, persyaratan akurasi pada vektor rotasi permainan berimplikasi pada akurasi yang diperlukan untuk giroskop fisik. Terserah produsen perangkat untuk menentukan persyaratan sensor fisik.