החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
עדכוני מערכת ללא בדיקת A/B
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
עדכונים שאינם AB הם שיטת OTA מדור קודם שמשמשת מכשירים ישנים יותר של Android (Android 6 וגרסאות ישנות יותר). במכשירים האלה יש מחיצה ייעודית לשחזור שמכילה את התוכנה הדרושה כדי לפתוח את חבילת העדכון שהורדתם ולהחיל את העדכון על המחיצות האחרות.
במכשירי Android ישנים יותר ללא מחיצות A/B, נפח האחסון ב-Flash מכיל בדרך כלל את המחיצות הבאות:
- אתחול
-
מכיל את ליבה Linux ומערכת קבצים מינימלית ברמה הבסיסית (root) (המערכת נטענת בדיסק RAM). הוא מחבר את המערכת ומחיצות אחרות ומפעיל את סביבת זמן הריצה שנמצאת במחיצה של המערכת.
- מערכת
-
ספריות ואפליקציות מערכת שיש להן קוד מקור שזמין בפרויקט Android Open Source Project (AOSP). במהלך הפעולה הרגילה, המחיצה הזו מורכבת לקריאה בלבד, והתוכן שלה משתנה רק במהלך עדכון OTA.
- ספק
-
ספריות ואפליקציות מערכת שללא זמין להן קוד מקור בפרויקט Android Open Source Project (AOSP). במהלך הפעולה הרגילה, המחיצה הזו מורכבת לקריאה בלבד, והתוכן שלה משתנה רק במהלך עדכון OTA.
- userdata
-
כאן נשמרים הנתונים שנשמרו על ידי אפליקציות שהמשתמש התקין וכו'. בדרך כלל, תהליך העדכון ב-OTA לא נוגע למחיצה הזו.
- מטמון
-
אזור אחסון זמני שמשמש כמה אפליקציות (כדי לגשת למחיצה הזו נדרשות הרשאות מיוחדות לאפליקציות) ולאחסון חבילות עדכון OTA שהורדתם. תוכנות אחרות משתמשות במרחב הזה, מתוך הנחה שהקבצים יכולים להיעלם בכל שלב. התקנות של חבילות OTA מסוימות עלולות למחוק את המחיצה הזו לחלוטין. המטמון מכיל גם את יומני העדכונים מעדכון OTA.
- שחזור
-
מערכת Linux מלאה שנייה, כולל ליבה והקובץ הבינארי המיוחד לשחזור,
שמקריא חבילה ומשתמש בתוכן שלה כדי לעדכן את המחיצות האחרות.
- שונות
-
מחיצה זעירה שמשמשת את תהליך השחזור כדי לאחסן מידע מסוים על הפעולות שהוא מבצע, למקרה שהמכשיר יופעל מחדש בזמן החלת חבילת ה-OTA.
מחזור החיים של עדכון OTA
עדכון OTA אופייני כולל את השלבים הבאים:
-
המכשיר מבצע בדיקה שוטפת עם שרתי OTA ומקבל הודעה על זמינות של עדכון, כולל כתובת ה-URL של חבילת העדכון ומחרוזת תיאור שמוצגת למשתמש.
-
מעדכנים את ההורדות במטמון או במחיצה של נתונים, והחתימה הקריפטוגרפית שלהם מאומתת מול האישורים שב-
/system/etc/security/otacerts.zip. המשתמש מתבקש להתקין את העדכון.
-
המכשיר מופעל מחדש למצב שחזור, שבו הליבה והמערכת במחיצה לשחזור מאתחול במקום הליבה במחיצה לאתחול.
-
קובץ הבינארי של השחזור מופעל על ידי init. הוא מוצא ארגומנטים של שורת הפקודה ב-
/cache/recovery/command שמפנים אותו לחבילה שהורדתם.
-
התהליך של שחזור הנתונים מאמת את החתימה הקריפטוגרפית של החבילה באמצעות המפתחות הציבוריים שב-
/res/keys (חלק מדיסק ה-RAM שנמצא במחיצה של התהליך לשחזור).
-
הנתונים נשלפים מהחבילה ומשמשים לעדכון המחיצות של האתחול, המערכת ו/או הספק לפי הצורך. אחד מהקבצים החדשים שנותרו במחיצה של המערכת מכיל את התוכן של מחיצת השחזור החדשה.
-
המכשיר יופעל מחדש באופן תקין.
-
מחלצים את מחיצת האתחול המעודכנת, מחברים אותה ומתחילים להריץ קבצים בינאריים במחיצה המערכת המעודכנת.
-
כחלק מההפעלה הרגילה, המערכת בודקת את התוכן של מחיצת השחזור לעומת התוכן הרצוי (שאוחסן קודם בקובץ
/system). אם יש הבדל, מתבצע פלאש מחדש של מחיצת השחזור עם התוכן הרצוי. (בהפעלות הבאות, מחיצה לשחזור כבר מכילה את התוכן החדש, כך שאין צורך לבצע שחזור מחדש).
עדכון המערכת הושלם! יומני העדכונים נמצאים ב-/cache/recovery/last_log.#.
עדכון חבילות
חבילת עדכון היא קובץ .zip שמכיל את קובץ הבינארי להפעלה META-INF/com/google/android/update-binary. אחרי אימות החתימה על החבילה, recovery מחלץ את הקובץ הבינארי הזה אל /tmp ומריץ אותו, עם הארגומנטים הבאים:
-
עדכון מספר הגרסה של ה-API הבינארי אם הארגומנטים שהועברו ל-update משתנים, המספר הזה עולה.
-
מתאר הקובץ של צינור הפקודה. תוכנית העדכון יכולה להשתמש בצינור הזה כדי לשלוח פקודות בחזרה לקובץ הבינארי של התהליך לשחזור, בעיקר בשביל שינויים בממשק המשתמש, כמו ציון ההתקדמות למשתמש.
-
שם הקובץ
.zip של חבילת העדכון.
חבילת עדכון יכולה להשתמש בכל קובץ בינארי מקושר באופן סטטי כקובץ הבינארי של העדכון. הכלים ליצירת חבילות OTA משתמשים בתוכנית העדכון (bootable/recovery/updater), שמספקת שפת סקריפט פשוטה שיכולה לבצע משימות התקנה רבות. אפשר להחליף אותו בכל קובץ בינארי אחר שפועל במכשיר.
לפרטים על קובץ העדכון הבינארי, התחביר של edify והפונקציות המובנות, ראו Inside OTA Packages.
העברה מגרסאות קודמות
כשעוברים מגרסה של Android 2.3/3.0/4.0, השינוי העיקרי הוא ההמרה של כל הפונקציונליות הספציפית למכשיר מקבוצה של פונקציות C עם שמות מוגדרים מראש לאובייקטים של C++.
בטבלה הבאה מפורטות הפונקציות הישנות והשיטות החדשות שמטרתן דומה:
| פונקציית C |
שיטה ב-C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(וגם RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
המרת פונקציות ישנות לשיטות חדשות אמורה להיות פשוטה יחסית. חשוב לא לשכוח להוסיף את הפונקציה החדשה make_device() כדי ליצור מכונה של המשנה החדשה של Device ולהחזיר אותה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
