APEX في Android Q: ما هو أكبر شيء منذ مشروع Treble؟

ربما يكون تنفيذ APEX هو أكبر مشكلة واجهتها Google منذ تقديم Project Treble. ما هو APEX، وكيف سيغير تقديمه نظام Android؟

الفكرة وراء APEX في حد ذاتها شائعة إلى حد ما في توزيعات GNU/Linux اليومية: تحديثات الحزمة تستهدف أقسامًا معينة من مجموعة مكتبات Linux. ولكن هذا شيء لم تحاول Google أبدًا القيام به نظرًا لأن Android استخدم قسم RO (للقراءة فقط) حيث توجد جميع مكتبات النظام و يتم تخزين أطر العمل مقابل أقسام RW (القراءة والكتابة) المعتادة المستخدمة في معظم توزيعات Linux، مما يجعل عملية الترقية القياسية غير ملائم.

المكتبات عبارة عن تعليمات برمجية مجمعة مسبقًا يمكن استخدامها في برامج أخرى. يمكن تحويل الأساليب شائعة الاستخدام إلى مكتبات لتطبيقات Android للاتصال بها، مما يؤدي إلى تقليل حجم ملفات APK حيث لن يلزم إعادة تنفيذ نفس الكود عبر تطبيقات متعددة. يمكنك العثور على العديد من مكتبات النظام المثبتة مسبقًا في المجلدين /system/lib و/system/lib64. لا يتم عادةً تحديث مكتبات نظام Android بشكل فردي، بل يتم تحديثها كجزء من ترقيات أنظمة Android الأساسية عبر تحديث عبر الهواء. من ناحية أخرى، قد يتم تحديث المكتبات في توزيعات Linux بشكل فردي. مع تقديم APEX، يمكن تحديث مكتبات النظام في Android بشكل فردي مثل تطبيقات Android. وتتمثل الفائدة الرئيسية لذلك في أن مطوري التطبيقات سيكونون قادرين على الاستفادة من المكتبات المحدثة دون انتظار الشركة المصنّعة للمعدات الأصلية (OEM) لبدء ترقية النظام بالكامل. دعنا نتعمق في المزيد من التفاصيل الفنية حول كيفية عمل APEX.

كيف ستغير APEX طريقة تحديث المكتبات؟

APEX هو نظام بيئي أجبر (أو بالأحرى يجبر) Google على إعادة النظر في الطريقة التي يقوم بها Android بتحميل جميع المكتبات والملفات من قسم غير قياسي يختلف عن /system.

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

قام Android بتكوين مسار المكتبة تاريخيًا (المعروف باسم LD_LIBRARY_PATH في عالم Linux) بملف واحد يسمى ld.config.txt [0] لتكوين مسارات البحث المسموح بها للمكتبات المشتركة التي يحتاجها إما ثنائي أو آخر مكتبة. هذه المسارات مضمنة في التكوين وغير قابلة للتوسيع. يؤدي هذا التخطيط، بما في ذلك قسم النظام للقراءة فقط، إلى مكتبات غير قابلة للتحديث ما لم يقوم المستخدم بتثبيت تحديث OTA Android. قامت Google بإصلاح هذه المشكلة من خلال السماح بتوسيع مسار البحث عن طريق السماح لحزم APEX الفردية بتوفير ld.config.txt الخاص بها والذي يتضمن مسارات المكتبات الإضافية (والمحدثة) الموجودة فيها.

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

لكن APEX لا يقتصر على المكتبات والثنائيات وحدها. في الواقع، يمكن أن يحتوي على ملفات التكوين وتحديثات المنطقة الزمنية وبعض أطر عمل Java (يتم تشفيرها في وقت كتابة هذا التقرير).

فيما يلي بعض الأمثلة على حزم APEX الحالية التي تقدمها AOSP:

• com.android.runtime: ART ووقت التشغيل الإلكتروني (الثنائيات والمكتبات)
• com.android.tzdata: بيانات المنطقة الزمنية وICU (المكتبات وبيانات التكوين)
• com.android.resolv: المكتبة التي يستخدمها Android لحل الطلبات المتعلقة بالشبكة (المكتبات)
• com.android.conscrypt: موفر أمان Java (إطار عمل Java)

كيف يتم تثبيت وتنظيم حزمة APEX؟

حزمة APEX عبارة عن أرشيف مضغوط بسيط (مثل APK) يمكن تثبيته بواسطة ADB سهل الاستخدام (في هذه المرحلة من التطوير) وبعد ذلك، بواسطة المستخدم نفسه عبر مدير الحزم (مثل Google Play أو يدويًا من خلال حزمة Android المثبت).

تخطيط ZIP كما يلي:

دعونا نتعمق في ذلك.

يحدد apex_manifest.json اسم الحزمة وإصدارها.

إن apex_payload.img عبارة عن صورة لنظام ملفات صغير (بتنسيق EXT4).

تعد الملفات الأخرى جزءًا من عملية التحقق المستخدمة لتثبيت الحزمة. لنلقي نظرة.

حضور ال AndroidManifest.xml، حتى لو تم استخدامه بشكل أساسي في التطبيقات، فهو يساعدنا على فهم أن معظم التطبيقات المستخدمة لتثبيت APK القياسي يتم إعادة استخدامها حتى لهذه الحزم. في الواقع، يتم فحص الامتداد فقط للتمييز بينهما.

ال معلومات التعريف/ يحتوي الدليل على شهادة الحزمة ويستخدم نفس آلية ملفات APK العادية. إذن هذه الحزم يتم التحقق منها بواسطة زوج مفاتيح خاص/عام في وقت التشغيل قبل السماح للمستخدم بتثبيت التحديث. لكن ذلك لم يكن كافيًا لشركة Google، لذا أضافت طبقتين إضافيتين من الأمان. إنهم يستخدمون dm-verity للتحقق من سلامة الصورة وعمليات التحقق من AVB (Android Verified Boot) للتأكد من أن الصورة تأتي من مصدر موثوق به. في أسوأ السيناريوهات، سيتم رفض حزمة APEX.

إذا نجحت جميع خطوات التحقق، فسيتم وضع علامة على الصورة على أنها صالحة وستحل محل متغير النظام عند إعادة التشغيل التالية.

كيف يتم تثبيت الصورة عند الإقلاع؟

لنبدأ بإلقاء نظرة على APEXes المثبتة حاليًا على جهازي (محاكي)

كما ترون، يتم تخزين الحزم المثبتة مسبقًا في /system/apex/ وجميعها حاليًا على الإصدار رقم 1. ولكن ماذا يحدث عند تنشيط APEX؟ سنستخدم مرة أخرى com.android.tzdata كمثال.

لنعد تشغيل الجهاز ونحلل السجل.

يوفر السطران الأولان معلومات كافية لفهم أصل الحزمة وأين ستكون تم التثبيت: /apex/، وهو دليل جديد تم تقديمه في Android Q والذي سيتم استخدامه لتخزين الملفات المنشط الحزم.

بعد التحقق من الحزمة بنجاح باستخدام AVB وتطابق المفتاح العام، يتم تثبيت APEX باستخدام جهاز حلقة إلى /dev/block/loop0، مما يجعل نظام الملفات EXT4 متاحًا للنظام. جهاز الحلقة هو جهاز زائف يجعل الملف قابلاً للوصول كجهاز كتلة، مما يجعل محتويات هذا الملف قابلة للوصول كنقطة تحميل.

في هذه المرحلة، لا يزال APEX غير مستخدم بسبب اللاحقة @1 (التي تشير إلى إصدار الحزمة). لإعلام النظام أخيرًا بأن الحزمة الخاصة بنا قد تم تنشيطها بنجاح، سيتم ربطها بـ /apex/com.android.tzdata حيث يتوقع Android بقاء tzdata بشكل نشط. يتراكب حامل الربط مع دليل أو ملف موجود ضمن نقطة مختلفة. [1]

يتم تضمين تطبيق APEX بالكامل في مستودع واحد ضمن AOSP. [2] يحتوي دليل apexd (APEX daemon) على الكود الذي يعمل على Android. يحتوي دليل apexer على الكود الذي يستخدمه نظام الإنشاء لإنشاء حزم APEX.

ما هو الغرض؟

في هذه المرحلة، كل ما يمكنني فعله هو التكهن. أفضل تخميني هو أن Google تحاول إنشاء مجموعة أساسية من حزم APEX التي يمكن تحديثها بواسطة Google لإنشاء مجموعة أساسية نواة أساسية موحدة لنظام Android يتم مشاركتها بين البائعين، مما يجعل تحديثات "النظام" ممكنة فقط، ولكن باستخدام حزمة واحدة التحديثات.

هل جميع الأجهزة ستدعم APEX؟

لا. على سبيل المثال، يتطلب apexd أن يكون /data/apex متاحًا مباشرة بعد التمهيد لتحديث جميع وحدات Android. باستخدام FDE (تشفير القرص الكامل)، يتم تشفير /data/apex حتى يتم إلغاء قفل الجهاز من قبل المستخدم، مما يجعل APEX عديم الفائدة بشكل أساسي حيث سيتم تحميل متغيرات APEX للنظام فقط عند التمهيد. بخلاف ذلك، يجب أن تدعم جميع الأجهزة APEX، ولكنها تحتاج إلى عدد قليل من تصحيحات kernel (العديد منها عبارة عن إصلاحات عثر عليها Google أثناء اللعب بأجهزة الحلقة). [3] [4]

---

مصادر [0], [1], [2], [3], [4]