Eksplorasi Framework Project Treble dan Implementasi Generic System Image (GSI)

Latar Belakang dan Arsitektur Modular Project Treble

Sebelum diperkenalkannya Android 8.0 Oreo, proses pembaruan sistem operasi Android terkenal sangat lambat dan memerlukan biaya rekayasa yang sangat tinggi. Kendala utama ini berakar pada arsitektur monolitik sistem operasi, di mana kode kerangka kerja AOSP (Android Open Source Project) dan kode driver proprietary yang ditulis oleh vendor silikon (SoC vendor seperti Qualcomm, MediaTek, Samsung LSI) terjalin secara erat dalam partisi sistem yang sama.

Ketika Google merilis pembaruan versi Android baru, setiap vendor chipset harus melakukan penyesuaian ulang biner driver mereka, yang kemudian diserahkan kepada produsen perangkat (OEM) untuk dikompilasi kembali ke dalam firmware perangkat. Inisiatif Project Treble merombak total paradigma ini dengan memisahkan kode platform Android dari implementasi perangkat keras vendor melalui batas antarmuka formal yang terdefinisi secara stabil.

Pemisahan Partisi System, Vendor, dan Product

Treble memberlakukan arsitektur partisi modular yang ketat. Pada perangkat modern yang kompatibel dengan Treble, tanggung jawab fungsional didistribusikan ke partisi mandiri:

Partisi	Mount Point	Tanggung Jawab Komponen	Pembaruan Mandiri
`system`	`/system`	AOSP Application Framework, ART Runtime, dan pustaka biner inti Android.	Dapat diperbarui langsung tanpa memodifikasi driver vendor.
`vendor`	`/vendor`	Board Support Package (BSP), driver kernel HAL, dan firmware radio/sensor proprietari.	Dikelola oleh vendor chipset dan OEM perangkat keras.
`product`	`/product`	Kustomisasi antarmuka OEM, font sistem, dan paket aplikasi bawaan pabrik.	Dapat dikembangkan terpisah oleh tim UI produsen smartphone.
`system_ext`	`/system_ext`	Ekstensi kerangka kerja OEM yang terikat erat dengan platform system.	Memperluas API platform tanpa mencemari biner murni AOSP.

Rekomendasi Riset: Verifikasi Vendor Interface Matrix (VIM)

Sebelum memasang Generic System Image, pastikan file manifes kompatibilitas hardware pada /vendor/etc/vintf/manifest.xml selaras dengan target matrix framework pada /system/etc/vintf/compatibility_matrix.xml. Ketidakcocokan versi HAL akan memicu crash service_manager.

Antarmuka HAL: Dari Passthrough, HIDL, hingga AIDL untuk HAL

Sebagai jembatan komunikasi antara framework Android di ruang pengguna murni dengan driver vendor, Treble mendefinisikan antarmuka antarmuka Hardware Abstraction Layer (HAL) berbasis IPC (Inter-Process Communication):

Passthrough HAL: Biner pustaka bersama (.so) yang dimuat langsung ke dalam ruang memori proses pemanggil. Model ini ditinggalkan karena menimbulkan risiko crash proses sistem akibat bug driver pihak ketiga.
Binderized HAL via HIDL: Menggunakan HAL Interface Definition Language (HIDL) untuk menjalankan daemon vendor pada proses independen dan berkomunikasi melalui IPC /dev/vndbinder.
Stable AIDL HAL: Standar modern sejak Android 11+ yang menggabungkan antarmuka layanan IPC menggunakan bahasa definisi AIDL tunggal yang teruji dan hemat alokasi memori.

# Menampilkan seluruh layanan Hardware Abstraction Layer (HAL) yang terdaftar aktif
adb shell lshal

# Memeriksa kelayakan kompatibilitas VINTF (Vendor Interface)
adb shell vintf-cli check-compatibility

Penanganan Overlays dan Runtime Resource Overlay (RRO)

Tantangan teknis terbesar saat menjalankan image sistem generik murni (GSI) pada beragam perangkat keras OEM adalah perbedaan konfigurasi fisik layar (seperti punch-hole camera cutout, rounded corners, dan profil kurva kecerahan otomatis). Karena biner GSI tidak boleh dimodifikasi untuk masing-masing model telepon, AOSP memanfaatkan mekanisme Runtime Resource Overlay (RRO).

Paket RRO adalah file APK tanpa kode executable yang memuat pemetaan resource XML (misalnya config_mainBuiltInDisplayCutout). Paket overlay ini disimpan di partisi vendor atau product (/vendor/overlay/ atau /product/overlay/). Ketika sistem memuat aset UI, manajer resource sistem operasi Android secara dinamis menimpa nilai default AOSP dengan konfigurasi spesifik perangkat keras yang disediakan oleh vendor, menjamin antarmuka yang presisi tanpa mengubah biner sistem inti.

Verifikasi Kepatuhan Melalui CTS-on-GSI

Untuk memastikan bahwa pemisahan antarmuka Treble berjalan sempurna tanpa cacat fungsional, Google mewajibkan produsen menjalankan suite pengujian CTS-on-GSI. Dalam pengujian ini, partisi sistem bawaan pabrik dihapus sepenuhnya dan digantikan oleh image GSI resmi Google. Pengujian otomatis mengeksekusi ribuan kasus uji API publik Android untuk memverifikasi bahwa HAL vendor merespons pemanggilan binder secara standar. Jika perangkat gagal memenuhi kriteria kelulusan CTS-on-GSI, perangkat tersebut tidak akan memperoleh sertifikasi Google Mobile Services (GMS), menjamin bahwa ekosistem aplikasi pihak ketiga dapat berjalan secara konsisten di seluruh portofolio manufaktur.

Analisis Kompatibilitas Generic System Image (GSI)

Konsekuensi paling nyata dari pemisahan antarmuka Treble adalah terciptanya Generic System Image (GSI). GSI adalah build sistem operasi AOSP murni yang dikompilasi secara generik untuk arsitektur target prosesor tertentu (misalnya arm64-v8a) tanpa menyertakan satupun driver vendor proprietari.

Setiap perangkat seluler yang diluncurkan dengan sertifikasi Android 9.0 ke atas diwajibkan secara regulasi untuk dapat melakukan booting dan menjalankan pengujian Vendor Test Suite (VTS) menggunakan image biner GSI resmi tanpa modifikasi pada partisi vendor.

# Prosedur instalasi GSI murni via userspace fastbootd pada perangkat uji
# 1. Masuk ke mode fastbootd
fastboot reboot fastboot

# 2. Hapus partisi product lama jika terjadi kendala ruang pada partisi dinamis
fastboot delete-logical-partition product_a

# 3. Flashing image sistem AOSP murni ke partisi system
fastboot flash system system-arm64-ab.img

# 4. Format data pengguna untuk menginisialisasi ulang enkripsi FBE
fastboot -w
fastboot reboot

Kesimpulan dan Masa Depan Arsitektur AOSP

Project Treble merupakan transformasi struktural terbesar dalam sejarah perkembangan Android. Melalui batas isolasi antarmuka yang disiplin antara partisi system dan vendor, Treble tidak hanya mempercepat siklus rilis pembaruan keamanan bulanan dari produsen, melainkan juga membuka pintu laboratorium riset independen untuk mengeksplorasi build AOSP murni di atas ratusan model hardware ARM64 yang berbeda.