طرح تنسيق حاوية 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 وتكون على النحو التالي.
- يتم تنزيل ملف APEX عبر تطبيق أداة تثبيت الحزم أو أداة ADB أو غير ذلك المصدر.
- يبدأ مدير الحزمة إجراء التثبيت. عند إدراكك أن يكون الملف APEX، وينقل مدير الحزم التحكم إلى APEX مدير المشروع.
- يتحقّق مدير APEX من ملف APEX.
- في حال تم التحقّق من ملف APEX، سيتم حفظ قاعدة البيانات الداخلية لمدير APEX للإشارة إلى تفعيل ملف APEX عند التشغيل في المرة التالية.
- يتلقّى مقدِّم طلب التثبيت بثًا على الحزمة الناجحة. التحقق.
- لمواصلة التثبيت، يجب إعادة تشغيل النظام.
في مرحلة التشغيل التالية، يبدأ مدير APEX ويقرأ قاعدة البيانات الداخلية ما يلي لكل ملف APEX مُدرَج:
- للتحقّق من ملف APEX
- ينشئ جهاز استرجاع من ملف APEX.
- ينشئ جهاز كتلة خرائط للأجهزة أعلى جهاز الاسترجاع.
- تثبيت جهاز كتلة خرائط الجهاز على مسار فريد (على سبيل المثال،
/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 |
---|---|
المكتبات المشتركة | /lib و/lib64 (/lib/arm مقابل
المجموعة المترجَمة في x86) |
الملفات التنفيذية | /bin |
مكتبات Java | /javalib |
مُنشأة مسبقًا | /etc |
التبعيات الانتقالية
تتضمن ملفات 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 pairopenssl genrsa -out foo.pem 4096
# extract the public key from the key pairavbtool extract_public_key --key foo.pem --output foo.avbpubkey
# in Android.bpapex_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 عادةً على النحو التالي:
- يحمِّل المصنّع الأصلي للجهاز أو المصنّع الأصلي للجهاز ملف APEX مسبقًا ضمن
/system/apex
عندما يكون الجهاز: شحنها. - يمكن الوصول إلى الملفات في APEX من خلال مسار
/apex/<apex_name>/
. - عند تثبيت إصدار مُحدَّث من ملف APEX في "
/data/apex
"، يبدأ المسار يشير إلى ملف APEX الجديد بعد إعادة التشغيل.
تعديل خدمة باستخدام ملف APEX
لتعديل خدمة باستخدام ملف APEX:
ضَع علامة على الخدمة في قسم النظام تشير إلى أنّها قابلة للتحديث. إضافة الخيار
updatable
إلى تعريف الخدمة./system/etc/init/myservice.rc: service myservice /system/bin/myservice class core user system ... updatable
أنشئ ملف
.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.
- الملف
original_apex
داخل/system/apex/com.android.foo.capex
هو وفك ضغطها إلى/data/apex/decompressed/com.android.foo@37.apex
. - تم تنفيذ
restorecon /data/apex/decompressed/com.android.foo@37.apex
إلى التحقق من أنها تحتوي على تسمية SELinux صحيحة. - يتم تنفيذ عمليات التحقق من الملكية في
/data/apex/decompressed/com.android.foo@37.apex
للتأكد من صلاحيته: يتحقّقapexd
من المفتاح العام المجمَّع./data/apex/decompressed/com.android.foo@37.apex
للتأكّد من أنّه مساوية إلى المجموعة المضمّنة في/system/apex/com.android.foo.capex
. - ملف
/data/apex/decompressed/com.android.foo@37.apex
مرتبط مباشرةً بـ دليل/data/apex/active/com.android.foo@37.apex
. - يتم تنفيذ منطق التفعيل العادي لملفات 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 بشكل ثابت، والتي تنفذ الدوال.
وفي مثل هذه الحالات، لا تتم إعادة توجيه هذه التطبيقات.