กระบวนการเผยแพร่อิมเมจ Kernel ทั่วไป (GKI)

หน้านี้จะอธิบายวิธีเผยแพร่ GKI ซึ่งรวมถึงการเผยแพร่รายสัปดาห์ รายไตรมาส และการเผยแพร่ฉุกเฉินนอกช่วงเวลา เป้าหมายของเอกสารนี้คือเพื่อให้ OEM มีหลักเกณฑ์ในการรับ GKI รวมถึงกระบวนการแก้ไขฉุกเฉินนอกช่องทาง OEM ยังใช้การพัฒนา GKI เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีทำงานร่วมกับทีมเคอร์เนล Android เพื่อเพิ่มประสิทธิภาพเคอร์เนล GKI สำหรับผลิตภัณฑ์ของตนได้ด้วย

ความถี่ในการเผยแพร่ GKI

GKI จะเผยแพร่ทุกไตรมาสหลังจากการหยุดให้บริการ KMI

เดือนที่เผยแพร่ a12-5.10 a13-5.10 a13-5.15 a14-5.15 a14-6.1 a15-6.6 a16-6.12
มิถุนายน
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
16 มิ.ย.
30 มิ.ย.
2 มิ.ย.
16 มิ.ย.
2 มิ.ย.
16 มิ.ย.
2 มิ.ย.
18 มิ.ย.
กรกฎาคม
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
16 ก.ค.
31 ก.ค.
16 ก.ค.
31 ก.ค.
16 ก.ค.
31 ก.ค.
1 ก.ค.
15 ก.ค.
1 ก.ค.
15 ก.ค.
1 ก.ค.
15 ก.ค.
สิงหาคม
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
1 ส.ค.
15 ส.ค.
1 ส.ค.
15 ส.ค.
1 ส.ค.
15 ส.ค.
กันยายน
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
16 ก.ย.*
30 ก.ย.*
16 ก.ย.
30 ก.ย.
1 ก.ย.
15 ก.ย.
1 ก.ย.
15 ก.ย.
1 ก.ย.
15 ก.ย.
ตุลาคม
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
16-31 ต.ค.
1 ต.ค.
15 ต.ค.
1 ต.ค.
15 ต.ค.
พฤศจิกายน
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
ธันวาคม
2025
เช็คอินปิด
GKI พร้อมโหลดล่วงหน้า
1 ธ.ค.
15 ธ.ค.
1 ธ.ค.*
15 ธ.ค.*
1 ธ.ค.
15 ธ.ค.
1 ธ.ค.
15 ธ.ค.

ความถูกต้องของบิลด์ GKI สำหรับ OEM

OEM สามารถใช้ GKI ของ Android ที่เพิ่งเปิดตัว OEM สามารถเปิดตัวด้วยบิลด์ที่ได้รับการรับรอง GKI ตราบใดที่เป็นไปตามข้อกำหนด LTS ในกระดานข่าวสารความปลอดภัยของ Android (ASB)

เวอร์ชันสำหรับนักพัฒนาซอฟต์แวร์รายสัปดาห์

ระบบจะทดสอบรุ่นต่างๆ ด้วย Cuttlefish เพื่อตรวจสอบว่ารุ่นดังกล่าวผ่านเกณฑ์คุณภาพขั้นต่ำ

คุณสามารถดาวน์โหลดไฟล์ Binaries ของ GKI ได้ด้วยตนเองจาก Android Dev ทีม CI เมื่อมีการผสานการเปลี่ยนแปลง บิลด์รายสัปดาห์จะไม่ได้รับใบรับรอง แต่สามารถใช้เป็นบรรทัดฐานสำหรับการพัฒนาและการทดสอบได้ บิลด์รายสัปดาห์ใช้กับบิลด์อุปกรณ์เวอร์ชันที่ใช้งานจริงสำหรับผู้ใช้ปลายทางไม่ได้

รุ่นที่ผ่านการรับรองรายไตรมาส

릴리스รายไตรมาสของ GKI มี boot.img ที่ผ่านการทดสอบซึ่งมีใบรับรองที่ Google แทรกไว้เพื่อยืนยันว่าไบนารีสร้างขึ้นจากพื้นฐานโค้ดแหล่งที่มาที่รู้จัก

ทุกไตรมาสจะมีการเลือกรุ่น GKI ที่จะเผยแพร่เป็นเวอร์ชันทดลอง (ไม่ผ่านการรับรอง) หลังจากที่ถึงวันที่ปิดรับการเช็คอิน ซึ่งโดยปกติจะเป็นบิลด์รายสัปดาห์ที่ 2 ของเดือนนั้น หลังจากเลือกรุ่นที่พร้อมใช้งานเป็นรุ่นย่อยรายไตรมาสแล้ว ระบบจะไม่ยอมรับการเปลี่ยนแปลงใหม่ในรุ่นของเดือนนั้น ในระหว่างระยะเวลาที่ปิดอยู่ คุณจะแก้ไขได้เฉพาะข้อบกพร่องที่ทําให้การทดสอบล้มเหลว เวอร์ชันที่พร้อมเผยแพร่จะผ่านการตรวจสอบคุณภาพตามที่อธิบายไว้ในส่วนการรับรอง GKI เพื่อให้แน่ใจว่าการทดสอบการปฏิบัติตามข้อกำหนดจะผ่านในบิลด์ GSI+GKI ด้วยอุปกรณ์อ้างอิง รวมถึง Cuttlefish

ลำดับเวลาการเผยแพร่ GKI รูปที่ 1 ลำดับเวลาการเผยแพร่ GKI

กระบวนการส่งแอปอีกครั้งในกรณีฉุกเฉิน

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

  • วิธีอัปเดตรายการสัญลักษณ์
  • วิธีใช้การแก้ไขข้อบกพร่อง รวมถึงข้อบกพร่องที่พบระหว่างการอนุมัติจากห้องทดลองของผู้ให้บริการ
  • วิธีเพิ่มฮุกของผู้ให้บริการ
  • วิธีใช้แพตช์กับฟีเจอร์ที่มีอยู่
  • วิธีใช้แพตช์ความปลอดภัย (หลังจากผ่านไป 6 เดือน)

ระบบจะผสานแพตช์ความปลอดภัยลงในสาขารุ่นโดยอัตโนมัติสูงสุด 6 เดือนหลังจากการเผยแพร่สาขา หลังจากพ้นระยะเวลา 6 เดือนแล้ว คุณต้องขอส่งอีกครั้งเพื่อใช้แพตช์ความปลอดภัยกับสาขา

หลักเกณฑ์เกี่ยวกับคำขอหมุนใหม่

โปรดอ่านหลักเกณฑ์ต่อไปนี้ก่อนขอรับการตรวจสอบอีกครั้ง

  • การรีสปินใช้ได้เฉพาะในสาขารุ่นหลังจากเปิดตัวรุ่นแรกแบบสาธารณะของบิลด์รายไตรมาสแล้วเท่านั้น

  • เราจะยอมรับคำขอรีสปินสำหรับสาขารุ่นหนึ่งๆ เท่านั้น โดยไม่เกิน 6 เดือนหลังจากการเผยแพร่ครั้งแรกแบบสาธารณะ หลังจากผ่านไป 6 เดือน เวอร์ชันย่อยจะมีสิทธิ์ส่งอีกครั้งสำหรับแพตช์ความปลอดภัยที่ระบุไว้ในกระดานข่าวสารความปลอดภัยของ Android เท่านั้น

  • เมื่อข้อกําหนดของ LTS ที่กําหนดโดยกระดานข่าวสารด้านความปลอดภัยของ Android (ASB) ทําให้สาขาไม่เป็นไปตามข้อกําหนด ระบบจะเลิกใช้งานสาขานั้น ระบบไม่ยอมรับคำขอ Respin สำหรับสาขาที่เลิกใช้งานแล้ว วันที่เลิกใช้งานสำหรับ Branch ของรุ่น GKI หนึ่งๆ จะรวมอยู่ในบันทึกประจำรุ่นของ GKI รายไตรมาสในส่วนรุ่น เราจะอัปเดตข้อกำหนด LTS เป็นรายปีในเดือนพฤษภาคมและพฤศจิกายนเพื่อวางแผนในอนาคต ตัวอย่างเช่น ระบบจะไม่รองรับการส่งใหม่ของสาขา android12-5.10-2023-07 (5.10.177) หลังจากวันที่ 1 พฤษภาคม 2024 เนื่องจากสาขา android12-5.10-2023-07 (5.10.177) ไม่เป็นไปตามข้อกําหนด LTS ของ ASB-2024-05

  • การรีสปินใช้ได้กับการแก้ไขข้อบกพร่องเร่งด่วน การอัปเดตรายการสัญลักษณ์ หรือการใช้แพตช์เพื่อแก้ไขฟีเจอร์ที่มีอยู่เท่านั้น

  • แพตช์ทั้งหมดที่จะรวมอยู่ในสาขารุ่นรายไตรมาสต้องผสานรวมอยู่ในสาขาการพัฒนา GKI หลักแล้ว ตัวอย่างเช่น หากต้องใช้แพตช์สำหรับการรีสปิน android12-5.10-2022-09 แพตช์ดังกล่าวต้องผสานรวมกับ android12-5.10 แล้ว

  • คุณต้องเลือกแพตช์จากสาขาการพัฒนา GKI หลักและอัปโหลดแพตช์ไปยังสาขาการเผยแพร่รายไตรมาส

  • ในคำขอส่งงานอีกครั้ง คุณต้องกำหนดลำดับความสำคัญ (ความเร่งด่วน) ให้กับคำขอ ลำดับความสำคัญนี้จะช่วยให้ทีม GKI ช่วยเหลือพาร์ทเนอร์ได้ดีขึ้นและทันท่วงที สำหรับคำขอที่สำคัญหรือมีเวลาจำกัด ให้ทำเครื่องหมายลำดับความสำคัญเป็น P0 สำหรับคำขอ P0 และ P1 คุณต้องระบุเหตุผลของความเร่งด่วนด้วย ตารางต่อไปนี้แสดงการเชื่อมโยงระหว่างลำดับความสำคัญของข้อบกพร่องและเวลาในการแก้ไข (ESRT)

    ลำดับความสำคัญ ESRT
    P0 2 วันทำการ
    P1 5 วันทำการ
    P2 10 วันทำการ
    P3 15 วันทำการ
  • คุณต้องส่งคำขอส่งอีกครั้งแยกกันสำหรับแต่ละสาขารุ่น เช่น หากต้องส่งคำขอเข้าร่วมการทดสอบอีกครั้งทั้งสำหรับ android12-5.10-2022-08 และ android12-5.10-2022-09 คุณต้องสร้างคำขอเข้าร่วมการทดสอบอีกครั้ง 2 รายการ

  • หลังจากส่งบิลด์และทําเครื่องหมายคําขอส่งใหม่ว่า "แก้ไขแล้ว" แล้ว คุณไม่ควรเปิดคําขอส่งใหม่อีกครั้งเพื่อเพิ่ม CL เพิ่มเติม คุณต้องส่งคำขอรีสปินใหม่หากมีแพตช์เพิ่มเติมที่ต้องผสาน

  • เพิ่มแท็กต่อไปนี้สำหรับ CL แต่ละรายการที่อยู่ระหว่างการพิจารณา

    • Bug: ต้องเพิ่มรหัสข้อบกพร่องลงในข้อความคอมมิตสำหรับ CL แต่ละรายการ
    • Change-Id: ต้องเหมือนกับ Change-Id ของการเปลี่ยนแปลงในสาขาฐาน
  • หากคำขอส่งคำตอบอีกครั้งกำหนดให้คุณต้องตอบกลับ แต่คุณไม่ตอบกลับภายใน 3 วันทำการ ระบบจะลดระดับความสำคัญลง 1 ระดับ (เช่น P0 จะลดระดับเป็น P1) หากคุณไม่ตอบกลับเป็นเวลา 2 สัปดาห์ ระบบจะทําเครื่องหมายข้อบกพร่องว่าจะไม่แก้ไข (ล้าสมัย)

ส่งคำขอให้ประเมินใหม่

แผนภาพต่อไปนี้แสดงขั้นตอนการส่งอีกครั้ง กระบวนการจะเริ่มขึ้นเมื่อพาร์ทเนอร์ OEM (คุณ) ส่งคำขอส่งอีกครั้ง

กระบวนการส่งแอปอีกครั้งในกรณีฉุกเฉิน รูปที่ 2 กระบวนการส่งอีกครั้ง

วิธีเข้าสู่กระบวนการส่งอีกครั้ง

  1. กรอกแบบฟอร์มคำขอ Respin ของ GKI และติดต่อผู้จัดการลูกค้าด้านเทคนิคของ Google ทันที แบบฟอร์มนี้สร้างข้อบกพร่องของคำขอ GKI respin คุณจะ (ผู้ขอ) ทีม GKI และบุคคลที่คุณเพิ่มในรายชื่อสำเนาอีเมลของข้อบกพร่องเห็นข้อบกพร่องคำขอ Respin
    • หากคุณมีวิธีแก้ไขแล้ว คำขอควรชี้ไปยังการส่งแพตช์ใน AOSP เพื่อให้ Google ตรวจสอบได้ หากส่งแพตช์ไม่ได้ คุณต้องแนบแพตช์เป็นไฟล์ข้อความมากับคำขอ
    • หากไม่มีวิธีแก้ไข คำขอต้องมีข้อมูลมากที่สุดเท่าที่จะเป็นไปได้ ซึ่งรวมถึงหมายเลขเวอร์ชันเคอร์เนลและบันทึก เพื่อให้ Google ช่วยแก้ไขข้อบกพร่องได้
  2. ทีม GKI ของ Google จะตรวจสอบคำขอและอนุมัติ หรือส่งคำขอกลับให้คุณหากต้องการข้อมูลเพิ่มเติม
  3. หลังจากตกลงกันว่าจะแก้ไขแล้ว ทีม GKI ของ Google จะตรวจสอบโค้ด (CR+2) การเปลี่ยนแปลง การตรวจสอบจะเริ่มกรอบเวลา ESRT ทีม GKI จะผสาน บิลด์ ทดสอบการเกิดปัญหาซ้ำ และรับรองการเปลี่ยนแปลง
  4. เผยแพร่ไบนารีไปยัง ci.android.com กรอบเวลา ESRT สิ้นสุดลง และทีม GKI ของ Google ทำเครื่องหมายคำขอว่า "แก้ไขแล้ว" และอ้างอิงบิลด์ Respin ระบบจะโพสต์บิลด์ respin บนหน้าบิลด์รุ่นของ Generic Kernel Image (GKI) ด้วย

คุณสมบัติของ GKI

ประเภทของการสร้าง GKI การบังคับใช้คุณภาพ Notes
รายสัปดาห์ การทดสอบ Cuttlefish
  • บูต
  • ข้อมูล VTS บางส่วน
  • เซ็ตย่อยของ CTS
  • ไม่ได้รับการรับรอง สำหรับการทดสอบและการเปิดใช้งานอุปกรณ์
    เท่านั้น
  • ใช้เพื่อเปิดอุปกรณ์ไม่ได้
รายไตรมาส (ได้รับการรับรอง) การทดสอบ Cuttlefish
  • บูต
  • VTS
  • CTS
การทดสอบฮาร์ดแวร์อ้างอิง
  • บูต
  • VTS
  • CTS
การหมุนซ้ำ (ได้รับการรับรอง) การทดสอบ Cuttlefish
  • บูต
  • VTS
  • เซ็ตย่อยของ CTS
การทดสอบอุปกรณ์อ้างอิง
  • บูต
  • VTS
  • สร้างขึ้นจากบิลด์ที่ผ่านการรับรอง GKI
  • บิลด์จะได้รับการรับรองหลังจากผ่านเกณฑ์

แหล่งที่รับอาร์ติแฟกต์การสร้าง

คุณดูอาร์ติแฟกต์ของรุ่นทั้งหมดได้จาก ci.android.com

ดูข้อมูลเพิ่มเติมเกี่ยวกับ CI รวมถึงผลการทดสอบได้ในแดชบอร์ดการผสานรวมอย่างต่อเนื่องของ Android

คำถามที่พบบ่อย

ต่อไปนี้คือคําถามที่พบบ่อยเกี่ยวกับกระบวนการเผยแพร่ GKI

ฉันจะสร้างไบนารี GKI ใหม่โดยอิงตาม GKI ที่เผยแพร่แล้วได้ไหม

ใช่ เรียกว่า "การเริ่มใหม่" ระบบรองรับกระบวนการส่งอีกครั้ง ตราบใดที่บิลด์ GKI ที่เผยแพร่ (ซึ่งมีการขอส่งอีกครั้ง) เป็นไปตามข้อกำหนด LTS ในกระดานข่าวสารความปลอดภัยของ Android (ASB)

สามารถสร้างไฟล์ Binaries ของ GKI ซ้ำได้ไหม

ได้ ตัวอย่างมีดังนี้

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

หากต้องการสร้างตัวอย่างอีกครั้ง ให้ดาวน์โหลด manifest_$id.xml แล้วเรียกใช้คำสั่งต่อไปนี้

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

คุณเรียกข้อมูลโค้ดโค้ด GKI สำเนาได้จาก out/.../dist

ได้มีการสร้างไบนารี GKI (รวมถึงแพตช์การหมุนฉุกเฉิน) ในโค้ดเบสล่าสุดหรือไม่

ไม่ การรีสปินจะมีเฉพาะแพตช์ที่อยู่บนเคอร์เนลที่ได้รับการรับรองรายไตรมาสซึ่งได้รับเลือกเท่านั้น การตอบกลับเหล่านี้มีการแก้ไขข้อบกพร่องทั้งหมดที่บล็อกการเปิดตัวซึ่ง OEM รายงานจนถึงเวลาหนึ่งๆ โดยใช้รุ่นฐานรายไตรมาสที่เกี่ยวข้อง ดูตัวอย่างต่อไปนี้ของสถานการณ์ประเภทนี้

  • OEM1 และ OEM2 ตัดสินใจใช้รุ่นไบนารี GKI ตั้งแต่เดือนพฤศจิกายน 2021
  • OEM1 และ OEM2 พบปัญหาที่ต้องใช้แพตช์เพื่อรับการสนับสนุน โดยแพตช์เหล่านี้อาจแตกต่างกันหรือเหมือนกันก็ได้
  • การรีสปินเหนือไบนารีของเดือนพฤศจิกายน 2021 มีการแก้ไขการบล็อกการเปิดตัวที่ทั้ง OEM1 และ OEM2 รายงานเข้ามาในช่วงที่รีสปิน แต่ไม่มีอย่างอื่น
  • ปัญหาที่กล่าวถึงในหัวข้อที่ 2 จะรวมอยู่ใน GKI ฉบับรายไตรมาสต่อๆ ไปด้วย

การรายงานผลอีกครั้งในเดือนตุลาคมมีแพตช์ทั้งหมดที่ OEM ส่งมา แต่แพตช์อื่นๆ ของ OEM จะส่งผลต่อเรา เนื่องจากยังไม่ได้ทดสอบกับผลิตภัณฑ์ของเราโดยเฉพาะ เป็นไปได้ไหมที่จะรวมเฉพาะแพตช์ของเรา

เป็นไปไม่ได้ เส้นทางการส่งอีกครั้ง "ต่อ OEM" ปรับขนาดไม่ได้ แต่ทีม GKI จะตรวจสอบการเปลี่ยนแปลงทุกรายการที่นำไปใช้ในบิลด์ respin และทดสอบการเปลี่ยนแปลงกับฮาร์ดแวร์ทั้งหมดที่มีอยู่ก่อนที่จะสร้างบิลด์ใหม่ หากทีม GKI พบว่าปัญหาเกิดขึ้นเฉพาะกับ OEM, อุปกรณ์ หรือรุ่น ทีม GKI จะตรวจสอบได้ว่าโค้ดที่เพิ่มจากการเปลี่ยนแปลงจะทำงานในอุปกรณ์ รุ่น หรือ SKU ที่ได้รับผลกระทบเท่านั้น

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

Google มีสถานการณ์ที่ระบุข้อมูลเฉพาะเกี่ยวกับแพตช์ OEM และสถานการณ์ปัญหาเพื่อให้ OEM ประเมินผลกระทบและความเสี่ยงในการใช้แพตช์กับผลิตภัณฑ์ของตนหรือไม่

Google จะไม่เพิ่มการเปลี่ยนแปลงลงในบิลด์ที่ส่งใหม่จนกว่าจะเข้าใจปัญหาและรวบรวมรายละเอียดทั้งหมดแล้ว ซึ่งจะแสดงในบันทึกการเปลี่ยนแปลง (ข้อความคอมมิต) Google จะไม่เปิดเผยว่าอุปกรณ์ใดได้รับผลกระทบ แต่ OEM สามารถดูคำอธิบายและวิธีแก้ปัญหาได้ในบันทึกการเปลี่ยนแปลง