اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تحديثات النظام (سلسة) من النوع أ/ب

تضمن تحديثات نظام A/B القديمة، المعروفة أيضًا باسم التحديثات السلسة، بقاء نظام التمهيد قابلاً للاستخدام على القرص أثناء التحديث عبر شبكة غير سلكية (OTA). يقلل هذا النهج من احتمالية أن يصبح الجهاز غير نشط بعد التحديث، ما يعني تقليل عمليات استبدال الجهاز وإعادة فلاش الجهاز في مراكز الإصلاح والضمان. تستخدم أنظمة التشغيل الأخرى من المستوى التجاري، مثل نظام التشغيل ChromeOS، أيضًا تحديثات A/B بنجاح.

لمزيد من المعلومات عن تحديثات نظام A/B وطريقة عملها، اطّلِع على اختيار القسم (الخانات).

توفّر تحديثات نظام A/B المزايا التالية:

يمكن أن تحدث التحديثات عبر الهواء أثناء تشغيل النظام، بدون مقاطعة المستخدم. يمكن للمستخدمين مواصلة استخدام أجهزتهم أثناء عملية التحديث عبر الهواء، ويكون وقت الاستراحة الوحيد أثناء التحديث هو عند إعادة تشغيل الجهاز في قسم القرص المعدَّل.
بعد التحديث، لا تستغرق إعادة التشغيل وقتًا أطول من إعادة التشغيل العادية.
في حال تعذّر تطبيق تحديث OTA (على سبيل المثال، بسبب فلاش غير صالح)، لن يتأثّر المستخدم. سيستمر المستخدم في تشغيل نظام التشغيل القديم، ويحق للعميل إعادة محاولة التحديث.
في حال تطبيق تحديث عبر شبكة لاسلكية وتعذّر تشغيله، ستتم إعادة تشغيل الجهاز على القسم القديم وسيظل قابلاً للاستخدام. يمكن للعميل إعادة محاولة التحديث.
لا تؤثّر أي أخطاء (مثل أخطاء الإدخال/الإخراج) إلا في مجموعة الأقسام غير المستخدَمة ويمكن إعادة المحاولة. ويقلّ احتمال حدوث هذه الأخطاء أيضًا لأنّ عبء الإدخال/الإخراج منخفض عن قصد لتجنّب خفض جودة تجربة المستخدم.
يمكن بث التحديثات إلى أجهزة A/B، ما يغني عن تنزيل الحزمة قبل تثبيتها. ويعني البث المباشر أنّه ليس من الضروري أن يتوفّر لدى المستخدم مساحة خالية كافية لتحميل حزمة التحديث على /data أو /cache.
لم يعُد يتم استخدام قسم ذاكرة التخزين المؤقت لتخزين حِزم التحديثات عبر شبكة غير سلكية، لذا ليس عليك التأكّد من أنّ قسم ذاكرة التخزين المؤقت كبير بما يكفي لتخزين التحديثات المستقبلية.
dm-verity يضمن أنّ الجهاز سيشغّل صورة سليمة. إذا لم يتم تشغيل الجهاز بسبب توفُّر تحديث OTA أو dm-verity غير صالح، يمكن إعادة تشغيل الجهاز لعرض صورة قديمة. (لا تتطلّب ميزة التشغيل المتحقَّق منه في Android تحديثات A/B.)

لمحة عن تحديثات نظام A/B

تتطلّب تحديثات اختبار أ/ب إجراء تغييرات على كلّ من العميل والنظام. ومع ذلك، لن يتطلّب خادم حِزم OTA إجراء تغييرات، إذ لا يزال يتم عرض حِزم التحديثات عبر بروتوكول HTTPS. بالنسبة إلى الأجهزة التي تستخدم البنية الأساسية لنظام التشغيل من خلال التحديثات التلقائية (OTA) من Google، تكون جميع تغييرات النظام في AOSP، ويكون رمز العميل مقدَّمًا من "خدمات Google Play". ستتمكّن المصنّعون الأصليون للأجهزة الذين لا يستخدمون البنية الأساسية لميزة "التحديث عبر الهواء" من Google من إعادة استخدام رمز نظام AOSP، ولكن عليهم توفير برنامجهم الخاص.

بالنسبة إلى المصنّعين الأصليّين للأجهزة الذين يوفّرون برنامج العملاء الخاص بهم، على العميل تنفيذ ما يلي:

تحديد وقت إجراء التحديث وبما أنّ تحديثات اختبار أ/ب تحدث في الخلفية، لم يعد المستخدم هو من يبدأها. لتجنُّب تعطيل المستخدمين، ننصحك بتحديد موعد للتحديثات عندما يكون الجهاز في وضع الصيانة في وضع عدم النشاط، مثل الليل، وعلى شبكة Wi-Fi. ومع ذلك، يمكن للعميل استخدام أيّ منهجيات استقرائية تريدها.
تحقَّق من خوادم حِزم OTA وحدِّد ما إذا كان هناك تحديث متاح. يجب أن يكون هذا الرمز متطابقًا إلى حدٍ كبير مع رمز العميل الحالي، باستثناء أنّك تريد الإشارة إلى أنّ الجهاز متوافق مع اختبار A/B. (يتضمّن برنامج Google أيضًا زرًا التحقّق الآن يتيح للمستخدمين التحقّق من توفّر أحدث تحديث).
يُرجى الاتصال برقم update_engine وإرسال عنوان URL لبروتوكول HTTPS لحزمة التحديث، على افتراض أنّه متوفّر. update_engine سيعدّل الكتل الأوّلية في القسم غير المستخدَم حاليًا أثناء بث حزمة التحديث.
أبلِغ عن حالات نجاح عملية التثبيت أو تعذّرها على خوادمك استنادًا إلى رمز النتيجة update_engine. في حال تطبيق التحديث بنجاح، سيطلب update_engine من مشغّل الإقلاع تشغيل نظام التشغيل الجديد عند إعادة التشغيل التالية. سيعود مُشغِّل الإقلاع إلى نظام التشغيل القديم في حال تعذّر تشغيل نظام التشغيل الجديد، لذا ليس على العميل تنفيذ أي إجراءات. إذا تعذّر التحديث، على العميل تحديد وقت إعادة المحاولة (وما إذا كان سيتم ذلك) استنادًا إلى رمز الخطأ التفصيلي. على سبيل المثال، يمكن لعميل جيد التعرّف على تعذُّر تثبيت حزمة OTA جزئية ("diff") ومحاولة تثبيت حزمة OTA كاملة بدلاً من ذلك.

يمكن للعميل إجراء ما يلي اختياريًا:

عرض إشعار يطلب من المستخدم إعادة تشغيل الجهاز إذا كنت تريد تنفيذ سياسة يتم فيها تشجيع العميل على إجراء التحديثات بشكل روتيني، يمكن إضافة هذا الإشعار إلى العميل. إذا لم يطلب العميل من المستخدمين التحديث، سيحصل المستخدمون على التحديث في المرة التالية التي يُعيدون فيها تشغيل الجهاز على أي حال. (يتضمن برنامج Google تأخيرًا قابلاً للضبط لكل تحديث).
عرض إشعار يُعلم المستخدمين بما إذا كانوا قد بدأوا تشغيل إصدار جديد من نظام التشغيل أو ما إذا كان من المفترض أن يفعلوا ذلك ولكنهم عادوا إلى استخدام الإصدار القديم من نظام التشغيل (لا يفعل العميل في Google عادةً أيًا من ذلك).

من جانب النظام، تؤثر تحديثات نظام A/B في ما يلي:

اختيار القسم (المنافذ) وتفاعلات update_engine daemon و bootloader (الموضّحة أدناه)
عملية الإنشاء وإنشاء حزمة التحديث عبر الهواء (الموضَّحة في تنفيذ تحديثات A/B)

اختيار الأقسام (الخانات)

تستخدِم تحديثات نظام A/B مجموعتَين من الأقسام يُشار إليهما باسم الخانات (عادةً الخانة "أ" والخانة "ب"). يتم تشغيل النظام من الفتحة الحالية ولا يمكن للنظام الجاري الوصول إلى الأقسام في الفتحة غير المستخدَمة أثناء التشغيل العادي. تجعل هذه الطريقة التحديثات مقاومة للأعطال من خلال الاحتفاظ بالمساحة غير المستخدَمة كأحد الخيارات الاحتياطية: إذا حدث خطأ أثناء التحديث أو بعد الانتهاء منه مباشرةً، يمكن للنظام الرجوع إلى المساحة القديمة ومواصلة استخدام النظام. لتحقيق هذا الهدف، يجب عدم تعديل أي قسم يستخدمه القسم الحالي كجزء من تحديث OTA (بما في ذلك الأقسام التي تتوفّر منها نسخة واحدة فقط).

تحتوي كل خانة على سمة قابل للتشغيل تشير إلى ما إذا كانت الخانة تحتوي على نظام صحيح يمكن للجهاز تشغيله. يمكن تشغيل الجهاز من خلال الفتحة الحالية عند تشغيله، ولكن قد تحتوي الفتحة الأخرى على إصدار قديم (لا يزال صحيحًا) من النظام أو إصدار أحدث أو بيانات غير صالحة. بغض النظر عن الفتحة الحالية، هناك فتحة واحدة هي الفتحة النشطة (التي سيتم تشغيل أداة تحميل البرامج من خلالها في عملية التشغيل التالية) أو الفتحة المفضّلة.

تحتوي كل خانة أيضًا على سمة successful التي تحدّدها مساحة المستخدم، وهي ذات صلة فقط إذا كانت الخانة قابلة للتشغيل أيضًا. من المفترض أن تتمكّن الفتحة الناجحة من التمهيد والتشغيل والتحديث بنفسها. يجب أن يضع مشغّل الإقلاع علامة على أنّ الشريحة القابلة للتشغيل التي لم يتم وضع علامة عليها على أنّها ناجحة (بعد إجراء عدة محاولات لمحاولة التمهيد منها)، بما في ذلك تغيير الشريحة النشط إلى شريحة قابلة للتشغيل أخرى (عادةً إلى الشريحة التي تعمل مباشرةً قبل محاولة التمهيد إلى الشريحة الجديدة النشطة). يتم تحديد التفاصيل المحدّدة للواجهة في boot_control.h.

برنامج Update engine daemon

تستخدِم تحديثات نظام A/B برنامجًا تابعًا للنظام يعمل في الخلفية يُسمى update_engine لإعداد النظام لبدء التشغيل إلى إصدار جديد معدَّل. يمكن لهذا العميل تنفيذ الإجراءات التالية:

قراءة البيانات من أقسام الفتحة A/B الحالية وكتابة أي بيانات في أقسام الفتحة A/B غير المستخدَمة وفقًا للتعليمات الواردة في حزمة OTA
استدعاء واجهة boot_control في سير عمل محدّد مسبقًا
شغِّل برنامج بعد التثبيت من القسم الجديد بعد كتابة جميع أقسام الشريحة غير المستخدَمة، وفقًا للتعليمات الواردة في حزمة OTA. (لمعرفة التفاصيل، يُرجى الاطّلاع على بعد التثبيت).

بما أنّ الخادم update_engine لا يشارك في عملية التشغيل نفسها، فإنّه لا يمكنه تنفيذ بعض الإجراءات أثناء التحديث بسبب ميزات وسياسات SELinux في المساحة الحالية (لا يمكن تعديل هذه الميزات والسياسات إلى أن يتم تشغيل النظام في إصدار جديد). للحفاظ على استقرار النظام، يجب ألّا تعدّل عملية التحديث جدول الأقسام أو محتويات الأقسام في المربّع الحالي أو محتويات الأقسام غير A/B التي لا يمكن محو بياناتها من خلال إعادة الضبط على الإعدادات الأصلية.

تعديل مصدر المحرّك

يقع مصدر update_engine في system/update_engine. يتم تقسيم ملفات dexopt لميزة A/B OTA بين installd ومدير الحِزم:

frameworks/native/cmds/installd/تتضمن ota* النص البرمجي لعمليات ما بعد التثبيت والملف الثنائي لـ chroot ونسخة طبق الأصل من installd التي تستدعي dex2oat والنص البرمجي لنقل العناصر بعد تحديث OTA وملف rc للنص البرمجي لنقل البيانات.
‫frameworks/base/services/core/java/com/android/server/pm/OtaDexoptService.java (بالإضافة إلى OtaDexoptShellCommand) هو مدير الحِزم الذي يُعدّ أوامر dex2oat للتطبيقات.

للاطّلاع على مثال عملي، يُرجى الرجوع إلى /device/google/marlin/device-common.mk.

تعديل سجلات المحرّك

بالنسبة إلى إصدارات Android 8.x والإصدارات الأقدم، يمكن العثور على سجلّات update_engine في logcat وفي تقرير الأخطاء. لتوفير سجلّات update_engine في نظام الملفات، عليك تطبيق التغييرات التالية على الإصدار:

تؤدي هذه التغييرات إلى حفظ نسخة من أحدث سجلّ update_engine في /data/misc/update_engine_log/update_engine.YEAR-TIME. بالإضافة إلى السجلّ الحالي، يتم حفظ آخر خمسة سجلّات ضمن /data/misc/update_engine_log/. سيتمكّن المستخدمون الذين لديهم رقم تعريف مجموعة log من الوصول إلى سجلّات نظام الملفات.

تفاعلات مع برنامج الإقلاع

يستخدم update_engine (وربما تطبيقات systemd الأخرى) واجهة برمجة التطبيقات boot_control HAL لتوجيه أداة تحميل البرامج إلى الجهاز الذي سيتم تشغيله منه. تشمل أمثلة السيناريوهات الشائعة الحالات المرتبطة بها ما يلي:

الحالة العادية: يعمل النظام من الفتحة الحالية، إما الفتحة "أ" أو الفتحة "ب". لم يتم تطبيق أي تعديلات حتى الآن. تكون الشريحة الحالية للنظام قابلة للتشغيل وناجحة وتكون الشريحة النشطة.
التحديث قيد التقدّم: يعمل النظام من الفتحة B، لذا الفتحة B هي الفتحة النشطة التي يمكن تشغيلها بنجاح. تم وضع علامة على الفتحة "أ" على أنّها لا يمكن تشغيلها لأنّه يتم تعديل محتوى الفتحة "أ" ولكن لم تكتمل عملية التعديل بعد. من المفترض أن تؤدي إعادة التشغيل في هذه الحالة إلى مواصلة التشغيل من الفتحة B.
تم تطبيق التحديث، في انتظار إعادة التشغيل: يعمل النظام من الفتحة "ب"، وهي قابل للتشغيل وناجحة، ولكن تم وضع علامة على الفتحة "أ" كنشطة (وبالتالي تم وضع علامة عليها كقابلة للتشغيل). لم يتم وضع علامة على الشريحة "أ" بعد على أنّها ناجحة، ويجب أن يحاول مشغّل الإقلاع إجراء عدد من المحاولات لبدء التشغيل من الشريحة "أ".
تم إعادة تشغيل النظام لتثبيت تحديث جديد: يعمل النظام من الفتحة "أ" للمرة الأولى، ولا تزال الفتحة "ب" قابلة للتشغيل وناجحة، في حين أنّ الفتحة "أ" قابلة للتشغيل فقط، ولا تزال نشطة ولكن غير ناجحة. من المفترض أن يضع الخادم الدائم لمساحة المستخدم، update_verifier، علامة على خانة A كنجاح بعد إجراء بعض عمليات التحقّق.

التوافق مع تحديثات البث

لا تتوفّر دائمًا مساحة كافية على أجهزة المستخدمين في /data لتنزيل حزمة التحديث. وبما أنّ المصنّعين الأصليّين للأجهزة والمستخدمين لا يريدون إهدار المساحة في قسم /cache، لا يتلقّى بعض المستخدمين التحديثات لأنّ الجهاز لا يتوفّر فيه مكان لتخزين حزمة التحديث. لمعالجة هذه المشكلة، أضاف نظام التشغيل Android 8.0 ميزة بث تحديثات A/B التي تكتب الكتل مباشرةً في القسم B أثناء تنزيلها، بدون الحاجة إلى تخزين الكتل على /data. لا تتطلّب تحديثات البث المباشر من خلال اختبار أ/ب مساحة تخزين مؤقتة تقريبًا، بل تتطلّب فقط مساحة تخزين كافية تقريبًا لـ 100 كيلوبايت من البيانات الوصفية.

لتفعيل تحديثات البث في Android 7.1، اختَر الرموز البرمجية التالية:

هذه الإصلاحات مطلوبة لتفعيل ميزة "البث المباشر لنظام التشغيل Android" في الإصدار 7.1 من Android والإصدارات الأحدث، سواء باستخدام خدمات Google للأجهزة الجوّالة (GMS) أو أي مثبّت آخر للنظام.

دورة حياة تحديث أ/ب

تبدأ عملية التحديث عندما تصبح حزمة OTA (يُشار إليها في الرمز البرمجي باسم حمولة) متاحة للتنزيل. قد تؤجل السياسات في الجهاز تنزيل الحمولة المفيد وتطبيقها استنادًا إلى مستوى شحن البطارية أو نشاط المستخدم أو حالة الشحن أو سياسات أخرى. بالإضافة إلى ذلك، بما أنّ التحديث يتم تشغيله في الخلفية، قد لا يعلم المستخدمون أنّه قيد التنفيذ. ويعني ذلك أنّه قد يتم إيقاف عملية التحديث في أي وقت بسبب السياسات أو عمليات إعادة التشغيل غير المتوقّعة أو إجراءات المستخدم.

يمكن أن تشير البيانات الوصفية في حزمة OTA نفسها بشكل اختياري إلى إمكانية بث التحديث، ويمكن أيضًا استخدام الحزمة نفسها للتثبيت بدون بث. قد يستخدم الخادم البيانات الوصفية لاطلاع العميل على أنّه يتم البثّ، ما يسمح للعميل بتسليم البث المباشر إلى update_engine بشكل صحيح. يمكن لصنّاع الأجهزة الذين لديهم خادم وعميل تفعيل ميزة بث التحديثات من خلال التأكّد من أنّ الخادم يحدّد أنّ التحديث يتم بثه (أو يفترض أنّ جميع التحديثات يتم بثها) وأنّ العميل يُجري الطلب الصحيح إلى update_engine لبث التحديث. يمكن للمصنعين استخدام حقيقة أنّ الحزمة من نوع البث لإرسال علامة إلى العميل لبدء عملية التسليم إلى جانب الإطار على أنّه بث.

بعد توفّر الحمولة، تتم عملية التحديث على النحو التالي:

الخطوة	الأنشطة
1	يتم وضع علامة على خانة المحتوى الحالية (أو "الخانة المصدر") على أنّها ناجحة (إذا لم يتم وضع علامة عليها من قبل) باستخدام الرمز `markBootSuccessful()`.
2	يتم وضع علامة على الفتحة غير المستخدَمة (أو "الفتحة المستهدَفة") على أنّها لا يمكن تشغيلها من خلال استدعاء الدالة `setSlotAsUnbootable()`. يتم دائمًا وضع علامة على الشريحة الحالية على أنّها ناجحة في بداية التحديث لمنع أداة تحميل التشغيل من الرجوع إلى الشريحة غير المستخدَمة، والتي ستتضمّن قريبًا بيانات غير صالحة. إذا وصل النظام إلى المرحلة التي يمكنه فيها بدء تطبيق تحديث، يتم وضع علامة على الفتحة الحالية على أنّها ناجحة حتى إذا كانت المكوّنات الرئيسية الأخرى متعطّلة (مثل واجهة المستخدم في حلقة تعطُّل)، لأنّه من الممكن طرح برمجية جديدة لحلّ هذه المشاكل. الحِزمة البرمجية للتحديث هي ملف غير شفاف يحتوي على تعليمات التحديث إلى الإصدار الجديد. تتألف حمولة التحديث من ما يلي: البيانات الوصفية: البيانات الوصفية هي جزء صغير نسبيًا من الحمولة المعدَّلة، وتحتوي على قائمة بالعمليات اللازمة لإنشاء الإصدار الجديد والتحقّق منه في المربّع المستهدف. على سبيل المثال، يمكن أن تؤدي العملية إلى فك ضغط ملف تعريفي معيّن وكتابته في وحدات تخزين معيّنة في قسم مستهدَف، أو القراءة من قسم مصدر، وتطبيق تصحيح ثنائي وكتابة البيانات في وحدات تخزين معيّنة في قسم مستهدَف. البيانات الإضافية: وبما أنّ البيانات الإضافية المرتبطة بالعمليات تشكّل الجزء الأكبر من الحمولة، فإنّها تتألف من العنصر المضغوط أو التصحيح الثنائي في هذه الأمثلة.
3	يتم تنزيل بيانات تعريف الحمولة.
4	بالنسبة إلى كل عملية محدّدة في البيانات الوصفية، يتم بالتسلسل تنزيل البيانات المرتبطة (إن وُجدت) إلى الذاكرة، ويتم تطبيق العملية، ويتم تجاهل الذاكرة المرتبطة.
5	تتم إعادة قراءة الأقسام بالكامل والتحقّق منها مقارنةً بالقيمة المتوقّعة من التجزئة.
6	يتم تنفيذ خطوة ما بعد التثبيت (إن توفّرت). في حال حدوث خطأ أثناء تنفيذ أي خطوة، يتعذّر إجراء التحديث ويتم إعادة المحاولة باستخدام حمولة مختلفة. إذا نجحت كل الخطوات إلى الآن، تنجح عملية التعديل ويتم تنفيذ الخطوة الأخيرة.
7	يتم وضع علامة على الخانة غير المستخدَمة على أنّها نشطة من خلال طلب `setActiveBootSlot()`. لا يعني وضع علامة "نشط" على الفتحة غير المستخدَمة أنّه سيتم الانتهاء من عملية التمهيد. يمكن لبرنامج الإقلاع (أو النظام نفسه) تبديل الفتحة النشطة مرة أخرى إذا لم يقرأ حالة ناجحة.
8	بعد التثبيت (كما هو موضّح أدناه)، يتم تشغيل برنامج من "الإصدار الجديد" أثناء تشغيله في الإصدار القديم. إذا تم تحديد هذه الخطوة في حزمة OTA، تكون إلزامية ويجب أن يعرض البرنامج رمز الخروج `0`، وإلا سيتعذّر إكمال التحديث.
9	بعد أن يتم تشغيل النظام بنجاح في الفتحة الجديدة وينتهي من عمليات التحقّق بعد إعادة التشغيل، يتم وضع علامة "بنجاح" على الفتحة الحالية (المعروفة سابقًا باسم "الفتحة المستهدَفة") من خلال استدعاء `markBootSuccessful()`.

بعد التثبيت

بالنسبة إلى كل قسم تم تحديد خطوة ما بعد التثبيت له، يمُكّن update_engine من تركيب القسم الجديد في موقع محدّد وتنفيذ البرنامج المحدّد في عملية التحديث عبر الهواء بالنسبة إلى القسم المثبَّت. على سبيل المثال، إذا تم تعريف برنامج ما بعد التثبيت على أنّه usr/bin/postinstall في قسم النظام، سيتم تركيب هذا القسم من الفتحة غير المستخدَمة في موقع ثابت (مثل /postinstall_mount) وسيتم تنفيذ الأمر /postinstall_mount/usr/bin/postinstall.

لكي تنجح عملية ما بعد التثبيت، يجب أن يكون بالإمكان تنفيذ ما يلي باستخدام النواة القديمة:

تحميل تنسيق نظام الملفات الجديد لا يمكن تغيير نوع نظام الملفات ما لم يكن هناك دعم له في النواة القديمة، بما في ذلك تفاصيل مثل أسلوب التجميع المستخدَم في حال استخدام نظام ملفات مضغوط (مثل SquashFS).
التعرّف على تنسيق البرنامج بعد التثبيت في القسم الجديد في حال استخدام ملف ثنائي بتنسيق Executable and Linkable Format ‏ (ELF)، يجب أن يكون متوافقًا مع الإصدار القديم من الإصدار المرئي (مثل برنامج جديد بنظام 64 بت يعمل على إصدار قديم من الإصدار المرئي بنظام 32 بت في حال تم التبديل من بنية إصدارات 32 بت إلى إصدارات 64 بت). ما لم يتم توجيه أداة التحميل (ld) لاستخدام مسارات أخرى أو إنشاء ملف ثنائي ثابت، سيتم تحميل المكتبات من صورة النظام القديمة وليس من الصورة الجديدة.

على سبيل المثال، يمكنك استخدام نص برمجي لنظام التشغيل كبرنامج ما بعد التثبيت يفسّره ملف ثنائي لنظام التشغيل القديم (مع علامة #! في أعلى الصفحة)، ثم إعداد مسارات المكتبة من البيئة الجديدة لتنفيذ برنامج ثنائي أكثر تعقيدًا بعد التثبيت. بدلاً من ذلك، يمكنك تنفيذ خطوة ما بعد التثبيت من ملف شخصي أصغر مخصّص لتفعيل تنسيق نظام الملفات في ملف النظام الرئيسي بدون مواجهة مشاكل التوافق مع الإصدارات القديمة أو التحديثات الوسيطة، ما يسمح للمستخدمين بالتحديث مباشرةً إلى أحدث إصدار من صورة المصنع.

يخضع البرنامج الجديد بعد التثبيت لسياسات SELinux المحدّدة في النظام القديم. وبناءً على ذلك، فإنّ خطوة ما بعد التثبيت مناسبة لتنفيذ المهام المطلوبة حسب التصميم على جهاز معيّن أو مهام أخرى تعتمد على أفضل الجهود. إنّ خطوة ما بعد التثبيت غير مناسبة لإصلاح الأخطاء لمرة واحدة قبل إعادة التشغيل التي تتطلّب سوى أذونات غير متوقّعة.

يتم تشغيل برنامج ما بعد التثبيت المحدّد في postinstall سياق SELinux. سيتم وضع علامة postinstall_file على كل الملفات في القسم الجديد المثبَّت، بغض النظر عن سماتها بعد إعادة التشغيل في هذا النظام الجديد. لن تؤثر التغييرات التي يتم إجراؤها على سمات SELinux في النظام الجديد في خطوة ما بعد التثبيت. إذا كان البرنامج الذي يتم تشغيله بعد التثبيت يحتاج إلى أذونات إضافية، يجب إضافتها إلى سياق ما بعد التثبيت.

بعد إعادة التشغيل

بعد إعادة التشغيل، يبدأ update_verifier عملية التحقّق من السلامة باستخدام dm-verity. يبدأ هذا التحقّق قبل zygote لتجنُّب إجراء خدمات Java لأي تغييرات لا يمكن التراجع عنها من شأنها منع التراجع الآمن. خلال هذه العملية، قد يؤدي برنامج الإقلاع والنواة أيضًا إلى إعادة التشغيل إذا رصدت ميزة "التشغيل المُتحقَّق منه" أو dm-verity أي تلف. بعد اكتمال عملية التحقّق، يضعupdate_verifier علامة على أنّ عملية التشغيل قد تمت بنجاح.

لن يقرأ update_verifier سوى الكتل المدرَجة في /data/ota_package/care_map.txt، والتي يتم تضمينها في حزمة A/B OTA عند استخدام رمز AOSP. يستخرج برنامج Java لتعديل نظام التشغيل، مثل GmsCore، care_map.txt، ويضبط إذن الوصول قبل إعادة تشغيل الجهاز، ويحذف الملف المستخرَج بعد تشغيل النظام بنجاح على الإصدار الجديد.