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

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

קצב ההפצה של GKI

GKI משוחרר בתדירות רבעונית לאחר הקפאת KMI.

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

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

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

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

גרסאות מוסמכות רבעוניות

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

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

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

תהליך שליחת בקשה חוזרת (respin) במקרה חירום

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

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

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

הנחיות לשליחת בקשה להעלאת גרסת build מחדש

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

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

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

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

• צריך לשלוח בקשה נפרדת ל-respin לכל סניף של גרסה. לדוגמה, אם צריך לבצע שליחה חוזרת גם של android12-5.10-2022-08 וגם של android12-5.10-2022-09, צריך ליצור שתי בקשות שליחה חוזרת.

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

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

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

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

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

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

איור 2. תהליך ה-respin

כדי להתחיל בתהליך ה-respin:

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

הסמכות GKI

איפה אפשר לקבל את ארטיפקטי ה-build

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

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

שאלות נפוצות

ריכזנו כאן כמה שאלות נפוצות שקשורות לתהליך השחרור של GKI.

האם אפשר ליצור קובץ GKI בינארי חדש על סמך GKI שכבר שוחרר?

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

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

• יצרני הציוד המקורי (OEM1 ו-OEM2) מחליטים להשתמש במהדורה הבינארית של GKI מנובמבר 2021.
• OEM1 ו-OEM2 מוצאים בעיות שדורשות תיקונים כדי לקבל תמיכה. התיקונים האלה יכולים להיות שונים או זהים.
• ב-respins מעל הקובץ הבינארי של נובמבר 2021 יש תיקונים לחסימת השקת שדווחו על ידי OEM1 ו-OEM2 במהלך חלון ה-respin, אבל לא יותר מזה.
• הבעיות שצוינו בפסקה השנייה נכללות גם במהדורות הרבעוניות הבאות של GKI.

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

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

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

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

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