Skema pembuatan versi GKI

Halaman ini menjelaskan skema pembuatan versi untuk Generic Kernel Images (GKI). Generic Kernel Image (GKI) memiliki ID unik yang disebut rilis kernel. Rilis kernel terdiri dari versi antarmuka modul kernel (KMI) dan sublevel. Rilis kernel khusus untuk image yang dirilis, sedangkan versi KMI merepresentasikan antarmuka yang digunakan untuk membangun rilis. Versi KMI dapat mendukung beberapa rilis kernel. Rilis kernel hanya terkait dengan satu versi KMI. Jika antarmuka modul kernel harus diubah, pembuatan KMI akan diulang untuk mencerminkan perubahan pada versi KMI.

Ringkasan persyaratan

Tabel berikut merangkum istilah penting yang digunakan di halaman ini dan untuk update GKI.

Nama Simbol Contoh Deskripsi
Rilis kernel w.x.y-zzz-k-suffix 5.4.42-android12-0-foo ID unik untuk rilis GKI. Nilai ini adalah nilai yang ditampilkan oleh uname.
Versi KMI w.x-zzz-k 5.4-android12-0 Menjelaskan antarmuka modul kernel (KMI) antara GKI dan modul kernel yang dapat dimuat secara dinamis (DLKM).
Sublevel y 42 Menjelaskan urutan rilis rilis kernel dalam versi KMI yang sama.

Tabel berikut mencantumkan istilah terkait lainnya sebagai referensi.

Nama Simbol Contoh Deskripsi
w.x.y w.x.y 5.4.42

Untuk mengetahui detailnya, lihat Makefile Kernel Linux (cari "KERNELRELEASE").

w.x.y digunakan langsung di seluruh dokumen ini. Hal ini juga biasanya disebut sebagai nomor versi tiga bagian. Istilah yang digunakan dalam VINTF, versi kernel, dapat menyebabkan kebingungan dengan istilah lain, terutama w.

Variabel ini disebut sebagai kernel_version_tuple di libkver.

Tuple ini tidak boleh dikurangi oleh update apa pun, termasuk OTA atau mainline.
Cabang kernel zzz-w.x android12-5.4 Istilah ini digunakan dalam Jenis cabang kernel umum.
Versi w 5 Istilah ini tidak digunakan dalam dokumen ini. Variabel ini disebut sebagai version di libkver.
Tingkat patch x 4 Istilah ini tidak digunakan dalam dokumen ini. Variabel ini disebut sebagai patch_level di libkver.
Rilis Android zzz android12

Ini adalah nomor rilis Android (dessert) yang terkait dengan kernel.

Saat membandingkan kolom AndroidRelease, bagian numerik diekstrak dari string untuk perbandingan.

Nomor rilis Android tidak boleh dikurangi oleh update apa pun, termasuk OTA atau mainline.

Pembuatan KMI k 0

Ini adalah angka tambahan yang ditambahkan untuk menangani peristiwa yang tidak mungkin terjadi. Jika perbaikan bug keamanan memerlukan perubahan pada KMI dalam rilis Android yang sama, pembuatan KMI akan ditingkatkan.

Nomor pembuatan KMI dimulai dengan 0.

Desain pembuatan versi

Rilis kernel

Definisi

Untuk perangkat yang dikirimkan dengan GKI, rilis kernel ditentukan sebagai berikut:

KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w      .x         .y       -zzz           -k            -something

Untuk mengetahui informasi selengkapnya, lihat Menentukan rilis kernel dari perangkat.

Berikut adalah contoh rilis kernel.

5.4.42-android12-0-00544-ged21d463f856

Deskripsi

Rilis kernel adalah ID unik rilis GKI. Jika dua biner GKI memiliki rilis kernel yang sama, keduanya harus identik byte-wise.

Rilis kernel terdiri dari versi KMI, sublevel, dan akhiran. Untuk tujuan dokumen ini, sufiks setelah pembuatan KMI diabaikan.

Versi KMI

Definisi

Versi KMI ditentukan sebagai berikut:

KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w      .x         -zzz           -k

Perhatikan bahwa sublevel, y bukan bagian dari versi KMI. Untuk contoh di Rilis kernel, versi KMI adalah:

5.4-android12-0

Deskripsi

Versi KMI menjelaskan antarmuka modul kernel (KMI) antara GKI dan modul kernel yang dapat dimuat secara dinamis (DLKM).

Jika dua rilis kernel memiliki versi KMI yang sama, keduanya mengimplementasikan antarmuka modul kernel yang sama. DLKM yang kompatibel dengan salah satu perangkat juga kompatibel dengan perangkat lainnya.

Versi KMI tidak boleh diturunkan oleh update OTA apa pun.

Sublevel

Sublevel, y, menjelaskan urutan rilis kernel dalam versi KMI yang sama.

Untuk dua rilis kernel yang memiliki versi KMI yang sama, tetapi memiliki sublevel Y1 dan Y2:

  • Jika Y1 kurang dari atau sama dengan Y2, perangkat yang menjalankan Y1 dapat menerima update ke Y2.
  • Jika Y1 lebih besar dari Y2, perangkat yang menjalankan Y1 tidak dapat diupdate ke Y2.

Artinya, jika versi KMI tidak berubah, sublevel tidak boleh diturunkan oleh update OTA apa pun.

Menentukan rilis kernel dari perangkat

Rilis kernel lengkap dapat ditemukan dengan menjalankan uname -r, atau uname(2) dengan cuplikan kode berikut:

std::string get_kernel_release() {
  struct utsname buf;
  return uname(&buf) == 0 ? buf.release : "";
}

Contoh output-nya adalah:

5.4.42-android12-0-00544-ged21d463f856

Untuk tujuan dokumen ini, semua yang terjadi setelah pembuatan KMI diabaikan saat mengekstrak informasi kernel. Secara lebih formal, output uname -r diuraikan dengan regex berikut (dengan asumsi zzz selalu dimulai dengan "android"):

^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$

Informasi yang diabaikan dapat mencakup informasi seperti nomor build ci.android.com, jumlah patch di atas kernel dasar, dan hash SHA dari commit git.

libkver

Library, libkver, menyediakan antarmuka C++ untuk mengurai rilis kernel atau string versi KMI. Untuk mengetahui daftar API yang diekspos libkver, lihat packages/modules/Gki/libkver/include/kver.

Pemeriksaan VINTF

Untuk Android 11 atau yang lebih rendah, bagian rilis Android dari versi KMI ditentukan secara manual dalam manifes perangkat oleh produsen perangkat. Untuk mengetahui detailnya, lihat Aturan pencocokan kernel VINTF.

Mulai dari Android S, bagian rilis Android dari versi KMI dapat diekstrak dari kernel dan dimasukkan ke dalam manifes perangkat pada waktu build.

Karena persyaratan konfigurasi kernel umumnya tidak berubah, tidak perlu mengenkode k dalam matriks kompatibilitas. Namun, dalam kasus yang tidak mungkin terjadi di mana persyaratan konfigurasi kernel perlu diubah, pastikan hal berikut:

  • Persyaratan yang sesuai dari matriks kompatibilitas dihapus.
  • Pengujian VTS tambahan ditambahkan untuk memeriksa persyaratan baru yang bersyarat pada pembuatan KMI.

Versi image boot di metadata OTA

Meskipun image booting diupdate melalui update OTA, image tersebut harus dienkapsulasi dalam format payload OTA, payload.bin. Payload OTA mengenkode kolom version untuk setiap partisi. Saat update_engine menangani payload OTA, kolom ini dibandingkan untuk memastikan partisi tidak di-downgrade.

Untuk menghindari kebingungan, kolom version untuk partisi booting di metadata OTA disebut boot image version.

Karena ramdisk selalu dibangun dari awal, penggunaan stempel waktu ramdisk sudah cukup untuk mendeskripsikan seluruh image boot. Tidak perlu mengenkode rilis kernel dalam versi image boot, kecuali jika Anda menggabungkan image boot lama ke biner kernel baru di masa mendatang.

Sebelum update OTA, klien OTA memeriksa versi image booting dengan cara yang sama seperti partisi lainnya.