בדף הזה מוסבר איך מתבצעת ההפצה של GKI, כולל הפצות רבעוניות והפצות חירום מחוץ לטווח. המטרה של הדף הזה היא לספק ליצרני ציוד מקורי (OEM) הנחיות לגבי המקום שבו אפשר להוריד את GKI, וגם לגבי התהליך של תיקוני חירום מחוץ לפס. יצרני ציוד מקורי (OEM) יכולים גם להשתמש בפיתוח GKI כדי לקבל מידע נוסף על האופן שבו הם יכולים לעבוד עם צוות ליבת Android כדי לבצע אופטימיזציה של ליבת GKI למוצרים שלהם.
קצב ההפצה של GKI
ה-GKI מופץ אחת לרבעון אחרי הקפאת ה-KMI.
| חודש ההפצה | a12-5.10 | a13-5.10 | a13-5.15 | a14-5.15 | a14-6.1 | a15-6.6* | a16-6.12* | a17-6.18* | |
|---|---|---|---|---|---|---|---|---|---|
| אוקטובר 2025 |
המועד האחרון לביצוע צ'ק-אין |
16 באוקטובר | 1 באוקטובר | 1 באוקטובר | |||||
| הטעינה מראש של GKI מוכנה | 31 באוקטובר | 15 באוקטובר | 15 באוקטובר | ||||||
| דצמבר 2025 |
המועד האחרון לביצוע צ'ק-אין |
1 בדצמבר | 1 בדצמבר | 1 בדצמבר | 1 בדצמבר | ||||
| הטעינה מראש של GKI מוכנה | 15 בדצמבר | 15 בדצמבר | 15 בדצמבר | 15 בדצמבר | |||||
| ינואר 2026 |
המועד האחרון לביצוע צ'ק-אין |
16 בינואר | 2 בינואר | 2 בינואר | |||||
| הטעינה מראש של GKI מוכנה | 31 בינואר | 15 בינואר | 15 בינואר | ||||||
| פברואר 2026 |
המועד האחרון לביצוע צ'ק-אין |
||||||||
| הטעינה מראש של GKI מוכנה | |||||||||
| מרץ 2026 |
המועד האחרון לביצוע צ'ק-אין |
1 במרץ | 1 במרץ | 15 במרץ | |||||
| הטעינה מראש של GKI מוכנה | 15 במרץ | 15 במרץ | 31 במרץ | ||||||
| אפריל 2026 |
המועד האחרון לביצוע צ'ק-אין |
16 באפריל | 16 באפריל | 1 באפריל | 1 באפריל | ||||
| הטעינה מראש של GKI מוכנה | 30 באפריל | 30 באפריל | 15 באפריל | 15 באפריל | |||||
| מאי 2026 |
המועד האחרון לביצוע צ'ק-אין |
||||||||
| הטעינה מראש של GKI מוכנה | |||||||||
| יוני 2026 |
המועד האחרון לביצוע צ'ק-אין |
1 ביוני | 15 ביוני | 15 ביוני | 1 ביוני | ||||
| הטעינה מראש של GKI מוכנה | 15 ביוני | 30 ביוני | 30 ביוני | 15 ביוני | |||||
| יולי 2026 |
המועד האחרון לביצוע צ'ק-אין |
16 ביולי | 16 ביולי | 1 ביולי | 1 ביולי | ||||
| הטעינה מראש של GKI מוכנה | 31 ביולי | 31 ביולי | 15 ביולי | 15 ביולי | |||||
| אוגוסט 2026 |
המועד האחרון לביצוע צ'ק-אין |
||||||||
| הטעינה מראש של GKI מוכנה | |||||||||
| ספטמבר 2026 |
המועד האחרון לביצוע צ'ק-אין |
1 בספטמבר | 16 בספטמבר | 16 בספטמבר | 1 בספטמבר | ||||
| הטעינה מראש של GKI מוכנה | 15 בספטמבר | 30 בספטמבר | 30 בספטמבר | 15 בספטמבר | |||||
| אוקטובר 2026 |
המועד האחרון לביצוע צ'ק-אין |
16 באוקטובר | 16 באוקטובר | 1 באוקטובר | 1 באוקטובר | ||||
| הטעינה מראש של GKI מוכנה | 31 באוקטובר | 31 באוקטובר | 15 באוקטובר | 15 באוקטובר | |||||
| נובמבר 2026 |
המועד האחרון לביצוע צ'ק-אין |
||||||||
| הטעינה מראש של GKI מוכנה | |||||||||
| דצמבר 2026 |
המועד האחרון לביצוע צ'ק-אין |
1 בדצמבר | 1 בדצמבר | 1 בדצמבר | 1 בדצמבר | ||||
| הטעינה מראש של GKI מוכנה | 15 בדצמבר | 15 בדצמבר | 15 בדצמבר | 15 בדצמבר | |||||
תוקף ה-Build של GKI ליצרני ציוד מקורי
יצרני ציוד מקורי יכולים להשתמש ב-GKI של Android שפורסם לאחרונה. יצרני ציוד מקורי (OEM) יכולים להשיק מכשירים עם גרסאות build שאושרו על ידי GKI, כל עוד הם עומדים בדרישות של ליבת LTS (תמיכה לטווח ארוך) שמפורטות בחדשות האבטחה של Android (ASB).
מהדורות מוסמכות רבעוניות
מהדורות GKI רבעוניות מכילות boot.img שנבדק וכולל אישור שנוסף על ידי Google כדי לאשר שהקובצים הבינאריים נוצרו מבסיס קוד מוכר.
בכל רבעון, נבחר מועמד למהדורת GKI רבעונית (לא מאושרת) אחרי תאריך הסיום של הצ'ק-אין. אחרי שבוחרים את גרסת המועמד להפצה הרבעונית, לא יתקבלו שינויים חדשים בגרסה של אותו חודש. במהלך תקופת החלון הסגור, אפשר לטפל רק בתיקונים של באגים שגורמים לשגיאת בדיקה. גרסה מועמדת להפצה עוברת בדיקת בקרת איכות – כפי שמתואר בקטע על ההסמכה של GKI – כדי לוודא שמבחני התאימות עוברים בגרסת GSI+GKI עם מכשיר ייחוס וגם עם Cuttlefish.
איור 1. ציר הזמן של ההשקה של GKI
דרישות הסף לשימוש ב-GKI
| סוגים של גרסאות GKI | אכיפת מדיניות האיכות | Notes |
|---|---|---|
| רבעוני (מאושר) | בדיקות ב-Cuttlefish
|
|
| ספינים חוזרים (מאושרים) | בדיקות ב-Cuttlefish
|
|
איפה אפשר להשיג פריטי מידע על בנייה
יצרני ציוד מקורי יכולים לקבל ארטיפקטים של כל הגרסאות מ-ci.android.com.
מידע נוסף על ה-CI, כולל תוצאות הבדיקה, זמין בלוח הבקרה Android Continuous Integration.
שאלות נפוצות
ריכזנו כאן כמה שאלות נפוצות שקשורות לתהליך ההפצה של GKI.
האם אפשר ליצור קובץ בינארי חדש של GKI על סמך GKI שכבר פורסם?
כן, זה נקרא respin. תהליך הספין מחדש נתמך כל עוד גרסת ה-build של 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/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
אפשר לאחזר את עותק הארטיפקט של GKI מ-out/.../dist.
האם הקובץ הבינארי של GKI (כולל תיקון החירום) נוצר על בסיס קוד העדכני ביותר?
לא. גרסאות Respin מכילות רק את התיקונים שנוספו על ליבות שאושרו ברבעון ונבחרו. הגרסאות האלה כוללות את כל תיקוני הבאגים שמונעים הפעלה, שדווחו עד למועד מסוים על ידי יצרני ציוד מקורי (OEM) באמצעות הגרסה הרבעונית הבסיסית המתאימה. בדוגמה הבאה אפשר לראות איך תרחיש כזה קורה.
- חברות OEM1 ו-OEM2 מחליטות להשתמש בגרסה הבינארית של GKI מנובמבר 2021.
- חברות OEM1 ו-OEM2 מוצאות בעיות שדורשות תיקונים כדי לתמוך במוצר. יכול להיות שהתיקונים יהיו שונים או זהים.
- הגרסאות החדשות של קובץ הבינארי מנובמבר 2021 כוללות תיקונים של בעיות שמונעות הפעלה, שדווחו על ידי OEM1 ו-OEM2 במהלך חלון הזמן של הגרסה החדשה, אבל לא יותר מזה.
- הבעיות שצוינו בתבליט השני כלולות גם במהדורות הבאות של GKI שיוצאות מדי רבעון.
הגרסה המחודשת של אוקטובר כוללת את כל התיקונים שנשלחו על ידי יצרני הציוד המקורי, אבל תיקונים אחרים של יצרני ציוד מקורי משפיעים עלינו כי הם לא נבדקו באופן ספציפי עם המוצרים שלנו. האם אפשר לכלול רק את התיקון שלנו?
אי אפשר לעשות את זה. אי אפשר להרחיב את השימוש בנתיב של ספין מחדש ליצרני ציוד מקורי (OEM) ספציפיים. במקום זאת, צוות GKI בודק בקפידה כל שינוי שנכלל בגרסאות respin, ובודק את השינויים בכל החומרה הזמינה לפני יצירת גרסה חדשה. אם צוות GKI יגלה שהבעיה ספציפית ל-OEM, למכשיר או לדגם, הצוות יוכל לוודא שהקוד שנוסף על ידי השינוי מופעל רק במכשיר, בדגם או במק"ט שמושפעים.
היתרון העיקרי של עדכונים מאוחדים הוא שכל מכשיר שמשתמש באותו בסיס של גרסה נהנה מהעדכונים, במיוחד אם הבאגים שמתגלים הם כלליים ורלוונטיים לכל המשתמשים. דוגמה ספציפית למושג הזה היא באגים בליבת הקרנל שנמצאו בבדיקות של ספקי סלולר.
האם יש מצבים שבהם Google מספקת מידע ספציפי על תיקונים של יצרני ציוד מקורי (OEM) ועל תרחישי בעיות, כדי שיצרני ציוד מקורי יוכלו להעריך את ההשפעה והסיכון של הטמעת התיקונים במוצרים שלהם?
Google לא תוסיף שינוי לגרסת respin עד שצוות GKI יבין את הבעיה ויאסוף את כל הפרטים. אפשר לראות את זה ביומן השינויים (הודעת commit). Google לא חושפת את המכשיר הספציפי שהבעיה משפיעה עליו, אבל יצרני ציוד מקורי (OEM) תמיד יכולים למצוא את תיאור הבעיה והפתרון ביומן השינויים.