การกำหนดเวอร์ชัน GKI

หน้านี้อธิบายรูปแบบการกำหนดเวอร์ชันสำหรับ Generic Kernel Images (GKI) Generic Kernel Image (GKI) มีตัวระบุเฉพาะที่เรียกว่าเคอร์เนลรีลีส รีลีสเคอร์เนลประกอบด้วยเวอร์ชันเคอร์เนลโมดูลอินเตอร์เฟส (KMI) และระดับย่อย เคอร์เนลรีลีสนั้นเฉพาะสำหรับอิมเมจที่ปล่อยออกมา ในขณะที่เวอร์ชัน KMI แสดงถึงอินเทอร์เฟซที่สร้างรีลีส เวอร์ชัน KMI สามารถรองรับเคอร์เนลได้หลายรุ่น การเผยแพร่เคอร์เนลเชื่อมโยงกับ KMI เวอร์ชันเดียวเท่านั้น ในกรณีที่ต้องเปลี่ยนอินเทอร์เฟซโมดูลเคอร์เนลซึ่งไม่น่าจะเกิดขึ้นได้ การสร้าง KMI จะถูกทำซ้ำเพื่อสะท้อนการเปลี่ยนแปลงในเวอร์ชัน KMI

สรุปเงื่อนไข

ตารางต่อไปนี้สรุปคำศัพท์สำคัญที่ใช้ในหน้านี้และสำหรับการอัปเดต GKI

ชื่อ	เครื่องหมาย	ตัวอย่าง	คำอธิบาย
เคอร์เนลปล่อย	wxy-zzz-k-คำต่อท้าย	5.4.42-android12-0-foo	ตัวระบุที่ไม่ซ้ำสำหรับรุ่น GKI นี่คือค่าที่ส่งคืนโดย uname
เวอร์ชัน KMI	wx-zzz-k	5.4-android12-0	อธิบายอินเทอร์เฟซโมดูลเคอร์เนล (KMI) ระหว่าง GKI และโมดูลเคอร์เนลที่โหลดได้แบบไดนามิก (DLKM)
ระดับย่อย	y	42	อธิบายลำดับการวางจำหน่ายของเคอร์เนลรีลีสภายในเวอร์ชัน KMI เดียวกัน

ตารางต่อไปนี้แสดงรายการคำที่เกี่ยวข้องอื่น ๆ เป็นข้อมูลอ้างอิง

ชื่อ	เครื่องหมาย	ตัวอย่าง	คำอธิบาย
wxy	wxy	5.4.42	สำหรับรายละเอียด โปรดดูที่ Linux Kernel Makefiles (ค้นหา "KERNELELEASE") wxy ถูกใช้โดยตรงตลอดทั้งเอกสารนี้ โดยทั่วไปจะเรียกว่า หมายเลขเวอร์ชันสามส่วน คำที่ใช้ใน VINTF ซึ่งเป็น เวอร์ชันเคอร์เนล อาจทำให้เกิดความสับสนกับคำอื่นๆ โดยเฉพาะ w ตัวแปรนี้เรียกว่า kernel_version_tuple ใน libkver tuple นี้ต้องไม่ลดลงโดยการอัปเดตใดๆ รวมถึง OTA หรือ mainline
สาขาเคอร์เนล	zzz-wx	android12-5.4	คำนี้ใช้ใน ประเภทสาขาเคอร์เนลทั่วไป
เวอร์ชั่น	w	5	คำนี้ไม่ได้ใช้ในเอกสารนี้ ตัวแปรนี้เรียกว่า เวอร์ชัน ใน libkver
ระดับแพทช์	x	4	คำนี้ไม่ได้ใช้ในเอกสารนี้ ตัวแปรนี้เรียกว่า patch_level ใน libkver
การเปิดตัว Android	zzz	android12	นี่คือหมายเลขรีลีสของ Android (ของหวาน) ที่เชื่อมโยงกับเคอร์เนล เมื่อเปรียบเทียบฟิลด์ AndroidRelease ส่วนที่เป็นตัวเลขจะถูกดึงออกจากสตริงเพื่อเปรียบเทียบ หมายเลขรุ่นของ Android จะต้องไม่ลดลงจากการอัปเดตใดๆ รวมถึง OTA หรือ mainline
การสร้าง KMI	k	0	นี่เป็นหมายเลขเพิ่มเติมที่เพิ่มเข้ามาเพื่อจัดการกับเหตุการณ์ที่ไม่น่าจะเกิดขึ้น หากการแก้ไขจุดบกพร่องด้านความปลอดภัยจำเป็นต้องเปลี่ยนแปลง KMI ภายใน Android รุ่นเดียวกัน การสร้าง KMI จะเพิ่มขึ้น หมายเลขรุ่น KMI เริ่มต้นด้วย 0

การออกแบบเวอร์ชัน

เคอร์เนลปล่อย

คำนิยาม

สำหรับอุปกรณ์ที่มาพร้อมกับ GKI เคอร์เนลรีลีสถูกกำหนดดังนี้:

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

สำหรับข้อมูลเพิ่มเติม โปรดดูที่ การ พิจารณารีลีสเคอร์เนลจากอุปกรณ์

ต่อไปนี้คือตัวอย่างการรีลีสเคอร์เนล

5.4.42-android12-0-00544-ged21d463f856

คำอธิบาย

รีลีสเคอร์เนลเป็น ID เฉพาะของรีลีส GKI หากไบนารี GKI สองรายการมีเคอร์เนลรีลีสเหมือนกัน ไบนารีจะต้องเหมือนกันทุกประการ

การเผยแพร่เคอร์เนลประกอบด้วยเวอร์ชัน KMI ระดับย่อย และส่วนต่อท้าย สำหรับวัตถุประสงค์ของเอกสารนี้ คำต่อท้ายหลังจากการสร้าง KMI จะถูกละเว้น

เวอร์ชัน KMI

คำนิยาม

เวอร์ชัน KMI ถูกกำหนดดังนี้:

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

โปรดทราบว่าระดับย่อย y ไม่ได้เป็นส่วนหนึ่งของเวอร์ชัน KMI สำหรับตัวอย่างใน Kernel release เวอร์ชัน KMI คือ:

5.4-android12-0

คำอธิบาย

เวอร์ชัน KMI อธิบายอินเทอร์เฟซโมดูลเคอร์เนล (KMI) ระหว่าง GKI และโมดูลเคอร์เนลที่โหลดได้แบบไดนามิก (DLKM)

หากเคอร์เนลรีลีสสองรุ่นมีเวอร์ชัน KMI เดียวกัน เคอร์เนลจะใช้อินเทอร์เฟซโมดูลเคอร์เนลเดียวกัน DLKM ที่เข้ากันได้ก็เข้ากันได้กับอีกอันหนึ่งเช่นกัน

เวอร์ชัน KMI ต้องไม่ลดลงด้วยการอัปเดต OTA ใดๆ

ระดับย่อย

ระดับย่อย y อธิบายลำดับการวางจำหน่ายของเคอร์เนลรีลีสภายในเวอร์ชัน KMI เดียวกัน

สำหรับสองเคอร์เนลรีลีสที่มีเวอร์ชัน KMI เดียวกัน แต่มีระดับย่อย Y1 และ Y2 ตามลำดับ:

• หาก Y1 น้อยกว่าหรือเท่ากับ Y2 อุปกรณ์ที่ใช้งาน Y1 สามารถรับการอัปเดตเป็น Y2 ได้
• หาก Y1 มากกว่า Y2 อุปกรณ์ที่ใช้งาน Y1 จะไม่สามารถอัปเดตเป็น Y2 ได้

นั่นคือ หากเวอร์ชัน KMI ไม่เปลี่ยนแปลง ระดับย่อยจะต้องไม่ลดลงตามการอัปเดต OTA ใดๆ

กำหนดเคอร์เนลรีลีสจากอุปกรณ์

คุณสามารถค้นหาเคอร์เนลรุ่นเต็มได้โดยเรียกใช้ uname -r หรือ uname(2) ด้วยข้อมูลโค้ดต่อไปนี้:

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

ตัวอย่างผลลัพธ์คือ:

5.4.42-android12-0-00544-ged21d463f856

สำหรับวัตถุประสงค์ของเอกสารนี้ สิ่งใดก็ตามหลังจากการสร้าง KMI จะถูกละเว้นเมื่อทำการดึงข้อมูลเคอร์เนล อย่างเป็นทางการมากขึ้น ผลลัพธ์ของ uname -r ถูกแยกวิเคราะห์ด้วย regex ต่อไปนี้ (สมมติว่า zzz ขึ้นต้นด้วย "android" เสมอ):

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

ข้อมูลที่ละเว้นอาจรวมถึงข้อมูล เช่น หมายเลข บิลด์ ci.android.com จำนวนแพตช์ที่ด้านบนของเคอร์เนลพื้นฐาน และแฮช SHA ของคอมมิต git

libkver

ไลบรารี libkver จัดเตรียมอินเทอร์เฟซ C++ เพื่อแยกวิเคราะห์เคอร์เนลรีลีสหรือสตริงเวอร์ชัน KMI สำหรับรายการ API ที่ libkver เปิดเผย โปรดดูที่ packages/modules/Gki/libkver/include/kver

การตรวจสอบ VinTF

สำหรับ Android 11 หรือต่ำกว่า ส่วนการวางจำหน่าย Android ของเวอร์ชัน KMI จะถูกระบุด้วยตนเองในรายการอุปกรณ์โดยผู้ผลิตอุปกรณ์ สำหรับรายละเอียด โปรดดู กฎการจับคู่เคอร์เนล VINTF

จาก Android S ส่วนการวางจำหน่าย Android ของเวอร์ชัน KMI สามารถดึงข้อมูลจากเคอร์เนลและฉีดเข้าไปในรายการอุปกรณ์ในเวลาที่สร้าง

เนื่องจากข้อกำหนดคอนฟิกูเรชันเคอร์เนลโดยทั่วไปไม่เปลี่ยนแปลง ไม่จำเป็นต้องเข้ารหัส k ภายในเมทริกซ์ความเข้ากันได้ อย่างไรก็ตาม ในกรณีที่จำเป็นต้องเปลี่ยนข้อกำหนดคอนฟิกูเรชันเคอร์เนล ซึ่งไม่น่าจะเป็นไปได้ ให้ตรวจสอบสิ่งต่อไปนี้:

• ข้อกำหนดที่เกี่ยวข้องจากเมทริกซ์ความเข้ากันได้จะถูกลบออก
• มีการเพิ่มการทดสอบ VTS เพิ่มเติมเพื่อตรวจสอบข้อกำหนดใหม่ที่มีเงื่อนไขในการสร้าง KMI

เวอร์ชันอิมเมจบูตในข้อมูลเมตาของ OTA

แม้ว่าอิมเมจสำหรับบูตจะได้รับการอัปเดตผ่านการอัปเดต OTA ก็ต้องรวมไฟล์ไว้ในรูปแบบเพย์โหลด OTA payload.bin เพย์โหลด OTA เข้ารหัสฟิลด์ version สำหรับแต่ละพาร์ติชั่น เมื่อ update_engine จัดการเพย์โหลด OTA จะเปรียบเทียบฟิลด์นี้เพื่อให้แน่ใจว่าพาร์ติชั่นจะไม่ถูกดาวน์เกรด

เพื่อหลีกเลี่ยงความสับสน ฟิลด์ version สำหรับพาร์ติชันสำหรับเริ่มระบบในข้อมูลเมตา OTA จะเรียกว่า boot image version

เนื่องจาก ramdisk สร้างขึ้นตั้งแต่เริ่มต้นเสมอ การใช้การ ประทับเวลา ramdisk ก็เพียงพอที่จะอธิบายอิมเมจสำหรับบูตทั้งหมด ไม่จำเป็นต้องเข้ารหัสการวางจำหน่ายเคอร์เนลในเวอร์ชันอิมเมจสำหรับบูต เว้นแต่ว่าคุณกำลังต่ออิมเมจสำหรับบูตเก่ากับไบนารีเคอร์เนลใหม่ในอนาคต

ก่อนการอัปเดต OTA ไคลเอ็นต์ OTA จะตรวจสอบเวอร์ชันอิมเมจสำหรับบูตในลักษณะเดียวกับพาร์ติชันอื่นๆ