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 mengabaikan 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 sampling yang diinginkan 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.
Kerangka kerja
Framework ini bertanggung jawab untuk menautkan beberapa aplikasi ke HAL. HAL itu sendiri adalah satu klien. 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
memperhitungkan persyaratan dari setiap aplikasi dan mengirim parameter yang diperbarui
yang diminta ke HAL.
- Frekuensi sampling akan menjadi maksimum dari frekuensi sampling 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 Pengelompokan untuk mengetahui detail selengkapnya.
- Saat aplikasi terakhir yang terdaftar ke satu sensor membatalkan pendaftarannya, framework akan mengirimkan permintaan ke HAL untuk menonaktifkan sensor sehingga daya tidak terpakai secara tidak perlu.
Dampak multiplexing
Kebutuhan akan lapisan multipleks 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 kecepatan lebih cepat, aplikasi pertama juga akan menerimanya dengan kecepatan cepat.
- Ketidakpastian yang sama berlaku untuk latensi pelaporan maksimum yang diminta: aplikasi mungkin menerima peristiwa dengan latensi yang jauh lebih rendah dari yang diminta.
- Selain frekuensi sampling 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 satu dari dua mode tersebut yang dapat digunakan di perangkat Android, karena jika tidak, aplikasi dapat meminta mode akurasi tinggi, dan aplikasi lainnya mode daya rendah; tidak ada cara bagi framework untuk memenuhi kedua aplikasi tersebut. Framework harus selalu dapat memuaskan semua kliennya, sehingga hal ini bukan merupakan opsi.
- Tidak ada mekanisme untuk mengirim data dari aplikasi ke sensor atau driver-nya. Hal ini memastikan satu aplikasi tidak dapat mengubah perilaku sensor, sehingga merusak aplikasi lain.
Penggabungan sensor
Framework Android menyediakan implementasi default untuk beberapa sensor komposit. 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 masih dapat menggunakannya.
Implementasi default tidak memiliki akses ke semua data yang dapat diakses oleh implementasi lain, dan harus berjalan di SoC, sehingga tidak akurat atau hemat daya seperti 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) daripada mengandalkan implementasi default ini. Produsen perangkat juga dapat meminta vendor chip sensor untuk menyediakan penerapan.
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). Hal 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 level rendah untuk mendapatkan akses ke hardware sensor.
Framework native
Framework native ditentukan di frameworks/native/ dan menyediakan native
yang setara dengan paket android.hardware. Framework native memanggil proxy IPC Binder untuk mendapatkan akses ke
layanan khusus sensor.
IPC Binder
Proksi IPC Binder memfasilitasi komunikasi melalui batas proses.
HAL
Sensors Hardware Abstraction Layer (HAL) API adalah antarmuka antara driver hardware dan framework Android. Modul ini terdiri dari satu antarmuka HAL sensors.h dan satu implementasi HAL yang kita sebut sebagai sensors.cpp.
Antarmuka ditentukan oleh kontributor Android dan AOSP, dan implementasinya disediakan oleh produsen perangkat.
Antarmuka HAL sensor berada di hardware/libhardware/include/hardware.
Lihat sensors.h
untuk detail tambahan.
Siklus rilis
Implementasi HAL menentukan versi antarmuka HAL yang
diimplementasikannya dengan menetapkan your_poll_device.common.version. Versi antarmuka HAL
yang ada ditentukan di sensors.h, dan fungsinya terikat dengan
versi tersebut.
Framework Android saat ini mendukung versi 1.0 dan 1.3, tetapi 1.0 tidak akan didukung lagi dalam waktu dekat. Dokumentasi ini menjelaskan perilaku versi 1.3, yang harus diupgrade oleh semua perangkat. Untuk mengetahui detail tentang 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 merekalah yang menulis implementasi HAL.
Dalam semua kasus, implementasi HAL dan driver kernel adalah tanggung jawab produsen hardware, dan Android tidak memberikan pendekatan yang lebih disukai 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, menambahkan FIFO hardware untuk peristiwa sensor. Lihat Penggabungan 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 board pengembangan Hikey atau Hikey960.
Cara hub sensor diwujudkan bergantung pada arsitektur. Terkadang chip ini terpisah, dan terkadang disertakan pada chip yang sama dengan SoC. Karakteristik penting dari hub sensor adalah harus berisi memori yang memadai untuk pengelompokan dan menggunakan daya yang sangat sedikit untuk memungkinkan penerapan sensor Android daya rendah. Beberapa hub sensor berisi mikrokontroler untuk komputasi umum, dan akselerator hardware untuk mengaktifkan komputasi daya sangat rendah untuk sensor daya rendah.
Cara hub sensor dirancang dan cara 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 wake-up (untuk sensor wake-up), dan yang lainnya untuk interupsi non-wake-up (untuk sensor non-wake-up).
Sensor
Chip MEMs fisik itulah yang melakukan pengukuran. Dalam banyak kasus, beberapa sensor fisik ada di chip yang sama. Misalnya, beberapa chip menyertakan akselerometer, giroskop, dan magnetometer. (Chip tersebut sering disebut chip 9 sumbu, karena setiap sensor memberikan data melalui 3 sumbu.)
Beberapa chip tersebut juga berisi beberapa logika untuk melakukan komputasi biasa seperti deteksi gerakan, deteksi langkah, dan penggabungan sensor 9 sumbu.
Meskipun rekomendasi dan persyaratan daya serta akurasi 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 giroskopi fisik. Produsen perangkat dapat menentukan persyaratan untuk sensor fisik.