Proses rilis Generic Kernel Image (GKI)

Halaman ini menjelaskan cara GKI dirilis, termasuk rilis darurat mingguan, per kuartal, dan di luar band. Tujuan dokumen ini adalah untuk memberikan panduan kepada OEM tentang tempat mengambil GKI serta proses untuk perbaikan darurat di luar 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 dengan build bersertifikasi GKI selama build tersebut mematuhi persyaratan LTS dalam Android Security Bulletin (ASB).

Rilis bersertifikasi per kuartal

Rilis GKI per kuartal berisi boot.img yang telah diuji dan mencakup sertifikat yang disisipkan 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, yang biasanya merupakan build mingguan kedua pada bulan tersebut. 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 jaminan kualitas—seperti yang dijelaskan di bagian kualifikasi GKI—untuk memastikan bahwa pengujian kepatuhan lulus pada build GSI+GKI dengan perangkat referensi serta cuttlefish.

Gambar 1. Linimasa rilis GKI

Kualifikasi GKI

Tempat mendapatkan artefak build

Artefak untuk semua rilis dapat diperoleh 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 membuat biner GKI baru berdasarkan GKI yang sudah dirilis?

Ya, ini dikenal sebagai putaran ulang. Proses respin didukung selama build GKI yang dirilis (yang digunakan untuk meminta respin) mematuhi persyaratan LTS dalam Android Security Bulletin (ASB).

Apakah mungkin mereproduksi biner GKI?

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 dibangun 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 menggunakan rilis triwulanan dasar yang sesuai. Lihat contoh berikut tentang cara terjadinya skenario jenis ini.

• OEM1 dan OEM2 memutuskan untuk menggunakan rilis biner GKI mulai 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 ada yang lain.
• 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 "per-OEM" tidak dapat diskalakan. 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 memastikan bahwa kode yang ditambahkan oleh perubahan hanya dieksekusi di perangkat, model, atau SKU yang terpengaruh.

Manfaat utama dari rilis ulang terpadu adalah setiap perangkat yang menggunakan basis rilis yang sama akan saling diuntungkan, terutama jika bug yang ditemukan 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 dengan produk mereka?

Google tidak akan pernah menambahkan perubahan pada build respin hingga masalahnya dipahami dan semua detailnya telah dikumpulkan. Hal ini terlihat di log perubahan (pesan commit). Google tidak mengungkapkan perangkat spesifik yang terpengaruh, tetapi OEM selalu dapat menemukan deskripsi dan solusi masalah dalam log perubahan.