Gambar di bawah menunjukkan stack sensor Android. Setiap komponen berkomunikasi hanya dengan komponen yang berada langsung di atas dan di bawahnya, meskipun beberapa sensor dapat melewati pusat sensor saat ada. Alur kontrol dari aplikasi ke sensor, dan data mengalir dari sensor ke menggunakan berbagai aplikasi obrolan.
Gambar 1. Lapisan tumpukan sensor Android dan masing-masing pemiliknya
SDK
Aplikasi mengakses sensor melalui Sensors SDK (Software Development Kit) API. SDK berisi fungsi untuk mencantumkan sensor yang tersedia dan untuk mendaftar ke sensor.
Saat mendaftar ke sensor, aplikasi menentukan pengambilan sampel pilihannya frekuensi dan persyaratan latensinya.
- Misalnya, aplikasi mungkin mendaftar ke akselerometer default, meminta peristiwa pada 100 Hz, dan mengizinkan peristiwa dilaporkan dengan latensi yang rendah.
- Aplikasi akan menerima peristiwa dari akselerometer pada laju pada setidaknya 100 Hz, dan mungkin tertunda hingga 1 detik.
Lihat dokumentasi developer untuk informasi selengkapnya tentang SDK.
Kerangka kerja
Framework ini bertugas menghubungkan beberapa aplikasi ke HAL. HAL itu sendiri adalah klien tunggal. Tanpa {i>multiplexing<i} ini yang terjadi di pada level framework, hanya satu aplikasi yang dapat mengakses setiap sensor mereka butuhkan di tiap 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 mengambil
mempertimbangkan persyaratan akun dari setiap aplikasi dan mengirimkan permintaan
parameter ke HAL.
- Frekuensi pengambilan sampel adalah maksimum dari frekuensi pengambilan sampel yang diminta, yang berarti beberapa aplikasi akan menerima peristiwa dengan frekuensi yang lebih tinggi dari yang mereka diminta.
- Latensi pelaporan maksimum adalah jumlah minimum dari yang diminta. Jika satu aplikasi memintanya sensor dengan latensi pelaporan maksimum 0, semua aplikasi akan menerima peristiwa dari sensor ini dalam mode berkelanjutan meskipun beberapa sensor meminta sensor dengan latensi pelaporan maksimum yang bukan nol. Lihat Pengelompokan untuk mengetahui detail selengkapnya.
- Ketika aplikasi terakhir yang didaftarkan ke satu sensor membatalkan pendaftaran darinya, mengirimkan permintaan ke HAL untuk menonaktifkan sensor agar daya tidak dikonsumsi jika tidak perlu dilakukan.
Dampak multipleksing
Kebutuhan akan lapisan multiplexing dalam kerangka kerja ini menjelaskan beberapa desain keputusan penting.
- Saat aplikasi meminta frekuensi sampling tertentu, tidak ada menjamin bahwa peristiwa tidak akan terjadi dengan kecepatan lebih cepat. Jika aplikasi lain meminta sensor yang sama dengan kecepatan lebih cepat, aplikasi pertama juga akan menerimanya dengan cepat.
- Kurangnya jaminan yang sama berlaku untuk latensi pelaporan maksimum yang diminta: aplikasi dapat menerima kejadian dengan latensi yang jauh lebih sedikit daripada yang diminta.
- Selain frekuensi pengambilan sampel dan latensi pelaporan maksimum, aplikasi tidak dapat
mengonfigurasi parameter sensor.
- Misalnya, bayangkan sensor fisik yang dapat berfungsi baik dalam "akurasi" dan "daya rendah".
- Hanya salah satu dari dua mode tersebut yang dapat digunakan di perangkat Android, karena jika tidak, aplikasi bisa meminta mode akurasi tinggi, dan mode lainnya mode daya rendah; tidak akan ada cara bagi kerangka kerja untuk memenuhi persyaratan menggunakan berbagai aplikasi obrolan. Kerangka kerja harus selalu dapat memuaskan semua kliennya, jadi ini bukanlah sebuah pilihan.
- Tidak ada mekanisme untuk mengirimkan data dari aplikasi ke sensor atau pengemudi mereka. Hal ini memastikan satu aplikasi tidak bisa memodifikasi perilaku sensor, yang dapat merusak aplikasi lainnya.
Fusi sensor
Framework Android menyediakan implementasi default untuk beberapa sensor. Jika giroskop, akselerometer, dan magnetometer ada di perangkat, tetapi tidak ada sensor vektor rotasi, gravitasi, dan percepatan linear, framework akan menerapkan sensor tersebut sehingga aplikasi masih dapat menggunakannya.
Implementasi {i>default<i} tidak memiliki akses ke semua data yang dapat diakses, dan harus berjalan di SoC, sehingga akurat maupun hemat daya dibandingkan implementasi lainnya. Sebanyak memungkinkan, produsen perangkat harus menentukan sensor menyatu mereka sendiri (rotasi vektor, gravitasi, dan akselerasi linear, serta sensor komposit yang lebih baru seperti vektor rotasi game) daripada mengandalkan implementasi default ini. Produsen perangkat dapat juga meminta vendor {i>chip<i} sensor untuk menyediakan implementasi di dalamnya.
Implementasi fusi sensor default tidak dipertahankan dan dapat menyebabkan perangkat yang mengandalkannya menggagalkan CTS.
Di balik layar
Bagian ini disediakan sebagai informasi latar belakang bagi mereka yang mengelola Kode framework Proyek Open Source Android (AOSP). Hal ini tidak relevan untuk produsen perangkat keras.
JNI
Framework ini 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 native
setara dengan paket android.hardware. Framework native memanggil proxy Binder IPC untuk mendapatkan akses ke
layanan khusus sensor.
IPC Binder
Proxy Binder IPC memfasilitasi komunikasi melalui batas-batas proses.
HAL
Sensors Hardware Abstraksi Layer (HAL) API adalah antarmuka antara {i>driver <i}perangkat keras dan kerangka kerja Android. HAL ini terdiri dari satu antarmuka HAL sensor.h dan satu penerapan HAL yang kami sebut sebagai sensors.cpp.
Antarmuka didefinisikan oleh kontributor Android dan AOSP, serta implementasi disediakan oleh produsen perangkat.
Antarmuka HAL sensor terletak di hardware/libhardware/include/hardware.
Lihat sensors.h
untuk detail tambahan.
Siklus rilis
Implementasi HAL menetapkan
versi antarmuka HAL yang
terapkan dengan menetapkan your_poll_device.common.version. HAL yang sudah ada
versi antarmuka ditentukan dalam sensors.h, dan fungsionalitas terikat dengan
versi.
Framework Android saat ini mendukung versi 1.0 dan 1.3, tetapi 1.0 akan segera tidak akan didukung lagi. Dokumentasi ini menjelaskan perilaku versi hingga versi 1.3, dan semua perangkat harus diupgrade. Untuk detail tentang cara meningkatkan ke 1.3, lihat penghentian versi HAL.
Driver kernel
Driver sensor berinteraksi dengan perangkat fisik. Dalam beberapa kasus, HAL implementasi dan {i>driver-<i}nya adalah entitas perangkat lunak yang sama. Dalam kasus lain, integrator perangkat keras meminta produsen chip sensor untuk menyediakan {i>driver<i}, tetapi merekalah yang menulis implementasi HAL.
Dalam semua kasus, implementasi HAL dan driver {i>kernel<i} adalah tanggung jawab produsen perangkat keras, dan Android tidak menyediakan pendekatan yang disukai untuk tulislah.
Hub sensor
Tumpukan sensor perangkat dapat secara opsional menyertakan hub sensor, yang berguna untuk melakukan beberapa komputasi tingkat rendah dengan daya rendah sementara SoC dapat dalam mode ditangguhkan. Misalnya, penghitungan langkah atau fusi sensor dapat dilakukan pada keripik-chip tersebut. Ini juga merupakan tempat yang baik untuk mengimplementasikan pengelompokan sensor, menambahkan FIFO perangkat keras untuk kejadian sensor. Lihat Pengelompokan 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 terwujud bergantung pada arsitektur. Kadang-kadang {i>chip<i} yang terpisah, dan kadang-kadang termasuk pada {i>chip<i} yang sama dengan SoC. Penting karakteristik hub sensor adalah bahwa tempat ini harus memiliki memori yang cukup untuk mengelompokkan dan mengkonsumsi daya sangat sedikit guna memungkinkan implementasi mengaktifkan sensor Android. Beberapa hub sensor mengandung mikrokontroler untuk komputasi, dan akselerator perangkat keras untuk memungkinkan komputasi berdaya sangat rendah untuk sensor daya rendah.
Bagaimana arsitektur hub sensor dan cara berkomunikasi dengan sensor dan SoC (I2C bus, SPI bus, ...) tidak ditentukan oleh Android, tetapi harus untuk meminimalkan penggunaan daya secara keseluruhan.
Salah satu opsi yang tampaknya memiliki dampak signifikan pada penerapan kesederhanaan adalah memiliki dua jalur interupsi yang berpindah dari hub sensor ke SoC: satu untuk interupsi bangun (untuk sensor bangun), dan satunya lagi untuk bukan bangun interupsi (untuk sensor yang tidak diaktifkan).
Sensor
Mereka adalah chip MEMs fisik yang melakukan pengukuran. Di banyak kasus, beberapa sensor fisik ada pada {i>chip<i} yang sama. Misalnya, beberapa {i>chip<i} termasuk akselerometer, giroskop, dan magnetometer. (Chip seperti itu sering disebut chip 9 sumbu, karena setiap sensor menyediakan data melalui 3 sumbu.)
Beberapa dari {i>chip<i} itu juga berisi beberapa logika untuk melakukan perhitungan biasa seperti sebagai deteksi gerakan, deteksi langkah, dan fusi sensor 9 sumbu.
Meskipun persyaratan daya dan akurasi CDD serta rekomendasi menargetkan Sensor Android dan bukan sensor fisik, persyaratan tersebut memengaruhi pilihan sensor fisik. Misalnya, persyaratan akurasi pada game vektor rotasi berimplikasi pada akurasi yang diperlukan untuk model giroskop. Terserah produsen perangkat untuk mendapatkan persyaratan untuk sensor fisik.