Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Lingkungan Waktu Proses Hub Konteks (CHRE)

Ponsel cerdas berisi sejumlah prosesor, masing-masing dioptimalkan untuk melakukan tugas berbeda. Namun, Android hanya berjalan pada satu prosesor: prosesor aplikasi (AP). AP disetel untuk memberikan kinerja yang luar biasa untuk kasus penggunaan layar seperti bermain game, tetapi terlalu haus daya untuk mendukung fitur-fitur yang memerlukan proses yang sering dan singkat sepanjang waktu, bahkan saat layar mati. Prosesor yang lebih kecil mampu menangani beban kerja ini dengan lebih efisien, menyelesaikan tugasnya tanpa memengaruhi masa pakai baterai secara signifikan. Namun, lingkungan perangkat lunak dalam prosesor berdaya rendah ini lebih terbatas dan dapat sangat bervariasi, membuat pengembangan lintas platform menjadi sulit.

Context Hub Runtime Environment (CHRE) menyediakan platform umum untuk menjalankan aplikasi pada prosesor berdaya rendah, dengan API sederhana, terstandardisasi, dan ramah tersemat. CHRE memudahkan perangkat OEM dan mitra tepercaya mereka untuk memindahkan pemrosesan dari AP, untuk menghemat baterai dan meningkatkan berbagai area pengalaman pengguna, dan mengaktifkan kelas fitur yang selalu aktif dan sadar kontekstual, terutama yang melibatkan aplikasi mesin belajar penginderaan ambien.

Konsep kunci

CHRE adalah lingkungan perangkat lunak tempat aplikasi asli kecil, yang disebut nanoapps , dijalankan pada prosesor berdaya rendah dan berinteraksi dengan sistem yang mendasarinya melalui API CHRE umum. Untuk mempercepat implementasi yang tepat dari CHRE API, implementasi referensi lintas platform 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 lebih aplikasi klien yang berjalan di Android, yang berinteraksi dengan CHRE dan nanoapps melalui API sistem ContextHubManager dengan akses terbatas .

Pada tingkat tinggi, kesejajaran dapat ditarik antara arsitektur CHRE dan Android secara keseluruhan. Namun, ada beberapa perbedaan penting:

  • CHRE mendukung hanya menjalankan nanoapps yang dikembangkan dalam kode asli (C atau C ++); Java tidak didukung.
  • Karena batasan sumber daya dan batasan keamanan, CHRE tidak terbuka untuk digunakan oleh aplikasi Android pihak ketiga yang sewenang-wenang. Hanya aplikasi tepercaya sistem yang dapat mengaksesnya.

Ada juga perbedaan penting yang harus dibuat antara konsep CHRE dan hub sensor. Meskipun umum menggunakan perangkat keras yang sama untuk mengimplementasikan hub sensor dan CHRE, CHRE itu sendiri tidak menyediakan fungsionalitas sensor yang dibutuhkan oleh Android Sensors HAL . CHRE terikat ke HAL Hub Konteks, dan berfungsi sebagai klien kerangka kerja sensor khusus perangkat untuk menerima data sensor tanpa melibatkan AP.

Arsitektur kerangka CHRE

Gambar 1. Arsitektur framework CHRE

Hub Konteks HAL

Lapisan abstraksi perangkat keras Hub Konteks (HAL) adalah antarmuka antara kerangka kerja Android dan implementasi CHRE perangkat, yang ditentukan di hardware/interfaces/contexthub . Context Hub HAL mendefinisikan API yang melaluinya framework Android menemukan hub konteks yang tersedia dan nanoappnya, berinteraksi dengan nanoapp tersebut melalui penyampaian pesan, dan memungkinkan nanoapp untuk dimuat dan dibongkar. Implementasi referensi dari Context Hub HAL yang bekerja dengan implementasi referensi CHRE tersedia di system/chre/host .

Jika terjadi konflik antara dokumentasi ini dan definisi HAL, definisi HAL akan diutamakan.

Inisialisasi

Saat Android melakukan boot, ContextHubService memanggil fungsi getHubs() HAL untuk menentukan apakah ada hub konteks yang tersedia di perangkat. Ini adalah panggilan satu kali pemblokiran, sehingga harus diselesaikan dengan cepat untuk menghindari penundaan boot, dan harus mengembalikan hasil yang akurat, karena hub konteks baru tidak dapat diperkenalkan setelahnya.

Memuat dan membongkar nanoapps

Hub konteks dapat menyertakan sekumpulan nanoapp yang disertakan dalam gambar perangkat dan dimuat saat CHRE dimulai. Ini dikenal sebagai nanoapps pramuat, dan harus disertakan dalam kemungkinan respons pertama ke queryApps() .

Context Hub HAL juga mendukung bongkar muat nanoapps secara dinamis saat runtime, melalui fungsi loadNanoApp() dan unloadNanoApp() . Nanoapps disediakan untuk HAL dalam format biner khusus untuk perangkat keras CHRE dan implementasi perangkat lunak perangkat.

Jika implementasi untuk memuat nanoapp melibatkan penulisannya ke memori nonvolatile, seperti penyimpanan flash yang terpasang ke prosesor yang menjalankan CHRE, maka implementasi CHRE harus selalu boot dengan nanoapps dinamis ini dalam keadaan nonaktif. Ini berarti bahwa tidak ada kode nanoapp yang dijalankan hingga permintaan enableNanoapp() diterima melalui HAL. Nanoapps yang dimuat sebelumnya dapat menginisialisasi dalam keadaan aktif.

Hub konteks dimulai ulang

Meskipun CHRE tidak diharapkan untuk memulai ulang selama operasi normal, itu mungkin diperlukan untuk memulihkan dari kondisi yang tidak terduga seperti upaya untuk mengakses alamat memori yang tidak dipetakan. Dalam situasi ini, CHRE memulai ulang secara independen dari Android. HAL memberi tahu Android tentang ini melalui acara RESTARTED , yang harus dikirim hanya setelah CHRE diinisialisasi ulang ke titik di mana ia dapat menerima permintaan baru, seperti queryApps() .

Gambaran umum sistem CHRE

CHRE dirancang di sekitar arsitektur yang digerakkan oleh peristiwa, di mana unit utama komputasi adalah peristiwa yang diteruskan ke titik masuk penanganan peristiwa nanoapp. Meskipun kerangka kerja CHRE dapat multithread, nanoapp tertentu tidak pernah dijalankan dari beberapa utas secara paralel. Kerangka kerja CHRE berinteraksi dengan nanoapp tertentu melalui salah satu dari tiga titik masuk nanoapp ( nanoappStart() , nanoappHandleEvent() , dan nanoappEnd() ) atau melalui callback yang diberikan dalam panggilan CHRE API sebelumnya, dan nanoapps berinteraksi dengan kerangka kerja CHRE dan sistem yang mendasari melalui CHRE API. CHRE API menyediakan sekumpulan fungsionalitas dasar serta fasilitas untuk mengakses sinyal kontekstual, termasuk sensor, GNSS, Wi-Fi, WWAN, dan audio, dan dapat diperluas dengan kemampuan khusus vendor tambahan untuk digunakan oleh nanoapps khusus vendor. .

Bangun sistem

Meskipun Context Hub HAL dan komponen sisi AP lain yang diperlukan dibuat bersama Android, kode yang berjalan dalam CHRE dapat memiliki persyaratan yang membuatnya tidak kompatibel dengan sistem build Android, seperti kebutuhan akan toolchain khusus. Oleh karena itu, proyek CHRE di AOSP menyediakan sistem build yang disederhanakan berdasarkan GNU Make untuk mengkompilasi nanoapps, dan, secara opsional, kerangka kerja CHRE menjadi pustaka yang dapat diintegrasikan dengan sistem. Produsen perangkat yang menambahkan dukungan untuk CHRE harus mengintegrasikan dukungan sistem build untuk perangkat target mereka ke dalam AOSP.

CHRE API ditulis dengan standar bahasa C99, dan implementasi referensi menggunakan subset terbatas C ++ 11 yang cocok untuk aplikasi terbatas sumber daya.

CHRE API

CHRE API adalah kumpulan file header C yang menentukan antarmuka perangkat lunak antara nanoapp dan sistem. Ini dirancang untuk membuat kode nanoapps kompatibel di semua perangkat yang mendukung CHRE, yang berarti bahwa kode sumber untuk nanoapp tidak perlu dimodifikasi untuk mendukung jenis perangkat baru, meskipun mungkin perlu dikompilasi ulang khusus untuk prosesor perangkat target set instruksi atau antarmuka biner aplikasi (ABI). Arsitektur CHRE dan desain API juga memastikan bahwa nanoapp kompatibel dengan biner di berbagai versi CHRE API, yang berarti nanoapp tidak perlu dikompilasi ulang untuk dijalankan pada sistem yang mengimplementasikan versi berbeda dari CHRE API dibandingkan dengan API target tempat nanoapp dikompilasi. Dengan kata lain, jika biner nanoapp berjalan pada perangkat yang mendukung CHRE API v1.3, dan perangkat tersebut ditingkatkan untuk mendukung CHRE API v1.4, biner nanoapp yang sama akan terus berfungsi. Demikian pula, nanoapp dapat berjalan di CHRE API v1.2, dan dapat menentukan pada waktu proses apakah memerlukan fungsionalitas dari API v1.3 untuk mencapai fungsinya, atau apakah dapat beroperasi, berpotensi dengan degradasi fitur yang anggun.

Versi baru CHRE API dirilis bersamaan dengan Android, namun karena implementasi CHRE adalah bagian dari implementasi vendor , versi CHRE API yang didukung pada perangkat tidak harus ditautkan ke versi Android.

Ringkasan versi

Seperti skema pembuatan versi HIDL Android , CHRE API mengikuti pembuatan versi semantik . Versi mayor menunjukkan kompatibilitas biner, sedangkan versi minor bertambah ketika fitur yang kompatibel dengan versi sebelumnya diperkenalkan. CHRE API menyertakan penjelasan 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 kapan perbaikan bug atau pembaruan kecil dilakukan dalam implementasi.

Versi 1.0 (Android 7)

Termasuk dukungan untuk sensor, dan fungsionalitas nanoapp inti, seperti acara 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 penyempurnaan umum untuk mengaktifkan komunikasi nanoapp-ke-nanoapp, dan peningkatan lainnya.

Versi 1.2 (Android 9)

Menambahkan dukungan untuk data dari mikrofon berdaya rendah, rentang Wi-Fi RTT, pemberitahuan bangun / tidur AP, dan peningkatan lainnya.

Versi 1.3 (Android 10)

Meningkatkan kemampuan yang terkait dengan data kalibrasi sensor, menambahkan dukungan untuk pembilasan data sensor batch sesuai permintaan, menentukan jenis sensor deteksi langkah, dan memperluas peristiwa lokasi GNSS dengan bidang akurasi tambahan.

Versi 1.4 (Android 11)

Menambahkan dukungan untuk informasi sel 5G, dump debug nanoapp, dan peningkatan lainnya.

Fitur sistem wajib

Sementara sumber sinyal kontekstual, seperti sensor, dikategorikan ke dalam area fitur opsional, beberapa fungsi inti diperlukan di semua implementasi CHRE. Ini termasuk API sistem inti, seperti yang untuk menyetel pengatur waktu, mengirim dan menerima pesan ke klien di prosesor aplikasi, logging, dan lainnya. Untuk detail selengkapnya, lihat header API .

Selain fitur sistem inti yang dikodifikasikan dalam CHRE API, ada juga fitur level sistem CHRE wajib yang ditentukan pada level HAL Hub Konteks. Yang paling signifikan dari ini adalah kemampuan untuk memuat dan membongkar nanoapps secara dinamis.

Library standar C / C ++

Untuk meminimalkan penggunaan memori dan kompleksitas sistem, implementasi CHRE diperlukan hanya untuk mendukung subset dari library C dan C ++ standar dan fitur bahasa yang memerlukan dukungan runtime. Mengikuti prinsip-prinsip ini, beberapa fitur secara eksplisit dikecualikan karena memori dan / atau ketergantungan tingkat OS yang ekstensif, dan lainnya karena digantikan oleh API khusus CHRE yang lebih sesuai. Meskipun tidak dimaksudkan sebagai daftar yang lengkap, kemampuan berikut 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 ++
  • C ++ Standard Template Library (STL)
  • Pustaka Ekspresi Reguler Standar C ++
  • Alokasi memori dinamis melalui fungsi standar (misalnya, malloc , calloc , realloc , free , operator new ), dan fungsi library standar lainnya yang secara inheren menggunakan alokasi dinamis, seperti std::unique_ptr
  • Lokalisasi dan dukungan karakter Unicode
  • Perpustakaan tanggal dan waktu
  • Fungsi yang mengubah aliran program normal, termasuk <setjmp.h> , <signal.h> , abort , std::terminate
  • Mengakses lingkungan host, termasuk system , getenv
  • POSIX dan pustaka lain yang tidak termasuk dalam standar bahasa C99 atau C ++ 11

Dalam banyak kasus, fungsionalitas yang setara tersedia dari fungsi CHRE API dan / atau pustaka utilitas. Misalnya, chreLog bisa digunakan untuk debug logging yang ditargetkan ke sistem logcat Android, di mana program yang lebih tradisional mungkin menggunakan printf atau std::cout .

Sebaliknya, beberapa fungsionalitas pustaka standar diperlukan. Terserah pada implementasi platform untuk mengeksposnya melalui pustaka statis untuk dimasukkan dalam biner nanoapp, atau dengan penautan dinamis antara nanoapp dan sistem. Ini termasuk, tetapi tidak terbatas pada:

  • Utilitas string / array: memcmp , memcpy , memmove , memset , strlen
  • Pustaka matematika: Fungsi floating-point presisi tunggal yang umum digunakan:

    • Operasi dasar: ceilf , fabsf , floorf , fmaxf , fminf , fmodf , roundf , lroundf , remainderf
    • Fungsi eksponensial / daya: expf , log2f , powf , sqrtf
    • Trigonometri / fungsi hiperbolik: sinf , cosf , tanf , asinf , acosf , atan2f , tanhf

Sementara beberapa platform yang mendasarinya mendukung fungsionalitas tambahan, nanoapp tidak dianggap portabel di seluruh implementasi CHRE kecuali jika itu membatasi ketergantungan eksternalnya ke fungsi API CHRE dan fungsi pustaka standar yang disetujui.

Fitur pilihan

Untuk mempromosikan perangkat keras dan perangkat lunak, CHRE API dibagi menjadi beberapa area fitur, yang dianggap opsional dari perspektif API. Meskipun fitur ini mungkin tidak diperlukan untuk mendukung implementasi CHRE yang kompatibel, fitur tersebut mungkin diperlukan untuk mendukung nanoapp tertentu. Meskipun platform tidak mendukung sekumpulan API tertentu, nanoapp yang mereferensikan fungsi tersebut harus dapat dibangun dan dimuat.

Sensor

CHRE API memberikan kemampuan untuk meminta data dari sensor termasuk akselerometer, giroskop, magnetometer, sensor cahaya sekitar, dan proximity. API ini dimaksudkan untuk menyediakan set fitur yang mirip dengan Android Sensors API, termasuk dukungan untuk sampel sensor batch untuk mengurangi konsumsi daya. Memproses data sensor dalam CHRE memungkinkan daya yang jauh lebih rendah dan pemrosesan latensi sinyal gerakan yang lebih rendah dibandingkan dengan berjalan di AP.

GNSS

CHRE menyediakan API untuk meminta data lokasi dari sistem satelit navigasi global (GNSS), termasuk GPS dan konstelasi satelit lainnya. Ini termasuk permintaan untuk perbaikan posisi berkala, serta data pengukuran mentah, meskipun keduanya merupakan kemampuan independen. Karena CHRE memiliki tautan langsung ke subsistem GNSS, daya berkurang dibandingkan dengan permintaan GNSS berbasis AP, karena AP dapat tetap tertidur selama seluruh siklus hidup sesi lokasi.

Wifi

CHRE menyediakan kemampuan untuk berinteraksi dengan chip Wi-Fi, terutama untuk tujuan lokasi. Meskipun GNSS berfungsi dengan baik untuk lokasi luar ruangan, hasil pemindaian Wi-Fi dapat memberikan informasi lokasi yang akurat di dalam ruangan dan di area berkembang. Selain untuk menghindari biaya membangunkan AP untuk pemindaian, CHRE dapat mendengarkan hasil pemindaian Wi-Fi yang dilakukan oleh firmware Wi-Fi untuk tujuan konektivitas, yang biasanya tidak dikirimkan ke AP karena alasan daya. Memanfaatkan pemindaian konektivitas untuk tujuan kontekstual membantu mengurangi jumlah total pemindaian Wi-Fi yang dilakukan, menghemat daya.

Dukungan untuk Wi-Fi telah ditambahkan di CHRE API v1.1, termasuk kemampuan untuk memantau hasil pemindaian dan memicu pemindaian sesuai permintaan. Kemampuan ini diperluas di v1.2 dengan kemampuan untuk melakukan pengukuran Round-Trip Time (RTT) terhadap titik akses yang mendukung fitur tersebut, yang memungkinkan penentuan posisi relatif yang akurat.

WWAN

CHRE API menyediakan kemampuan untuk mengambil informasi identifikasi sel untuk sel penyajian dan tetangganya, yang biasanya digunakan untuk tujuan lokasi berbutir kasar.

Audio

CHRE dapat memproses kumpulan data audio dari mikrofon berdaya rendah, yang biasanya memanfaatkan perangkat keras yang digunakan untuk mengimplementasikan SoundTrigger HAL. Memproses data audio di CHRE dapat memungkinkannya untuk digabungkan dengan data lain, seperti sensor gerak.

Implementasi referensi

Kode referensi untuk kerangka kerja CHRE disertakan dalam AOSP dalam proyek system/chre , diimplementasikan dalam C ++ 11. Meskipun tidak sepenuhnya diwajibkan, disarankan agar semua implementasi CHRE didasarkan pada basis kode ini, untuk membantu memastikan konsistensi dan mempercepat adopsi kemampuan baru. Kode ini dapat dilihat sebagai analog dengan kerangka kerja Android inti yang merupakan implementasi API sumber terbuka yang digunakan aplikasi, berfungsi sebagai dasar dan standar untuk kompatibilitas. Meskipun dapat disesuaikan dan diperluas dengan kemampuan khusus vendor, rekomendasinya adalah mempertahankan kode umum sedekat mungkin dengan referensi. Mirip dengan HAL Android, implementasi referensi CHRE menggunakan berbagai abstraksi platform untuk memungkinkannya diadaptasi ke perangkat apa pun yang memenuhi persyaratan minimum.

Untuk detail teknis dan panduan porting, lihat README yang disertakan dalam proyek system/chre .