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

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

קצב השקת הגרסאות של GKI

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

גרסה של GKI ל-Android 13,‏ 14 ו-15

הטבלה הבאה רלוונטית רק ל-android13-5.10, ל-android13-5.15 ול-android14-5.15.

גרסאות build מוסמכות חודשיות של GKI תאריך הסגירה של צ'ק-אין תאריך השלמת ההטענה מראש של GKI מוכן?
נובמבר 11 בנובמבר 2024 27 בנובמבר 2024 כן
ינואר 14 בינואר 2025 31 בינואר 2025 כן
מרץ 14 במרץ 2025 31 במרץ 2025 כן

הטבלה הבאה רלוונטית רק ל-android14-6.1 ול-android15-6.6.

גרסאות build מוסמכות חודשיות של GKI תאריך הסגירה של צ'ק-אין תאריך השלמת ההטענה מראש של GKI מוכן?
אוקטובר 1 באוקטובר 2024 14 באוקטובר 2024 כן
נובמבר 1 בנובמבר 2024 15 בנובמבר 2024 כן
דצמבר 2 בדצמבר 2024 16 בדצמבר 2024 כן
ינואר 6 בינואר 2025 22 בינואר 2025 כן

גרסה של GKI ל-Android 12

אחרי מאי 2024, הגרסאות של android12-5.10 GKI יפורסמו ברבעון ויפורסמו באמצע החודש. הטבלה הבאה רלוונטית רק ל-android12-5.10.

גרסאות build מוסמכות חודשיות של GKI תאריך הסגירה של צ'ק-אין תאריך השלמת ההטענה מראש של GKI מוכן?
נובמבר 1 בנובמבר 2024 15 בנובמבר 2024 כן
פברואר 3 בפברואר 2025 17 בפברואר 2025 כן

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

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

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

הגרסאות מתבצעות באמצעות Cuttlefish כדי לוודא שהן עומדות ברף האיכות המינימלי.

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

גרסאות מוסמכות חודשיות

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

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

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

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

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

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

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

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

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

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

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

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

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

בתרשים הבא מוצג תהליך ה-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. גרסה מחודשת של ה-build תפורסם גם בדף של גרסאות build של Generic Kernel Image‏ (GKI).

הסמכות GKI

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

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

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

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

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

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

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