שאלות נפוצות

האם גוגל השתמשה ב-A/B OTA במכשירים כלשהם?

כן. השם השיווקי של עדכוני A/B הוא עדכונים חלקים . טלפונים Pixel ו-Pixel XL מאוקטובר 2016 נשלחו עם A/B, וכל מכשירי ה-Chromebook משתמשים באותה יישום update_engine של A/B. יישום קוד הפלטפורמה הדרוש הוא ציבורי באנדרואיד 7.1 ומעלה.

מדוע A/B OTAs טובים יותר?

A/B OTAs מספקים חווית משתמש טובה יותר בעת קבלת עדכונים. מדידות של עדכוני אבטחה חודשיים מראות שהתכונה הזו כבר הוכיחה את עצמה כהצלחה: נכון למאי 2017, 95% מבעלי ה-Pixel מריצים את עדכון האבטחה האחרון לאחר חודש לעומת 87% ממשתמשי Nexus, ומשתמשי Pixel מתעדכנים מוקדם יותר ממשתמשי Nexus. כשלים בעדכון בלוקים במהלך OTA כבר לא מביאים למכשיר שלא יאתחל; עד שתמונת המערכת החדשה לאתחל בהצלחה, אנדרואיד שומרת על היכולת לחזור לתמונת המערכת הקודמת.

כיצד השפיע A/B על גדלי מחיצות ה-Pixel 2016?

הטבלה הבאה מכילה פרטים על תצורת A/B למשלוח לעומת תצורה שאינה A/B שנבדקה פנימית:

עדכוני A/B דורשים עלייה של 320 MiB בלבד ב-Flash, עם חיסכון של 32MiB מהסרת מחיצת השחזור ועוד 100MiB נשמר על ידי הסרת מחיצת המטמון. זה מאזן את העלות של מחיצות B עבור טוען האתחול, מחיצת האתחול ומחיצת הרדיו. מחיצת הספק הכפילה את גודלה (הרוב המכריע של הגדלה). תמונת מערכת ה-A/B של Pixel היא חצי מהגודל של תמונת המערכת המקורית שאינה A/B.

עבור גרסאות Pixel A/B ולא-A/B שנבדקו באופן פנימי (רק A/B נשלח), השטח שנעשה בו שימוש שונה ב-320MiB בלבד. במכשיר 32GiB, זה קצת פחות מ-1%. עבור מכשיר 16GiB זה יהיה פחות מ-2%, ולמכשיר 8GiB כמעט 4% (בהנחה שלכל שלושת המכשירים הייתה אותה תמונת מערכת).

למה לא השתמשת ב-SquashFS?

ניסינו עם SquashFS אך לא הצלחנו להשיג את הביצועים הרצויים עבור מכשיר מתקדם. אנחנו לא משתמשים או ממליצים על SquashFS עבור מכשירים כף יד.

ליתר דיוק, SquashFS סיפקה חיסכון של כ-50% בגודל במחיצת המערכת, אך הרוב המכריע של הקבצים שנדחסו היטב היו קובצי ה-.odex שהוקומפו מראש. לקבצים האלה היו יחסי דחיסה גבוהים מאוד (התקרבו ל-80%), אך יחס הדחיסה עבור שאר מחיצת המערכת היה נמוך בהרבה. בנוסף, SquashFS באנדרואיד 7.0 העלה את חששות הביצועים הבאים:

• ל-Pixel יש הבזק מהיר מאוד בהשוואה למכשירים קודמים, אך לא מספר עצום של מחזורי מעבד פנויים, כך שקריאת פחות בתים מ-Flash אך צורך ביותר מעבד ל-I/O היה צוואר בקבוק פוטנציאלי.
• שינויים ב-I/O שמבצעים ביצועים טובים ב-benchmark מלאכותי על מערכת לא נטענת, לפעמים לא עובדים טוב במקרים של שימוש בעולם האמיתי בעומס בעולם האמיתי (כגון קריפטו ב-Nexus 6).
• בנצ'מרקינג הראו רגרסיות של 85% במקומות מסוימים.

ככל ש-SquashFS מתבגר ומוסיף תכונות להפחתת השפעת ה-CPU (כגון רשימת הלבנים של קבצים נפוצים שאסור לדחוס אותם), נמשיך להעריך אותו ולהציע המלצות ליצרני המכשירים.

איך הפחתת את גודל מחיצת המערכת ללא SquashFS?

יישומים מאוחסנים בקבצי .apk, שהם למעשה ארכיוני ZIP. כל קובץ apk מכיל בתוכו קובץ .dex אחד או יותר המכילים קוד בתים Dalvik נייד. קובץ .odex (מותאם .dex) חי בנפרד מקובץ .apk ויכול להכיל קוד מכונה ספציפי למכשיר. אם קובץ .odex זמין, אנדרואיד יכולה להריץ יישומים במהירויות קומפילציה מראש מבלי להמתין להידור הקוד בכל פעם שהאפליקציה מופעלת. קובץ .odex אינו הכרחי לחלוטין: אנדרואיד יכול למעשה להריץ את קוד ה-.dex ישירות באמצעות פרשנות או קומפילציה של Just-In-Time (JIT), אך קובץ .odex מספק את השילוב הטוב ביותר של מהירות השקה ומהירות ריצה אם מקום פנוי.

דוגמה: עבור installed-files.txt מ-Nexus 6P עם אנדרואיד 7.1 עם גודל תמונת מערכת כולל של 2628MiB (2755792836 בתים), הפירוט של התורמים הגדולים ביותר לגודל תמונת המערכת הכולל לפי סוג קובץ הוא כדלקמן:

נתונים אלה דומים גם עבור מכשירים אחרים, כך שבמכשירי Nexus/Pixel, קבצי .odex תופסים כמחצית ממחיצת המערכת. משמעות הדבר היא שנוכל להמשיך להשתמש ב-ext4 אך לכתוב את קבצי .odex למחיצת B במפעל ולאחר מכן להעתיק אותם אל /data באתחול הראשון. האחסון בפועל בשימוש עם ext4 A/B זהה ל-SquashFS A/B, מכיוון שאם היינו משתמשים ב-SquashFS היינו שולחים את קבצי ה-.odex המוגדרים מראש על system_a במקום system_b.

האם העתקת קובצי .odex אל /data אינה אומרת שהשטח שנשמר ב- /system אובד ב- /data?

לא בדיוק. ב-Pixel, רוב המקום שקובצי .odex תופסים מיועד לאפליקציות, שקיימות בדרך כלל ב- /data . יישומים אלה מקבלים עדכונים של Google Play, כך שקובצי ה-.apk ו-.odex בתמונת המערכת אינם בשימוש במשך רוב חיי המכשיר. ניתן להוציא קבצים כאלה לחלוטין ולהחליפם בקבצי .odex קטנים, מונעי פרופיל, כאשר המשתמש באמת משתמש בכל אפליקציה (ולכן לא דורש מקום לאפליקציות שהמשתמש אינו משתמש בהן). לפרטים, עיין בהרצאה של Google I/O 2016 The Evolution of Art .

ההשוואה קשה מכמה סיבות עיקריות:

• לאפליקציות שעודכנו על ידי Google Play תמיד היו קבצי .odex ב- /data ברגע שהם מקבלים את העדכון הראשון.
• אפליקציות שהמשתמש אינו מפעיל אינן זקוקות לקובץ .odex כלל.
• קומפילציה מונעת פרופיל מייצרת קובצי .odex קטנים יותר מאשר קומפילציה מוקדמת (מכיוון שהראשון מייעל רק קוד קריטי לביצועים).

לפרטים על אפשרויות הכוונון הזמינות ליצרני OEM, ראה הגדרת ART .

האם אין שני עותקים של קבצי .odex ב-/data?

זה קצת יותר מסובך... אחרי שתמונת המערכת החדשה נכתבה, הגרסה החדשה של dex2oat מופעלת מול קבצי ה-.dex החדשים כדי ליצור את קבצי ה-.odex החדשים. זה מתרחש בזמן שהמערכת הישנה עדיין פועלת, כך שקובצי ה-.odex הישנים והחדשים נמצאים שניהם ב- /data בו-זמנית.

הקוד ב-OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) קורא getAvailableSpace לפני ביצוע אופטימיזציה של כל חבילה כדי למנוע מילוי יתר של /data . שים לב שזמין כאן הוא עדיין שמרני: זה כמות השטח שנותר לפני פגיעה בסף המרחב הנמוך הרגיל של המערכת (נמדד גם באחוז וגם בספירת בתים). אז אם /data מלא, לא יהיו שני עותקים של כל קובץ .odex. לאותו קוד יש גם BULK_DELETE_THRESHOLD: אם המכשיר מתקרב כל כך למילוי השטח הפנוי (כפי שתואר זה עתה), קובצי ה-.odex השייכים לאפליקציות שאינן בשימוש יוסרו. זה עוד מקרה ללא שני עותקים של כל קובץ .odex.

במקרה הגרוע ביותר בו /data מלא לחלוטין, העדכון ממתין עד שהמכשיר יאתחל מחדש במערכת החדשה ואינו זקוק עוד לקבצי ה-.odex של המערכת הישנה. ה-PackageManager מטפל בזה: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). לאחר אתחול המערכת החדשה בהצלחה, installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) יכולה להסיר את קבצי ה-.odex ששימשו את המערכת הישנה, ​​ולהחזיר את ההתקן למצב יציב שבו יש רק עותק אחד.

לכן, למרות שזה אפשרי ש- /data מכיל שני עותקים של כל קבצי ה-odex, (א) זה זמני ו-(ב) מתרחש רק אם בכל מקרה היה לך הרבה מקום פנוי ב- /data . למעט במהלך עדכון, יש רק עותק אחד. וכחלק מתכונות החוסן הכלליות של ART, הוא לעולם לא ימלא /data בקבצי .odex בכל מקרה (מכיוון שזו תהיה בעיה גם במערכת שאינה A/B).

האם כל הכתיבה/העתקה הזו לא מגבירה את שחיקת הבזק?

רק חלק קטן מהפלאש נכתב מחדש: עדכון מערכת Pixel מלא כותב על 2.3GiB. (גם יישומים מקומפלטים מחדש, אבל זה נכון גם לגבי לא-A/B.) באופן מסורתי, OTAs מלאים מבוססי בלוק כתבו כמות דומה של נתונים, כך ששיעורי הבלאי בלאי צריכים להיות דומים.

האם מהבהב של שתי מחיצות מערכת מגדיל את זמן ההבהוב של היצרן?

לא. Pixel לא גדל בגודל תמונת המערכת (הוא רק חילק את החלל על פני שתי מחיצות).

האם שמירת קבצי .odex ב-B לא הופכת את האתחול מחדש לאחר איפוס נתוני היצרן לאט?

כן. אם באמת השתמשת במכשיר, לקחת OTA וביצעת איפוס לנתוני היצרן, האתחול הראשון יהיה איטי יותר ממה שהיה קורה אחרת (1m40s לעומת 40s ב-Pixel XL) מכיוון שקובצי ה-odex יאבדו מ B לאחר ה-OTA הראשון ולכן לא ניתן להעתיקו אל /data . זה הפשרה.

איפוס נתוני היצרן אמור להיות פעולה נדירה בהשוואה לאתחול רגיל, כך שהזמן שלוקח פחות חשוב. (זה לא משפיע על משתמשים או סוקרים שמקבלים את המכשיר שלהם מהמפעל, כי במקרה כזה מחיצת B זמינה.) השימוש במהדר JIT אומר שאנחנו לא צריכים להדר מחדש הכל , אז זה לא רע כמוך עלול לחשוב. אפשר גם לסמן אפליקציות כדורשות קומפילציה מראש באמצעות coreApp="true" במניפסט: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). זה נמצא כעת בשימוש על ידי system_server מכיוון שהוא אינו מורשה JIT מסיבות אבטחה.

האם שמירת קבצי .odex ב-/data ולא ב-/system הופכת את האתחול מחדש לאחר OTA לאיטי?

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

האם (האם) אנחנו יכולים לשלוח מכשיר 32GiB A/B? 16GiB? 8GiB?

32GiB עובד היטב כפי שהוכח ב-Pixel, ו-320MiB מתוך 16GiB פירושו הפחתה של 2%. באופן דומה, 320MiB מתוך 8GiB הפחתה של 4%. ברור ש-A/B לא תהיה הבחירה המומלצת במכשירים עם 4GiB, שכן התקורה של 320MiB היא כמעט 10% מסך השטח הזמין.

האם AVB2.0 דורש A/B OTAs?

לא. Android Verified Boot תמיד דרש עדכונים מבוססי בלוק, אך לא בהכרח עדכוני A/B.

האם A/B ​​OTAs דורשים AVB2.0?

לא.

האם A/B ​​OTAs שוברים את הגנת החזרה לאחור של AVB2.0?

לא. יש כאן קצת בלבול מכיוון שאם מערכת A/B לא מצליחה לאתחל לתוך תמונת המערכת החדשה, היא תחזור (לאחר מספר נסיונות חוזרים שנקבעו על ידי טוען האתחול שלך) אוטומטית לתמונת המערכת ה"קודמת". נקודת המפתח כאן היא ש"קודם" במובן A/B הוא למעשה עדיין תמונת המערכת ה"נוכחית". ברגע שהמכשיר מאתחל בהצלחה תמונה חדשה, הגנת גלגול חוזרת נכנסת ומבטיחה שלא תוכל לחזור אחורה. אבל עד שלא אתחול בהצלחה את התמונה החדשה, הגנת החזרה לא מחשיבה אותה כתמונת המערכת הנוכחית.

אם אתה מתקין עדכון בזמן שהמערכת פועלת, זה לא איטי?

עם עדכונים שאינם A/B, המטרה היא להתקין את העדכון במהירות האפשרית מכיוון שהמשתמש ממתין ואינו יכול להשתמש במכשיר שלו בזמן שהעדכון מוחל. עם עדכוני A/B, ההיפך הוא הנכון; מכיוון שהמשתמש עדיין משתמש במכשיר שלו, כמה שפחות השפעה היא המטרה, ולכן העדכון איטי בכוונה. באמצעות היגיון בלקוח עדכון המערכת של Java (שעבור גוגל הוא GmsCore, חבילת הליבה שמספקת GMS), גם אנדרואיד מנסה לבחור זמן שבו המשתמשים אינם משתמשים במכשיריהם כלל. הפלטפורמה תומכת בהשהיית/חידוש העדכון, והלקוח יכול להשתמש בזה כדי להשהות את העדכון אם המשתמש מתחיל להשתמש במכשיר ולחדש אותו כשהמכשיר שוב לא פעיל.

ישנם שני שלבים בעת נטילת OTA, המוצגים בבירור בממשק המשתמש כשלב 1 מתוך 2 ושלב 2 מתוך 2 מתחת לסרגל ההתקדמות. שלב 1 מתכתב עם כתיבת בלוקי הנתונים, בעוד ששלב 2 הוא הידור מקדים של קובצי ה-.dex. שני השלבים הללו שונים למדי מבחינת השפעת הביצועים. השלב הראשון הוא I/O פשוט. זה דורש מעט משאבים (RAM, CPU, I/O) מכיוון שהוא פשוט מעתיק לאט בלוקים מסביב.

השלב השני מריץ את dex2oat כדי להדר מראש את תמונת המערכת החדשה. ברור שיש לזה גבולות פחות ברורים לגבי הדרישות שלו מכיוון שהוא מרכיב אפליקציות בפועל. וברור שיש הרבה יותר עבודה כרוכה בהידור של אפליקציה גדולה ומורכבת מאשר אפליקציה קטנה ופשוטה; ואילו בשלב 1 אין בלוקים של דיסקים גדולים או מורכבים יותר מאחרים.

התהליך דומה לשלב שבו Google Play מתקין עדכון אפליקציה ברקע לפני הצגת 5 האפליקציות המעודכנות , כפי שנעשה כבר שנים.

מה אם משתמש באמת מחכה לעדכון?

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

מה קורה אם יש כשל בהחלת עדכון?

עם עדכונים שאינם A/B, אם עדכון לא הצליח להחיל, המשתמש נשאר בדרך כלל עם מכשיר לא שמיש. החריג היחיד היה אם התקלה התרחשה לפני שהאפליקציה בכלל התחילה (מכיוון שהחבילה לא הצליחה לאמת, למשל). עם עדכוני A/B, כשל בהחלת עדכון אינו משפיע על המערכת הפועלת כעת. ניתן פשוט לנסות מחדש את העדכון מאוחר יותר.

אילו מערכות בשבב (SoCs) תומכות ב-A/B?

החל מ-2017-03-15, יש לנו את המידע הבא:

לפרטים על לוחות זמנים, בדוק עם אנשי הקשר שלך ב-SoC. עבור SoCs שאינם מופיעים למעלה, פנה ישירות ל-SoC שלך.