از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
به روز رسانی سیستم غیر A/B
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
به‌روزرسانی‌های غیر AB یک روش OTA منسوخ است که توسط دستگاه‌های Android قدیمی (Android 6 و نسخه‌های قبلی‌تر) استفاده می‌شود. این دستگاه‌ها دارای یک پارتیشن بازیابی اختصاصی هستند که شامل نرم‌افزار مورد نیاز برای بازکردن بسته به‌روزرسانی دانلود شده و اعمال به‌روزرسانی روی پارتیشن‌های دیگر است.
در دستگاه‌های اندرویدی قدیمی‌تر بدون پارتیشن A/B، فضای فلش معمولاً شامل پارتیشن‌های زیر است:
- چکمه
- حاوی هسته لینوکس و حداقل سیستم فایل ریشه (بارگذاری شده در دیسک RAM) است. سیستم و پارتیشن‌های دیگر را سوار می‌کند و زمان اجرا واقع در پارتیشن سیستم را شروع می‌کند.
- سیستم
- شامل برنامه‌ها و کتابخانه‌های سیستمی است که دارای کد منبع در پروژه منبع باز Android (AOSP) هستند. در طول عملیات عادی، این پارتیشن فقط خواندنی نصب می شود. محتویات آن فقط در طول به روز رسانی OTA تغییر می کند.
- فروشنده
- شامل برنامه‌ها و کتابخانه‌های سیستمی است که کد منبع موجود در پروژه منبع باز Android (AOSP) را ندارند . در طول عملیات عادی، این پارتیشن فقط خواندنی نصب می شود. محتویات آن فقط در طول به روز رسانی OTA تغییر می کند.
- داده های کاربر
- داده های ذخیره شده توسط برنامه های نصب شده توسط کاربر و غیره را ذخیره می کند. این پارتیشن معمولاً توسط فرآیند به روز رسانی OTA لمس نمی شود.
- حافظه پنهان
- منطقه نگهداری موقت که توسط چند برنامه استفاده می شود (دسترسی به این پارتیشن به مجوزهای ویژه برنامه نیاز دارد) و برای ذخیره بسته های به روز رسانی OTA دانلود شده. برنامه های دیگر از این فضا با این انتظار استفاده می کنند که فایل ها می توانند در هر زمان ناپدید شوند. برخی از نصب های بسته OTA ممکن است منجر به پاک شدن کامل این پارتیشن شود. کش همچنین شامل گزارش‌های به‌روزرسانی از یک به‌روزرسانی OTA است.
- بهبود
- شامل دومین سیستم کامل لینوکس، شامل یک هسته و باینری بازیابی ویژه است که یک بسته را می خواند و از محتویات آن برای به روز رسانی پارتیشن های دیگر استفاده می کند.
- متفرقه
- پارتیشن کوچکی که توسط بازیابی برای مخفی کردن برخی از اطلاعات در مورد کارهایی که انجام می دهد در صورت راه اندازی مجدد دستگاه در حین اعمال بسته OTA استفاده می شود.
زندگی یک به روز رسانی OTA
یک به روز رسانی معمولی OTA شامل مراحل زیر است:
- دستگاه بررسی منظم را با سرورهای OTA انجام می دهد و از در دسترس بودن به روز رسانی، از جمله URL بسته به روز رسانی و یک رشته توضیحات برای نشان دادن به کاربر مطلع می شود.
- دانلودها را به حافظه پنهان یا پارتیشن داده به‌روزرسانی کنید و امضای رمزنگاری آن در برابر گواهی‌های موجود در
/system/etc/security/otacerts.zip تأیید می‌شود. از کاربر خواسته می شود که به روز رسانی را نصب کند. - دستگاه به حالت بازیابی مجدد راه اندازی می شود، که در آن هسته و سیستم در پارتیشن بازیابی به جای هسته در پارتیشن بوت بوت می شوند.
- باینری بازیابی توسط init شروع می شود. آرگومان های خط فرمان را در
/cache/recovery/command پیدا می کند که آن را به بسته دانلود شده هدایت می کند. - Recovery امضای رمزنگاری بسته را در برابر کلیدهای عمومی در
/res/keys (بخشی از دیسک RAM موجود در پارتیشن بازیابی) تأیید می کند. - داده ها از بسته خارج می شوند و در صورت لزوم برای به روز رسانی بوت، سیستم و/یا پارتیشن های فروشنده استفاده می شوند. یکی از فایل های جدید باقی مانده در پارتیشن سیستم حاوی محتویات پارتیشن بازیابی جدید است.
- دستگاه به طور معمول راه اندازی مجدد می شود.
- پارتیشن بوت به‌روزرسانی شده بارگیری می‌شود، و نصب می‌شود و اجرای باینری‌ها را در پارتیشن سیستم به‌روزرسانی‌شده جدید آغاز می‌کند.
- به عنوان بخشی از راه اندازی عادی، سیستم محتویات پارتیشن بازیابی را در برابر محتویات مورد نظر (که قبلاً به عنوان یک فایل در
/system ذخیره می شد) بررسی می کند. آنها متفاوت هستند، بنابراین پارتیشن بازیابی با محتوای مورد نظر دوباره فلش می شود. (در بوت های بعدی، پارتیشن بازیابی از قبل حاوی محتویات جدید است، بنابراین نیازی به reflash نیست.)
به روز رسانی سیستم کامل شد! گزارش‌های به‌روزرسانی را می‌توانید در /cache/recovery/last_log. # .
بسته ها را به روز کنید
بسته به روز رسانی یک فایل .zip است که حاوی فایل اجرایی باینری META-INF/com/google/android/update-binary . پس از تأیید امضای بسته، recovery این باینری را به /tmp استخراج می کند و باینری را اجرا می کند و آرگومان های زیر را ارسال می کند:
- شماره نسخه API باینری را به روز کنید . اگر آرگومان های ارسال شده به باینری به روز رسانی تغییر کند، این عدد افزایش می یابد.
- توصیف کننده فایل فرمان لوله . برنامه به روز رسانی می تواند از این لوله برای ارسال دستورات به باینری بازیابی استفاده کند، بیشتر برای تغییرات UI، مانند نشان دادن پیشرفت به کاربر.
- نام فایل بسته به روز رسانی فایل
.zip .
یک بسته به‌روزرسانی می‌تواند از هر باینری مرتبط استاتیک به عنوان باینری به‌روزرسانی استفاده کند. ابزارهای ساخت پکیج OTA از برنامه به‌روزرسانی ( bootable/recovery/updater ) استفاده می‌کنند که یک زبان برنامه‌نویسی ساده را فراهم می‌کند که می‌تواند بسیاری از کارهای نصب را انجام دهد. می توانید هر باینری دیگری را که روی دستگاه اجرا می شود جایگزین کنید.
برای جزئیات بیشتر در مورد باینری به‌روزرسانی‌کننده، ساختار نحوی و توابع داخلی، به Inside OTA Packages مراجعه کنید.
از نسخه های قبلی مهاجرت کنید
هنگام مهاجرت از نسخه اندروید 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() | دستگاه::HandleMenuKey() |
| device_perform_action() | Device::InvokeMenuItem() |
| device_wipe_data() | Device::WipeData() |
| device_ui_init() | ScreenRecoveryUI::Init() |
تبدیل توابع قدیمی به روش های جدید باید به طور منطقی ساده باشد. فراموش نکنید که تابع new make_device() برای ایجاد و برگرداندن نمونه ای از زیرکلاس Device جدید خود اضافه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
