Gambar di bawah menunjukkan stack 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 stack sensor Android dan pemiliknya masing-masing
SDK
Aplikasi mengakses sensor melalui Sensors SDK (Software Development Kit) API. SDK berisi fungsi untuk mencantumkan sensor yang tersedia dan mendaftar ke sensor.
Saat mendaftar ke sensor, aplikasi menentukan frekuensi pengambilan sampel yang disukainya dan persyaratan latensinya.
- Misalnya, aplikasi dapat mendaftar ke akselerometer default, meminta peristiwa pada 100 Hz, dan mengizinkan peristiwa dilaporkan dengan latensi 1 detik.
- Aplikasi akan menerima peristiwa dari akselerometer dengan kecepatan minimal 100 Hz, dan mungkin tertunda hingga 1 detik.
Lihat dokumentasi developer untuk mengetahui informasi selengkapnya tentang SDK.
Framework
Framework ini bertanggung jawab untuk menautkan beberapa aplikasi ke HAL. HAL itu sendiri adalah klien tunggal. Tanpa multipleks ini yang terjadi di tingkat framework, hanya satu aplikasi yang dapat mengakses setiap sensor pada waktu tertentu.
- Saat aplikasi pertama mendaftar ke sensor, framework akan mengirim permintaan ke HAL untuk mengaktifkan sensor.
- Saat aplikasi tambahan mendaftar ke sensor yang sama, framework akan
mempertimbangkan persyaratan dari setiap aplikasi dan mengirim parameter yang diminta
yang telah diperbarui ke HAL.
- Frekuensi pengambilan sampel akan menjadi frekuensi pengambilan sampel maksimum yang diminta, yang berarti beberapa aplikasi akan menerima peristiwa pada frekuensi yang lebih tinggi daripada yang diminta.
- Latensi pelaporan maksimum akan menjadi minimum dari latensi 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 meminta sensor dengan latensi pelaporan maksimum yang bukan nol. Lihat Batching untuk mengetahui detail selengkapnya.
- Saat aplikasi terakhir yang terdaftar ke satu sensor membatalkan pendaftarannya, framework mengirim permintaan ke HAL untuk menonaktifkan sensor sehingga daya tidak dikonsumsi secara tidak perlu.
Dampak multiplexing
Kebutuhan akan lapisan multiplexing dalam framework ini menjelaskan beberapa keputusan desain.
- Saat aplikasi meminta frekuensi sampling tertentu, tidak ada jaminan bahwa peristiwa tidak akan tiba dengan kecepatan yang lebih cepat. Jika aplikasi lain meminta sensor yang sama dengan laju lebih cepat, aplikasi pertama juga akan menerimanya dengan laju cepat.
- Kurangnya jaminan yang sama berlaku untuk latensi pelaporan maksimum yang diminta: aplikasi mungkin menerima peristiwa dengan latensi yang jauh lebih rendah daripada yang diminta.
- Selain frekuensi pengambilan sampel dan latensi pelaporan maksimum, aplikasi tidak dapat
mengonfigurasi parameter sensor.
- Misalnya, bayangkan sensor fisik yang dapat berfungsi dalam mode “akurasi tinggi” dan “daya rendah”.
- Hanya salah satu dari kedua mode tersebut yang dapat digunakan di perangkat Android, karena jika tidak, satu aplikasi dapat meminta mode akurasi tinggi, dan aplikasi lain meminta mode daya rendah; framework tidak akan dapat memenuhi kedua aplikasi tersebut. Framework harus selalu dapat memenuhi semua kliennya, jadi ini bukan opsi.
- Tidak ada mekanisme untuk mengirim data dari aplikasi ke sensor atau drivernya. Hal ini memastikan bahwa satu aplikasi tidak dapat mengubah perilaku sensor, sehingga merusak aplikasi lain.
Penggabungan sensor
Framework Android menyediakan penerapan default untuk beberapa sensor gabungan. Jika giroskop, akselerometer, dan magnetometer ada di perangkat, tetapi tidak ada sensor vektor rotasi, gravitasi, dan akselerasi linear, framework akan menerapkan sensor tersebut sehingga aplikasi tetap dapat menggunakannya.
Implementasi default tidak memiliki akses ke semua data yang dapat diakses oleh implementasi lain, dan harus berjalan di SoC, sehingga tidak seakurat atau sehemat daya implementasi lainnya. Sebisa mungkin, produsen perangkat harus menentukan sensor gabungan mereka sendiri (vektor rotasi, gravitasi, dan akselerasi linear, serta sensor komposit yang lebih baru seperti vektor rotasi game), bukan mengandalkan implementasi default ini. Produsen perangkat juga dapat meminta vendor chip sensor untuk memberikan penerapan kepada mereka.
Implementasi penggabungan sensor default tidak dipertahankan dan dapat menyebabkan perangkat yang mengandalkannya gagal dalam CTS.
Di balik layar
Bagian ini disediakan sebagai informasi latar belakang bagi mereka yang mengelola kode framework Project Open Source Android (AOSP). Bagian ini tidak relevan untuk produsen hardware.
JNI
Framework ini menggunakan Java Native Interface (JNI) yang terkait dengan android.hardware dan terletak di direktori frameworks/base/core/jni/. Kode ini memanggil kode native tingkat bawah untuk mendapatkan akses ke hardware sensor.
Framework native
Framework native ditentukan dalam frameworks/native/ dan menyediakan padanan native untuk paket android.hardware. Framework native memanggil proxy Binder IPC untuk mendapatkan akses ke
layanan khusus sensor.
IPC Binder
Proxy IPC Binder memfasilitasi komunikasi melalui batas proses.
HAL
API Hardware Abstraction Layer (HAL) Sensor adalah antarmuka antara driver hardware dan framework Android. HAL ini terdiri dari satu antarmuka HAL sensors.h dan satu implementasi HAL yang kami sebut sebagai sensors.cpp.
Antarmuka ditentukan oleh kontributor Android dan AOSP, dan implementasinya disediakan oleh produsen perangkat.
Antarmuka HAL sensor terletak di hardware/libhardware/include/hardware.
Lihat sensors.h
untuk mengetahui detail tambahan.
Siklus rilis
Implementasi HAL menentukan versi antarmuka HAL yang diimplementasikannya
dengan menyetel your_poll_device.common.version. Versi antarmuka HAL yang ada ditentukan di sensors.h, dan fungsi terikat dengan versi tersebut.
Framework Android saat ini mendukung versi 1.0 dan 1.3, tetapi 1.0 akan segera tidak didukung lagi. Dokumentasi ini menjelaskan perilaku versi 1.3, yang harus diupgrade oleh semua perangkat. Untuk mengetahui detail cara mengupgrade ke 1.3, lihat Penghentian penggunaan versi HAL.
Driver kernel
Driver sensor berinteraksi dengan perangkat fisik. Dalam beberapa kasus, implementasi HAL dan driver adalah entitas software yang sama. Dalam kasus lain, integrator hardware meminta produsen chip sensor untuk menyediakan driver, tetapi mereka yang menulis implementasi HAL.
Dalam semua kasus, implementasi HAL dan driver kernel adalah tanggung jawab produsen hardware, dan Android tidak memberikan pendekatan pilihan untuk menulisnya.
Hub sensor
Stack sensor perangkat secara opsional dapat menyertakan hub sensor, yang berguna untuk melakukan beberapa komputasi tingkat rendah dengan daya rendah saat SoC dapat berada dalam mode penangguhan. Misalnya, penghitungan langkah atau penggabungan sensor dapat dilakukan di chip tersebut. Ini juga merupakan tempat yang tepat untuk menerapkan pengelompokan sensor, dengan menambahkan FIFO hardware untuk peristiwa sensor. Lihat Batching untuk mengetahui informasi selengkapnya.
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.
Cara hub sensor diwujudkan bergantung pada arsitektur. Terkadang berupa chip terpisah, dan terkadang disertakan pada chip yang sama dengan SoC. Karakteristik penting hub sensor adalah harus berisi memori yang cukup untuk pengelompokan dan mengonsumsi daya yang sangat kecil untuk memungkinkan penerapan sensor Android berdaya rendah. Beberapa hub sensor berisi mikrokontroler untuk komputasi generik, dan akselerator hardware untuk mengaktifkan komputasi berdaya sangat rendah untuk sensor berdaya rendah.
Arsitektur hub sensor dan cara hub sensor berkomunikasi dengan sensor dan SoC (bus I2C, bus SPI, …) tidak ditentukan oleh Android, tetapi harus bertujuan untuk meminimalkan penggunaan daya secara keseluruhan.
Salah satu opsi yang tampaknya memiliki dampak signifikan pada kesederhanaan penerapan adalah memiliki dua jalur interupsi yang berasal dari hub sensor ke SoC: satu untuk interupsi aktifkan (untuk sensor aktifkan), dan yang lainnya untuk interupsi non-aktifkan (untuk sensor non-aktifkan).
Sensor
Itu adalah chip MEM fisik yang melakukan pengukuran. Dalam banyak kasus, beberapa sensor fisik ada di chip yang sama. Misalnya, beberapa chip menyertakan akselerometer, giroskop, dan magnetometer. (Chip semacam itu sering disebut chip 9-sumbu, karena setiap sensor memberikan data di 3 sumbu.)
Beberapa chip tersebut juga berisi beberapa logika untuk melakukan komputasi biasa seperti deteksi gerakan, deteksi langkah, dan penggabungan sensor 9 sumbu.
Meskipun persyaratan dan rekomendasi akurasi serta daya CDD menargetkan sensor Android, bukan sensor fisik, persyaratan tersebut memengaruhi pilihan sensor fisik. Misalnya, persyaratan akurasi pada vektor rotasi game memiliki implikasi pada akurasi yang diperlukan untuk giroskop fisik. Produsen perangkat yang menentukan persyaratan untuk sensor fisik.