Android 11 תומך בהפעלות מחדש רכות, שהן הפעלות מחדש של תהליכים בזמן ריצה במרחב המשתמש, שמשמשות להחלת עדכונים שדורשים הפעלה מחדש (לדוגמה, עדכונים לחבילות APEX). נכון לעכשיו, הפעלה מחדש רכה מוגבלת לתהליכים שהתחילו אחרי שהכונן userdata
הותקן.
אפשר לבקש הפעלה רכה מחדש בדרכים הבאות:
מ-
PowerManager
, באמצעות התקשרות אלPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
ממעטפת, באמצעות
adb shell svc power reboot userspace
אוadb reboot userspace
אחרי הפעלה מחדש רכה, אחסון פרטי הכניסה המוצפנים נשאר פתוח.
אם המכשיר תומך בהפעלה מחדש רכה, השיטה PowerManager.isRebootingUserspace()
של ה-API מחזירה את הערך true
, והערך של מאפיין המערכת init.userspace_reboot.is_supported
שווה ל-1
.
אם המכשיר לא תומך בהפעלה מחדש רכה, השיחות למספרים PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
, adb reboot
userspace
ו-adb shell svc power reboot userspace
ייכשלו.
הפעלה מחדש רכה
אחרי שמבקשים הפעלה מחדש רכה (דרך PowerManager
או משורת פקודה), init
מבצע את השלבים הבאים:
מקבל
sys.powerctl=reboot,userspace
.מבצע פיצול (fork) של תהליך
UserspaceRebootWatchdogThread()
נפרד כדי לעקוב אחרי ההפעלה מחדש הרכה.מפעיל פעולת
userspace-reboot-requested
, שמאפסת את כל מאפייני המערכת שעשויים להשפיע על ההפעלה הרכה מחדש. נכסים מושפעים:sys.usb.config
sys.usb.state
sys.boot_completed
dev.bootcomplete
sys.init.updatable_crashing
sys.init.updatable_crashing_process_name
apexd.status
sys.user.0.ce_available
sys.shutdown.requested
service.bootanim.exit
צריך להגדיר מחדש את המאפיינים שלמעלה במהלך רצף האתחול. אם צריך, אפשר לאפס מאפיינים נוספים. לדוגמה, אפשר לעיין בפעולה
on userspace-reboot-requested
בrootdir/init.rc
.מריץ את הפונקציה
DoUserspaceReboot
שמבצעת את הפעולות הבאות:- שולח
SIGTERM
לתהליכים שהתחילו אחרי ש-userdata
הותקן ומחכה שהם יסתיימו. - אחרי שהזמן הקצוב לתפוגה מסתיים, נשלחת הפקודה
SIGKILL
כדי להפסיק את כל התהליכים הפעילים. - שיחות
/system/bin/vdc volume reset
. - מבטל את הטעינה של מכשיר הגיבוי של zRAM.
- מבטלת את הטעינה של חבילות APEX פעילות.
- חוזרים למרחב השמות של נקודת העיגון של bootstrap.
- מפעיל את הפעולה
userspace-reboot-resume
- שולח
אם נשלחה בקשה ליצירת נקודת ביקורת במערכת הקבצים לפני ההפעלה מחדש הרכה, userdata
מותקן מחדש במצב של יצירת נקודת ביקורת במהלך הפעולה userspace-reboot-fs-remount
(פרטים נוספים מופיעים בקטע הבא). הפעלה מחדש רכה נחשבת אחרי שהערך של sys.boot_completed property
מוגדר ל-1
. בסיום ההפעלה מחדש הרכה, המסך נשאר כבוי ונדרשת אינטראקציה מפורשת של המשתמש כדי להפעיל אותו.
יצירת נקודות ביקורת במערכת הקבצים
אם נשלחה בקשה לנקודת ביקורת של מערכת הקבצים לפני ההפעלה הרכה מחדש,
userdata
מותקן מחדש במצב של נקודת ביקורת במהלך ההפעלה הרכה מחדש.
הלוגיקה של ההרכבה מחדש מיושמת בפונקציה fs_mgr_remount_userdata_into_checkpointing
, והיא שונה בין שיטות שונות של יצירת נקודות ביקורת. באופן ספציפי, כש-userdata
תומך ב:
יצירת נקודות ביקורת ברמת מערכת הקבצים (לדוגמה,
f2fs
),userdata
מותקן מחדש עם האפשרותcheckpoint=disable
.Block level checkpointing (לדוגמה,
ext4
), ואז/data
מבוטל וכל המכשירים של מיפוי המכשירים של ההורה שהוא היה מחובר אליהם נהרסים. בשלב הבא,userdata
מותקן באמצעות אותו נתיב קוד שמשמש באתחול רגיל של נקודת ביקורת.
אם משתמשים במחזיק מפתחות ברמת מערכת הקבצים כדי לנהל מפתחות מוצפנים באמצעות אישורים (CE) ומפתחות מוצפנים באמצעות מכשיר (DE), המפתחות יאבדו אחרי שמבטלים את הטעינה של userdata
. כדי לאפשר שחזור של מפתח, כשמתקינים מפתח במחזיק מפתחות של מערכת קבצים, vold
מתקינים גם את אותו מפתח מסוג fscrypt-provisioning
במחזיק מפתחות ברמת הסשן. כשקוראים ל-init_user0
, vold
מתקין מחדש את המפתחות במחזיק המפתחות של מערכת הקבצים.
חזרה לאתחול קשיח
כדי לוודא שהפעלה רכה מחדש לא תשאיר את המכשיר במצב לא שמיש, Android 11 כולל מעבר חזרה להפעלה קשה מחדש שמופעלת כשמתקיים אחד מהתנאים הבאים:
- מכשיר לא מצליח להפעיל הפעלה רכה מחדש (כלומר,
sys.init.userspace_reboot.in_progress=1
) בתוך פסק זמן נתון. - תהליך לא מפסיק לפעול בתוך פרק זמן קצוב.
- הפעולה
/system/bin/vdc volume reset
נכשלת. - הסרת ההרכבה של מכשיר zRAM נכשלת.
- חבילת APEX פעילה מוסרת בצורה שגויה.
- ניסיון להרכיב מחדש את
userdata
במצב של יצירת נקודות ביקורת נכשל. - מכשיר לא מצליח לבצע אתחול (כלומר,
sys.boot_completed=1
) בתוך פסק זמן נתון.
הגדרה לכל מכשיר
אפשר לשנות את הערכים של המאפיינים הבאים כדי לשנות חלק מההיבטים של ההפעלה מחדש הרכה:
init.userspace_reboot.is_supported
קובע מתי מכשיר יכול לבצע הפעלה מחדש רכה. אם הערך של המאפיין הזה הואfalse
,0
או לא צוין, הניסיונות להפעלה מחדש יידחו.-
init.userspace_reboot.sigkill.timeoutmillis
שולט בערך הזמן הקצוב לתפוגה (timeout) במילישניות לתהליכים שקיבלו אותSIGKILL
להפסקה. אם אחד מהתהליכים לא מפסיק לפעול בפרק הזמן שמוגדר כטיימאוט, מופעלת חזרה לטעינה מחדש. -
init.userspace_reboot.sigterm.timeoutmillis
שולט בערך הזמן הקצוב לתפוגה (timeout) באלפיות השנייה (מילישניות) לתהליכים שקיבלו אותSIGTERM
לסיום. כל התהליכים שלא הסתיימו בפרק הזמן שצוין מקבלים אותSIGKILL
. -
init.userspace_reboot.started.timeoutmillis
קובע את הזמן הקצוב לתפוגה באלפיות השנייה עד להפעלה של החזרה לפעולה (כלומר,sys.init.userspace_reboot.in_progress=1
). אם המכשיר לא מצליח להפעיל את החזרה לפעולה בתוך הזמן הקצוב לתפוגה שצוין, מופעלת הפעלה מחדש. -
init.userspace_reboot.userdata_remount.timeoutmillis
קובע את הזמן הקצוב לתפוגה באלפיות השנייה לביטול הטעינה שלuserdata
. אם ניסיון להסרת אמצעי אחסון במכשירuserdata
נכשל בתוך הזמן הקצוב שנקבע, מופעלת חזרה לאיפוס קשיח. init.userspace_reboot.watchdog.timeoutmillis
קובעת את הזמן הקצוב לתפוגה (timeout) להפעלה מוצלחת של מכשיר (כלומר,sys.boot_completed=1
). אם מכשיר לא מופעל בזמן הקצוב לתפוגה שצוין, מופעלת חזרה לגיבוי של הפעלה מחדש.
התאמה אישית של האנימציה במהלך הפעלה מחדש רכה
ההטמעה לדוגמה של הפעלה מחדש רכה כוללת אפשרות להתאים אישית את האנימציה שמוצגת במהלך ההפעלה מחדש.
בסיום הפעולה userspace-reboot-fs-remount
, שירות bootanim
מתחיל.init
השירות הזה מחפש את קובצי האנימציה הבאים, בסדר שמופיע ברשימה, ומפעיל את הראשון שהוא מוצא:
/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip
אם לא מציינים קובצי אנימציה ספציפיים להפעלה רכה מחדש, מוצגת אנימציית ברירת המחדל android
.bootanim
בדיקה
Android 11 כולל הטמעה לדוגמה של הפעלה מחדש רכה. בנוסף, אפשר לאמת הפעלה מחדש רכה באמצעות בדיקות CTS ב-UserspaceRebootHostTest
.