Smartphone memiliki sejumlah prosesor, masing-masing dioptimalkan untuk tugas yang berbeda. Namun, Android hanya berjalan pada satu prosesor: aplikasi pemroses (AP). AP disesuaikan untuk memberikan performa luar biasa untuk layar lain seperti {i>game<i}, tetapi aplikasi itu terlalu menggunakan daya untuk mendukung fitur yang memerlukan pemrosesan yang sering dan singkat sepanjang waktu, bahkan ketika layar nonaktif. Prosesor yang lebih kecil dapat menangani beban kerja ini dengan lebih efisien, menyelesaikan tugas mereka tanpa mempengaruhi masa pakai baterai. Namun, perangkat lunak di prosesor berdaya rendah ini lebih terbatas dan dapat sangat bervariasi, sehingga sulit untuk melakukan pengembangan lintas platform.
Context Hub Runtime Environment (CHRE) menyediakan platform umum untuk menjalankan aplikasi berdaya rendah, dengan antarmuka yang sederhana, API yang cocok untuk sematan. CHRE memudahkan OEM perangkat dan produk tepercaya mitra untuk mengurangi beban pemrosesan dari AP, untuk menghemat baterai dan meningkatkan area pengalaman pengguna, dan memungkinkan kelas selalu aktif fitur yang kontekstual, terutama yang melibatkan penerapan machine learning ke sensor sekitar.
Konsep utama
CHRE adalah lingkungan software tempat aplikasi native kecil, yang disebut
nanoapps, dieksekusi pada prosesor berdaya rendah dan berinteraksi dengan
melalui CHRE API umum. Untuk mempercepat penerapan yang tepat
CHRE API, implementasi referensi lintas platform dari CHRE disertakan dalam
AOSP. Implementasi referensi mencakup kode umum dan abstraksi ke
perangkat keras dan perangkat lunak yang mendasarinya melalui
serangkaian lapisan abstraksi platform
(PAL). Nanoapps hampir selalu terikat dengan satu atau beberapa aplikasi klien yang berjalan di
Android, yang berinteraksi dengan CHRE dan nanoapps melalui akses terbatas
ContextHubManager
API sistem.
Pada dasarnya, paralel dapat digambar antara arsitektur CHRE dan Android secara keseluruhan. Namun, ada beberapa perbedaan penting:
- CHRE hanya mendukung pengoperasian aplikasi nano yang dikembangkan dalam kode native (C atau C++); Java tidak didukung.
- Karena keterbatasan resource dan keamanan, CHRE tidak terbuka untuk digunakan oleh aplikasi Android pihak ketiga arbitrer. Hanya aplikasi tepercaya sistem yang dapat mengaksesnya.
Ada juga perbedaan penting yang harus dibuat antara konsep CHRE dan hub sensor. Meskipun umum untuk menggunakan perangkat keras yang sama untuk mengimplementasikan hub sensor dan CHRE, CHRE sendiri tidak memberikan kemampuan sensor yang diperlukan oleh Sensor Android HAL. CHRE terkait dengan Context Hub HAL, dan bertindak sebagai klien dari sensor khusus perangkat untuk menerima data sensor tanpa melibatkan AP.
Gambar 1. Arsitektur framework CHRE
Hub Konteks HAL
Lapisan abstraksi hardware (HAL) Context Hub adalah antarmuka antara
Framework Android dan implementasi CHRE perangkat, yang ditentukan di
hardware/interfaces/contexthub
Context Hub HAL mendefinisikan API yang digunakan oleh framework Android
menemukan hub konteks yang tersedia dan nanoapp-nya, berinteraksi dengan
nanoapps melalui penerusan pesan, dan
memungkinkan nanoaplikasi dimuat dan
dibongkar. Implementasi referensi HAL Hub Konteks yang berfungsi dengan
penerapan referensi CHRE tersedia di
system/chre/host
Jika terjadi pertentangan antara dokumentasi ini dan definisi HAL, Definisi HAL lebih diutamakan.
Inisialisasi
Saat Android melakukan booting,
ContextHubService
memanggil fungsi HAL getHubs() untuk menentukan apakah ada hub konteks
yang tersedia di perangkat. Panggilan ini bersifat satu kali pemblokiran, sehingga harus diselesaikan
dengan cepat untuk menghindari penundaan {i>booting<i}, dan harus memberikan hasil yang akurat, karena
{i>context hub<i} tidak dapat
diperkenalkan setelahnya.
Memuat dan menghapus muatan nanoaplikasi
Hub konteks dapat mencakup serangkaian aplikasi nano yang disertakan dalam perangkat
dan dimuat saat CHRE dimulai. Ini dikenal sebagai aplikasi
nano yang dimuat sebelumnya,
dan harus disertakan dalam respons pertama yang memungkinkan untuk queryApps().
Context Hub HAL juga mendukung pemuatan dan pembongkaran nanoaplikasi secara dinamis di
runtime, melalui fungsi loadNanoApp() dan unloadNanoApp(). Aplikasi Nano
disediakan ke HAL dalam format biner
khusus untuk perangkat keras CHRE dan
implementasi perangkat lunak dari suatu perangkat.
Jika implementasi untuk memuat nanoapp melibatkan penulisannya ke nonvolatil
lain, seperti penyimpanan flash yang dipasang ke prosesor yang menjalankan CHRE, maka
Implementasi CHRE harus selalu melakukan booting dengan aplikasi nano dinamis ini di
status nonaktif. Artinya, tidak satu pun kode nanoapp yang dieksekusi hingga
Permintaan enableNanoapp() diterima melalui HAL. {i>nanoapp<i} yang dipramuat dapat
melakukan inisialisasi dalam keadaan aktif.
Hub konteks dimulai ulang
Meskipun CHRE tidak diharapkan untuk dimulai ulang
selama operasi normal, namun
diperlukan untuk memulihkan data dari
kondisi yang tidak terduga seperti upaya untuk
mengakses alamat memori
yang tidak dipetakan. Dalam situasi ini, CHRE akan dimulai ulang
secara independen dari Android. HAL memberi tahu Android tentang hal ini melalui
Peristiwa RESTARTED, yang hanya boleh dikirim setelah CHRE diinisialisasi ulang ke
titik tersebut dapat menerima permintaan baru, seperti queryApps().
Ringkasan sistem CHRE
CHRE dirancang berdasarkan arsitektur berbasis peristiwa, di mana unit utama
komputasi adalah peristiwa yang diteruskan ke titik entri penanganan peristiwa aplikasi nano. Meskipun
framework CHRE bisa bersifat multi-thread, nanoapp tertentu tidak pernah dieksekusi dari
beberapa thread secara paralel. Framework CHRE berinteraksi dengan aplikasi nano tertentu
melalui salah satu dari tiga titik entri nanoapp (nanoappStart(),
nanoappHandleEvent(), dan nanoappEnd()) atau melalui callback yang disediakan dalam
panggilan CHRE API sebelumnya, dan aplikasi nano berinteraksi dengan framework CHRE dan
yang mendasarinya melalui CHRE API. CHRE API menyediakan kumpulan fitur
serta fasilitas untuk mengakses sinyal kontekstual, termasuk
sensor, GNSS, Wi-Fi, WWAN, dan audio, serta dapat diperluas dengan
kemampuan khusus vendor untuk digunakan oleh nanoapps khusus vendor.
Sistem build
Sementara Context Hub HAL dan komponen sisi AP lain yang diperlukan dibangun bersama Android, kode yang berjalan dalam CHRE bisa memiliki persyaratan yang membuatnya tidak kompatibel dengan sistem build Android, misalnya kebutuhan akan Rantai Alat (Toolchain). Oleh karena itu, project CHRE di AOSP menyediakan build yang disederhanakan berbasis GNU Make untuk mengkompilasi nanoapps, dan secara opsional menjadi library yang dapat diintegrasikan dengan sistem. Perangkat produsen yang menambahkan dukungan untuk CHRE harus mengintegrasikan dukungan sistem build untuk perangkat target mereka ke dalam AOSP.
CHRE API ditulis ke standar bahasa C99, dan referensi menggunakan subset terbatas dari C++11 cocok untuk resource-terbatas aplikasi.
API CHRE
CHRE API adalah kumpulan file header C yang menentukan software antarmuka antara aplikasi nano dan sistem. Alat ini dirancang untuk membuat nanoaplikasi yang kompatibel dengan semua perangkat yang mendukung CHRE, yang berarti bahwa kode sumber untuk nanoapp tidak perlu dimodifikasi untuk mendukung perangkat baru walaupun mungkin perlu dikompilasi ulang secara khusus untuk set petunjuk prosesor atau application binary interface (ABI). CHRE dan desain API juga memastikan bahwa nanoaplikasi kompatibel dengan biner di berbagai versi CHRE API, yang berarti bahwa aplikasi nano tidak perlu dikompilasi ulang untuk berjalan pada sistem yang mengimplementasikan versi yang berbeda dari CHRE API dibandingkan dengan API target yang digunakan dalam kompilasi nanoapp. Dengan kata lain, jika biner nanoapp berjalan di perangkat yang mendukung CHRE API v1.3, dan perangkat tersebut diupgrade untuk mendukung CHRE API v1.4, aplikasi nano yang sama biner tetap berfungsi. Demikian pula, nanoapp dapat berjalan di CHRE API v1.2, dan dapat menentukan pada runtime apakah diperlukan kemampuan dari API v1.3 hingga mencapai penggunaannya, atau apakah dapat beroperasi, mungkin dengan halus degradasi fitur.
Versi baru CHRE API dirilis bersama Android, tetapi saat CHRE implementasi adalah bagian dari implementasi vendor, versi CHRE API yang didukung pada perangkat tidak selalu ditautkan ke Versi Android.
Ringkasan versi
Seperti
Skema pembuatan versi HIDL Android,
CHRE API mengikuti pembuatan versi semantik.
Versi utama menunjukkan kompatibilitas biner, sedangkan versi minor menunjukkan
bertambah ketika fitur yang
kompatibel dengan versi sebelumnya diperkenalkan. CHRE API
menyertakan anotasi kode sumber untuk mengidentifikasi versi mana yang memperkenalkan fungsi
atau parameter, misalnya @since v1.1.
Implementasi CHRE juga mengekspos versi patch khusus platform melalui
chreGetVersion(), yang menunjukkan saat perbaikan bug atau update minor dilakukan di
dalam penerapannya.
Versi 1.0 (Android 7)
Mencakup dukungan untuk sensor, dan kemampuan aplikasi nano inti, seperti peristiwa dan timer.
Versi 1.1 (Android 8)
Memperkenalkan kemampuan lokasi melalui lokasi GNSS dan pengukuran mentah, Pemindaian Wi-Fi, dan informasi jaringan seluler, bersama dengan penajaman umum untuk memungkinkan komunikasi nanoapp-ke-nanoapp, dan peningkatan lainnya.
Versi 1.2 (Android 9)
Menambahkan dukungan untuk data dari mikrofon berdaya rendah, jangkauan Wi-Fi RTT, AP notifikasi bangun dan tidur, serta peningkatan lainnya.
Versi 1.3 (Android 10)
Meningkatkan kemampuan terkait data kalibrasi sensor, menambahkan dukungan untuk memasukkan data sensor batch sesuai permintaan, menentukan jenis sensor deteksi langkah, dan memperluas peristiwa lokasi GNSS dengan kolom akurasi tambahan.
Versi 1.4 (Android 11)
Menambahkan dukungan untuk informasi sel 5G, file dump debug nanoapp, dan peningkatan performa.
Fitur sistem wajib
Meskipun sumber sinyal kontekstual, seperti sensor, dikategorikan ke dalam opsi opsional area fitur, beberapa fungsi inti diperlukan di seluruh CHRE implementasi yang tepat. Ini termasuk API sistem inti, seperti API untuk setelan timer, mengirim dan menerima pesan ke klien pada pemroses aplikasi, {i>logging<i}, dan lain-lain. Untuk detail selengkapnya, lihat Header API.
Selain fitur sistem inti yang terkodifikasi dalam CHRE API, ada juga fitur tingkat sistem CHRE wajib yang ditentukan di level HAL Context Hub. Tujuan paling signifikan di antaranya adalah kemampuan untuk secara dinamis memuat dan membongkar aplikasi nano.
Library standar C/C++
Untuk meminimalkan penggunaan memori dan kompleksitas sistem, implementasi CHRE yang hanya diperlukan untuk mendukung subset dari library C dan C++ standar dan fitur bahasa yang memerlukan dukungan runtime. Dengan mengikuti prinsip-prinsip ini, beberapa secara eksplisit dikecualikan karena memori dan tingkat OS yang luas dependensi, dan lainnya karena digantikan oleh API khusus CHRE. Meskipun tidak dimaksudkan sebagai daftar lengkap, hal-hal berikut kemampuan ini tidak dimaksudkan untuk tersedia bagi nanoapps:
- Pengecualian C++ dan informasi jenis runtime (RTTI)
- Dukungan multithreading library standar, termasuk header C++11
<thread>,<mutex>,<atomic>,<future> - Library Input/Output Standar C dan C++
- Library Template Standar (STL) C++
- Library Regular Expressions C++
- Alokasi memori dinamis melalui fungsi standar (misalnya,
malloc,calloc,realloc,free,operator new), dan standar lainnya fungsi library yang secara inheren menggunakan alokasi dinamis, sepertistd::unique_ptr - Dukungan karakter Unicode dan pelokalan
- Library tanggal dan waktu
- Fungsi yang mengubah alur program normal, termasuk
<setjmp.h>,<signal.h>,abort,std::terminate - Mengakses lingkungan host, termasuk
system,getenv - POSIX dan library lainnya yang tidak termasuk dalam bahasa C99 atau C++11 standar
Dalam banyak kasus, kemampuan yang setara tersedia dari fungsi CHRE API
dan library utilitas. Misalnya, chreLog dapat digunakan untuk logging debug
yang ditargetkan ke sistem Android {i>logcat<i}, di mana
program yang lebih tradisional mungkin
gunakan printf atau std::cout.
Sebaliknya, beberapa kemampuan library standar diperlukan. Terserah implementasi platform untuk mengeksposnya melalui library statis untuk disertakan dalam biner aplikasi nano, atau dengan penautan dinamis antara aplikasi nano dan sistem. Ini termasuk, tetapi tidak terbatas pada:
- Utilitas string dan array:
memcmp,memcpy,memmove,memset,strlen Library matematika: Fungsi floating point presisi tunggal yang umum digunakan:
- Operasi dasar:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Fungsi eksponensial dan pangkat:
expf,log2f,powf,sqrtf - Fungsi trigonometri dan hiperbolik:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Operasi dasar:
Meskipun beberapa platform dasar mendukung kemampuan tambahan, aplikasi nano tidak dianggap portabel di seluruh implementasi CHRE kecuali membatasi dependensi eksternal ke fungsi CHRE API dan library standar yang disetujui fungsi-fungsi lainnya.
Fitur opsional
Untuk mempromosikan perangkat keras dan perangkat lunak, CHRE API dibagi menjadi beberapa area fitur, yang dianggap opsional dari perspektif API. Meskipun fitur-fitur ini mungkin tidak diperlukan untuk mendukung implementasi CHRE yang kompatibel, yang diperlukan untuk mendukung aplikasi nano tertentu. Bahkan jika platform tidak mendukung satu set API tertentu, aplikasi nano yang mereferensikan fungsi tersebut dan memuat.
Sensor
CHRE API memberikan kemampuan untuk meminta data dari sensor termasuk akselerometer, giroskop, magnetometer, sensor cahaya sekitar, dan kedekatan. API ini dimaksudkan untuk menyediakan set fitur yang mirip dengan Sensor Android API, termasuk dukungan untuk mengelompokkan contoh sensor guna mengurangi konsumsi daya. Pemrosesan data sensor dalam CHRE memungkinkan daya yang jauh lebih rendah dan latensi yang lebih rendah pemrosesan sinyal gerakan bila dibandingkan dengan berjalan di AP.
GNSS
CHRE menyediakan API untuk meminta data lokasi dari navigasi global sistem satelit (GNSS), termasuk GPS dan rasi bintang lainnya. Ini termasuk permintaan perbaikan posisi berkala, serta data pengukuran mentah, meskipun keduanya adalah kemampuan independen. Karena CHRE memiliki link langsung ke GNSS subsistem, daya akan berkurang dibandingkan dengan permintaan GNSS berbasis AP, karena AP bisa tetap tertidur selama seluruh siklus proses sesi lokasi.
Wi-Fi
CHRE memberikan kemampuan untuk berinteraksi dengan {i>chip<i} Wi-Fi, terutama untuk lokasi untuk keperluan lokasi. Meskipun GNSS berfungsi dengan baik untuk lokasi luar ruangan, hasil dari Pemindaian Wi-Fi dapat memberikan informasi lokasi yang akurat di dalam dan di luar ruangan area tersebut. Selain menghindari biaya pengaktifan AP untuk pemindaian, CHRE dapat dengarkan hasil pemindaian Wi-Fi yang dilakukan oleh Wi-Fi {i>firmware<i} untuk keperluan konektivitas, yang biasanya tidak dikirimkan ke AP karena alasan listrik. Memanfaatkan pemindaian konektivitas untuk tujuan kontekstual membantu mengurangi jumlah total pemindaian Wi-Fi yang dilakukan, sehingga menghemat daya.
Dukungan untuk Wi-Fi ditambahkan di CHRE API v1.1, termasuk kemampuan untuk memantau memindai hasil dan memicu pemindaian sesuai permintaan. Kemampuan ini diperluas dalam v1.2 dengan kemampuan untuk melakukan Waktu Round-Trip (RTT) terhadap titik akses yang mendukung fitur tersebut, yang memungkinkan penentuan posisi relatif yang akurat.
WWAN
CHRE API memberikan kemampuan untuk mengambil informasi identifikasi sel untuk sel penyaluran dan tetangganya, yang biasanya digunakan untuk tujuan lokasi yang terperinci.
Audio
CHRE dapat memproses batch data audio dari mikrofon berdaya rendah, yang biasanya memanfaatkan perangkat keras yang digunakan untuk menerapkan HAL SoundTrigger. Memproses data audio dalam CHRE dapat memungkinkannya untuk digabungkan dengan data lain, seperti gerakan sensor.
Penerapan referensi
Kode referensi untuk framework CHRE disertakan dalam AOSP di system/chre
, diimplementasikan dalam C++11. Meskipun tidak sepenuhnya
diwajibkan, disarankan untuk
semua implementasi CHRE didasarkan pada codebase ini, untuk membantu memastikan
konsistensi dan mempercepat
penerapan kemampuan baru. Kode ini dapat dilihat
sebagai analog terhadap framework Android inti karena merupakan
implementasi API yang digunakan aplikasi, yang berfungsi sebagai dasar pengukuran dan standar
untuk kompatibilitas. Meskipun dapat disesuaikan dan diperluas dengan spesifik per vendor
kemampuannya, rekomendasinya adalah untuk menjaga kode umum sedekat mungkin dengan
referensi terbaik. Mirip dengan HAL Android, referensi CHRE
menggunakan berbagai abstraksi platform
agar dapat diadaptasikan dengan
perangkat apa pun yang memenuhi persyaratan minimum.
Untuk detail teknis dan panduan transfer, lihat
README
disertakan dalam project system/chre.