HAL ConfigStore

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, HAL ConfigStore 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 umum (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).

ConfigStore HAL 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 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 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 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 jumlah 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 memiliki ruang alamat yang berharga.

Kami mencoba mengatasi batasan ini tanpa mengorbankan kompatibilitas, tetapi terus merasa 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 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 kondisional) di HIDL.
  • Vendor dan OEM memberikan nilai khusus SoC dan 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 dirujuk oleh framework disertakan dalam paket HIDL berversi (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 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.