Android 11 תומך בהפעלות מחדש עם יכולת שחזור,
הפעלות מחדש של תהליכים בזמן הריצה במרחב המשתמש, המשמשים להחלת עדכונים
מחייבת הפעלה מחדש (לדוגמה, עדכונים לחבילות APEX). כרגע, רך
ההפעלה מחדש מוגבלת לתהליכים שהתחילו אחרי הטעינה של userdata
.
נדרשת הפעלה מחדש עם יכולת שחזור בדרכים הבאות:
החל מ-
PowerManager
, באמצעות שיחהPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
מהמעטפת, באמצעות
adb shell svc power reboot userspace
אוadb reboot userspace
לאחר הפעלה מחדש עם יכולת שחזור, האחסון המוצפן של פרטי הכניסה יישאר לא נעול.
אם מכשיר תומך בהפעלות מחדש עם יכולת שחזור,
שיטת ה-API PowerManager.isRebootingUserspace()
מחזירה את הערך 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
.מזלגת נפרדת
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 פעילות.
- חזרה למרחב השמות של טעינת bootrap.
- מפעיל את
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
.חסימה של שלב ביקורת (checkpoint) (לדוגמה,
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
שולט/ת בזמן הקצוב לתפוגה בעוד אלפיות שנייה עבור תהליכים שקיבלו אותSIGKILL
כדי להפסיק. אם אחד מ- התהליכים לא עוצרים בזמן הזמן הקצוב הנתון, ואז חוזרים למצב קשיח מופעלת מחדש.init.userspace_reboot.sigterm.timeoutmillis
שולט/ת בזמן הקצוב לתפוגה בעוד אלפיות השנייה עבור תהליכים שקיבלו אות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
שולטת בזמן הקצוב לתפוגה של במכשיר לאתחול בהצלחה (כלומר,sys.boot_completed=1
). אם מכשיר לא ניתן להפעיל את המכשיר בתוך פרק הזמן הקצוב לתפוגה, כחלופה להפעלה קשיחה מחדש מופעל.
התאמה אישית של האנימציה במהלך הפעלה מחדש עם יכולת שחזור
הטמעת קובץ העזר של הפעלה מחדש עם יכולת שחזור כוללת יכולת להתאים אישית אנימציה שמוצגת במהלך ההפעלה מחדש הרכה.
בסוף הפעולה userspace-reboot-fs-remount
, init
יתחיל
שירות bootanim
. השירות הזה מחפש את הקיום של
קובצי אנימציה, לפי הסדר שבו הם רשומים, ומפעיל את הקובץ הראשון שהיא מוצאת:
/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip
אם לא הוגדרו קובצי אנימציה מסוימים עם הפעלה מחדש עם יכולת שחזור, bootanim
יציג
אנימציית android
שמוגדרת כברירת מחדל.
בדיקה
ב-Android 11 יש קובצי עזר להטמעת
הפעלה מחדש עם יכולת שחזור. בנוסף, ניתן לאמת הפעלה מחדש עם יכולת שחזור באמצעות CTS
בדיקות ב:
UserspaceRebootHostTest