Mulai tahun 2026, untuk menyelaraskan dengan model pengembangan stabil trunk kami dan memastikan stabilitas platform untuk ekosistem, kami akan memublikasikan kode sumber ke AOSP pada Q2 dan Q4. Untuk membuat dan berkontribusi ke AOSP, gunakan android-latest-release. Cabang manifes android-latest-release akan selalu merujuk ke rilis terbaru yang dikirim ke AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 penggunaan memori yang tinggi dan penggunaan yang sulit, ConfigStore HAL telah dihentikan.

ConfigStore HAL tetap berada 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 kembali ke ConfigStore HAL.

Android 8.0 membagi Android OS monolitik menjadi partisi generik (system.img) dan khusus hardware (vendor.img dan odm.img). Sebagai hasil 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 ConfigStore HAL (dan alasan properti sistem tidak digunakan untuk tujuan ini); halaman lain di bagian ini menjelaskan detail antarmuka HAL, implementasi 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 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. Pada dasarnya, semua nilai 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 dikodekan sebagai array dari tiga string).
Menimpa. Karena properti sistem hanya baca diimplementasikan sebagai properti tulis sekali, vendor/OEM 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 ditimpa oleh 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 ruang alamatnya sangat berharga.

Kami mencoba mengatasi batasan ini tanpa mengorbankan kompatibilitas, tetapi terus khawatir bahwa properti sistem tidak dirancang untuk mendukung akses ke item konfigurasi hanya baca. Pada akhirnya, kami memutuskan bahwa properti sistem lebih cocok untuk berbagi 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 ConfigStore HAL

Desain dasarnya sederhana:

Desain HAL Configstore

Gambar 1. Desain ConfigStore HAL

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

Item konfigurasi yang saat ini direferensikan oleh framework disertakan dalam paket HIDL versi (android.hardware.configstore@1.0). Vendor/OEM menyediakan 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 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 pada android.hardware.configstore package karena antarmuka yang dipisahkan tidak lagi kompatibel mundur.