מערכת Android 9 כוללת את השינויים הבאים במפרט הסיבה להפעלה של תוכנת האתחול.
הסיבות להפעלה
תוכנת אתחול משתמשת במשאבי חומרה וזיכרון שזמינים באופן ייחודי כדי
להבין למה המכשיר הופעל מחדש, ואז מעביר את המידע
הוספה של androidboot.bootreason=<reason>
ל-Android
בשורת הפקודה של הליבה להשקה. ואז init
מתרגם את זה
שורת הפקודה להעברה לנכס Android
bootloader_boot_reason_prop
(ro.boot.bootreason
).
במכשירים עם Android מגרסה 12 ואילך:
עם גרסת ליבה (kernel) 5.10 ומעלה, androidboot.bootreason=<reason>
נוספה ל-bootconfig במקום לשורת הפקודה של הליבה.
מפרטים של הסיבות להפעלה
בגרסאות הקודמות של Android צוין פורמט סיבת הפעלה שלא נעשה בו שימוש
רווחים, באותיות קטנות, כולל כמה דרישות (כמו דיווח)
kernel_panic
, watchdog
cold
/warm
/hard
), ומה שגרם לכך
שאין לך זכאות מסיבות ייחודיות אחרות. המפרט החופשי הזה הוביל
של מאות הסברים מותאמים אישית (ולפעמים חסרי משמעות)
מחרוזות, דבר שבתורו הוביל למצב שלא ניתן לניהול. נכון לתאריך הנוכחי
גרסת Android, המומנטום האדיר של תוכן שכמעט לא ניתן לניתוח או חסר משמעות
שנשלח על ידי תוכנת האתחול גרמה לבעיות תאימות עבור
bootloader_boot_reason_prop
בגרסת Android 9, צוות Android
מזהה שהגרסה הקודמת של bootloader_boot_reason_prop
מומנטום משמעותי ולא ניתן לשכתב אותו בזמן ריצה. שיפורים כלשהם ב-
לכן מפרט סיבת האתחול חייב להגיע מאינטראקציות עם
מפתחי תוכנת אתחול ושינויים במערכת הקיימת. כדי לסיים את התהליך,
צוות Android הוא:
- אינטראקציה עם מפתחי תוכנת אתחול לעודד אותם:
- לספק סיבות קנוניות, ניתנות לניתוח וניתנות לזיהוי כדי
bootloader_boot_reason_prop
- להשתתף ב-
system/core/bootstat/bootstat.cpp
רשימה שלkBootReasonMap
.
- לספק סיבות קנוניות, ניתנות לניתוח וניתנות לזיהוי כדי
- להוסיף מקור מבוקר שניתן לכתיבה בזמן הריצה
system_boot_reason_prop
(sys.boot.reason
). א' קבוצה מוגבלת של אפליקציות מערכת (כמוbootstat
וinit
) אפשר לשכתב את המאפיין הזה, אבל כל האפליקציות יכולות העניקו זכויות לשימוש ב-Sepolicy לקרוא אותו. - הודעה למשתמשים לגבי סיבת ההפעלה שצריך להמתין עד לסיום הטעינה של נתוני המשתמשים
לפני שסומכים על התוכן במאפיין סיבת ההפעלה של המערכת
system_boot_reason_prop
למה כל כך מאוחר? למרות ש-bootloader_boot_reason_prop
זמין מוקדם
בזמן ההפעלה, הוא נחסם על ידי מדיניות האבטחה של Android לפי הצורך
כי הוא מייצג מידע לא מדויק, לא ניתן לניתוח ולא קנוני.
ברוב המקרים, רק מפתחים עם ידע מעמיק על מערכת ההפעלה
נדרשת גישה למידע הזה. גרסה משופרת, ניתנת לניתוח וקנונית
ה-API לסיבת ההפעלה עם system_boot_reason_prop
יכול להיות מהימן
והם נאספים באופן מדויק רק אחרי נתוני המשתמש.
פרטים נוספים:
- לפני הטעינה של נתוני המשתמשים,
system_boot_reason_prop
יכיל את הערך מתוךbootloader_boot_reason_prop
- אחרי טעינת נתוני המשתמשים,
ייתכן ש-
system_boot_reason_prop
עודכן כדי לעמוד בדרישות או כדי כדי לדווח על מידע מדויק יותר.
לכן, מערכת Android 9 מאריכה את התקופה של
לפני שניתן להשיג את סיבת האתחול באופן רשמי,
דיוק מיידי בהפעלה (עם bootloader_boot_reason_prop
)
כך שיהיו זמינים רק אחרי שנתוני המשתמש נטענים (עם
system_boot_reason_prop
).
לוגיקת Bigstat תלויה
bootloader_boot_reason_prop
כשהנכס הזה משתמש
בפורמט צפוי, הוא משפר את הדיוק של כל הפעלה מחדש מבוקרת
תרחישי כיבוי, אשר בתורם משפרים ומרחיבים את הדיוק והמשמעות
מתוך system_boot_reason_prop
.
פורמט קנוני של סיבת האתחול
הפורמט הקנוני של סיבת ההפעלה עבור bootloader_boot_reason_prop
ב-Android 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
מנהל התקן בליבה (kernel)) מכיל תוכן עקבי."shutdown"
"reboot"
בדרך כלל המדינהramoops
היא לא ידוע ומצב החומרה לא ידוע. הערך הזה הוא כללי כמו הערכיםcold
,hard
ו-warm
מספקים רמזים לגבי עומק האיפוס של המכשיר.
תוכנת אתחול צריכה לספק ליבה (kernel) או קבוצה קהה reason
, וגם
מומלץ מאוד לספק subreason
אם ניתן
נקבע. לדוגמה, לחיצה ארוכה על מקש הפעלה מונעת
הסיבה להפעלת הגיבוי היא ramoops
"reboot,longkey"
.
לא ניתן לכלול reason
בטווח הראשון של subreason
או
detail
. אבל, מכיוון שסיבות להגדרת הליבה (kernel) לא יכולות להיות מופקות על ידי
מרחב המשתמש, ניתן לעשות שימוש חוזר ב-"watchdog"
לאחר סיבה קהה,
וגם פרטים על המקור (למשל,
"reboot,watchdog,service_manager_unresponsive"
, או
"reboot,software,watchdog"
).
סיבות ההפעלה לא צריכות לדרוש ידע פנימי של מומחה כדי לפענח ו/או
חייב להיות קריא לאנשים עם דוח אינטואיטיבי. למשל:
"shutdown,vbxd"
(לא טוב), "shutdown,uv"
(טוב יותר),
"shutdown,undervoltage"
(המועדף).
שילובים של סיבה משנית
Android שומר קבוצה של 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 המשויך
בהיסטוריה של יומן השינויים במאגר המקור של Android.
דיווח על סיבות הפעלה
כל הסיבות להפעלה, מתוכנת האתחול או נרשמות בהפעלה הקנונית
חייבת להיות רשומה בקטע 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
משמעותי יותר זמינים.
בדיקת התאימות של סיבת ההפעלה
בשלב זה, מערכת Android לא מספקת בדיקת CTS פעילה שיכולה לספק מידע מדויק. להפעיל או לבדוק את כל הסיבות האפשריות לאתחול שתוכנת האתחול יכולה לספק; שותפים עדיין יכולים לנסות להריץ בדיקה פסיבית כדי לקבוע תאימות.
לכן, כדי לעמוד בדרישות של תוכנת האתחול, מפתחי תוכנת האתחול צריכים
לציית מרצון לרוח הכללים וההנחיות שתוארו למעלה.
אנחנו ממליצים למפתחים כאלה לתרום ל-AOSP (במיוחד כדי
system/core/bootstat/bootstat.cpp
) ולהשתמש בהזדמנות הזו בתור
לדיונים על בעיות הקשורות לאתחול.