ConfigStore HAL

Di Android 10, ConfigStore HAL menggunakan flag build untuk menyimpan nilai konfigurasi di partisi vendor , dan layanan di partisi system mengakses nilai tersebut menggunakan HIDL (hal ini juga berlaku di Android 9). Namun, karena konsumsi memori yang tinggi dan penggunaan yang sulit, ConfigStore HAL sudah tidak digunakan lagi.

ConfigStore HAL tetap berada di AOSP untuk mendukung partisi vendor lama. Pada perangkat yang menjalankan Android 10 atau lebih baru, surfaceflinger membaca properti sistem terlebih dahulu; jika tidak ada properti sistem yang ditentukan untuk item konfigurasi di `SurfaceFlingerProperties.sysprop`, `surfaceflinger` akan dikembalikan ke ConfigStore HAL.

Android 8.0 membagi OS Android monolitik menjadi partisi generik ( system.img ) dan khusus perangkat keras ( vendor.img dan odm.img ). Sebagai akibat dari perubahan ini, kompilasi bersyarat harus dihapus dari modul yang diinstal pada partisi sistem dan modul tersebut harus menentukan konfigurasi sistem pada waktu proses (dan berperilaku berbeda tergantung pada konfigurasi tersebut).

ConfigStore HAL menyediakan sekumpulan API untuk mengakses item konfigurasi read-only yang digunakan untuk mengonfigurasi framework Android. Halaman ini menjelaskan desain ConfigStore HAL (dan mengapa properti sistem tidak digunakan untuk tujuan ini); halaman lain di bagian ini merinci antarmuka HAL , implementasi layanan , dan penggunaan sisi klien , semuanya menggunakan surfaceflinger sebagai contoh. Untuk bantuan mengenai kelas antarmuka ConfigStore, lihat Menambahkan Kelas dan Item Antarmuka .

Mengapa tidak menggunakan properti sistem?

Kami mempertimbangkan untuk menggunakan properti sistem tetapi menemukan beberapa masalah mendasar, termasuk:

  • Batasan panjang nilai. Properti sistem memiliki batasan ketat pada panjang nilainya (92 byte). Selain itu, karena batasan ini telah diekspos secara langsung ke aplikasi Android sebagai makro C, menambah panjangnya dapat menyebabkan masalah kompatibilitas ke belakang.
  • Tidak ada dukungan tipe. Semua nilai pada dasarnya adalah string, dan API hanya mengurai string menjadi int atau bool . Tipe data gabungan lainnya (misalnya, array dan struct) harus dikodekan/didekode oleh klien (misalnya, "aaa,bbb,ccc" dapat dikodekan sebagai array yang terdiri dari tiga string).
  • Menimpa. Karena properti sistem baca-saja diimplementasikan sebagai properti tulis-sekali, vendor/ODM yang ingin mengganti nilai-nilai baca-saja yang ditentukan AOSP harus mengimpor nilai-nilai baca-saja mereka sendiri sebelum nilai-nilai baca-saja yang ditentukan AOSP. Hal ini, pada gilirannya, mengakibatkan nilai-nilai yang dapat ditulis ulang yang ditentukan vendor digantikan oleh nilai-nilai yang ditentukan AOSP.
  • Mengatasi kebutuhan ruang. Properti sistem memerlukan ruang alamat yang relatif besar dalam setiap proses. Properti sistem dikelompokkan dalam unit prop_area dengan ukuran tetap 128 KB, yang semuanya dialokasikan ke ruang alamat proses meskipun hanya satu properti sistem di dalamnya yang diakses. Hal ini dapat menyebabkan masalah pada perangkat 32-bit yang memerlukan ruang alamat.

Kami berusaha mengatasi keterbatasan ini tanpa mengorbankan kompatibilitas, namun tetap khawatir bahwa properti sistem tidak dirancang untuk mendukung akses item konfigurasi read-only. Akhirnya kami memutuskan bahwa properti sistem lebih cocok untuk berbagi beberapa item yang diperbarui secara dinamis di seluruh Android secara real-time, dan terdapat kebutuhan akan sistem baru yang didedikasikan untuk mengakses item konfigurasi hanya-baca.

Desain ConfigStore HAL

Desain dasarnya sederhana:

Desain HAL toko konfigurasi

Gambar 1. Desain ConfigStore HAL

  • Jelaskan flag build (saat ini digunakan untuk mengkompilasi kerangka kerja secara kondisional) di HIDL.
  • Vendor dan OEM memberikan SoC dan nilai khusus perangkat untuk flag build dengan mengimplementasikan layanan HAL.
  • Ubah kerangka kerja untuk menggunakan layanan HAL guna menemukan nilai item konfigurasi saat runtime.

Item konfigurasi yang saat ini direferensikan oleh kerangka kerja disertakan dalam paket HIDL berversi ( android.hardware.configstore@1.0 ). Vendor/OEM memberikan nilai pada item konfigurasi dengan mengimplementasikan antarmuka dalam paket ini, dan kerangka kerja menggunakan antarmuka tersebut ketika perlu mendapatkan nilai untuk item konfigurasi.

Pertimbangan keamanan

Flag build yang ditentukan dalam antarmuka yang sama dipengaruhi oleh kebijakan SELinux yang sama. Jika satu atau lebih flag build memiliki kebijakan SELinux yang berbeda, flag tersebut harus dipisahkan ke antarmuka lain . Hal ini memerlukan revisi besar-besaran pada android.hardware.configstore package karena antarmuka yang terpisah tidak lagi kompatibel dengan versi sebelumnya.