اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لتنفيذ التحديثات عبر شبكة غير سلكيّة، يجب أن يتمكّن
برنامج الإقلاع من الوصول إلى قرص RAM لإعادة التشغيل أثناء عملية الإقلاع. إذا كان الجهاز
يستخدم صورة استرداد AOSP لم يتم تعديلها، يقرأ برنامج الإقلاع أول 32 بايت
في قسم misc. وإذا كانت البيانات المعروضة تتطابق مع boot-recovery، يبدأ
برنامج الإقلاع في تشغيل صورة recovery. تتيح هذه الطريقة مواصلة تنفيذ أي عملية قيد الانتظار لمحاولة memulihkan الجهاز (مثل تطبيق تحديث OTA أو إزالة البيانات) حتى اكتمالها.
لتفعيل ميزة تحديثات OTA على الأجهزة التي تستخدم تحديثات A/B، تأكَّد من استيفاء أداة تحميل نظام التشغيل للجهاز
للمعايير التالية.
المعايير العامة
يجب أن تكون جميع الأقسام التي تم تحديثها من خلال شبكة غير سلكية (OTA) قابلة للتحديث أثناء التمهيد
للنظام الرئيسي (ولا يتم تحديثها في وضع الاسترداد).
لتشغيل قسم system، يُرسِل أداة تحميل البرامج القيمة التالية في سطر ro root=/dev/[node] rootwait init=/init.
تقع على عاتق إطار عمل Android مسؤولية استدعاء markBootSuccessful
من HAL. يجب ألا يضع برنامج الإقلاع علامة على أي قسم على أنّه تم التمهيد منه بنجاح.
توفُّر واجهة HAL للتحكّم في عملية التشغيل
يجب أن يتوافق برنامج الإقلاع مع واجهة برمجة التطبيقات boot_control HAL كما هو محدّد في
hardware/libhardware/include/hardware/boot_control.h. يُجري أداة التحديث طلب بحث في HAL لوحدة التحكّم في بدء التشغيل، ويُجري تحديثًا لفتحة بدء التشغيل غير المستخدَمة، ويغيّر الفتحة النشطة باستخدام HAL، ويعيد تشغيل الجهاز ليعمل بنظام التشغيل المُحدَّث. لمعرفة التفاصيل، يُرجى الاطّلاع على
تنفيذ واجهة برمجة التطبيقات
HAL الخاصة بإدارة عملية التشغيل.
إتاحة الفتحات
يجب أن يتيح برنامج الإقلاع الوظائف ذات الصلة بالأقسام والمنافذ،
بما في ذلك:
يجب أن تتضمّن أسماء الأقسام إضافة لاحقة تحدِّد الأقسام التي تنتمي
إلى خانة معيّنة في أداة تحميل البرامج. لكل قسم من هذا النوع،
يكون هناك متغيّر مقابل
has-slot:partition base name بقيمة
yes. يتم تسمية الفتحات أبجديًا مثل a وb وc وما إلى ذلك، والتي تتوافق مع القسمات التي تحتوي على اللاحقة _a و_b و_c وما إلى ذلك. من المفترض أن يُعلم أداة تحميل البرامج النظام التشغيل بالفتحة التي تم تشغيله منها باستخدام سمة سطر الأوامر
androidboot.slot_suffix. يتم ضبط هذه السمة من خلال bootconfig للأجهزة التي يتم تشغيلها باستخدام الإصدار 12 من Android أو إصدار أحدث.
تتم إعادة ضبط قيمة slot-retry-count على قيمة موجبة (عادةً 3)،
إما من خلال وحدة HAL الخاصة بإدارة عملية التمهيد من خلال دالة الاستدعاء setActiveBootSlot أو
من خلال الأمر fastboot set_active. عند تعديل قسم هو
جزء من خانة، يُزيل برنامج الإقلاع الرسالة "تم الإقلاع بنجاح" ويعيد ضبط
عدد عمليات إعادة المحاولة للخانة.
من المفترض أن يحدِّد برنامج الإقلاع أيضًا خانة التحميل. يعرض الشكل مثالاً على عملية اتخاذ القرار.
الشكل 1. مسار حجز مساحة في برنامج الإقلاع
حدِّد خانة الإعلان التي تريد عرضها. لا تحاول تحميل خانة تم وضع علامة عليها
slot-unbootable. يجب أن تكون هذه الفتحة متسقة مع القيم التي تعرضها أداة
fastboot، ويُشار إليها باسم الفتحة الحالية.
إذا لم يتم وضع علامة slot-successful على الفتحة الحالية وكانت تحتوي على slot-retry-count = 0، ضَع علامة slot-unbootable على الفتحة الحالية. بعد ذلك،
اختَر خانة مختلفة غير مميّزة بالرمز unbootable ومميّزة بالرمز
slot-successful، وأصبحت هذه الخانة هي الخانة المحدّدة. إذا لم تكن هناك خانة حالية متاحة، يجب التمهيد إلى وضع الاسترداد أو عرض رسالة خطأ مفيدة للمستخدِم.
اختَر boot.img المناسب وأدرِج المسار إلى القسم الصحيح لنظام التشغيل
في سطر أوامر kernel.
املأ مَعلمة slot_suffix في سطر أوامر kernel.
التشغيل إذا لم يتم وضع علامة slot-successful، عليك خفض القيمة slot-retry-count.
تحدِّد الأداة fastboot القسم الذي سيتم برمجته عند تنفيذ أي من أوامر برمجة الفلاش. على سبيل المثال، يؤدي تشغيل الأمر fastboot flash system system.img
أولاً إلى طلب متغيّر current-slot ثم تسلسل النتيجة
إلى النظام لإنشاء اسم القسم الذي يجب برمجته
(system_a أو system_b أو غير ذلك).
عند ضبط الفتحة الحالية باستخدام الأمر fastboot set_active أو الأمر
boot control HAL setActiveBootSlot، من المفترض أن يعدّل أداة تحميل البرامج الثابتة
الفتحة الحالية، وتُمحو slot-unbootable وslot-successful، وتتم إعادة ضبط
عدد عمليات إعادة المحاولة (هذه هي الطريقة الوحيدة لمحو slot-unbootable).
يجب أن يحتوي القسم recovery على صورة يمكنها قراءة
صورة نظام من بعض الأقسام المتوافقة (cache وuserdata) وكتابة
هذه الصورة في القسم system.
من المفترض أن يتيح برنامج الإقلاع الانتقال مباشرةً إلى وضع الاسترداد.
إذا كانت تحديثات صور الراديو متاحة، يجب أن يكون القسم recovery
قادرًا أيضًا على تحديث الراديو. يمكن تنفيذ ذلك بطريقتَين:
يُبرمِج برنامج الإقلاع الراديو. في هذه الحالة، من المفترض أن يكون بإمكانك
إعادة التشغيل من قسم الاسترداد إلى برنامج الإقلاع لإكمال
التحديث.
تومض صورة الاسترداد جهاز الراديو. يمكن توفير هذه الوظيفة كمكتبة ثنائية أو أداة.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
