קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כדי להטמיע את העדכונים האלחוטיים (OTA), תוכנת האתחול צריכה לקבל גישה לדיסק RAM לשחזור במהלך האתחול. אם במכשיר נעשה שימוש בתמונת שחזור AOSP ללא שינוי, תוכנת האתחול קוראת את 32 הבייטים הראשונים במחיצה misc. אם הנתונים תואמים ל-boot-recovery, תוכנת האתחול תפעיל את קובץ האימג' recovery. השיטה הזו מאפשרת להמשיך את כל פעולות השחזור בהמתנה (למשל, החלת עדכון OTA או הסרת נתונים) עד להשלמתן.
כדי לתמוך בעדכוני OTA במכשירים שמשתמשים בעדכוני A/B, צריך לוודא שתוכנת האתחול של המכשיר עומדת בקריטריונים הבאים.
קריטריונים כלליים
כל המחיצות שעודכנו באמצעות OTA אמורות להיות ניתנות לעדכון בזמן שהמערכת הראשית מופעלת (ולא מתעדכנות במצב שחזור).
כדי לאתחל את המחיצה system, מנהל האתחול מעביר את הערך הבא בשורת הפקודה של הליבה: ro root=/dev/[node] rootwait init=/init.
הקריאה ל-markBootSuccessful מ-HAL היא באחריות מסגרת Android. תוכנת האתחול אף פעם לא אמורה לסמן מחיצה כהפעלה מוצלחת.
תמיכה ב-HAL לבקרת אתחול
מנהל האתחול חייב לתמוך ב-HAL של boot_control כפי שמוגדר ב-hardware/libhardware/include/hardware/boot_control.h. העדכן שולח שאילתה ל-boot control HAL, מעדכן את חריץ האתחול שלא בשימוש, משנה את החריץ הפעיל באמצעות ה-HAL ומפעיל מחדש את מערכת ההפעלה המעודכנת. פרטים נוספים זמינים במאמר הטמעת HAL לבקרת אתחול.
תמיכה בחריגות
מנהל האתחול חייב לתמוך בפונקציונליות שקשורה למחיצות ולתאים, כולל:
שמות המחיצות חייבים לכלול סיומת שמזהה את המחיצות ששייכות למק"ט מסוים. לכל מחיצה כזו יש משתנה תואם has-slot:partition base name עם הערך yes. השמות של התחנות מתחילים באותיות האלפבית, a, b, c וכו', בהתאם למחיצות עם הסיומת _a, _b, _c וכו'. תוכנת האתחול צריכה להודיע למערכת ההפעלה איזו תחנה הופעל באמצעות מאפיין שורת הפקודה androidboot.slot_suffix. המאפיין הזה מוגדר דרך bootconfig במכשירים שמריצים Android מגרסה 12 ואילך.
הערך של slot-retry-count מתאפס לערך חיובי (בדרך כלל 3), על ידי HAL לבקרת האתחול דרך הקריאה החוזרת (callback) setActiveBootSlot או דרך הפקודה fastboot set_active. כשמשנים מחיצה שנכללת בחריץ, תוכנת האתחול מנקה את הסטטוס 'הפעלה מוצלחת' ומאפסת את מספר הניסיונות החוזרים באותו חריץ.
תוכנת האתחול צריכה גם לקבוע איזה חריץ לטעון. באיור מוצגת דוגמה לתהליך קבלת החלטות.
איור 1. תהליך הקצאת שטחי פרסום ב-Bootloader
קובעים באיזה חריץ לנסות. אין לנסות לטעון חריץ שמסומן ב-slot-unbootable. החריץ הזה צריך להיות עקבי עם הערכים שמוחזרים על ידי fastboot, והוא נקרא 'החריץ הנוכחי'.
אם השקע הנוכחי לא מסומן כ-slot-successful ויש בו slot-retry-count = 0, מסמנים את השקע הנוכחי כ-slot-unbootable. לאחר מכן בוחרים יחידת קיבולת אחרת שלא מסומנת ב-unbootable ומסומנת ב-slot-successful. יחידת הקיבולת הזו תהיה עכשיו היחידה שנבחרה. אם אין חריץ זמין, צריך להפעיל את המכשיר במצב שחזור או להציג למשתמש הודעת שגיאה משמעותית.
בוחרים את boot.img המתאים ומצרפים את הנתיב למחיצה הנכונה של המערכת בשורת הפקודה של הליבה.
מאכלסים את הפרמטר slot_suffix בשורת הפקודה של הליבה.
אתחול. אם הוא לא מסומן ב-slot-successful, מפחיתים את slot-retry-count.
הכלי fastboot קובע איזו מחיצה יהיה צריך לבצע בה את הפעולה 'פלאש' כשמריצים פקודות פלאש. לדוגמה, כשמריצים את הפקודה fastboot flash system system.img, קודם שולחים שאילתה למשתנה current-slot ואז מקשרים את התוצאה למערכת כדי ליצור את השם של המחיצה שצריך לבצע בה את הפעולה של מחיקת הנתונים והוספת נתונים מחדש (system_a, system_b וכו').
כשמגדירים את החריץ הנוכחי באמצעות הפקודה set_active של fastboot או הפקודה setActiveBootSlot של HAL לבקרת אתחול, מנהל האתחול אמור לעדכן את החריץ הנוכחי, למחוק את slot-unbootable ואת slot-successful ולאפס את מספר הניסיונות החוזרים (זו הדרך היחידה למחוק את slot-unbootable).
מכשירים ללא עדכוני A/B
כדי לתמוך בעדכוני OTA במכשירים שלא משתמשים בעדכוני A/B (ראו מכשירים שלא ניתן לעדכן באמצעות A/B), צריך לוודא שה-bootloader של המכשיר עומד בקריטריונים הבאים.
המחיצה recovery צריכה להכיל קובץ אימג' שיכול לקרוא קובץ אימג' של מערכת ממחיצה נתמכת כלשהי (cache, userdata) ולכתוב אותו במחיצה system.
תוכנת האתחול אמורה לתמוך בהפעלה ישירה למצב שחזור.
אם יש תמיכה בעדכוני קובצי אימג' של הרדיו, אפשר גם להשתמש במחיצה recovery כדי להפעיל את הרדיו. אפשר לעשות זאת באחת משתי דרכים:
תוכנת האתחול מאתחלת את הרדיו. במקרה כזה, אמורה להיות אפשרות להפעיל מחדש את המכשיר ממחיקת השחזור חזרה ל-bootloader כדי להשלים את העדכון.
קובץ האימג' לשחזור מפעיל את הרדיו. אפשר לספק את הפונקציונליות הזו בתור ספרייה בינארית או כלי שימושי.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Implement OTA updates\n\nTo implement the [over-the-air (OTA) updates](/docs/core/ota), the\nbootloader must be able to access a recovery RAM disk during boot. If the device\nuses an unmodified AOSP recovery image, the bootloader reads the first 32 bytes\non the `misc` partition; if the data there matches `boot-recovery`, the\nbootloader boots into the `recovery` image. This method enables any pending\nrecovery work (for example, applying an OTA or removing data) to continue to\ncompletion.\n\nFor details on the content of a block in flash used for communications by\nrecovery and the bootloader, refer to\n[bootable/recovery/bootloader_message/bootloader_message.h](https://android.googlesource.com/platform/bootable/recovery/+/android16-release/bootloader_message/include/bootloader_message/bootloader_message.h#64).\n\nDevices with A/B updates\n------------------------\n\nTo support OTA updates on devices that use [A/B\nupdates](/docs/core/ota/ab), ensure that the device bootloader meets\nthe following criteria.\n\n### General criteria\n\n- All partitions updated through an OTA should be updatable while the main\n system is booted (and not updated in recovery).\n\n- To boot the `system` partition, the bootloader passes the following value on\n kernel command line: `ro root=/dev/[node] rootwait init=/init`.\n\n- It's the responsibility of the Android framework to call `markBootSuccessful`\n from the HAL. The bootloader should never mark a partition as successfully\n booted.\n\n### Support for boot control HAL\n\nThe bootloader must support the `boot_control` HAL as defined in\n`hardware/libhardware/include/hardware/boot_control.h`. The updater queries the\n[boot control\nHAL](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/boot/1.0/IBootControl.hal),\nupdates the boot slot not in use, changes the active slot using the\nHAL, and reboots into the updated operating system. For details, see\n[Implementing the boot control\nHAL](/docs/core/ota/ab/ab_implement#bootcontrol).\n\n### Support for slots\n\nThe bootloader must support functionality related to partitions and slots,\nincluding:\n\n- Partition names must include a suffix that identifies which partitions\n belong to a particular slot in the bootloader. For each such partition,\n there's a corresponding variable\n `has-slot:`\u003cvar translate=\"no\"\u003epartition base name\u003c/var\u003e with a value of\n `yes`. Slots are named alphabetically as a, b, c, etc. corresponding to\n partitions with the suffix `_a`, `_b`, `_c`, etc. The bootloader should inform\n the operating system which slot was booted using the command line property\n `androidboot.slot_suffix`. This property is set through bootconfig for devices\n launching with Android 12 or higher.\n\n- The `slot-retry-count` value is reset to a positive value (usually `3`),\n either by the boot control HAL through the `setActiveBootSlot` callback or\n through the `fastboot set_active` command. When modifying a partition that's\n part of a slot, the bootloader clears \"successfully booted\" and resets the\n retry count for the slot.\n\nThe bootloader should also determine which slot to load. The figure shows an\nexample decision process.\n**Figure 1.** Bootloader slotting flow\n\n1. Determine which slot to attempt. Don't attempt to load a slot marked\n `slot-unbootable`. This slot should be consistent with the values returned by\n fastboot, and is referred to as the current slot.\n\n2. If the current slot isn't marked as `slot-successful` and has a\n `slot-retry-count = 0`, mark the current slot as `slot-unbootable`. Then\n select a different slot that is not marked `unbootable` and is marked as\n `slot-successful`; this slot is now the selected slot. If no current slot is\n available, boot to recovery or display a meaningful error message to the\n user.\n\n3. Select the appropriate `boot.img` and include the path to correct system\n partition on the kernel command line.\n\n4. Populate the kernel command line `slot_suffix` parameter.\n\n5. Boot. If not marked `slot-successful`, decrement `slot-retry-count`.\n\nThe `fastboot` utility determines which partition to flash when running any\nflash commands. For example, running the `fastboot flash system system.img`\ncommand first queries the `current-slot` variable then concatenates the result\nto system to generate the name of the partition that should be flashed\n(`system_a`, `system_b`, etc.).\n\nWhen setting the current slot using the fastboot `set_active` command or the\nboot control HAL `setActiveBootSlot` command, the bootloader should update\nthe current slot, clear `slot-unbootable` and `slot-successful`, and reset the\nretry count (this is the only way to clear `slot-unbootable`).\n\nDevices without A/B updates\n---------------------------\n\nTo support OTA updates on devices that don't use A/B updates (see [Non-A/B\nupdatable devices](/docs/core/ota/nonab)), ensure that the device\nbootloader meets the following criteria.\n\n- The `recovery` partition should contain an image that is capable of reading a\n system image from some supported partition (`cache`, `userdata`) and writing\n it to the `system` partition.\n\n- The bootloader should support booting directly into recovery mode.\n\n- If radio image updates are supported, the `recovery` partition should also be\n able to flash the radio. This can be accomplished in one of two ways:\n\n - The bootloader flashes the radio. In this case, it should be possible to\n reboot from the recovery partition back into the bootloader to complete the\n update.\n\n - The recovery image flashes the radio. This functionality can be provided as\n a binary library or utility."]]
