אנדרואיד 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
) ולהשתמש בהזדמנות זו כפורום לדיונים על בעיות סיבת האתחול.