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

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

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

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

لمزيد من المعلومات حول تحديثات النظام من النوع أ/ب وطريقة عملها، يُرجى الاطّلاع على اختيار الأقسام (الخانات).

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

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

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

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

بالنسبة إلى الشركات المصنّعة للمعدات الأصلية التي توفّر عميلها الخاص، يجب أن يتوفّر لدى العميل ما يلي:

تحديد وقت تثبيت التحديث بما أنّ تحديثات A/B تتم في الخلفية، لم يعُد المستخدم هو من يبدأها. ولتجنُّب إزعاج المستخدمين، يُنصح بجدولة التحديثات عندما يكون الجهاز في وضع الصيانة غير النشط، مثلاً أثناء الليل، وعند الاتصال بشبكة 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 وتفاعلات برنامج تحميل التشغيل (الموضّحة أدناه)
عملية الإنشاء وإنشاء حزمة التحديث عبر اتصال لاسلكي (موضّحة في مقالة تنفيذ تحديثات A/B)

اختيار القسم (الفتحات)

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

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

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

تعديل البرنامج الخفي للمحرّك

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

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

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

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

يقع مصدر update_engine في system/update_engine. يتم تقسيم ملفات dexopt الخاصة بتحديثات A/B عبر الأثير بين 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.

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

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

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

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

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

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

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

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

لتفعيل تحديثات البث في Android 7.1، اختَر التصحيحات التالية:

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

مراحل تحديث اختبار أ/ب

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

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

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

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

بعد التثبيت

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

لكي تنجح عملية ما بعد التثبيت، يجب أن يكون بإمكان النواة القديمة إجراء ما يلي:

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

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

يتم تقييد البرنامج الجديد بعد التثبيت من خلال سياسات 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، ويضبط إذن الوصول قبل إعادة تشغيل الجهاز، ويحذف الملف المستخرَج بعد تشغيل النظام بنجاح في الإصدار الجديد.