اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تحديثات النظام غير المستندة إلى تقنية A/B
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
إنّ التحديثات غير التلقائية هي منهجية قديمة لنظام OTA تستخدمها أجهزة Android القديمة (Android 6 والإصدارات الأقدم). تحتوي هذه الأجهزة على قسم استرداد مخصّص يحتوي على البرنامج المطلوب لشدَّد حزمة التحديث التي تم تنزيلها وتطبيق التحديث على الأقسام الأخرى.
على أجهزة Android القديمة التي لا تتضمّن قسمَي A/B، تحتوي مساحة الفلاش عادةً على
الأقسام التالية:
- التشغيل
-
يحتوي على نواة Linux ونظام ملفات جذر أساسي (يتم تحميله في قرص ذاكرة وصول عشوائي). يتم تثبيت
النظام والأقسام الأخرى وبدء وقت التشغيل في قسم النظام.
- النظام
-
يحتوي على تطبيقات ومكتبات النظام التي تتوفّر لها رموز المصدر على "المشروع المفتوح المصدر لنظام Android" (AOSP). أثناء التشغيل العادي، يتم تركيب هذا القسم للقراءة فقط، ولا يتم تغيير محتوياته إلا أثناء تحديث OTA.
- المُورِّد
-
يحتوي على تطبيقات ومكتبات نظام لا يتوفّر لها رمز المصدر
في "المشروع المفتوح المصدر لنظام Android" (AOSP). أثناء التشغيل العادي، يتم تركيب هذا القسم
للقراءة فقط، ولا يتغيّر محتواه إلا أثناء تحديث OTA.
- userdata
-
يتم تخزين البيانات المحفوظة بواسطة التطبيقات التي ثبَّتها المستخدم وما إلى ذلك. لا يتم عادةً تعديل هذا القسم
من خلال عملية التحديث عبر الهواء.
- ذاكرة التخزين المؤقت
-
مساحة تخزين مؤقتة تستخدمها بعض التطبيقات (يتطلب الوصول إلى هذا القسم أذونات خاصة
للتطبيقات) وتخزين حِزم التحديثات التي يتم تنزيلها عبر شبكة غير سلكية. تستخدم البرامج الأخرى هذه
المساحة مع توقّع أنّه يمكن أن تختفي الملفات في أي وقت. قد تؤدي بعض عمليات تثبيت حِزم OTA
إلى محو هذا القسم بالكامل. تحتوي ذاكرة التخزين المؤقت أيضًا على
سجلات التحديث من تحديث OTA.
- الاسترداد
-
يحتوي على نظام Linux كامل ثانٍ، بما في ذلك نواة ورمز ثنائي خاص للاسترداد
الذي يقرأ حزمة ويستخدم محتوياتها لتعديل الأقسام الأخرى.
- misc
-
قسم صغير يستخدمه وضع الاسترداد لتخزين بعض المعلومات حول ما يفعله في حالة إعادة تشغيل الجهاز أثناء تطبيق حزمة OTA
مدة توفّر تحديث عبر الهواء
يتضمّن التحديث العادي عبر OTA الخطوات التالية:
-
يُجري الجهاز عمليات تحقّق منتظمة مع خوادم OTA ويتم إعلامه بمدى توفّر
تحديث، بما في ذلك عنوان URL لحزمة التحديث وسلسلة وصفية لعرضها على المستخدم.
-
يتم تعديل عمليات التنزيل إلى ذاكرة تخزين مؤقت أو قسم بيانات، ويتم التحقّق من توقيعه التشفيري
مقارنةً بالشهادات في
/system/etc/security/otacerts.zip. يُطلَب من المستخدم تثبيت التحديث.
-
تتم إعادة تشغيل الجهاز في وضع الاسترداد، حيث يتم تشغيل النظام والنواة في قسم الاسترداد بدلاً من تشغيل النواة في قسم الإقلاع.
-
يتم تشغيل ملف Recovery الثنائي بواسطة init. يبحث عن وسيطات سطر الأوامر في
/cache/recovery/command التي تشير إلى الحزمة التي تم تنزيلها.
-
تتحقّق عملية الاسترداد من صحة التوقيع التشفيري للحزمة مقارنةً بالمفاتيح العامة في
/res/keys (جزء من ذاكرة الوصول العشوائي (RAM) المتوفّرة في قسم الاسترداد).
-
يتم سحب البيانات من الحزمة واستخدامها لتعديل أقسام التمهيد و/أو النظام و/أو المصنّع
حسب الحاجة. يحتوي أحد الملفات الجديدة التي تم تركها في قسم النظام على
محتويات قسم الاسترداد الجديد.
-
تتم إعادة تشغيل الجهاز بشكل طبيعي.
-
يتم تحميل قسم التمهيد الذي تم تعديله حديثًا، ويتم تثبيته وبدء تنفيذ الملفات الثنائية
في قسم النظام الذي تم تعديله حديثًا.
-
كجزء من عملية التشغيل العادية، يتحقّق النظام من محتويات قسم الاسترداد مقارنةً بالمحتوى المطلوب (الذي تم تخزينه سابقًا كملف في
/system). إذا كان المحتوى مختلفًا، تتم إعادة فلاش قسم الاسترداد باستخدام المحتوى المطلوب. (في عمليات التشغيل اللاحقة، يحتوي قسم الاسترداد على المحتوى الجديد، لذا لا يلزم إعادة فلاش الجهاز).
اكتملت عملية تحديث النظام. يمكن العثور على سجلّات التحديثات في
/cache/recovery/last_log.#.
تحديث الحِزم
حزمة التحديث هي ملف .zip يحتوي على الملف الثنائي التنفيذي
META-INF/com/google/android/update-binary. بعد التحقّق من التوقيع على
الحزمة، يستخرج recovery هذا الملف الثنائي إلى /tmp ويشغّله،
مع تمرير الوسيطات التالية:
-
تعديل رقم إصدار واجهة برمجة التطبيقات الثنائية إذا تغيّرت الوسيطات التي تم تمريرها إلى القيمة الثنائي
update، يزداد هذا العدد.
-
واصِف ملف مسار الأوامر يمكن لبرنامج التحديث استخدام هذا الأنبوب لإرسال الأوامر مرة أخرى إلى ملف recovery الثنائي، وذلك في معظم الأحيان
بسبب تغييرات واجهة المستخدم، مثل الإشارة إلى مستوى التقدّم للمستخدم.
-
اسم ملف حزمة التحديث
.zip
يمكن لحزمة التحديث استخدام أي ملف ثنائي مرتبط بشكل ثابت كملف ثنائي للتحديث. تستخدم أدوات إنشاء حِزم OTA
برنامج التحديث (bootable/recovery/updater)، الذي
يقدّم لغة برمجة نصية بسيطة يمكنها تنفيذ العديد من مهام التثبيت. يمكنك استبدال
أي ملف ثنائي آخر قيد التشغيل على الجهاز.
لمعرفة التفاصيل حول الملف الثنائي لبرنامج التحديث وبنية edify والدوالّ المضمّنة، يُرجى الاطّلاع على
الاطّلاع على حِزم OTA.
نقل البيانات من الإصدارات السابقة
عند نقل البيانات من الإصدار 2.3/3.0/4.0 من نظام التشغيل Android، يكون التغيير الرئيسي هو تحويل كل
الوظائف الخاصة بالجهاز من مجموعة من دوال 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()
الجديدة لإنشاء مثيل من الفئة الفرعية الجديدة للجهاز وإرجاعه.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
