Gambar di bawah menunjukkan tumpukan sensor Android. Setiap komponen hanya berkomunikasi dengan komponen langsung di atas dan di bawahnya, meskipun beberapa sensor dapat melewati hub sensor saat 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 mendaftar ke sensor.
Saat mendaftar ke sensor, aplikasi menentukan frekuensi pengambilan sampel yang disukai dan persyaratan latensinya.
- Misalnya, aplikasi mungkin mendaftar ke akselerometer default, meminta peristiwa pada 100Hz, dan mengizinkan peristiwa dilaporkan dengan latensi 1 detik.
- Aplikasi akan menerima peristiwa dari akselerometer pada kecepatan setidaknya 100Hz, dan mungkin tertunda hingga 1 detik.
Lihat dokumentasi pengembang untuk informasi selengkapnya tentang SDK.
Kerangka
Kerangka tersebut bertugas menghubungkan beberapa aplikasi ke HAL . HAL itu sendiri adalah klien tunggal. Tanpa multiplexing ini terjadi pada tingkat kerangka kerja, hanya satu aplikasi yang dapat mengakses setiap sensor pada waktu tertentu.
- Saat aplikasi pertama mendaftar ke sensor, framework mengirimkan permintaan ke HAL untuk mengaktifkan sensor.
- Saat aplikasi tambahan mendaftar ke sensor yang sama, kerangka kerja memperhitungkan persyaratan akun dari setiap aplikasi dan mengirimkan parameter yang diminta yang diperbarui ke HAL.
- Frekuensi pengambilan sampel akan menjadi frekuensi pengambilan sampel maksimum yang diminta, yang berarti beberapa aplikasi akan menerima kejadian pada frekuensi yang lebih tinggi dari yang diminta.
- Latensi pelaporan maksimum akan menjadi minimum dari 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 bukan nol. Lihat Batching untuk lebih jelasnya.
- Ketika aplikasi terakhir yang terdaftar ke satu sensor tidak terdaftar darinya, kerangka kerja mengirimkan permintaan ke HAL untuk menonaktifkan sensor sehingga daya tidak dikonsumsi secara tidak perlu.
Dampak multiplexing
Kebutuhan akan lapisan multiplexing dalam kerangka kerja ini menjelaskan beberapa keputusan desain.
- Saat aplikasi meminta frekuensi pengambilan sampel tertentu, tidak ada jaminan bahwa peristiwa tidak akan tiba dengan kecepatan yang lebih cepat. Jika aplikasi lain meminta sensor yang sama dengan kecepatan yang lebih cepat, aplikasi pertama juga akan menerimanya dengan kecepatan yang lebih cepat.
- Kurangnya jaminan yang sama berlaku untuk latensi pelaporan maksimum yang diminta: aplikasi mungkin menerima peristiwa 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 sebuah sensor fisik yang dapat berfungsi baik dalam mode "akurasi tinggi" dan "daya rendah".
- Hanya satu dari dua mode tersebut yang dapat digunakan pada perangkat Android, karena jika tidak, sebuah 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 harus selalu dapat memuaskan semua kliennya, jadi ini bukan pilihan.
- Tidak ada mekanisme untuk mengirimkan data dari aplikasi ke sensor atau drivernya. Ini memastikan satu aplikasi tidak dapat mengubah perilaku sensor, merusak aplikasi lain.
Penggabungan sensor
Kerangka kerja Android menyediakan implementasi default untuk beberapa sensor komposit. Ketika giroskop , akselerometer , dan magnetometer ada pada perangkat, tetapi tidak ada vektor rotasi , gravitasi , dan sensor percepatan linier , kerangka kerja 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 seefisien daya seperti implementasi lainnya. Sebisa mungkin, produsen perangkat harus menentukan sensor fusi mereka sendiri (vektor rotasi, gravitasi, dan akselerasi 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 memberikan implementasi kepada mereka.
Implementasi fusi sensor default tidak dipertahankan dan dapat menyebabkan perangkat yang mengandalkannya gagal CTS.
Dibawah tenda
Bagian ini disediakan sebagai informasi latar belakang bagi mereka yang memelihara kode kerangka kerja Android Open Source Project (AOSP). Ini tidak relevan untuk produsen perangkat keras.
JNI
Framework menggunakan Java Native Interface (JNI) yang terkait dengan android.hardware dan terletak di direktori frameworks/base/core/jni/ . Kode ini memanggil kode asli tingkat yang lebih rendah untuk mendapatkan akses ke perangkat keras sensor.
Kerangka kerja asli
Kerangka kerja asli didefinisikan dalam frameworks/native/ dan menyediakan asli yang setara dengan paket android.hardware . Kerangka kerja asli memanggil proxy Binder IPC untuk mendapatkan akses ke layanan khusus sensor.
IPC pengikat
Proxy Binder IPC memfasilitasi komunikasi melewati batas proses.
HAL
Sensors Hardware Abstraction Layer (HAL) API adalah antarmuka antara driver perangkat keras dan kerangka kerja Android. Ini terdiri dari satu sensor antarmuka HAL dan satu implementasi HAL yang kami sebut sebagai sensor.cpp.
Antarmuka 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 didefinisikan dalam sensor.h, dan fungsionalitas terkait dengan versi tersebut.
Kerangka kerja 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 ditingkatkan 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 driver adalah entitas perangkat lunak yang sama. Dalam kasus lain, integrator perangkat keras 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 perangkat keras, dan Android tidak menyediakan pendekatan yang disukai untuk menulisnya.
pusat sensor
Tumpukan sensor perangkat secara opsional dapat menyertakan hub sensor, berguna untuk melakukan beberapa perhitungan tingkat rendah dengan daya rendah sementara SoC dapat berada dalam mode tunda. Misalnya, penghitungan langkah atau fusi sensor dapat dilakukan pada chip tersebut. Ini juga merupakan tempat yang baik untuk menerapkan pengelompokan sensor, menambahkan FIFO perangkat keras untuk peristiwa sensor. Lihat Batching 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 tergantung pada arsitekturnya. Terkadang merupakan chip yang terpisah, dan terkadang disertakan pada chip yang sama dengan SoC. Karakteristik penting dari hub sensor adalah bahwa ia harus berisi memori yang cukup untuk batching dan mengkonsumsi daya yang sangat kecil untuk memungkinkan penerapan sensor Android berdaya rendah. Beberapa hub sensor berisi mikrokontroler untuk komputasi umum, dan akselerator perangkat keras untuk mengaktifkan komputasi daya yang sangat rendah untuk sensor daya rendah.
Bagaimana hub sensor diarsitektur dan bagaimana ia berkomunikasi dengan sensor dan SoC (bus I2C, bus SPI, ...) tidak ditentukan oleh Android, tetapi harus ditujukan untuk meminimalkan penggunaan daya secara keseluruhan.
Salah satu opsi yang tampaknya memiliki dampak signifikan pada 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 MEMs fisik yang melakukan pengukuran. Dalam banyak kasus, beberapa sensor fisik hadir pada chip yang sama. Misalnya, beberapa chip termasuk akselerometer, giroskop, dan magnetometer. (Chip tersebut sering disebut chip 9-sumbu, karena setiap sensor menyediakan data melalui 3 sumbu.)
Beberapa dari chip tersebut juga berisi beberapa logika untuk melakukan perhitungan 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 mendapatkan persyaratan untuk sensor fisik.