ConfigStore HAL

Di Android 10, HAL ConfigStore 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, HAL ConfigStore telah dihentikan.

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

Android 8.0 membagi OS Android monolitik menjadi partisi generik (system.img) dan khusus hardware (vendor.img dan odm.img). Sebagai akibat dari 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).

HAL ConfigStore menyediakan serangkaian API untuk mengakses item konfigurasi hanya baca yang digunakan untuk mengonfigurasi framework Android. Halaman ini menjelaskan desain HAL ConfigStore (dan alasan properti sistem tidak digunakan untuk tujuan ini); halaman lain dalam 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 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, peningkatan panjang dapat menyebabkan masalah kompatibilitas mundur.
  • Tidak ada dukungan jenis. Semua nilai pada dasarnya adalah string, dan API hanya mengurai string menjadi int atau bool. Jenis data gabungan lainnya (misalnya, array dan struct) harus di-encode/decode oleh klien (misalnya, "aaa,bbb,ccc" dapat dikodekan sebagai array tiga string).
  • Menimpa. 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. Akibatnya, nilai yang dapat ditulis ulang yang ditentukan vendor akan diganti dengan nilai yang ditentukan AOSP.
  • Persyaratan ruang alamat. Properti sistem menggunakan ruang alamat yang relatif besar di 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 memiliki ruang alamat terbatas.

Kami mencoba mengatasi batasan ini tanpa mengorbankan kompatibilitas, tetapi tetap khawatir bahwa properti sistem tidak dirancang untuk mendukung akses ke item konfigurasi hanya baca. Pada 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 akan sistem baru yang dikhususkan 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 kondisional) di HIDL.
  • Vendor dan OEM menyediakan nilai khusus SoC dan perangkat untuk tanda build dengan menerapkan layanan HAL.
  • Ubah framework untuk menggunakan layanan HAL guna menemukan nilai item konfigurasi saat runtime.

Item konfigurasi yang saat ini dirujuk oleh framework disertakan dalam paket HIDL versi (android.hardware.configstore@1.0). Vendor/OEM memberikan nilai ke item konfigurasi dengan menerapkan antarmuka dalam paket ini, dan framework menggunakan antarmuka saat 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 beberapa tanda build harus memiliki kebijakan SELinux yang berbeda, tanda tersebut harus dipisahkan ke antarmuka lain. Hal ini dapat memerlukan revisi besar pada android.hardware.configstore package karena antarmuka yang terpisah tidak lagi kompatibel dengan versi lama.