Proses rilis Generic Kernel Image (GKI)

Halaman ini menjelaskan cara GKI dirilis, termasuk rilis darurat di luar jadwal dan rilis per kuartal. Tujuan halaman ini adalah memberikan panduan kepada OEM tentang tempat mengambil GKI serta proses untuk perbaikan darurat out-of-band. OEM juga dapat menggunakan pengembangan GKI untuk mempelajari lebih lanjut cara mereka dapat bekerja sama dengan tim Kernel Android untuk mengoptimalkan kernel GKI untuk produk mereka.

Ritme rilis GKI

GKI dirilis setiap tiga bulan setelah pembekuan KMI.

Validitas build GKI untuk OEM

OEM dapat menggunakan GKI Android yang baru dirilis. OEM dapat meluncurkan build bersertifikasi GKI selama build tersebut mematuhi persyaratan kernel yang Didukung Jangka Panjang (LTS) dalam Android Security Bulletin (ASB).

Rilis GKI 16 KB

Tim rilis GKI menangani rilis GKI 16 KB menggunakan irama rilis per kuartal, pengujian kualifikasi, dan proses respin yang sama seperti rilis GKI 4 KB:

• Cabang yang didukung:
  • android15-6.6 (mulai Januari 2026)
  • android16-6.12 (mulai Maret 2026)
  • android17-6.18 (mulai Juni 2026)
• Paritas dan sertifikasi build: Biner GKI 16 KB menggunakan tag sumber dan ID build kernel yang sama dengan rilis GKI 4 KB yang sesuai. Hingga tahun 2027, tab build rilis 16 KB di halaman build rilis android15-6.6, android16-6.12, dan android17-6.18 menyediakan biner rilis GKI 16 KB yang tidak bersertifikasi. Anda tidak perlu mengupdate kernel 4 KB dan 16 KB secara bersamaan, meskipun kami merekomendasikannya.
• Respin on demand: Minta respin GKI 16 KB menggunakan proses dan formulir permintaan respin yang sama dengan build 4 KB.

Rilis bersertifikasi per kuartal

Rilis GKI per kuartal berisi boot.img yang telah diuji dan menyertakan sertifikat yang dimasukkan Google untuk membuktikan bahwa biner dibuat dari dasar kode sumber yang diketahui.

Setiap kuartal, kandidat rilis kuartalan GKI (tidak disertifikasi) dipilih setelah tanggal batas check-in. Setelah kandidat rilis kuartalan dipilih, perubahan baru tidak akan diterima dalam rilis bulan tersebut. Selama periode jendela tertutup, hanya perbaikan untuk bug yang menyebabkan kegagalan pengujian yang dapat ditangani. Kandidat rilis menjalani uji mutu—seperti yang dijelaskan di bagian kualifikasi GKI—untuk memverifikasi bahwa pengujian kepatuhan lulus pada build GSI+GKI dengan perangkat referensi serta Cuttlefish.

Gambar 1. Linimasa rilis GKI

Kualifikasi GKI

Tempat mendapatkan artefak build

OEM dapat memperoleh artefak untuk semua rilis dari ci.android.com.

Anda dapat menemukan informasi selengkapnya tentang CI, termasuk hasil pengujian di dasbor Android Continuous Integration.

FAQ

Berikut beberapa pertanyaan umum (FAQ) terkait proses rilis GKI.

Apakah mungkin untuk membangun biner GKI baru berdasarkan GKI yang sudah dirilis?

Ya, ini disebut sebagai respin. Proses respin didukung selama build GKI yang dirilis (yang respinnya diminta) mematuhi persyaratan LTS dalam Android Security Bulletin (ASB).

Apakah biner GKI dapat direproduksi?

Ya, berikut contohnya:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Untuk mereproduksi contoh, download manifest_$id.xml dan jalankan perintah berikut:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Anda dapat mengambil salinan artefak GKI dari out/.../dist.

Apakah biner GKI (termasuk patch spin darurat) telah di-build di codebase terbaru?

Tidak. Respin hanya berisi patch yang berada di atas kernel bersertifikasi kuartalan yang telah dipilih. Respin ini berisi semua perbaikan bug yang memblokir peluncuran yang dilaporkan hingga waktu tertentu oleh OEM yang menggunakan rilis triwulanan dasar yang sesuai. Lihat contoh berikut tentang cara terjadinya jenis skenario ini.

• OEM1 dan OEM2 memutuskan untuk menggunakan rilis biner GKI dari November 2021.
• OEM1 dan OEM2 menemukan masalah yang memerlukan patch untuk dukungan. Patch ini mungkin berbeda atau sama.
• Respin di atas biner November 2021 memiliki perbaikan pemblokiran peluncuran yang dilaporkan oleh OEM1 dan OEM2 selama periode respin, tetapi tidak lebih.
• Masalah yang disebutkan dalam poin kedua juga disertakan dalam rilis kuartalan GKI berikutnya.

Respin bulan Oktober memiliki semua patch yang dikirimkan OEM, tetapi patch OEM lainnya memengaruhi kami, karena belum diuji secara khusus dengan produk kami. Apakah hanya patch kami yang dapat disertakan?

Hal ini tidak mungkin. Jalur respin untuk masing-masing OEM tidak skalabel. Sebagai gantinya, tim GKI memeriksa setiap perubahan yang masuk ke build respin dan menguji perubahan dengan semua hardware yang tersedia sebelum membuat build baru. Jika tim GKI menemukan bahwa masalah tersebut khusus untuk OEM, perangkat, atau model tertentu, tim GKI dapat memverifikasi bahwa kode yang ditambahkan oleh perubahan hanya dieksekusi di perangkat, model, atau SKU yang terpengaruh.

Manfaat utama dari respin terpadu adalah setiap perangkat yang menggunakan dasar rilis yang sama akan saling mendapatkan manfaat, terutama jika bug yang mereka temukan bersifat umum dan berlaku untuk semua pengguna. Bug kernel inti yang ditemukan dalam pengujian operator adalah contoh spesifik dari konsep ini.

Apakah ada situasi saat Google memberikan informasi spesifik tentang patch OEM dan skenario masalah, sehingga OEM dapat mengevaluasi dampak dan risiko penerapan patch pada produk mereka?

Google tidak akan pernah menambahkan perubahan pada build respin hingga tim GKI memahami masalahnya dan mengumpulkan semua detailnya. Anda dapat melihatnya di log perubahan (pesan commit). Google tidak mengungkapkan perangkat spesifik yang terpengaruh, tetapi OEM selalu dapat menemukan deskripsi dan solusi masalah dalam log perubahan.