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

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

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

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

  • תזמון: אפשר לבקש שינויים רק בענפי הפצה אחרי השקה ראשונית של גרסת build רבעונית לציבור. אפשר לבקש שינוי של בקשות ל-vendor-hooks או לתכונות אחרות רק עבור ענף של גרסה מסוימת, למשך שישה חודשים לכל היותר אחרי הפרסום הראשוני של הגרסה.
  • אבטחה ו-LTS: אחרי שישה חודשים, אפשר ליצור גרסה חדשה להסתעפויות רק כדי לתקן באגים קריטיים או כדי להחיל תיקוני אבטחה שמופיעים בעדכון האבטחה של Android‏ (ASB).
  • הוצאה משימוש: אם ההסתעפות לא עומדת בדרישות LTS, שמוגדרות בעדכון האבטחה של Android‏ (ASB), היא תוצא משימוש. לא נקבל בקשות ליצירת גרסאות (respin) להסתעפויות שהוצאו משימוש.
    • תאריך ההוצאה משימוש של ענף גרסה מסוים של GKI מופיע בהערות הגרסה הרבעוניות של GKI בקטע Releases (גרסאות). לדוגמה, המהדורה מספטמבר 2025 נתמכת לשינויים חוזרים עד מרץ 2027. התאריך הזה משקף את משך החיים של גרסת הליבה LTS 2.0, שהוא 18 חודשים לגרסאות שיוצאות החל מספטמבר 2025 (לגרסאות שיצאו לפני ספטמבר 2025 היה משך חיים של 12 חודשים).
  • היקף: אפשר לבקש ספינים חוזרים רק לתיקוני באגים דחופים, לעדכונים של רשימת הסמלים או להחלת תיקון לתיקון תכונה קיימת.

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

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

מקור מידע אמין ובחירה סלקטיבית

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

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

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

תגים נדרשים

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

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

עדיפות ו-ESRT

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

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

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

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

מדיניות SLA

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

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

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

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

כדי לשלוח בקשה לשינוי:

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

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

  2. הכנת תיקונים:

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

    דוגמה: כדי לבצע cherry-pick של CL מ-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 בודק את הבקשה ומאשר אותה או מקצה אותה בחזרה אליך אם נדרש מידע נוסף.
      • אחרי שמסכימים על תיקון, צוות Google GKI מבצע בדיקת קוד של השינוי. הטיימר של ESRT פועל במהלך הבדיקה הזו. עם זאת, אם התיקון נדחה או שנדרשת עבודה מחדש, הטיימר של ESRT מתאפס.
      • צוות GKI ממזג, בונה, בודק רגרסיה ומאשר את השינוי.

    • גרסה: