รูปแบบการกำหนดเวอร์ชัน GKI

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

สรุปข้อกำหนด

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

ตารางต่อไปนี้แสดงคำอื่นๆ ที่เกี่ยวข้องเพื่อใช้อ้างอิง

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

การเปิดตัวเคอร์เนล

คำจำกัดความ

สำหรับอุปกรณ์ที่จัดส่งพร้อม GKI การเผยแพร่เคอร์เนลมีคำจำกัดความดังนี้

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

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

ตัวอย่างการเผยแพร่เคอร์เนลมีดังนี้

5.4.42-android12-0-00544-ged21d463f856

คำอธิบาย

รุ่นเคอร์เนลคือรหัสที่ไม่ซ้ำกันของรุ่น GKI หากไบนารี GKI 2 รายการมี เคอร์เนลรีลีสเดียวกัน ไบนารีทั้ง 2 รายการต้องเหมือนกันแบบไบต์ต่อไบต์

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

เวอร์ชัน KMI

คำจำกัดความ

เวอร์ชัน KMI มีการกำหนดดังนี้

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

โปรดทราบว่าระดับย่อย y ไม่ใช่ส่วนหนึ่งของเวอร์ชัน KMI สำหรับตัวอย่าง ในการเผยแพร่เคอร์เนล เวอร์ชัน KMI คือ

5.4-android12-0

คำอธิบาย

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

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

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

ระดับย่อย

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

สำหรับเคอร์เนล 2 รุ่นที่มี 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 จะ แยกวิเคราะห์ด้วยนิพจน์ทั่วไปต่อไปนี้ (สมมติว่า zzz ขึ้นต้นด้วย "android" เสมอ)

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

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

libkver

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

การตรวจสอบ VINTF

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

ตั้งแต่ Android S เป็นต้นไป คุณสามารถแยกส่วนการเผยแพร่ Android ของเวอร์ชัน KMI จากเคอร์เนลและแทรกลงในไฟล์ Manifest ของอุปกรณ์ในเวลาที่สร้างได้

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

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

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

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

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

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

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