Halaman ini menjelaskan bagaimana GKI dirilis, termasuk mingguan, bulanan, dan keluar rilis darurat tali smartwatch. Tujuan dokumen ini adalah untuk memberikan OEM pedoman tentang di mana harus mengambil GKI serta proses untuk pelatihan dan perbaikan darurat. OEM juga dapat menggunakan GKI pengembangan mempelajari lebih lanjut cara bekerja dengan tim Kernel Android untuk mengoptimalkan {i>kernel<i} GKI untuk produk mereka.
Ritme rilis GKI
GKI dirilis dengan ritme bulanan setelah pembekuan KMI.
Rilis GKI Android 13, 14, dan 15
Tabel berikut hanya berlaku untuk
android13-5.10,
android13-5.15,
dan
android14-5.15.
Lihat tanggal rilis September 2024 di pengumuman ini.
| Build tersertifikasi bulanan GKI | Tanggal batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| November | 11 November 2024 | 27 November 2024 | Ya |
| Januari | 17 Januari 2025 | 31 Januari 2025 | Ya |
| Februari | 14 Februari 2025 | 28 Februari 2025 | Ya |
Tabel berikut hanya berlaku untuk
android14-6.1
dan
android15-6.6
Lihat tanggal rilis September 2024 di pengumuman ini.
| Build tersertifikasi bulanan GKI | Tanggal batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| Oktober | 1 Oktober 2024 | 14 Oktober 2024 | Ya |
| November | 1 November 2024 | 15 November 2024 | Ya |
| Desember | 2 Desember 2024 | 16 Desember 2024 | Ya |
| Januari | 6 Januari 2025 | 22 Januari 2025 | Ya |
Rilis GKI Android 12
Setelah Mei 2024, rilis GKI android12-5.10 dilakukan setiap tiga bulan dan
dipublikasikan pada pertengahan bulan.
Tabel berikut hanya berlaku untuk
android12-5.10
| Build tersertifikasi bulanan GKI | Tanggal batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| Juli | 3 Juli 2023 | 14 Juli 2023 | Ya |
| September | 1 September 2023 | 15 September 2023 | Ya |
| November | 3 November 2023 | 17 November 2023 | Ya |
| Januari | 5 Januari 2024 | 19 Januari 2024 | Ya |
| Maret | 4 Maret 2024 | 15 Maret 2024 | Ya |
| Mei | 1 Mei 2024 | 17 Mei 2024 | Ya |
| Agustus | 1 Agustus 2024 | 16 Agustus 2024 | Ya |
| November | 1 November 2024 | 15 November 2024 | Ya |
| Februari | 3 Februari 2025 | 17 Februari 2025 | Ya |
Validitas build GKI untuk OEM
OEM dapat menggunakan GKI Android yang baru saja dirilis. OEM dapat meluncurkan dengan Build bersertifikasi GKI selama memenuhi persyaratan LTS di Buletin Keamanan Android (ASB).
Rilis pengembangan mingguan
Rilis diuji dengan Cuttlefish untuk memastikan iklan tersebut lulus standar kualitas minimum.Biner GKI tersedia untuk layanan mandiri dari Android CI saat perubahan digabungkan. Build mingguan tidak akan disertifikasi, meskipun dapat digunakan sebagai dasar untuk pengembangan dan pengujian. Build mingguan tidak bisa digunakan untuk perangkat produksi untuk pengguna akhir.
Rilis tersertifikasi bulanan
Rilis bulanan GKI berisi boot.img yang diuji, yang menyertakan
sertifikat yang dimasukkan untuk membuktikan bahwa biner dibuat dari sumber yang dikenal
dasar kode Anda.
Setiap bulan, kandidat rilis bulanan GKI (tidak tersertifikasi) dipilih setelah tanggal batas waktu {i>check-in<i}, yang biasanya merupakan build mingguan kedua dari bulan itu. Setelah kandidat rilis bulanan dipilih, baru perubahan tidak akan diterima dalam rilis bulan tersebut. Selama jendela ditutup , hanya perbaikan untuk {i>bug<i} yang menyebabkan kegagalan uji yang dapat ditangani. Tujuan kandidat rilis menjalani uji mutu—sebagaimana dijelaskan dalam GKI kualifikasi—untuk memastikan lulus pengujian kepatuhan GSI+GKI di-build dengan perangkat referensi, serta sotong.
Gambar 1. Linimasa rilis GKI
Proses pemulihan darurat
Respin mengacu pada proses penggabungan ulang, pembuatan ulang, pengujian ulang, dan sertifikasi ulang biner setelah rilis publik kernel GKI. Anda dapat meminta respin biner tersertifikasi untuk salah satu dari hal berikut situasi:
- Untuk memperbarui daftar simbol.
- Untuk menerapkan perbaikan pada bug, termasuk bug yang ditemukan selama persetujuan lab operator.
- Untuk menambahkan hook vendor.
- Untuk menerapkan patch ke fitur yang sudah ada.
- Untuk menerapkan patch keamanan (setelah 6 bulan).
Patch keamanan secara otomatis digabungkan ke dalam cabang rilis hingga 6 bulan setelah cabang dirilis. Setelah batas waktu 6 bulan, Anda harus meminta respin untuk menerapkan patch keamanan ke cabang.
Panduan permintaan penyematan ulang
Sebelum meminta respin, perhatikan panduan berikut:
Respin hanya diizinkan di cabang rilis setelah rilis publik awal dari build bulanan telah diluncurkan.
Permintaan respin hanya diterima untuk cabang rilis tertentu untuk maksimum enam bulan setelah rilis publik awal. Setelah enam bulan, cabang memenuhi syarat untuk respin hanya untuk patch keamanan yang dikutip di Android Security Buletin.
Jika persyaratan LTS, yang ditentukan oleh Android Security Bulletin (ASB) menyebabkan cabang tidak mematuhi persyaratan, cabang tersebut tidak digunakan lagi. Berhenti menghubungkan ulang permintaan untuk cabang yang tidak digunakan lagi tidak diterima. Tanggal penghentian GKI tertentu cabang rilis disertakan dalam catatan build rilis GKI bulanan di bawah Rilis. Untuk perencanaan mendatang, persyaratan LTS diperbarui pada bulan Mei dan November setiap tahunnya. Misalnya,
android12-5.10-2023-07cabang (5.10.177) tidak didukung untuk respins setelah 1 Mei 2024, karenaandroid12-5.10-2023-07cabang (5.10.177) tidak mematuhi persyaratan LTS ASB-2024-05.Respins hanya berlaku untuk perbaikan bug mendesak, pembaruan daftar simbol, atau untuk menerapkan patch guna memperbaiki fitur yang ada.
Semua {i>patch<i} yang masuk ke cabang rilis bulanan harus sudah digabungkan ke dalam cabang utama pengembangan GKI. Misalnya, jika suatu {i>patch<i} diperlukan untuk respin dari
android12-5.10-2022-09, harus sudah digabungkan menjadiandroid12-5.10.Anda harus memilih patch dari cabang pengembangan GKI utama dan mengupload patch ke cabang rilis bulanan.
Dalam permintaan respin, Anda harus menetapkan prioritas (urgensi) pada permintaan tersebut. Prioritas ini membantu tim GKI untuk membantu partner dengan lebih baik pada waktu yang tepat. Untuk permintaan penting atau mendesak, tandai prioritas sebagai P0. Untuk P0 dan P1 permintaan, Anda juga harus menjustifikasi urgensi tersebut. Tabel berikut memberikan pemetaan prioritas {i>bug<i} dan waktu untuk resolusi (ESRT):
Prioritas ESRT P0 2 hari kerja P1 5 hari kerja P2 10 hari kerja P3 15 hari kerja
Anda harus mengirimkan permintaan respin terpisah per cabang rilis. Misalnya, jika respin diperlukan untuk
android12-5.10-2022-08danandroid12-5.10-2022-09, Anda harus membuat dua permintaan respin.Setelah build disediakan dan permintaan respin ditandai sebagai telah diperbaiki, Anda seharusnya tidak membuka kembali permintaan {i>respin<i} untuk menambahkan CL tambahan. Anda harus mengirimkan respin jika ada patch tambahan yang perlu digabungkan.
Untuk setiap CL yang dipertimbangkan, tambahkan tag berikut.
Bug: ID bug harus ditambahkan ke pesan commit untuk setiap CL.Change-Id: harus sama dengan ID Perubahan cabang dasar.
Jika permintaan respin memerlukan respons Anda, dan Anda tidak merespons dalam tiga hari kerja, prioritasnya akan turun satu tingkat (misalnya, P0 didowngrade menjadi P1). Jika Anda tidak menanggapi selama dua minggu, {i>bug<i} adalah ditandai sebagai Tidak Dapat Diperbaiki (Usang).
Kirim permintaan respin
Diagram berikut menunjukkan proses respin. Prosesnya dimulai ketika Partner OEM (Anda) mengirimkan permintaan respin.
Gambar 2. Proses respin
Untuk memasuki proses respin:
- Isi formulir permintaan Respin GKI.
dan segera hubungi Manajer Akun Teknis Google Anda. Formulir ini
membuat {i>bug<i} permintaan respin GKI. Bug permintaan respin dapat Anda lihat
(pemohon), tim GKI, dan individu tertentu yang Anda tambahkan ke
daftar CC bug.
- Jika Anda sudah memiliki perbaikan, permintaan akan mengarah ke patch kirimkan di AOSP sehingga Google dapat meninjaunya. Jika pengiriman patch belum memungkinkan, {i>patch<i} tersebut harus dilampirkan sebagai file teks ke permintaan.
- Jika Anda tidak memiliki perbaikan, permintaan harus berisi sebanyak informasi penting, termasuk log dan nomor versi {i>kernel<i}, agar Google dapat membantu men-{i>debug<i} masalah.
- Tim GKI Google meninjau permintaan tersebut dan menyetujui atau menyerahkannya kembali kepada Anda jika memerlukan informasi lebih lanjut.
- Setelah perbaikan disepakati, tim GKI Google meninjau kode berubah. Peninjauan memulai jangka waktu ESRT. Tim GKI menggabungkan, membangun, dan menguji untuk regresi, dan mengesahkan perubahan.
- Biner dirilis ke ci.android.com. Tujuan Jangka waktu ESRT berakhir dan tim Google GKI menandai permintaan sebagai telah diperbaiki dan mereferensikan build respin. Build respin juga diposting di Halaman build rilis Kernel Image (GKI) generik.
Kualifikasi GKI
| Jenis build GKI | Penegakan kualitas | Catatan |
|---|---|---|
| Mingguan | Pengujian cumi-cumi
|
|
| Bulanan (tesertifikasi) | Pengujian cumi-cumi
|
|
| Respin (tersertifikasi) | Pengujian cumi-cumi
|
|
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 Continuous Integration Android.
FAQ
Berikut adalah beberapa pertanyaan umum (FAQ) terkait proses rilis GKI.
Apakah mungkin untuk membangun biner GKI baru berdasarkan GKI yang sudah dirilis?
Ya, hal ini dikenal sebagai respin. Proses respin didukung selama merilis build GKI (tempat respin diminta) sesuai dengan LTS dalam Android Security Bulletin (ASB).
Apakah saya dapat 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
berikut:
repo init -u https://android.googlesource.com/kernel/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_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 spin patch darurat) telah dibangun di codebase terbaru?
Tidak. Respin hanya berisi patch yang berada di atas sertifikasi bulanan {i>kernel<i} yang telah dipilih. Respin ini berisi semua bug pemblokir peluncuran perbaikan yang dilaporkan hingga waktu tertentu oleh OEM yang menggunakan basis yang sesuai rilis bulanan. Lihat contoh berikut tentang bagaimana jenis skenario ini terjadi.
- 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 mungkin sama.
- Respin di atas biner November 2021 memiliki perbaikan pemblokiran peluncuran yang dilaporkan oleh OEM1 dan OEM2 selama periode respin, tetapi tidak ada lagi.
- Hal-hal yang disebutkan dalam butir kedua juga disertakan dalam GKI berikutnya rilis bulanan.
Respin Oktober memiliki semua patch yang dikirimkan OEM, tetapi patch OEM lain memengaruhi kami, karena patch tersebut belum diuji secara khusus dengan produk kami. Apakah saya hanya dapat menyertakan patch?
Hal ini tidak mungkin. "Per-OEM" jalur respin tidak skalabel. Sebaliknya, tim GKI meneliti setiap perubahan yang masuk ke dalam membangun, dan menguji perubahan dengan semua perangkat keras yang tersedia sebelum membuat buat. Jika tim GKI menemukan bahwa masalah hanya terjadi pada OEM, perangkat, atau tim GKI dapat memastikan bahwa kode yang ditambahkan oleh perubahan hanya dapat dijalankan pada perangkat, model, atau SKU yang terpengaruh.
Manfaat utama dari perhitungan terpadu adalah bahwa setiap perangkat yang menggunakan basis rilis yang sama akan menguntungkan satu sama lain, terutama jika {i>bug<i} mereka temukan bersifat umum dan berlaku untuk semua pengguna. Bug kernel inti ditemukan dalam pengujian operator adalah contoh spesifik dari konsep ini.
Apakah ada situasi saat Google memberikan informasi spesifik tentang patch dan skenario masalah OEM, sehingga OEM dapat mengevaluasi dampak dan risiko penerapan patch pada produk mereka?
Google tidak akan pernah menambahkan perubahan pada build respin sampai masalahnya dipahami dan semua detail telah dikumpulkan. Hal ini terlihat di {i>changelog<i} (pesan commit). Google tidak mengungkapkan perangkat spesifik yang terpengaruh, tetapi OEM selalu dapat menemukan deskripsi dan solusi masalah dalam log perubahan.