תהליך הפצה גנרי של תמונת ליבה (GKI)

בדף הזה מוסבר איך מתבצעת ההפצה של GKI, כולל הפצות שבועיות, רבעוניות והפצות חירום מחוץ לטווח. מטרת המסמך הזה היא לספק ליצרני ציוד מקורי (OEM) הנחיות לגבי המקום שבו אפשר להוריד את GKI, וגם לגבי התהליך של תיקוני חירום מחוץ לפס. יצרני ציוד מקורי יכולים גם להשתמש בפיתוח GKI כדי לקבל מידע נוסף על האופן שבו הם יכולים לעבוד עם צוות ליבת Android כדי לבצע אופטימיזציה של ליבת GKI למוצרים שלהם.

קצב ההפצה של GKI

ה-GKI מופץ בקצב רבעוני אחרי הקפאת ה-KMI.

תוקף של גרסאות build של GKI ליצרני ציוד מקורי (OEM)

יצרני ציוד מקורי יכולים להשתמש ב-GKI של Android שפורסם לאחרונה. יצרני ציוד מקורי יכולים להשיק מכשירים עם גרסאות build שאושרו על ידי GKI, כל עוד הם עומדים בדרישות LTS שמופיעות בעדכון האבטחה ל-Android‏ (ASB).

גרסאות פיתוח שבועיות

קבצים בינאריים של GKI זמינים בשירות עצמי מ-Android CI כשהשינויים מתמזגים. גרסאות ה-build השבועיות לא יקבלו אישור, אבל אפשר להשתמש בהן כנקודת בסיס לפיתוח ולבדיקה. אי אפשר להשתמש בגרסאות שבועיות לבניית מכשירים לייצור עבור משתמשי קצה.

מהדורות מאושרות רבעוניות

מהדורות GKI רבעוניות מכילות boot.img שנבדק וכולל אישור שנוסף על ידי Google כדי לאשר שהקובצים הבינאריים נוצרו מבסיס קוד מקור ידוע.

בכל רבעון נבחרת גרסת קנדידט (לא מאושרת) של GKI, אחרי תאריך הסיום של הצ'ק-אין, שהוא בדרך כלל הבנייה השנייה של השבוע באותו חודש. אחרי שבוחרים את גרסת המועמדים להפצה הרבעונית, לא יתקבלו שינויים חדשים בגרסה של אותו חודש. במהלך התקופה שבה החלון סגור, אפשר לטפל רק בתיקונים של באגים שגורמים לכשל בבדיקה. מועמד לגרסה עובר בדיקות אבטחת איכות – כפי שמתואר בקטע על ההסמכה של GKI – כדי לוודא שמבחני התאימות עוברים ב-GSI+GKI build עם מכשיר ייחוס וגם עם Cuttlefish.

איור 1. ציר הזמן של ההשקות של GKI

תהליך חידוש במקרה חירום

ייצור מחדש (respin) הוא תהליך של מיזוג מחדש, בנייה מחדש, בדיקה מחדש והסמכה מחדש של קובץ בינארי אחרי שחרור פומבי של ליבת GKI. אפשר לבקש שינוי של קובץ בינארי מאומת בכל אחת מהנסיבות הבאות:

• כדי לעדכן רשימת סמלים.
• כדי להחיל תיקון על באג, כולל באגים שנמצאו במהלך אישור המעבדה של הספק.
• כדי להוסיף vendor hook.
• כדי להחיל תיקון על תכונה קיימת.
• כדי להחיל תיקון אבטחה (אחרי 6 חודשים).

תיקוני אבטחה משולבים אוטומטית בענף של גרסה עד 6 חודשים אחרי שהגרסה פורסמה. אחרי 6 חודשים, תצטרכו לבקש גרסת build מחדש כדי להחיל תיקוני אבטחה על הסתעפות.

הנחיות לבקשות ליצירת וריאציות

לפני שמבקשים ספין חוזר, חשוב לשים לב להנחיות הבאות:

• מותר לבצע Respin רק בענפי הפצה אחרי שהפצה ציבורית ראשונית של גרסת build רבעונית הושקה.

• בקשות ליצירת גרסאות (respin) מתקבלות רק עבור הסתעפות של גרסה מסוימת, למשך שישה חודשים לכל היותר אחרי הפרסום הראשוני לציבור. אחרי שישה חודשים, אפשר ליצור גרסה חדשה להסתעפויות רק לתיקוני אבטחה שמופיעים בעדכון האבטחה ל-Android.

• אם ההסתעפות לא עומדת בדרישות LTS, שמוגדרות בעדכון האבטחה של Android‏ (ASB), היא תוסר משימוש. לא נקבל בקשות ליצירת גרסאות (respin) להסתעפויות שהוצאו משימוש. תאריך ההוצאה משימוש של ענף גרסה מסוים של GKI מופיע בהערות לגבי גרסאות ה-build של GKI שמתפרסמות מדי רבעון, בקטע Releases. לצורך תכנון עתידי, הדרישות של LTS מתעדכנות במאי ובנובמבר מדי שנה. לדוגמה, אי אפשר להשתמש בענף android12-5.10-2023-07 (5.10.177) אחרי 1 במאי 2024, כי הוא לא עומד בדרישות של LTS של ASB-2024-05.android12-5.10-2023-07

• האפשרות הזו רלוונטית רק לתיקוני באגים דחופים, לעדכונים של רשימת הסמלים או להחלת תיקון באג כדי לתקן תכונה קיימת.

• כל תיקוני האבטחה שייכללו בענף של הגרסה הרבעונית כבר צריכים להיות ממוזגים בענף הפיתוח הראשי של GKI. לדוגמה, אם נדרש תיקון בשביל respin של 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, צריך ליצור שתי בקשות לספין מחדש.

• אחרי שגרסת build מסופקת ובקשת respin מסומנת כפתורה, לא מומלץ לפתוח מחדש את בקשת ה-respin כדי להוסיף רשימות CL נוספות. אם יש תיקונים נוספים שצריך למזג, צריך לשלוח בקשה חדשה לשינוי הגרסה.

• לכל רשימת שינויים שרוצים לבדוק, מוסיפים את התגים הבאים.

  • ‫Bug: צריך להוסיף את מזהה הבאג להודעת הקומיט של כל CL.
  • ‫Change-Id: חייב להיות זהה ל-Change-Id של השינוי בענף הבסיס.

• אם בקשה לשינוי ספין דורשת תגובה מכם, ולא תגיבו תוך שלושה ימי עסקים, העדיפות תרד ברמה אחת (לדוגמה, P0 תרד ל-P1). אם לא תתקבל ממך תגובה במשך שבועיים, הבאג יסומן כבעיה שאי אפשר לתקן (לא רלוונטית).

שליחת בקשה ליצירת גרסה חדשה

בתרשים הבא מוצג תהליך ההפעלה מחדש. התהליך מתחיל כששותף ה-OEM (אתם) שולח את הבקשה לשליחת גרסת הסתעפות.

איור 2. תהליך השינוי

כדי להתחיל בתהליך הייצור מחדש (respin):

1. ממלאים את הטופס לבקשת GKI Respin ופונים מיד למנהל הטכני של חשבון Google. הטופס הזה יוצר באג של בקשת GKI respin. באגים בבקשות ליצירת גרסה חדשה גלויים לכם (למי ששולח את הבקשה), לצוות GKI ולאנשים ספציפיים שאתם מוסיפים לרשימת העותקים של הבאג.
   • אם כבר יש לכם תיקון, הבקשה צריכה להפנות לשליחת התיקון ב-AOSP כדי ש-Google תוכל לבדוק אותו. אם אי אפשר לשלוח את התיקון, צריך לצרף אותו לבקשה כקובץ טקסט.
   • אם אין לכם תיקון, הבקשה צריכה לכלול כמה שיותר מידע, כולל מספר גרסת הליבה ויומנים, כדי ש-Google תוכל לעזור לכם לנפות את הבעיה.
2. צוות Google GKI בודק את הבקשה ומאשר אותה או מקצה אותה בחזרה אליך אם נדרש מידע נוסף.
3. אחרי שמסכימים על תיקון, צוות Google GKI מבצע בדיקת קוד (CR+2) של השינוי. תהליך הבדיקה מתחיל במסגרת הזמן של ESRT. הצוות של GKI ממזג, בונה, בודק רגרסיה ומאשר את השינוי.
4. הקובץ הבינארי מתפרסם בכתובת ci.android.com. מסגרת הזמן של ESRT מסתיימת וצוות Google GKI מסמן את הבקשה כבקשה שטופלה ומפנה אל גרסת ה-respin. גרסת ה-build של ה-respin תפורסם גם בדף גרסאות ה-build של Generic Kernel Image (GKI).

דרישות הסף לשימוש ב-GKI

איפה אפשר להשיג פריטי מידע מה-build

אפשר להוריד ארטיפקטים של כל הגרסאות מכתובת ci.android.com.

מידע נוסף על ה-CI, כולל תוצאות הבדיקה, זמין בלוח הבקרה Android Continuous Integration.

שאלות נפוצות

ריכזנו כאן כמה שאלות נפוצות שקשורות לתהליך ההפצה של 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 במהלך חלון הגרסה החדשה, אבל לא יותר מזה.
• הבעיות שמוזכרות בתבליט השני כלולות גם במהדורות הבאות של GKI שיוצאות מדי רבעון.

הגרסה המחודשת של אוקטובר כוללת את כל התיקונים שנשלחו על ידי יצרני הציוד המקורי, אבל תיקונים אחרים של יצרני ציוד מקורי משפיעים עלינו כי הם לא נבדקו באופן ספציפי עם המוצרים שלנו. האם אפשר לכלול רק את התיקון שלנו?

אי אפשר לעשות את זה. אי אפשר להרחיב את השימוש בנתיב respin 'לכל יצרן ציוד מקורי'. במקום זאת, צוות GKI בודק בקפידה כל שינוי שמוכנס לבניית respin, ובודק את השינויים בכל החומרה הזמינה לפני יצירת בנייה חדשה. אם צוות GKI יגלה שהבעיה ספציפית ליצרן ציוד מקורי, למכשיר או לדגם, הצוות יוכל לוודא שהקוד שנוסף על ידי השינוי יופעל רק במכשיר, בדגם או ב-SKU שמושפעים.

היתרון העיקרי של עדכונים מאוחדים הוא שכל מכשיר שמשתמש באותו בסיס של גרסה נהנה מהעדכונים של מכשירים אחרים, במיוחד אם הבאגים שמתגלים הם כלליים ורלוונטיים לכל המשתמשים. דוגמה ספציפית למושג הזה היא באגים בליבת הקרנל שנמצאו בבדיקות של ספקי סלולר.

האם יש מצבים שבהם Google מספקת מידע ספציפי על תיקוני OEM ועל תרחישי בעיות, כדי שיצרני OEM יוכלו להעריך את ההשפעה והסיכון של הטמעת התיקונים במוצרים שלהם?

‫Google לא תוסיף שינוי לגרסת respin עד שתבין את הבעיה ותאסוף את כל הפרטים. המידע הזה מופיע ביומן השינויים (הודעת השמירה). ‫Google לא חושפת את המכשיר הספציפי שהבעיה משפיעה עליו, אבל יצרני ציוד מקורי (OEM) תמיד יכולים למצוא את תיאור הבעיה והפתרון ביומן השינויים.