בקשה לסיבוב חוזר

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

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

דרישות סף ומחזור חיים

  • תזמון: אפשר לבקש ספינים חוזרים רק בענפי הפצה אחרי השקה ראשונית של גרסת build רבעונית. אפשר לבקש שינוי של בקשות ל-vendor-hooks או לתכונות אחרות רק עבור ענף של גרסה מסוימת, למשך שישה חודשים לכל היותר אחרי הפרסום הראשוני של הגרסה לציבור.
  • אבטחה ו-LTS: אחרי שישה חודשים, אפשר ליצור גרסה חדשה להסתעפויות רק לתיקוני אבטחה שמופיעים בעדכון האבטחה של Android‏ (ASB) או לתיקוני באגים קריטיים.
  • הוצאה משימוש: אם ההסתעפות לא עומדת בדרישות LTS, שמוגדרות ב-Android Security Bulletin (ASB), היא תוצא משימוש. לא נקבל בקשות ליצירת גרסאות (respin) להסתעפויות שהוצאו משימוש.
    • תאריך ההוצאה משימוש של ענף גרסאות GKI מסוים מופיע בהערות של גרסת build להפצה של GKI שזמינה מדי רבעון, בקטע 'גרסאות'. לדוגמה, הגרסה של ספטמבר 2025 תומכת בגרסאות respin עד מרץ 2027. התאריך הזה משקף את משך החיים של גרסת הליבה LTS 2.0, שהוא 18 חודשים לגרסאות שיוצאות החל מספטמבר 2025 (לגרסאות שיצאו לפני ספטמבר 2025 היה משך חיים של 12 חודשים).
  • היקף: אפשר לבקש סבבי בדיקה חוזרים רק לצורך תיקוני באגים דחופים, עדכונים של רשימת הסמלים או כדי להחיל תיקון לתכונה קיימת.
  • גרסאות GKI בגודל 16 KB: גרסאות חוזרות על פי דרישה עבור ענפי GKI בגודל 16 KB (‫android15-6.6,‏ android16-6.12 ו-android17-6.18) פועלות לפי אותו טופס בקשה לגרסה חוזרת, אותם תקנים לשליחת תיקונים ואותו תהליך הסמכה כמו בגרסאות בגודל 4 KB. לא צריך לעדכן את ליבות ה-4 KB וה-16 KB ביחד, אבל מומלץ לעשות זאת.

תקנים לשליחת תיקונים

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

מקור מידע אמין ושימוש בקוד מהסתעפות אחרת (Cherry-picking)

  • קודם כל ענף הפיתוח: כל התיקונים שנכנסים לענף של הגרסה הרבעונית חייבים כבר להיות ממוזגים בענף הפיתוח הראשי של GKI. לדוגמה, אם נדרש תיקון לגרסה חדשה של android15-6.6-2025-08, הוא כבר צריך להיות ממוזג ב-android15-6.6.
  • שימוש בקוד מהסתעפות אחרת (Cherry-picking) ללא שינויים: צריך להשתמש בקוד מהסתעפות אחרת (Cherry-picking) ישירות מהסתעפות הפיתוח. אל תשתמשו בקוד מהסתעפויות אחרות של גרסאות (לדוגמה, אל תבחרו מ-2025-08 ל-2025-09), כי זה יכול לגרום לכך שפרטי המחבר או פרטי השמירה לא יהיו עקביים עם הגרסה בהסתעפות הפיתוח. לא יתקבלו תיקונים עם מידע לא עקבי.
  • שמירת מטא-נתונים: שמירת המטא-נתונים המקוריים של הקומיט (לדוגמה, מחבר, חותמת זמן מקורית). כדי לשמור את המטא-נתונים, משתמשים ב-git cherry-pick -x.

שרשרת שמירות (commit)

  • שרשרת רציפה: אם בקשת ה-respin כוללת כמה תיקונים, צריך להעלות אותם כשרשרת רציפה אחת של פקודות commit.
  • מיקום של ABI ו-KMI: אם גרסה חוזרת של תיקון מרובה כוללת עדכונים של ממשק מודול ליבת המערכת (KMI) וממשק בינארי של אפליקציה (ABI) (לדוגמה, שינויים ברשימת הסמלים או עדכונים בקובץ XML/STG), צריך למקם את הקומיטים האלה בסוף שרשרת הקומיטים.
  • שינוי בסיס: אם עורכים קומיט אב בקשר, צריך לשנות את הבסיס של כל תיקוני הצאצא על גבי הגרסה האחרונה של תיקון האב כדי למנוע כשלים בבנייה.
  • פתרון קונפליקטים: מוודאים שאין סמני קונפליקטים בתיקון.
  • אימות גרסה: כל שרשרת ה-commit צריכה להיבנות בהצלחה.

תגים נדרשים

ההתקדמות בבקשה ליצירת גרסה חדשה חסומה בלי התגים הבאים בהודעת ה-commit:

  • ‫Change-Id: חייב להיות זהה ל-Change-Id של השינוי בענף הפיתוח.
  • ‫Bug (קיים): אסור להסיר תגי Bug: XYZ קיימים מה-commit המקורי של ענף הפיתוח.
  • Bug (גרסה חדשה): צריך להוסיף תג Bug: XYZ חדש, שבו XYZ תואם למזהה הבאג שמשויך לבקשה הנוכחית לגרסה חדשה.
  • מעדכנים את תג ה-commit של UPSTREAM אם צריך: כשמשתמשים בקוד מהסתעפות אחרת (Cherry-picking) של CL מהסתעפות הפיתוח להסתעפות הגרסה, וה-CL מתויג בתור UPSTREAM, כדאי להביא בחשבון את התרחישים הבאים:
    • אם ה-CL חל בצורה חלקה על ענף הגרסה, לא צריך לבצע פעולה נוספת.
    • אם ה-CL לא חל בצורה חלקה, צריך לפתור את הקונפליקטים, לעדכן את התג ל-BACKPORT ולתעד את הפעולות שבוצעו כחלק מפתרון הקונפליקטים. אפשר לעיין בדרישות לביצוע backport מ-mainline Linux.

עדיפות ו-ESRT

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

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

בטבלה הבאה מפורט מיפוי של עדיפות הבאג וזמן הפתרון (ESRT):

עדיפותESRT
P02 ימי עסקים
P15 ימי עסקים
P210 ימי עסקים
P315 ימי עסקים

מדיניות SLA

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

שליחת בקשה ל-respin

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

תהליך הפעלה מחדש של מכונה וירטואלית במקרה חירום איור 1.תהליך ייצור מחדש (respin) דחוף.

כדי לשלוח בקשה ל-respin:

  1. מלאו את טופס הבקשה ל-GKI respin ופנו מיד לאיש הקשר שלכם ב-Google.

    • הטופס הזה יוצר באג של בקשה ל-GKI respin.

  2. הכנת הטלאים:

    • מוודאים שהתיקון מוזג ל-GKI development branch.
    • מחילים את התיקון על ענף ההפצה המתאים של GKI.
    • משנים את התיקון שנבחר כך שיכלול תג Bug: XYZ שמציין את מזהה הבקשה ליצירת גרסה חדשה.

    דוגמה: כדי להשתמש בקוד מהסתעפות אחרת (Cherry-picking) של רשימת שינויים מ-android16-6.12 ל-android16-6.12-2025-12:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. שולחים את הבאג. אחרי ששולחים את הבקשה, קורים הדברים הבאים:

    • תהליך הבדיקה אחרי שליחת הבקשה:

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

    • גרסה: