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. Alur kontrol dari aplikasi ke sensor, dan alur data 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.
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 mengirimkan permintaan ke HAL untuk mengaktifkan sensor.
- Saat aplikasi tambahan mendaftar ke sensor yang sama, framework akan mempertimbangkan persyaratan dari setiap aplikasi dan mengirimkan parameter yang diminta yang telah diperbarui ke HAL.
- Frekuensi sampling akan menjadi maksimum dari frekuensi sampling yang diminta, yang berarti beberapa aplikasi akan menerima peristiwa dengan frekuensi yang lebih tinggi dari yang mereka minta.
- 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 akan mengirimkan permintaan ke HAL untuk menonaktifkan sensor sehingga daya tidak digunakan secara tidak perlu.
Dampak multipleks
Kebutuhan akan lapisan multipleks di 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 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 salah satu dari dua mode tersebut yang dapat digunakan di perangkat Android, karena jika tidak, aplikasi dapat meminta mode akurasi tinggi, dan aplikasi lain meminta mode daya rendah; tidak akan ada cara bagi framework untuk 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 satu aplikasi tidak dapat mengubah perilaku sensor, sehingga merusak aplikasi lain.
Penggabungan sensor
Framework Android menyediakan implementasi default untuk beberapa sensor komposit sensor. Jika giroskop, akselerometer, dan magnetometer ada di perangkat, tetapi tidak ada sensor vektor rotasi, gravitasi, dan akselerasi linear, framework akan mengimplementasikan 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 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 memberi mereka implementasi.
Implementasi penggabungan sensor default tidak dipertahankan dan dapat menyebabkan perangkat yang mengandalkannya gagal 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 menggunakan Java Native Interface (JNI) yang terkait dengan android.hardware dan berada di direktori frameworks/base/core/jni/. Kode ini memanggil kode native tingkat yang lebih rendah untuk mendapatkan akses ke hardware sensor.
Framework native
Framework native ditentukan di frameworks/native/ dan menyediakan padanan native
untuk paket android.hardware. Framework native memanggil proxy Binder IPC untuk mendapatkan akses ke
layanan khusus sensor.
Binder IPC
Proxy Binder IPC memfasilitasi komunikasi melalui batas proses.
HAL
Sensor Hardware Abstraction Layer (HAL) API adalah antarmuka antara driver hardware dan framework Android. API ini terdiri dari satu sensor antarmuka HAL sensors.h dan satu implementasi HAL yang kami sebut sebagai sensors.cpp.
Antarmuka ditentukan oleh kontributor Android dan AOSP, dan implementasi disediakan oleh produsen perangkat.
Antarmuka HAL sensor berada di hardware/libhardware/include/hardware.
Lihat sensors.h
untuk mengetahui 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 dalam sensors.h, dan fungsi terikat dengan versi
tersebut.
Framework Android saat ini mendukung versi 1.0 dan 1.3, tetapi 1.0 akan 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 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 adalah orang yang menulis implementasi HAL.
Dalam semua kasus, implementasi HAL dan driver kernel adalah tanggung jawab produsen hardware, dan Android tidak memberikan pendekatan pilihan untuk menuliskannya.
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 arsitekturnya. Terkadang merupakan chip terpisah, dan terkadang disertakan pada chip yang sama dengan SoC. Karakteristik penting hub sensor adalah harus berisi memori yang cukup untuk pengelompokan dan menggunakan daya yang sangat kecil untuk mengaktifkan implementasi sensor Android daya rendah. Beberapa hub sensor berisi mikrokontroler untuk komputasi umum, dan akselerator hardware untuk mengaktifkan komputasi daya yang sangat rendah untuk sensor daya rendah.
Cara hub sensor diarsitektur 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 implementasi adalah memiliki dua jalur interupsi yang berasal dari hub sensor ke SoC: satu untuk interupsi bangun (untuk sensor bangun), dan yang lainnya untuk interupsi non-bangun (untuk sensor non-bangun).
Sensor
Sensor 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 tersebut sering disebut chip 9 sumbu, karena setiap sensor menyediakan data di atas 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 daya dan 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 giroskop fisik. Produsen perangkat bertanggung jawab untuk mendapatkan persyaratan untuk sensor fisik.