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

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

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

GKI จะเผยแพร่เป็นรายเดือนหลังจากการหยุดให้บริการ KMI

การเปิดตัว Android 13, 14 และ 15 GKI

ตารางต่อไปนี้ใช้กับandroid13-5.10, android13-5.15 และ android14-5.15 เท่านั้น

ตารางต่อไปนี้เกี่ยวข้องกับ android14-6.1 และ android15-6.6 เท่านั้น

รุ่น GKI ของ Android 12

หลังจากเดือนพฤษภาคม 2024 android12-5.10 GKI จะเผยแพร่เป็นรายไตรมาสและเผยแพร่ในช่วงกลางเดือน ตารางต่อไปนี้ใช้กับ android12-5.10 เท่านั้น

ความถูกต้องของรุ่น GKI สำหรับ OEM

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

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

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

รุ่นที่ได้รับการรับรองรายเดือน

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

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

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

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

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

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

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

หลักเกณฑ์การส่งคำขออีกครั้ง

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

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

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

• เมื่อข้อกําหนดของ LTS ที่กําหนดโดยกระดานข่าวสารด้านความปลอดภัยของ Android (ASB) ทําให้สาขาไม่เป็นไปตามข้อกําหนด ระบบจะเลิกใช้งานสาขานั้น ระบบไม่ยอมรับคำขอ Respin สำหรับสาขาที่เลิกใช้งานแล้ว วันที่เลิกใช้งานสำหรับสาขารุ่น 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 หลัก แล้วอัปโหลดแพตช์ไปยัง Branch ของรุ่นรายเดือน

• ในคำขอส่งงานอีกครั้ง คุณต้องกำหนดลำดับความสำคัญ (ความเร่งด่วน) ให้กับคำขอ ลำดับความสำคัญนี้ช่วยให้ทีม 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

จะหาอาร์ติแฟกต์ของบิลด์ได้จากที่ใด

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

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

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

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

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

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

สามารถทำให้เกิดไบนารี 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 จะตรวจสอบทุกการเปลี่ยนแปลงที่เกิดขึ้นในงานใหม่ และทดสอบการเปลี่ยนแปลงกับฮาร์ดแวร์ที่มีอยู่ทั้งหมดก่อนสร้างบิลด์ใหม่ หากทีม GKI พบว่าปัญหาเกิดขึ้นเฉพาะกับ OEM, อุปกรณ์ หรือรุ่น ทีม GKI จะตรวจสอบได้ว่าโค้ดที่เพิ่มจากการเปลี่ยนแปลงจะทำงานเฉพาะในอุปกรณ์ รุ่น หรือ SKU ที่ได้รับผลกระทบเท่านั้น

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

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

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