HAL ConfigStore

Di Android 10, ConfigStore HAL menggunakan flag build untuk menyimpan nilai konfigurasi dalam partisi vendor, dan layanan dalam 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 tidak digunakan lagi.

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

Android 8.0 membagi OS Android monolitik menjadi partisi generik (system.img) dan khusus hardware (vendor.img dan odm.img). Akibat perubahan ini, kompilasi bersyarat harus dihapus dari modul yang diinstal ke partisi sistem dan modul tersebut harus menentukan konfigurasi sistem saat runtime (dan berperilaku berbeda bergantung pada konfigurasi tersebut).

ConfigStore HAL menyediakan serangkaian API untuk mengakses item konfigurasi hanya baca yang digunakan untuk mengonfigurasi framework Android. Halaman ini menjelaskan desain ConfigStore HAL (dan alasan properti sistem tidak digunakan untuk tujuan ini); halaman lain di bagian ini menjelaskan antarmuka HAL, penerapan layanan, dan penggunaan sisi klien, semuanya menggunakan surfaceflinger sebagai contoh. Untuk mendapatkan bantuan terkait class antarmuka ConfigStore, lihat Menambahkan Class dan Item Antarmuka.

Mengapa tidak menggunakan properti sistem?

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

  • Batas panjang pada nilai. Properti sistem memiliki batas ketat pada panjang nilainya (92 byte). Selain itu, karena batas ini telah diekspos langsung ke aplikasi Android sebagai makro C, meningkatkan panjangnya dapat menyebabkan masalah kompatibilitas mundur.
  • Tidak ada dukungan jenis. Semua nilai pada dasarnya adalah string, dan API hanya akan mengurai string menjadi int atau bool. Jenis data gabungan lainnya (misalnya, array dan struct) harus dienkode/didekode oleh klien (misalnya, "aaa,bbb,ccc" dapat dienkode sebagai array dari tiga string).
  • Penggantian. Karena properti sistem hanya baca diimplementasikan sebagai properti tulis sekali, vendor/ODM yang ingin mengganti nilai hanya baca yang ditentukan AOSP harus mengimpor nilai hanya baca mereka sendiri sebelum nilai hanya baca yang ditentukan AOSP. Hal ini, pada gilirannya, menyebabkan nilai yang dapat ditulis ulang yang ditentukan vendor diganti oleh nilai yang ditentukan AOSP.
  • Persyaratan ruang alamat. 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 saat ruang alamat sangat berharga.

Kami berusaha mengatasi batasan ini tanpa mengorbankan kompatibilitas, tetapi terus khawatir bahwa properti sistem tidak dirancang untuk mendukung akses item konfigurasi hanya-baca. Akhirnya, kami memutuskan bahwa properti sistem lebih cocok untuk membagikan beberapa item yang diperbarui secara dinamis di seluruh Android secara real time, dan bahwa ada kebutuhan untuk sistem baru yang didedikasikan untuk mengakses item konfigurasi hanya baca.

Desain HAL ConfigStore

Desain dasarnya sederhana:

Desain HAL Configstore

Gambar 1. Desain HAL ConfigStore

  • Menjelaskan flag build (saat ini digunakan untuk mengompilasi framework secara bersyarat) di HIDL.
  • Vendor dan OEM memberikan nilai SoC dan khusus perangkat untuk flag build dengan menerapkan layanan HAL.
  • Ubah framework untuk menggunakan layanan HAL guna menemukan nilai item konfigurasi saat runtime.

Item konfigurasi yang saat ini direferensikan oleh framework akan disertakan dalam paket HIDL berversi (android.hardware.configstore@1.0). Vendor/OEM menyediakan nilai ke item konfigurasi dengan mengimplementasikan antarmuka di paket ini, dan framework akan menggunakan antarmuka tersebut saat perlu mendapatkan nilai untuk item konfigurasi.

Pertimbangan keamanan

Flag build yang ditentukan di antarmuka yang sama akan terpengaruh oleh kebijakan SELinux yang sama. Jika satu atau beberapa flag build harus memiliki kebijakan SELinux yang berbeda, flag tersebut harus dipisahkan ke antarmuka lain. Hal ini dapat memerlukan revisi besar android.hardware.configstore package karena antarmuka yang terpisah tidak lagi kompatibel dengan versi sebelumnya.