במסמך הזה מתואר אופן ההשקה של GKI, כולל השקות שבועיות, חודשיות ומקרי חירום מחוץ למסגרת. מטרת המסמך הזה היא לספק ליצרני ציוד מקורי הנחיות לאיסוף GKI ואת התהליך לתיקונים מקרי חירום מחוץ למסגרת. יצרני ציוד מקורי יכולים גם להיעזר במדריך לפיתוח של GKI כדי לגלות איך הם יכולים לעבוד עם צוות הליבה של Android כדי לבצע אופטימיזציה של הליבה של GKI למוצרים שלהם.
קצב ההפצה של GKI
GKI משוחרר בקצב חודשי אחרי הקפאת KMI.
גרסת Android 13, 14 ו-15 GKI
הטבלה הבאה רלוונטית רק ל-android13-5.10, ל-android13-5.15 ול-android14-6.1.
| גרסאות build עם אישור חודשי ל-GKI | תאריך אחרון לצ'ק-אין | תאריך מוכן לטעינה מראש של GKI | מאושר? |
|---|---|---|---|
| אוקטובר | 14 באוקטובר 2022 | 31 באוקטובר 2022 | כן |
| נובמבר | 14 בנובמבר 2022 | 30 בנובמבר 2022 | כן |
| דצמבר | 9 בדצמבר 2022 | 21 בדצמבר 2022 | כן |
| ינואר | 17 בינואר 2023 | 31 בינואר 2023 | כן |
| פברואר | 15 בפברואר 2023 | 28 בפברואר 2023 | כן |
| מרץ | 15 במרץ 2023 | 31 במרץ 2023 | כן |
| אפריל | 13 באפריל 2023 | 28 באפריל 2023 | כן |
| מאי | 17 במאי 2023 | 31 במאי 2023 | כן |
| יוני | 15 ביוני 2023 | 30 ביוני 2023 | כן |
| יולי | 18 ביולי 2023 | 31 ביולי 2023 | כן |
| אוגוסט | 16 באוגוסט 2023 | 31 באוגוסט 2023 | כן |
| ספטמבר | 14 בספטמבר 2023 | 29 בספטמבר 2023 | כן |
| אוקטובר | 18 באוקטובר 2023 | 31 באוקטובר 2023 | כן |
| נובמבר | 10 בנובמבר 2023 | 30 בנובמבר 2023 | כן |
| דצמבר | 7 בדצמבר 2023 | 22 בדצמבר 2023 | כן |
| ינואר | 16 בינואר 2024 | 31 בינואר 2024 | כן |
| פברואר | 13 בפברואר 2024 | 29 בפברואר 2024 | כן |
| מרץ | 13 במרץ 2024 | 29 במרץ 2024 | כן |
| אפריל | 16 באפריל 2024 | 30 באפריל 2024 | כן |
| מאי | 14 במאי 2024 | 31 במאי 2024 | כן |
| יוני | 12 ביוני 2024 | 28 ביוני 2024 | כן |
| יולי | 16 ביולי 2024 | 31 ביולי 2024 | כן |
| אוגוסט | 15 באוגוסט 2024 | 30 באוגוסט 2024 | כן |
| ספטמבר | 17 בספטמבר 2024 | 30 בספטמבר 2024 | כן |
| אוקטובר | 15 באוקטובר 2024 | 31 באוקטובר 2024 | כן |
| נובמבר | 11 בנובמבר 2024 | 27 בנובמבר 2024 | כן |
| דצמבר | 6 בדצמבר 2024 | 23 בדצמבר 2024 | כן |
החל מינואר 2024, נחזור למהדורות החודשיות של android14-5.15 בהתאם לקצב החודשי שצוין בטבלה שבהמשך.
קצב ההפצה של android15-6.6 ישתנה החל מיולי 2024.
| גרסאות build עם אישור חודשי ל-GKI | תאריך אחרון לצ'ק-אין | תאריך מוכן לטעינה מראש של GKI | מאושר? |
|---|---|---|---|
| ינואר | 16 בינואר 2024 | 31 בינואר 2024 | כן |
| פברואר | 13 בפברואר 2024 | 29 בפברואר 2024 | כן |
| מרץ | 4 במרץ 2024 | 15 במרץ 2024 | כן |
| אפריל | 1 באפריל 2024 | 17 באפריל 2024 | כן |
| מאי | 1 במאי 2024 | 17 במאי 2024 | כן |
| יוני | 3 ביוני 2024 | 17 ביוני 2024 | כן |
| יולי | 1 ביולי 2024 | 15 ביולי 2024 | כן |
| אוגוסט | 1 באוגוסט 2024 | 16 באוגוסט 2024 | כן |
| ספטמבר | 2 בספטמבר 2024 | 16 בספטמבר 2024 | כן |
| אוקטובר | 1 באוקטובר 2024 | 14 באוקטובר 2024 | כן |
| נובמבר | 1 בנובמבר 2024 | 15 בנובמבר 2024 | כן |
| דצמבר | 2 בדצמבר 2024 | 16 בדצמבר 2024 | כן |
גרסת Android 12 GKI
אחרי מאי 2024, הגרסאות של GKI android12-5.10 מתפרסמות בקצב רבעוני ומתפרסמות באמצע החודש.
הטבלה הבאה רלוונטית רק לגבי android12-5.10.
| גרסאות build עם אישור חודשי ל-GKI | תאריך אחרון לצ'ק-אין | תאריך מוכן לטעינה מראש של GKI | מאושר? |
|---|---|---|---|
| יולי | 3 ביולי 2023 | 14 ביולי 2023 | כן |
| ספטמבר | 1 בספטמבר 2023 | 15 בספטמבר 2023 | כן |
| נובמבר | 3 בנובמבר 2023 | 17 בנובמבר 2023 | כן |
| ינואר | 5 בינואר 2024 | 19 בינואר 2024 | כן |
| מרץ | 4 במרץ 2024 | 15 במרץ 2024 | כן |
| מאי | 1 במאי 2024 | 17 במאי 2024 | כן |
| אוגוסט | 1 באוגוסט 2024 | 16 באוגוסט 2024 | כן |
| נובמבר | 1 בנובמבר 2024 | 15 בנובמבר 2024 | כן |
| פברואר | 3 בפברואר 2025 | 17 בפברואר 2025 | כן |
תוקף של גרסאות build של GKI ליצרני ציוד מקורי
יצרני ציוד מקורי יכולים להשתמש ב-Android GKI שהושק לאחרונה. יצרני ציוד מקורי יכולים להשיק גרסאות build שאושרו על ידי GKI, כל עוד הן עומדות בדרישות ה-LTS שמופיעות ב-Android Security Bulletin (ASB).
גרסאות פיתוח שבועיות
פריטי התוכן נבדקים באמצעות דיונון כדי לוודא שהם עוברים רמת איכות מינימלית.קבצים בינאריים של GKI זמינים לשירות עצמי בכתובת ci.android.com בזמן מיזוג השינויים. גרסאות build שבועיות לא יאושרו, אבל ניתן להשתמש בהן כבסיס לפיתוח ובדיקה. אי אפשר להשתמש בגרסאות build שבועיות של גרסת ה-build של המכשירים בסביבת הייצור.
גרסאות חודשיות שאושרו
הגרסאות החודשיות של GKI מכילות boot.img שנבדק וכולל אישור שהוכנס על ידי Google, כדי להצהיר שהקבצים הבינאריים נוצרו על בסיס קוד מקור ידוע.
בכל חודש, נבחר מועמד לגרסה חודשית של GKI (לא אושר) אחרי תאריך המועד האחרון לביצוע הצ'ק-אין, שהוא בדרך כלל גרסת ה-build השבועית השנייה באותו חודש. אחרי שבוחרים את המועמד לגרסה החודשית, לא יתקבלו שינויים חדשים בגרסה של אותו חודש. במהלך תקופת החלון הסגור אפשר לטפל רק בתיקונים של באגים שגורמים לכשל בבדיקה. המועמד לגרסה החדשה עובר בקרת איכות, כפי שמתואר בסעיף האישור של GKI, כדי לוודא שבדיקות התאימות עוברות את גרסאות GSI+GKI עם מכשיר עזר וגם דיונון.
איור 1. ציר הזמן להשקה של GKI
תהליך סגירה מחדש במקרה חירום
תיקון חוזר מתייחס לתהליך של מיזוג מחדש, בנייה מחדש, בדיקה מחדש ואישור מחדש של קובץ בינארי אחרי פרסום ציבורי של הליבה של GKI. אפשר לבקש החזרה מחדש של קובץ בינארי שאושר בכל אחת מהנסיבות:
- כדי לעדכן רשימת סמלים.
- כדי להחיל תיקון על באג, כולל באגים שנמצאו במהלך אישור שיעור ה-Lab על ידי הספק.
- כדי להוסיף הוק (hook) ספק.
- כדי להחיל תיקון על תכונה קיימת.
- להחיל תיקון אבטחה (אחרי 6 חודשים).
תיקוני האבטחה ממוזגים באופן אוטומטי להסתעפות של ההפצה למשך עד 6 חודשים אחרי שחרור ההסתעפות. אחרי המועד של 6 החודשים, צריך לבקש סיבוב חוזר כדי להחיל תיקוני אבטחה על הסתעפות.
לפני שמבקשים החזר כספי, חשוב לשים לב להנחיות הבאות:
מותר להשתמש בספינינג רק בהסתעפויות הפצה אחרי השקת הפצה ציבורית ראשונית של build חודשי.
בקשות Respin מתקבלות רק להסתעפות נתונה למשך שישה חודשים לכל היותר לאחר ההשקה הציבורית הראשונית. אחרי שישה חודשים, הסתעפויות עומדות בדרישות לסיבוב מחדש רק לתיקוני אבטחה המוזכרים במבזק האבטחה של Android.
כשדרישות ה-LTS, שמוגדרות על ידי מבזק האבטחה של Android (ASB), גורמות להסתעפות לא תואמת, ההסתעפות הוצאה משימוש. לא יתקבלו בקשות מסתובבות להסתעפויות שהוצאו משימוש. תאריך ההוצאה משימוש של הסתעפות נתונה של 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, צריך ליצור שתי בקשות respinאחרי שמספקים גרסת build והבקשה לסיבוב מחדש מסומנת כבעיה שתוקנה, אי אפשר לפתוח מחדש את הבקשה לסיבוב מחדש כדי להוסיף עוד CL. אם יש תיקונים נוספים שצריך למזג, צריך לשלוח בקשה חדשה להעתקה מחדש.
לכל CL שנכלל בבדיקה, יש להוסיף את התגים הבאים. ההתקדמות של הבקשה לסיבוב מחדש תיחסם בלי המידע הזה.
Bug: צריך להוסיף את מזהה הבאג להודעת השמירה עבור כל CL.Change-Id: חייב להיות זהה למזהה השינוי של שינוי ההסתעפות הבסיסית.
אם נדרשת תשובה לבקשה לחוזרת ולא מתקבלת תגובה תוך שלושה ימי עסקים, רמת העדיפות תשודרג לאחור ברמה אחת (לדוגמה, רמת העדיפות של P0 תשודרג לאחור ל-P1). אם לא תגיבו במשך שבועיים, הבאג יסומן כ-Won't Fix (מיושן).
שליחת בקשה לסגירה חוזרת
בתרשים הבא מוצג תהליך הסיבוב החוזר. התהליך מתחיל כששותף ה-OEM (אתם) שולח את הבקשה לסיבוב חוזר.
איור 2. תהליך הסיבוב החוזר
כדי להיכנס לתהליך הרוטציה:
- ממלאים את טופס הבקשה ל-GKI Respin ופונים מיד למנהל החשבונות הטכני של Google. הטופס הזה יוצר באג של בקשה לסיבוב חוזר של GKI. באגים בבקשות להצמדה מחדש גלויים לכם (למגיש הבקשה), לצוות GKI ולאנשים ספציפיים שהוספתם לרשימת
העותקים של הבאג.
- אם כבר יש תיקון, הבקשה צריכה להפנות לשליחת התיקון ב-AOSP כדי ש-Google תוכל לבדוק אותו. אם אי אפשר לשלוח את התיקון, צריך לצרף את התיקון כקובץ טקסט לבקשה.
- אם אין תיקון, הבקשה צריכה להכיל כמה שיותר מידע, כולל מספר גרסת הליבה ויומנים, כדי ש-Google תוכל לעזור לנפות את הבאגים שגרמו לבעיה.
- צוות Google GKI יבדוק את הבקשה ויאשר אותה, או יקצה לכם אותה בחזרה אם יידרש מידע נוסף.
- לאחר שהוסכם על תיקון, הקוד של צוות Google GKI יבדוק (CR+2) את השינוי. הבדיקה מתחילה במסגרת הזמן של ESRT. צוות GKI ממזג, בונה, בודק אם יש רגרסיה ומאשר את השינוי.
- הקובץ הבינארי משוחרר ל-ci.android.com. מסגרת הזמן של ה-ESRT מסתיימת וצוות Google GKI מסמן את הבקשה כקבועה ומפנה את ה-build החלופי. ה-build החוזר פורסם גם בדף גרסאות build גנריות של תמונת ליבה (GKI).
הסמכות GKI
| סוגי גרסאות build של GKI | אכיפת איכות | הערות |
|---|---|---|
| כל שבוע | בדיקת דיונון
|
|
| חודשי (מאושר) | בדיקת דיונון
|
|
| Respins (מאושר) | בדיקת דיונון
|
|
איפה משיגים ארטיפקטים של build
בכתובת ci.android.com אפשר למצוא את פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) של כל הגרסאות.
בלוח הבקרה אינטגרציה רציפה (CI) תוכלו למצוא מידע נוסף על ה-CI, כולל תוצאות הבדיקה.
שאלות נפוצות
האם ניתן לפתח קובץ בינארי חדש של GKI על סמך GKI שכבר פורסם?
כן, זה נקרא respin. תהליך ה-Respin נתמך כל עוד גרסת ה-GKI build שפורסמה (שנשלחה בקשה לביצוע ה-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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
אפשר לאחזר את עותק פריט המידע שנוצר בתהליך הפיתוח (Artifact) של GKI מ-out/.../dist.
האם הקובץ הבינארי של GKI (כולל תיקון הספין במצב חירום) נבנה על בסיס הקוד העדכני ביותר?
לא. הספיגה מכילה רק תיקונים בחלק מהליבה (kernel) של האישור החודשי שנבחרו. התוצאות האלו כוללות את כל תיקוני הבאגים שחוסמים את ההשקה, שמדווחים עד לזמן נתון על ידי יצרני ציוד מקורי (OEM) באמצעות הגרסה החודשית הבסיסית התואמת. הדוגמה הבאה מראה איך תרחיש כזה מתרחש.
- מנובמבר 2021, יצרני ציוד מקורי1 ו-OEM2 (יצרן הציוד המקורי) החליטו להשתמש בגרסה הבינארית של GKI.
- OEM1 ו-OEM2 (יצרני ציוד מקורי) מחפשים בעיות שדורשות תיקונים לקבלת תמיכה. התיקונים האלה עשויים להיות שונים או להיות זהים.
- הספיחה מעל הקובץ הבינארי של נובמבר 2021 כוללת תיקון של חסימת השקה, שדווחו על ידי OEM1 ו-OEM2 במהלך חלון העיבוד החוזר, אבל לא יותר.
- הבעיות שצוינו בסעיף השני נכללות גם בגרסאות החודשיות הבאות של GKI.
בתגובת ה-OEM באוקטובר יש את כל התיקונים שנשלחו על ידי ה-OEM, אבל תיקונים אחרים של ה-OEM משפיעים עלינו כי הם לא נבדקו באופן ספציפי עם המוצרים שלנו. האם אפשר לכלול רק את התיקון שלנו?
אי אפשר לעשות את זה. בשלב זה, לא ניתן לשנות נתיב מסתובב של "לכל OEM" (יצרן ציוד מקורי). במקום זאת, צוות GKI בוחן כל שינוי שמתבצע ב-respin build, ובודק את השינויים באמצעות כל החומרה הזמינה לפני יצירת build חדש. אם צוות GKI יגלה שהבעיה היא ספציפית ל-OEM, למכשיר/לדגם, צוות GKI יוכל לוודא שהקוד שנוסף בעקבות השינוי יפעל רק במכשיר, בדגם או במק"ט שהושפעו מהשינוי.
היתרון העיקרי של הוספות מאוחדות הוא שכל מכשיר שנעשה בו שימוש באותו בסיס הפצה מועיל זה לזה, במיוחד אם הבאגים שהם מגלים הם כלליים וחלים לכל המשתמשים. דוגמה ספציפית לקונספט הזה של באגים בליבה (kernel) שנמצאו בבדיקת הספק.
האם יש מצבים שבהם Google מספקת מידע ספציפי לגבי תיקונים של OEM (יצרן ציוד מקורי) ותרחישים של בעיות, כדי שיצרני ציוד מקורי יוכלו להעריך את ההשפעה והסיכון בהטמעת התיקונים במוצרים שלהם?
Google אף פעם לא תוסיף שינוי ל-build חוזר עד שמבינים את הבעיה וכל הפרטים נאספים. אפשר לראות את זה ביומן השינויים (הודעה לגבי התחייבות). Google לא חושפת על איזה מכשיר ספציפי היא משפיעה, אבל יצרני ציוד מקורי תמיד יכולים למצוא את התיאור והפתרון של הבעיה ביומן השינויים.