סיבה לאתחול קנונית

אנדרואיד 9 כולל את השינויים הבאים במפרט סיבת האתחול של טוען האתחול.

סיבות אתחול

טוען אתחול משתמש במשאבי חומרה וזיכרון זמינים באופן ייחודי כדי לקבוע מדוע התקן הופעל מחדש, ולאחר מכן מעביר את הקביעה הזו על ידי הוספת androidboot.bootreason=<reason> לשורת הפקודה של ליבת אנדרואיד לצורך השקתו. לאחר מכן, init מתרגם את שורת הפקודה הזו להתפשטות למאפיין האנדרואיד bootloader_boot_reason_prop ( ro.boot.bootreason ). עבור מכשירים המופעלים עם אנדרואיד 12 ואילך, המשתמשים בגרסת ליבה 5.10 ומעלה, androidboot.bootreason=<reason> מתווסף ל-bootconfig במקום לשורת הפקודה של הליבה.

מפרטי סיבת האתחול

מהדורות קודמות של אנדרואיד ציינו פורמט של סיבה לאתחול שלא השתמש ברווחים, הכל היה באותיות קטנות, כלל דרישות מועטות (כגון לדיווח kernel_panic , watchdog , cold / warm / hard ), ואשר התיר מסיבות ייחודיות אחרות. המפרט הרופף הזה הביא להתרבות של מאות מחרוזות סיבה לאתחול מותאמות אישית (ולפעמים חסרות משמעות), שבתורן הובילו למצב בלתי ניתן לניהול. נכון לגרסה הנוכחית של אנדרואיד, המומנטום העצום של תוכן כמעט בלתי ניתן לניתוח או חסר משמעות שהוגש על ידי טוען האתחול יצר בעיות תאימות עבור bootloader_boot_reason_prop .

עם שחרורו של אנדרואיד 9, צוות אנדרואיד מזהה כי ל- bootloader_boot_reason_prop מדור קודם יש מומנטום משמעותי ולא ניתן לכתוב אותו מחדש בזמן ריצה. לכן, כל שיפורים במפרט סיבת האתחול חייבים לבוא מאינטראקציות עם מפתחי מאתחול ומשינויים במערכת הקיימת. לשם כך צוות אנדרואיד הוא:

• יצירת קשר עם מפתחי מאתחול כדי לעודד אותם:
  • ספק סיבות קנוניות, ניתנות לניתוח וזיהוי ל- bootloader_boot_reason_prop .
  • השתתף ברשימת system/core/bootstat/bootstat.cpp kBootReasonMap .
• הוספת מקור מבוקר וניתן לשכתוב בזמן ריצה של system_boot_reason_prop ( sys.boot.reason ). קבוצה מוגבלת של יישומי מערכת (כגון bootstat ו- init ) יכולה לשכתב את המאפיין הזה, אך ניתן להעניק לכל היישומים זכויות מדיניות לקרוא אותו.
• להודיע ​​למשתמשים על סיבת האתחול להמתין עד לאחר הטעינה של נתוני המשתמש לפני שהם נותנים אמון בתוכן במאפיין סיבת האתחול של המערכת system_boot_reason_prop .

למה כל כך מאוחר? בעוד bootloader_boot_reason_prop זמין בשלב מוקדם באתחול, הוא נחסם על ידי מדיניות האבטחה של אנדרואיד על בסיס הצורך מכיוון שהוא מייצג מידע לא מדויק, בלתי ניתן לניתוח ולא קנוני. ברוב המצבים, רק מפתחים בעלי ידע מעמיק במערכת האתחול צריכים לגשת למידע זה. API מעודן, ניתן לנתח וקנוני מסיבה אתחול באמצעות system_boot_reason_prop ניתן לאסוף בצורה מהימנה ומדויקת רק לאחר העלאת נתוני משתמש. באופן ספציפי:

• לפני שנטען את נתוני המשתמש, system_boot_reason_prop יכיל את הערך מ- bootloader_boot_reason_prop .
• לאחר הטעינה של נתוני המשתמש, ייתכן system_boot_reason_prop תתעדכן כך שתהיה תואמת או כדי לדווח על מידע מדויק יותר.

מסיבה זו, אנדרואיד 9 מאריכה את פרק הזמן עד שניתן לרכוש את סיבת האתחול באופן רשמי, ומשנה אותה מלהיות מדויק מיידית באתחול (עם bootloader_boot_reason_prop ) להיות זמין רק לאחר העלאת נתוני המשתמש (עם system_boot_reason_prop ).

לוגיקה של Bootstat תלויה ב- bootloader_boot_reason_prop אינפורמטיבי ותואם יותר. כאשר מאפיין זה משתמש בפורמט צפוי, הוא משפר את הדיוק של כל תרחישי האתחול והכיבוי המבוקרים, אשר בתורו מחדד ומרחיב את הדיוק והמשמעות של system_boot_reason_prop .

פורמט סיבה לאתחול קנוני

פורמט סיבת האתחול הקנוני עבור bootloader_boot_reason_prop באנדרואיד 9 משתמש בתחביר הבא:

<reason>,<subreason>,<detail>…

כללי עיצוב:

• אוֹתִיוֹת קְטָנוֹת
• אין ריקים (השתמש בקו תחתון)
• כל התווים הניתנים להדפסה
• reason מופרדת בפסיקים , סיבה subreason detail אחד או יותר.
  • reason נדרשת המייצגת את הסיבה בעדיפות הגבוהה ביותר לכך שהמכשיר נאלץ לאתחל או לכבות.
  • סיבה subreason אופציונלית המייצגת סיכום קצר של הסיבה שהמכשיר נאלץ לאתחל או לכבות (או מי אתחל או כיבה את המכשיר).
  • ערך detail אופציונלי אחד או יותר. detail עשוי להצביע על תת-מערכת כדי לסייע בקביעה איזו מערכת ספציפית הובילה subreason . אתה יכול לציין ערכי detail מרובים, שצריכים בדרך כלל לעקוב אחר היררכיה של חשיבות. עם זאת, מקובל גם לדווח על ערכי detail מרובים בעלי חשיבות שווה.

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

דרישות סיבה

הערך שניתן reason (טווח ראשון, לפני סיום או פסיק) חייב להיות מהקבוצה הבאה המחולקת לסיבות ליבה, חזקות ובוטות:

• סט ליבה:
  • " watchdog"
  • "kernel_panic"
• סט חזק:
  • "recovery"
  • "bootloader"
• סט קהה:
  • "cold" . בדרך כלל מציין איפוס מלא של כל המכשירים, כולל זיכרון.
  • "hard" . בדרך כלל מציין שהמצב של החומרה אופס ו- ramoops אמור לשמור על תוכן מתמשך.
  • "warm" . בדרך כלל מציין שהזיכרון וההתקנים שומרים על מצב מסוים, ומאגר הגיבוי ramoops (ראה מנהל התקן pstore בליבה) מכיל תוכן מתמשך.
  • "shutdown"
  • "reboot" . בדרך כלל אומר שמצב ramoops אינו ידוע ומצב החומרה אינו ידוע. ערך זה הוא תמצית מכיוון שהערכים cold , hard warm מספקים רמזים לגבי עומק האיפוס של המכשיר.

מטעני האתחול חייבים לספק ערכת ליבה או reason ערכה בוטה, ומומלץ מאוד לספק subreason אם ניתן לקבוע אותה. לדוגמה, לחיצה ארוכה על מקש הפעלה שאולי יש גיבוי ramoops או לא תהיה הסיבה "reboot,longkey" .

שום reason ראשונה לא יכולה להיות חלק subreason או detail . עם זאת, מכיוון שלא ניתן לייצר סיבות לקבוצת ליבה על ידי מרחב המשתמש, ניתן לעשות שימוש חוזר "watchdog" לאחר סיבת סט בוטה, יחד עם פירוט המקור (למשל "reboot,watchdog,service_manager_unresponsive" , או "reboot,software,watchdog" ).

סיבות אתחול לא צריכות לפענח ידע פנימי של מומחה ו/או צריכות להיות קריאות אנושיות עם דוח אינטואיטיבי. דוגמאות: "shutdown,vbxd" (רע), "shutdown,uv" (טוב יותר), "shutdown,undervoltage" (מועדף).

שילובי סיבה-תת

אנדרואיד שומרת לעצמה קבוצה של reason - subreason -סיבות שאסור להעמיס עליהם בשימוש רגיל, אך ניתן להשתמש בהם על בסיס כל מקרה לגופו אם השילוב משקף במדויק את המצב המשויך. דוגמאות לשילובים שמורים כוללים:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (מ- thermald )
• "shutdown,battery"
• "shutdown,battery,thermal" (מאת BatteryStatsService )
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

לפרטים נוספים, עיין ב- kBootReasonMap ב- system/core/bootstat/bootstat.cpp והיסטוריית לוג השינויים המשויכת ל-git במאגר המקור של אנדרואיד.

דיווח על סיבות אתחול

כל סיבות האתחול, בין אם ממטען האתחול או מתועדות בסיבות האתחול הקנוניות, חייבות להיות מתועדות בקטע kBootReasonMap של system/core/bootstat/bootstat.cpp . רשימת kBootReasonMap היא שילוב של סיבות לא תואמות ומדור קודם. מפתחי אתחול צריכים לרשום כאן רק סיבות תואמות חדשות (ולא צריכים לרשום סיבות שאינן תואמות אלא אם המוצר כבר נשלח ולא ניתן לשנותו).

אנו ממליצים בחום להשתמש בערכים קיימים ותואמים ב- system/core/bootstat/bootstat.cpp ולנהוג באיפוק לפני השימוש במחרוזת שאינה תואמת. כקו מנחה, הוא:

• אישור לדווח על "kernel_panic" ממטען האתחול, מכיוון ש- bootstat עשוי להיות מסוגל לבדוק ramoops עבור kernel_panic signatures כדי לחדד את הסיבות המשנה לתוך system_boot_reason_prop הקנוני.
• לא בסדר לדווח על מחרוזת שאינה תואמת ב- kBootReasonMap (כגון "panic") ממטען האתחול, מכיוון שזה בסופו של דבר ישבור את היכולת לחדד את reason .

לדוגמה, אם kBootReasonMap מכיל "wdog_bark" , מפתח טוען אתחול צריך:

• שנה "watchdog,bark" והוסף לרשימה ב- kBootReasonMap .
• שקול מה המשמעות של "bark" עבור מי שלא מכיר את הטכנולוגיה וקבע אם יש subreason משמעותית יותר.

אימות תאימות של סיבת האתחול

בשלב זה, אנדרואיד לא מספקת בדיקת CTS פעילה שיכולה להפעיל או לבדוק במדויק את כל סיבות האתחול האפשריות שמטען אתחול יכול לספק; שותפים עדיין יכולים לנסות להפעיל בדיקה פסיבית כדי לקבוע תאימות.

כתוצאה מכך, תאימות של טוען אתחול מחייבת מפתחי אתחול לדבוק מרצון לרוח הכללים וההנחיות שתוארו לעיל. אנו קוראים למפתחים כאלה לתרום ל-AOSP (במיוחד ל- system/core/bootstat/bootstat.cpp ) ולהשתמש בהזדמנות זו כפורום לדיונים על בעיות סיבת האתחול.