تنسيق ملف APEX

طرح تنسيق حاوية Android Pony EXpress (APEX) في نظام التشغيل Android 10 ويتم استخدامه خلال مسار التثبيت للنظام ذي المستوى الأدنى الوحدات. ويسهِّل هذا التنسيق تحديثات مكونات النظام غير الملائمة. في نموذج تطبيق Android القياسي. بعض أمثلة المكوّنات أصلية والخدمات والمكتبات وطبقات تجريد الأجهزة (HALs)، وقت التشغيل (ART) ومكتبات الفئات.

مصطلح "APEX" ويمكن أن يشير أيضًا إلى ملف APEX.

خلفية

مع أنّ نظام Android يتيح تحديثات الوحدات التي تناسب التطبيق العادي. النموذج (مثل الخدمات والأنشطة) من خلال تطبيقات أداة تثبيت الحزم (مثل تطبيق متجر Google Play)، باستخدام نموذج مشابه لمكونات نظام التشغيل ذات المستوى الأدنى. على العيوب التالية:

• لا يمكن استخدام الوحدات المستندة إلى حزمة APK في مرحلة مبكرة من تسلسل التمهيد. الطرد هو المستودع المركزي للمعلومات حول التطبيقات ولا يمكن من مدير النشاط، والذي يصبح جاهزًا في مرحلة لاحقة من إجراء التمهيد.
• تمّ تصميم تنسيق APK (لا سيّما البيان) لتطبيقات Android قد لا تكون وحدات النظام مناسبة دائمًا.

التصميم

يصف هذا القسم التصميم عالي المستوى لتنسيق ملف APEX مدير APEX، وهو خدمة تدير ملفات APEX.

لمزيد من المعلومات حول سبب اختيار هذا التصميم لـ APEX، يمكنك الاطّلاع على البدائل التي يتم أخذها في الاعتبار عند تطوير APEX:

تنسيق APEX

هذا هو تنسيق ملف APEX.

الشكل 1. تنسيق ملف APEX

في المستوى الأعلى، ملف APEX هو ملف ZIP يتم فيه تخزين الملفات. غير مضغوطة على حدود 4 كيلوبايت.

الملفات الأربعة في ملف APEX هي:

• apex_manifest.json
• AndroidManifest.xml
• apex_payload.img
• apex_pubkey

يحتوي ملف apex_manifest.json على اسم الحزمة وإصدارها، وهما لتحديد ملف APEX. هذا هو ApexManifest مخزن بروتوكول مؤقت بتنسيق JSON.

يسمح ملف AndroidManifest.xml لملف APEX باستخدام الأدوات ذات الصلة بحِزمة APK مثل تطبيقات ADB وPackageManager وتطبيقات أداة تثبيت الحزم (مثل "متجر Play"). على سبيل المثال، يمكن أن يستخدم ملف APEX أداة حالية مثل aapt لفحص بيانات التعريف الأساسية من الملف. يحتوي الملف على اسم الحزمة معلومات الإصدار. تتوفر هذه المعلومات بشكل عام أيضًا في apex_manifest.json

يُنصح بـ apex_manifest.json على AndroidManifest.xml للحصول على رمز جديد التي تتعامل مع APEX. قد يحتوي AndroidManifest.xml على إضافات معلومات الاستهداف التي يمكن أن تستخدمها أدوات نشر التطبيقات الحالية.

apex_payload.img هي صورة نظام ملفات ext4 مدعومة بـ dm-verity. الصورة يتم تثبيته في بيئة التشغيل من خلال جهاز استرجاع. على وجه التحديد، تتضمن شجرة التجزئة يتم إنشاء مجموعة البيانات الوصفية باستخدام مكتبة libavb. حمولة بيانات نظام الملفات لم يتم تحليله (لأن الصورة يجب أن تكون قابلة للتثبيت في مكانها). الملفات العادية هي ضمن ملف apex_payload.img.

apex_pubkey هو المفتاح العام المُستخدَم لتوقيع صورة نظام الملفات. في وقت التشغيل، يضمن هذا المفتاح توقيع ملف APEX الذي تم تنزيله بالكيان نفسه. يوقّع ملف APEX نفسه في الأقسام المدمجة.

إرشادات اختيار اسم ملف APEX

للمساعدة في منع التعارضات في الأسماء بين حِزم APK الجديدة مع تقدُّم المنصة، استخدم إرشادات التسمية التالية:

• com.android.*
  • محجوزة لـ AOSP APEXes. ليس فريدًا لأي شركة أو جهاز.
• com.<companyname>.*
  • محجوز لشركة. يمكن أن يتم استخدامه من قِبل أجهزة متعددة الاتصالات.
• com.<companyname>.<devicename>.*
  • محجوزة لحِزم APK الفريدة لجهاز معيّن (أو مجموعة فرعية من الأجهزة).

مدير APEX

مدير APEX (أو apexd) هو عملية أصلية مستقلة ومسؤولة عن والتحقق من ملفات APEX وتثبيتها وإلغاء تثبيتها. تم إطلاق هذه العملية جاهزًا في وقت مبكر من تسلسل التمهيد. عادةً ما يتم تثبيت ملفات APEX مسبقًا على الجهاز ضمن /system/apex. يستخدم مدير APEX تلقائيًا هذه الإعدادات الحزم في حالة عدم توفر تحديثات.

يستخدم تسلسل تحديث ملف APEX فئة PackageManager وتكون على النحو التالي.

1. يتم تنزيل ملف APEX عبر تطبيق أداة تثبيت الحزم أو أداة ADB أو غير ذلك المصدر.
2. يبدأ مدير الحزمة إجراء التثبيت. عند إدراكك أن يكون الملف APEX، وينقل مدير الحزم التحكم إلى APEX مدير المشروع.
3. يتحقّق مدير APEX من ملف APEX.
4. في حال تم التحقّق من ملف APEX، سيتم حفظ قاعدة البيانات الداخلية لمدير APEX للإشارة إلى تفعيل ملف APEX عند التشغيل في المرة التالية.
5. يتلقّى مقدِّم طلب التثبيت بثًا على الحزمة الناجحة. التحقق.
6. لمواصلة التثبيت، يجب إعادة تشغيل النظام.

7. في مرحلة التشغيل التالية، يبدأ مدير APEX ويقرأ قاعدة البيانات الداخلية ما يلي لكل ملف APEX مُدرَج:

   1. للتحقّق من ملف APEX
   2. ينشئ جهاز استرجاع من ملف APEX.
   3. ينشئ جهاز كتلة خرائط للأجهزة أعلى جهاز الاسترجاع.
   4. تثبيت جهاز كتلة خرائط الجهاز على مسار فريد (على سبيل المثال، /apex/name@ver).

عند تثبيت جميع ملفات APEX المدرجة في قاعدة البيانات الداخلية، يحدد ملف APEX مدير يوفر خدمة الربط لمكونات النظام الأخرى للاستعلام للحصول على معلومات حول ملفات APEX المثبَّتة. على سبيل المثال، يستخدم النظام الآخر يمكن الاستعلام من قائمة ملفات APEX المثبتة في الجهاز أو الاستعلام عن المسار الدقيق الذي يتم فيه تثبيت APEX معيّن، وبالتالي يمكن الوصول إلى الملفات.

ملفات APEX هي ملفات APK

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

حجم الملف AndroidManifest.xml داخل ملف APEX هو الحد الأدنى، وهو يتكون من الحزمة name وversionCode والطرد الاختياري targetSdkVersion وminSdkVersion وmaxSdkVersion للاستهداف الدقيق. تتيح هذه المعلومات استخدام APEX الملفات المطلوب تسليمها عبر القنوات الحالية مثل تطبيقات أداة تثبيت الحزم ADB.

أنواع الملفات المتوافقة

يتوافق تنسيق APEX مع أنواع الملفات التالية:

• libs المشتركة الأصلية
• إعلانات تنفيذية أصلية
• ملفات JAR
• ملفات البيانات
• ملفات الإعداد

ولا يعني ذلك أنّ APEX يمكنها تعديل كل أنواع الملفات هذه. ما إذا كان الملف نوع يعتمد على النظام الأساسي ومدى استقرار تعريفات واجهات أنواع الملفات.

خيارات التوقيع

يتم توقيع ملفات APEX بطريقتين. أولاً، إنّ apex_payload.img (على وجه التحديد، فإن واصف vbmeta ملحق بـ apex_payload.img) تم توقيعه بمفتاح. بعد ذلك، يتم توقيع APEX بالكامل باستخدام الإصدار 3 من مخطّط توقيع حِزم APK يتم استخدام مفتاحين مختلفين في هذه العملية.

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

حزمة APEX في الأقسام المدمجة

يمكن العثور على ملفات APEX في أقسام مضمَّنة، مثل /system. تشير رسالة الأشكال البيانية في الوقت الحالي، يتم تثبيت ملفات APEX مباشرةً. من خلال جهاز الاسترجاع.

في حال توفُّر ملف APEX في قسم مضمّن، يمكن تعديل حزمة APEX من خلال توفير حزمة APEX التي تحمل اسم الحزمة نفسها وبأكبر من أو يساوي إلى رمز الإصدار. يتم تخزين ملف APEX الجديد في /data، وعلى غرار حِزم APK، يتم تخزين ملف الإصدار المثبت حديثًا يظل الإصدار الموجود بالفعل في الإصدار المدمج قسم القرص. وعلى عكس حِزم APK، لا يوفّر الإصدار المثبّت حديثًا من APEX سوى ويتم تنشيطها بعد إعادة التشغيل.

متطلبات النواة (Kernel)

لإتاحة وحدات APEX الرئيسية على جهاز Android، يمكن استخدام نظام التشغيل Linux التالي ميزات kernel مطلوبة: برنامج تشغيل الاسترجاع وdm-verity. الاسترجاع برنامج التشغيل يثبّت صورة نظام الملفات في وحدة APEX ويتحقق dm-verity من APEX.

يُعد أداء برنامج تشغيل الاسترجاع وdm-verity أمرًا مهمًا لتحقيق بأداء جيد للنظام عند استخدام وحدات APEX.

إصدارات النواة المتوافقة

تتوفّر وحدات APEX الرئيسية على الأجهزة التي تستخدم الإصدار 4.4 من النواة أو الإصدارات أعلى. إطلاق الأجهزة الجديدة التي تعمل بنظام التشغيل Android 10 أو الإصدارات الأحدث استخدام الإصدار 4.9 من النواة أو الإصدارات الأحدث للتوافق مع وحدات APEX

تصحيحات النواة المطلوبة

يتم تضمين رموز تصحيح النواة المطلوبة لدعم وحدات APEX في الشجرة الشائعة في Android استخدِم أحدث إصدار للحصول على رموز التصحيح التي تتوافق مع APEX. للشجرة المشتركة في Android.

الإصدار 4.4 من النواة

لا يتوفّر هذا الإصدار إلا للأجهزة التي تمت ترقيتها من Android 9 إلى نظام التشغيل Android 10 ويريدون استخدام وحدات APEX للحصول على التصحيحات المطلوبة، فالدمج المنخفض من فرع android-4.4 يكون بشدّة. الموصى بها. في ما يلي قائمة برموز التصحيحات الفردية المطلوبة للنواة الإصدار 4.4.

• UPSTREAM: التكرار الحلقي: إضافة ioctl لتغيير حجم الكتلة المنطقي (4.4)
• BACKPORT: حظر/حلقة: set hw_sectors (4.4)
• UPSTREAM: التكرار الحلقي: إضافة LOOP_SET_BLOCK_size في compat ioctl (4.4)
• ANDROID: mnt: إصلاح next_descendent (4.4)
• ANDROID: أمر: يجب أن تنتشر إعادة التحميل على عبيد العبيد (4.4)
• ANDROID: أمر: نشر إعادة التحميل بشكل صحيح (4.4)
• إلغاء التغييرات الأخيرة على "ANDROID: dm verity: إضافة الحد الأدنى لحجم الجلب المسبق" (4.4)
• UPSTREAM: التكرار الحلقي: إفلات ذاكرات التخزين المؤقت في حالة تغيير الإزاحة أو حجم الكتلة (4.4)

إصدارات النواة 4.9/4.14/4.19

للحصول على التصحيحات المطلوبة لإصدارات النواة 4.9/4.14/4.19، عليك الدمج من فرع android-common.

خيارات إعداد النواة المطلوبة

توضح القائمة التالية متطلبات الإعدادات الأساسية لدعم وحدات APEX التي تم طرحها في نظام التشغيل Android 10 العناصر المميزة بعلامة النجمة (*) متطلبات حالية من الإصدار Android 9 والإصدارات الأقدم

(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support

متطلبات مَعلمات سطر أوامر النواة (Kernel)

لإتاحة واجهة APEX، يجب التأكُّد من أنّ معلَمات سطر الأوامر في kernel تستوفي ما يلي: المتطلبات:

• يجب عدم ضبط loop.max_loop
• يجب أن تكون قيمة loop.max_part أقل من أو تساوي 8.

بناء APEX

يوضّح هذا القسم كيفية إنشاء واجهة APEX باستخدام نظام إصدار Android. في ما يلي مثال على Android.bp لملف APK باسم apex.test.

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    // libc.so and libcutils.so are included in the apex
    native_shared_libs: ["libc", "libcutils"],
    binaries: ["vold"],
    java_libs: ["core-all"],
    prebuilts: ["my_prebuilt"],
    compile_multilib: "both",
    key: "apex.test.key",
    certificate: "platform",
}

مثال لـ apex_manifest.json:

{
  "name": "com.android.example.apex",
  "version": 1
}

مثال لـ file_contexts:

(/.*)?           u:object_r:system_file:s0
/sub(/.*)?       u:object_r:sub_file:s0
/sub/file3       u:object_r:file3_file:s0

أنواع الملفات ومواقعها الجغرافية في APEX

التبعيات الانتقالية

تتضمن ملفات APEX تلقائيًا تبعيات متبادلة لملفات libs المشتركة الأصلية أو ملفات تنفيذية. على سبيل المثال، إذا كانت libFoo تعتمد على libBar، يتم تنسيق لغتَي الليبتين يتم تضمينها عندما يتم إدراج libFoo فقط في السمة native_shared_libs.

التعامل مع واجهات ABI متعددة

تثبيت السمة native_shared_libs لكلّ من اللغة الأساسية والثانوية واجهات التطبيق الثنائية (ABI) في الجهاز. إذا كانت حزمة APEX تستهدف أجهزة باستخدام واجهة تطبيق ثنائية (ABI) واحدة (أي 32 بت فقط أو 64 بت فقط)، تثبيت واجهة التطبيق الثنائية (ABI) المقابلة.

يجب تثبيت السمة binaries لواجهة التطبيق الثنائية (ABI) الأساسية فقط للجهاز باسم الموضحة أدناه:

• وإذا كان الجهاز يعمل بإصدار 32 بت فقط، سيتم استخدام صيغة 32 بت فقط من البرنامج الثنائي. مثبت.
• إذا كان الجهاز يعمل بإصدار 64 بت فقط، لن يكون سوى صيغة 64 بت من البرنامج الثنائي مثبت.

لإضافة تحكم أكثر دقة على واجهات ABI في المكتبات والبرامج الثنائية الأصلية، استخدام multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] المواقع.

• first: يتطابق مع واجهة التطبيق الثنائية (ABI) الأساسية للجهاز. هذا هو الإعداد الافتراضي البرامج الثنائية.
• lib32: يطابق واجهة التطبيق الثنائية (ABI) 32 بت للجهاز، إذا كان متوافقًا.
• lib64: يتوافق مع واجهة التطبيق الثنائية (ABI) 64 بت، وهو متوافق.
• prefer32: يطابق واجهة التطبيق الثنائية (ABI) 32 بت للجهاز، إذا كان متوافقًا. إذا كانت وهذه الواجهة غير متوافقة مع واجهة التطبيق الثنائية (ABI) 32 بت.
• both: يطابق كلاً من واجهات التطبيق الثنائية (ABI). هذا هو الإعداد الافتراضي native_shared_libraries

لا تتوافق المواقع java وlibraries وprebuilts مع واجهة التطبيق الثنائية (ABI).

هذا المثال مع جهاز متوافق مع عرض 32/64 ولا يفضّل 32:

apex {
    // other properties are omitted
    native_shared_libs: ["libFoo"], // installed for 32 and 64
    binaries: ["exec1"], // installed for 64, but not for 32
    multilib: {
        first: {
            native_shared_libs: ["libBar"], // installed for 64, but not for 32
            binaries: ["exec2"], // same as binaries without multilib.first
        },
        both: {
            native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
            binaries: ["exec3"], // installed for 32 and 64
        },
        prefer32: {
            native_shared_libs: ["libX"], // installed for 32, but not for 64
        },
        lib64: {
            native_shared_libs: ["libY"], // installed for 64, but not for 32
        },
    },
}

توقيع vbmeta

وقِّع كل ملف APEX باستخدام مفاتيح مختلفة. عندما يكون مفتاحًا جديدًا مطلوبًا، يمكنك إنشاء زوج من المفاتيح العامة والخاصة وإنشاء وحدة apex_key. استخدِم السمة key من أجل: وأوقّع على ملف APEX باستخدام المفتاح. ويتم تضمين المفتاح العام تلقائيًا في ملف APEX الذي يحمل الاسم avb_pubkey.

# create an rsa key pair
openssl genrsa -out foo.pem 4096

# extract the public key from the key pair
avbtool extract_public_key --key foo.pem --output foo.avbpubkey

# in Android.bp
apex_key {
    name: "apex.test.key",
    public_key: "foo.avbpubkey",
    private_key: "foo.pem",
}

في المثال أعلاه، يصبح اسم المفتاح العام (foo) هو رقم تعريف المفتاح المفتاح. تتم كتابة رقم تعريف المفتاح المستخدَم للتوقيع على حزمة APEX في ملف APEX. في وقت التشغيل، يتحقّق apexd من ملف APEX باستخدام مفتاح عام يحمل رقم التعريف نفسه في الجهاز.

توقيع APEX

توقيع ملفات APK بالطريقة نفسها التي تتّبعها لتوقيع حِزم APK توقيع APEXes مرتين؛ مرة واحدة ملف مصغر (ملف apex_payload.img) ومرة واحدة للملف بالكامل.

للتوقيع على ملف APEX على مستوى الملف، يجب ضبط السمة certificate في إحدى هذه الطرق الثلاث:

• لم يتم الضبط: في حال عدم ضبط أي قيمة، سيتم توقيع ملف APEX باستخدام الشهادة المتوفّرة. في PRODUCT_DEFAULT_DEV_CERTIFICATE. إذا لم يتم ضبط أي علامة، سيتم ضبط المسار تلقائيًا. إلى build/target/product/security/testkey.
• <name>: تم توقيع ملف APEX باستخدام شهادة <name> بالطريقة نفسها. الدليل باسم PRODUCT_DEFAULT_DEV_CERTIFICATE.
• :<name>: يتم توقيع ملف APEX باستخدام الشهادة التي تم تحديدها بواسطة باسم وحدة "سونغ" باسم "<name>". يمكن تعريف وحدة الشهادة على أنها يتابعها.

android_app_certificate {
    name: "my_key_name",
    certificate: "dir/cert",
    // this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}

تثبيت ملف APEX

لتثبيت حزمة APEX، استخدِم أداة ADB.

adb install apex_file_name
adb reboot

إذا تم ضبط supportsRebootlessUpdate على true في apex_manifest.json APEX المثبت حاليًا غير مستخدم (على سبيل المثال، أي خدمات تحتوي عليها تحتوي على تم إيقافها)، فيمكن تثبيت ملف APEX جديد بدون إعادة تشغيل الجهاز إبلاغ --force-non-staged

adb install --force-non-staged apex_file_name

استخدام ملف APEX

بعد إعادة التشغيل، يتم تثبيت APEX في /apex/<apex_name>@<version>. الدليل. يمكن تثبيت إصدارات متعددة من ملف APEX نفسه في الوقت نفسه. من بين مسارات التثبيت، المسار الذي يتوافق مع أحدث إصدار هو تم تثبيت الربط في /apex/<apex_name>.

يمكن للعملاء استخدام المسار المثبَّت على الربط لقراءة الملفات من APEX أو تنفيذها.

تُستخدم APEX عادةً على النحو التالي:

1. يحمِّل المصنّع الأصلي للجهاز أو المصنّع الأصلي للجهاز ملف APEX مسبقًا ضمن /system/apex عندما يكون الجهاز: شحنها.
2. يمكن الوصول إلى الملفات في APEX من خلال مسار /apex/<apex_name>/.
3. عند تثبيت إصدار مُحدَّث من ملف APEX في "/data/apex"، يبدأ المسار يشير إلى ملف APEX الجديد بعد إعادة التشغيل.

تعديل خدمة باستخدام ملف APEX

لتعديل خدمة باستخدام ملف APEX:

1. ضَع علامة على الخدمة في قسم النظام تشير إلى أنّها قابلة للتحديث. إضافة الخيار updatable إلى تعريف الخدمة.

   /system/etc/init/myservice.rc:
   
   service myservice /system/bin/myservice
       class core
       user system
       ...
       updatable
   

2. أنشئ ملف .rc جديدًا للخدمة المعدّلة. استخدام الخيار override لإعادة تعريف الخدمة الحالية.

   /apex/my.apex/etc/init.rc:
   
   service myservice /apex/my.apex/bin/myservice
       class core
       user system
       ...
       override
   

لا يمكن تحديد تعريفات الخدمة إلا في ملف .rc الخاص بملف APEX. ألعاب الحركة لا تتوافق المشغلات مع APEX.

في حال بدء خدمة تم وضع علامة عليها على أنّها قابلة للتحديث قبل تفعيل ملفات APK، يجب حتى يكتمل تفعيل واجهات برمجة التطبيقات (APEX).

إعداد النظام لإتاحة تحديثات APEX

اضبط خاصية النظام التالية على true لإتاحة تعديلات ملف APEX.

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

أو فقط

<device.mk>:

$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)

مؤشر APEX ثابت

بالنسبة إلى الأجهزة القديمة، يستحيل أو لا يمكن أحيانًا تحديث لدعم APEX بشكل كامل. على سبيل المثال، ربما تم إنشاء النواة بدون CONFIG_BLK_DEV_LOOP=Y، وهو أمر بالغ الأهمية لتثبيت نظام الملفات داخل ملف APEX.

حزمة APEX المسطحة هي واجهة برمجة تطبيقات تم تصميمها خصيصًا ويمكن تفعيلها على الأجهزة المزوّدة نواة قديمة. إنّ الملفات المتوفّرة في ملف APEX مسطح يتم تثبيتها مباشرةً في دليل. أسفل التقسيم المضمَّن. على سبيل المثال، lib/libFoo.so في ملف APEX مسطّح تم تثبيت my.apex على /system/apex/my.apex/lib/libFoo.so.

لا يشمل تفعيل واجهة APEX المسطَّحة جهاز الحلقة. يتم ربط الدليل /system/apex/my.apex مباشرةً بـ /apex/name@ver.

لا يمكن تعديل حِزم APK المعدَّلة من خلال تنزيل النُسخ المعدَّلة. لنقاط الوصول (APEX) من الشبكة لعدم إمكانية تسوية حِزم APK التي تم تنزيلها. لا يمكن تعديل نقاط الوصول المسطحة إلا من خلال التحديث عبر الهواء العادي.

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

لا يجوز المزج بين نقاط الوصول المسطَّحة وغير المسطحة في الجهاز يجب أن تكون جميع نقاط النهاية في الجهاز غير مسطَّحة أو مسطّحة. ويعد ذلك مهمًا بشكل خاص عند الشحن باستخدام ملفات APEX الموقّعة مسبقًا مشروعات مثل Mainline. نقاط الوصول غير الموقعة مسبقًا (أي التي يتم إنشاؤها من المصدر) يجب أيضًا أن يكون غير مسطح وتوقيعه بمفاتيح مناسبة. تشير رسالة الأشكال البيانية يجب أن يكتسب الجهاز من updatable_apex.mk كما هو موضّح في تحديث خدمة باستخدام APEX:

ملفات APEX المضغوطة

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

يقلل ضغط APEX من تأثير مساحة التخزين هذه باستخدام مجموعة مضغوطة بدرجة كبيرة من ملفات APEX على أقسام للقراءة فقط (مثل قسم /system). جهاز Android 12 والإصدارات الأحدث تستخدم خوارزمية ضغط zip DEFLATE.

لا يوفر الضغط أي تحسين لما يلي:

• واجهات برمجة التطبيقات (APEX) التي يجب تثبيتها في وقت مبكر جدًا من التشغيل التسلسل.

• نقاط الوصول غير القابلة للتحديث. لا يكون الضغط مفيدًا إلا في حال تثبيت إصدار معدَّل من ملف APEX. في قسم /data. تتوفّر قائمة كاملة بحِزم APK القابلة للتحديث على مكوّنات النظام المعيارية .

• كائنات APEX لملفات تعريف الارتباط المشتركة الديناميكية. بما أنّ apexd يفعِّل دائمًا كلا الإصدارين من ملفات APEX هذه (المثبتة مسبقًا والتي تمت ترقيتها)، فإن ضغطها لا يضيف أي قيمة.

تنسيق ملف APEX المضغوط

وهذا هو تنسيق ملف APEX مضغوط.

الشكل 2. تنسيق ملف APEX المضغوط

في المستوى الأعلى، ملف APEX المضغوط هو ملف ZIP يحتوي على الملف الأصلي ملف apex في شكل مصغر بمستوى ضغط يبلغ 9، ومع ملفات أخرى المخزنة غير مضغوطة.

تشتمل أربعة ملفات على ملف APEX:

• original_apex: تم انكماشها بمستوى ضغط يبلغ 9. هذا هو ملف APEX الأصلي غير المضغوط.
• apex_manifest.pb: تم التخزين فقط
• AndroidManifest.xml: تم التخزين فقط
• apex_pubkey: تم التخزين فقط

الملفات apex_manifest.pb وAndroidManifest.xml وapex_pubkey هي من النسخ من الملفات المقابلة في original_apex.

إنشاء ملف APEX مضغوط

يمكن إنشاء ملف APEX المضغوط باستخدام أداة apex_compression_tool.py الموجودة على system/apex/tools

تتوفّر في نظام الإصدار العديد من المَعلمات المرتبطة بضغط APEX.

في Android.bp، يتم التحكّم في ما إذا كان ملف APEX قابلاً للضغط أم لا من خلال السمة compressible:

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    compressible: true,
}

تتحكّم علامة المنتج PRODUCT_COMPRESSED_APEX في ما إذا كان سيتم إنشاء صورة النظام من المصدر يجب أن يحتوي على ملفات APEX مضغوطة.

لإجراء التجارب المحلية، يمكنك فرض عملية إنشاء لضغط ملفات APEX من خلال ضبط OVERRIDE_PRODUCT_COMPRESSED_APEX= إلى true

تحتوي ملفات APEX المضغوطة التي تم إنشاؤها من خلال نظام الإصدار على الامتداد .capex. تسهّل الإضافة التمييز بين الملفات المضغوطة وغير المضغوطة نُسخًا من ملف APEX.

خوارزميات الضغط المتوافقة

لا يتوافق Android 12 إلا مع ميزة "الضغط المضغوط"

تفعيل ملف APEX مضغوط أثناء التشغيل

لكي تتمكن من تفعيل ملف APEX مضغوط، يجب تحميل ملف original_apex. وفك ضغطها في الدليل /data/apex/decompressed. نتيجة يكون ملف APEX المضغوط مرتبطًا بشكل ثابت بدليل /data/apex/active.

انظر المثال التالي كمثال على العملية الموضحة أعلاه.

التعامل مع /system/apex/com.android.foo.capex كملف APEX مضغوط وتفعيله، برمز الإصدار 37.

1. الملف original_apex داخل /system/apex/com.android.foo.capex هو وفك ضغطها إلى /data/apex/decompressed/com.android.foo@37.apex.
2. تم تنفيذ restorecon /data/apex/decompressed/com.android.foo@37.apex إلى التحقق من أنها تحتوي على تسمية SELinux صحيحة.
3. يتم تنفيذ عمليات التحقق من الملكية في /data/apex/decompressed/com.android.foo@37.apex للتأكد من صلاحيته: يتحقّق apexd من المفتاح العام المجمَّع. /data/apex/decompressed/com.android.foo@37.apex للتأكّد من أنّه مساوية إلى المجموعة المضمّنة في /system/apex/com.android.foo.capex.
4. ملف /data/apex/decompressed/com.android.foo@37.apex مرتبط مباشرةً بـ دليل /data/apex/active/com.android.foo@37.apex.
5. يتم تنفيذ منطق التفعيل العادي لملفات APEX غير المضغوطة على /data/apex/active/com.android.foo@37.apex

التفاعل مع التحديث عبر الهواء

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

لدعم نظام OTA، يعرض apexd واجهتَي برمجة تطبيقات الربط هاتَين:

• calculateSizeForCompressedApex - لحساب الحجم المطلوب لفك الضغط APEX في حزمة OTA. ويمكن استخدامها للتحقق من أن الجهاز يحتوي على مساحة كافية قبل تنزيل التحديث عبر الهواء.
• reserveSpaceForCompressedApex - يحتفظ بالمساحة المتوفرة على القرص لاستخدامه في المستقبل بواسطة apexd لفك ضغط ملفات APEX المضغوطة داخل حزمة OTA.

في حال إجراء تحديث A/B عبر الهواء، يحاول apexd فك الضغط في الخلفية كجزء من سلسلة إجراءات ما بعد التثبيت عبر الهواء. وإذا فشل فك الضغط، ينفذ الجهاز apexd عملية فك الضغط أثناء عملية التشغيل التي تطبق التحديث عبر الهواء. تحديث.

البدائل التي يتم أخذها في الاعتبار عند تطوير APEX

في ما يلي بعض الخيارات التي وضعتها شركة AOSP في الاعتبار عند تصميم ملف APEX. وسبب تضمينها أو استبعادها.

أنظمة إدارة الحزم العادية

تحتوي توزيعات Linux على أنظمة إدارة حزم مثل dpkg وrpm، والتي تكون فعّالة ومخصّصة للبالغين وفعّالة ومع ذلك، لم يكن تم اعتمادها لـ APEX لأنها لا يمكنها حماية الحزم بعد التثبيت. يتم إجراء التحقق فقط عند تثبيت الحزم. ويمكن للمهاجمين تعطيل سلامة الحِزم المثبَّتة، بدون ملاحظتهم. هذا هو تراجع Android، حيث كانت جميع مكونات النظام مخزّنة في وضع القراءة فقط أنظمة الملفات التي تتم حماية سلامتها باستخدام dm-verity لكل إدخال/إخراج أي تقييم يجب حظر التلاعب بمكونات النظام أو أن يكون قابلاً للاكتشاف حتى إمكانية رفض الجهاز لتشغيله في حالة اختراقه.

dm-crypt للحفاظ على السلامة

إنّ الملفات في حاوية APEX هي من أقسام مُدمَجة (على سبيل المثال، قسم /system) المحمية باستخدام dm-verity، حيث تم إجراء أي تعديل على يتم حظر الملفات حتى بعد تثبيت الأقسام. لتوفير مستوى الأمان نفسه للملفات، سيتم تخزين جميع الملفات في ملف APEX في ملف صورة نظام يتم إقرانها مع شجرة تجزئة واصف vbmeta. بدون dm-verity، واجهة برمجة تطبيقات APEX في قسم /data معرَّضة للاختراق غير المقصود التعديلات التي يتم إجراؤها بعد التحقق من صحتها وتثبيتها.

وفي الواقع، تتم حماية قسم /data أيضًا من خلال طبقات التشفير مثل dm-crypt وبالرغم من أن هذا يوفر مستوى معين من الحماية ضد التلاعب، إلا أنه فإن الغرض الأساسي هو الخصوصية وليس السلامة. عندما يتمكن المهاجم من الوصول إلى /data، فلن يكون هناك حاجة إلى مزيد من الحماية، ومرة أخرى الانحدار مقارنةً بكل مكوّن نظام موجود في القسم /system. توفر شجرة التجزئة داخل ملف APEX مع dm-verity نفس مستوى حماية المحتوى.

إعادة توجيه المسارات من /system إلى /apex

يمكن الوصول إلى ملفات مكونات النظام المجمعة في APEX من خلال مسارات جديدة مثل /apex/<name>/lib/libfoo.so عندما كانت الملفات جزءًا من /system كان يمكن الوصول إليها من خلال مسارات مثل /system/lib/libfoo.so. حاسمة أن يستخدم عميل ملف APEX (ملفات APEX الأخرى أو النظام الأساسي) ملف والمسارات. قد تحتاج إلى تحديث الرمز الحالي نتيجةً لتغيير المسار.

على الرغم من أن إحدى الطرق لتجنب تغيير المسار هي تراكب محتويات الملف في APEX في قسم "/system"، قرر فريق Android عدم تركيب في قسم /system لأن ذلك قد يؤثر في أداء أداة عدد الملفات التي يتم تجميعها (ربما تكون مكدسة واحدًا تلو الآخر) زاد.

وكان الخيار الآخر هو اختراق وظائف الوصول إلى الملفات مثل open وstat readlink، بحيث تتم إعادة توجيه المسارات التي تبدأ بـ /system إلى المسارات المقابلة ضمن /apex. تجاهل فريق Android هذا الخيار. لأنه لا يمكن تغيير جميع الدوال التي تقبل المسارات. على سبيل المثال، تربط بعض التطبيقات Bionic بشكل ثابت، والتي تنفذ الدوال. وفي مثل هذه الحالات، لا تتم إعادة توجيه هذه التطبيقات.