تخزين حِزم APK مؤقتًا

يوضّح هذا المستند تصميم حلّ لتخزين حِزم APK مؤقتًا بهدف تسريع عملية تثبيت التطبيقات المحمَّلة مسبقًا على جهاز يتيح استخدام أقسام A/B.

يمكن لمصنّعي المعدات الأصلية وضع التطبيقات المحمَّلة مسبقًا والتطبيقات الشائعة في ذاكرة التخزين المؤقت لحِزم APK المخزَّنة في القسم B الفارغ في الغالب على الأجهزة الجديدة المقسَّمة إلى قسمَين A/B بدون التأثير في أي مساحة بيانات مرئية للمستخدم. من خلال توفير ذاكرة تخزين مؤقت لحِزم APK على الجهاز، تصبح الأجهزة الجديدة أو التي تمت إعادة ضبطها على الإعدادات الأصلية مؤخرًا جاهزة للاستخدام على الفور تقريبًا، بدون الحاجة إلى تنزيل ملفات APK من Google Play.

حالات الاستخدام

• تخزين التطبيقات المحمَّلة مسبقًا في القسم B لإعدادها بشكل أسرع
• تخزين التطبيقات الشائعة في القسم B لاستعادتها بشكلٍ أسرع

المتطلّبات الأساسية

لاستخدام هذه الميزة، يجب أن يتوفّر في الجهاز ما يلي:

• تم تثبيت الإصدار 8.1 من نظام التشغيل Android (O MR1)
• تم تنفيذ تقسيم A/B

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

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

التنفيذ

الطريقة 1 المحتوى في قسم system_other

الإيجابيات: لا يتم فقدان المحتوى المحمَّل مسبقًا بعد إعادة الضبط على الإعدادات الأصلية، بل سيتم نسخه من القسم B بعد إعادة التشغيل.

العيوب: تتطلّب مساحة على القسم B. يتطلّب بدء التشغيل بعد إعادة الضبط على الإعدادات الأصلية وقتًا إضافيًا لنسخ المحتوى المحمَّل مسبقًا.

لكي يتم نسخ عمليات التحميل المُسبَق أثناء عملية التشغيل الأولى، يستدعي النظام نصًا برمجيًا في /system/bin/preloads_copy.sh. يتم استدعاء البرنامج النصي باستخدام وسيطة واحدة (المسار إلى نقطة الربط للقراءة فقط لقسم system_b):

لتفعيل هذه الميزة، عليك إجراء التغييرات التالية الخاصة بالجهاز. إليك مثال من Marlin:

1. أضِف النص البرمجي الذي ينفّذ عملية النسخ إلى ملف device-common.mk (في هذه الحالة، device/google/marlin/device-common.mk) على النحو التالي:

   # Script that copies preloads directory from system_other to data partition
   PRODUCT_COPY_FILES += \
       device/google/marlin/preloads_copy.sh:system/bin/preloads_copy.sh
   

   يمكنك العثور على مثال لمصدر البرنامج النصي على: device/google/marlin/preloads_copy.sh
2. عدِّل ملف init.common.rc لإنشاء الدليل /data/preloads والأدلة الفرعية اللازمة:

   mkdir /data/preloads 0775 system system
   mkdir /data/preloads/media 0775 system system
   mkdir /data/preloads/demo 0775 system system
   

   يمكنك العثور على مصدر ملف المثال init على: device/google/marlin/init.common.rc
3. حدِّد نطاق SELinux جديدًا في الملف preloads_copy.te:

   type preloads_copy, domain, coredomain;
   type preloads_copy_exec, exec_type, vendor_file_type, file_type;
   
   init_daemon_domain(preloads_copy)
   
   allow preloads_copy shell_exec:file rx_file_perms;
   allow preloads_copy toolbox_exec:file rx_file_perms;
   allow preloads_copy preloads_data_file:dir create_dir_perms;
   allow preloads_copy preloads_data_file:file create_file_perms;
   allow preloads_copy preloads_media_file:dir create_dir_perms;
   allow preloads_copy preloads_media_file:file create_file_perms;
   
   # Allow to copy from /postinstall
   allow preloads_copy system_file:dir r_dir_perms;
   

   يمكنك العثور على مثال لملف نطاق SELinux على الرابط التالي: /device/google/marlin/+/android16-release/sepolicy/preloads_copy.te
4. تسجيل النطاق في ملف /sepolicy/file_contexts جديد:

   /system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
   

   يمكنك العثور على مثال لملف سياقات SELinux على الرابط التالي: device/google/marlin/sepolicy/preloads_copy.te
5. في وقت الإنشاء، يجب نسخ الدليل الذي يتضمّن المحتوى المُحمَّل مُسبقًا إلى القسم system_other:

   # Copy contents of preloads directory to system_other partition
   PRODUCT_COPY_FILES += \
       $(call find-copy-subdir-files,*,vendor/google_devices/marlin/preloads,system_other/preloads)
   

   هذا مثال على تغيير في ملف Makefile يسمح بنسخ موارد ذاكرة التخزين المؤقت لحِزم APK من مستودع Git الخاص بالمورّد (في حالتنا، كان vendor/google_devices/marlin/preloads) إلى الموقع الجغرافي على قسم system_other الذي سيتم نسخه لاحقًا إلى /data/preloads عند تشغيل الجهاز للمرة الأولى. يتم تشغيل هذا النص البرمجي في وقت الإنشاء لإعداد صورة system_other. ويتوقّع أن يتوفّر المحتوى المحمَّل مسبقًا في vendor/google_devices/marlin/preloads. يمكن لمصنّع المعدات الأصلية اختيار اسم/مسار المستودع الفعلي.
6. يقع ذاكرة التخزين المؤقت لملفات APK في /data/preloads/file_cache، ويكون تنسيقه على النحو التالي:

   /data/preloads/file_cache/
       app.package.name.1/
             file1
             fileN
       app.package.name.N/
   

   هذه هي بنية الدليل النهائية على الأجهزة. يمكن لمصنّعي المعدات الأصلية اختيار أي طريقة تنفيذ طالما أنّ بنية الملف النهائية تحاكي البنية الموضّحة أعلاه.

الطريقة 2 المحتوى المتعلّق ببيانات المستخدم التي تم عرضها بشكل سريع في المصنع

يفترض هذا الأسلوب البديل أنّ المحتوى المحمَّل مسبقًا مضمّن في الدليل /data/preloads على القسم /data.

الإيجابيات: تعمل هذه الميزة بدون أي إعدادات مسبقة، ولا حاجة إلى إجراء أي تخصيصات على الجهاز لنسخ الملفات عند التشغيل لأول مرة. المحتوى متوفّر حاليًا في قسم /data.

العيوب: يتم فقدان المحتوى المحمَّل مسبقًا بعد إعادة الضبط على الإعدادات الأصلية. مع أنّ هذا الإجراء قد يكون مقبولاً لدى البعض، إلا أنّه قد لا يكون مناسبًا دائمًا لمصنّعي المعدات الأصلية الذين يعيدون ضبط الأجهزة على الإعدادات الأصلية بعد إجراء عمليات فحص مراقبة الجودة.

تمت إضافة طريقة جديدة @SystemApi، وهي getPreloadsFileCache()، إلى android.content.Context. تعرض هذه الطريقة مسارًا مطلقًا إلى دليل خاص بالتطبيق في ذاكرة التخزين المؤقت المحمَّلة مسبقًا.

تمت إضافة طريقة جديدة، وهي IPackageManager.deletePreloadsFileCache، تتيح حذف دليل عمليات التحميل المُسبَق لاستعادة كل المساحة. لا يمكن استدعاء الطريقة إلا من خلال التطبيقات التي تحمل SYSTEM_UID، أي خادم النظام أو تطبيق "الإعدادات".

إعداد التطبيق

يمكن للتطبيقات التي لديها امتيازات فقط الوصول إلى دليل ذاكرة التخزين المؤقت للتحميل المُسبَق. وللحصول على هذا الإذن، يجب تثبيت التطبيقات في الدليل /system/priv-app.

التحقُّق

• بعد عملية التشغيل الأولى، من المفترض أن يحتوي الجهاز على محتوى في الدليل /data/preloads/file_cache.
• يجب حذف المحتوى في الدليل file_cache/ إذا كانت مساحة التخزين في الجهاز منخفضة.

استخدِم تطبيق ApkCacheTest كمثال لاختبار ذاكرة التخزين المؤقت لحِزم APK.

1. أنشئ التطبيق من خلال تنفيذ الأمر التالي من الدليل الجذر:

   make ApkCacheTest
   

2. ثبِّت التطبيق كتطبيق ذي امتيازات (تذكَّر أنّه لا يمكن للتطبيقات ذات الامتيازات فقط الوصول إلى ذاكرة التخزين المؤقت لحِزم APK). يتطلّب ذلك جهازًا مزوّدًا بإذن الوصول إلى الجذر:

   adb root && adb remount
   adb shell mkdir /system/priv-app/ApkCacheTest
   adb push $ANDROID_PRODUCT_OUT/data/app/ApkCacheTest/ApkCacheTest.apk /system/priv-app/ApkCacheTest/
   adb shell stop && adb shell start
   

3. محاكاة دليل ذاكرة التخزين المؤقت للملفات ومحتواه إذا لزم الأمر (يتطلب ذلك أيضًا امتيازات الجذر):

   adb shell mkdir -p /data/preloads/file_cache/com.android.apkcachetest
   adb shell restorecon -r /data/preloads
   adb shell "echo "Test File" > /data/preloads/file_cache/com.android.apkcachetest/test.txt"
   

4. اختبِر التطبيق. بعد تثبيت التطبيق وإنشاء دليل الاختبار file_cache، افتح تطبيق ApkCacheTest. من المفترض أن يعرض ملفًا واحدًا test.txt ومحتواه. راجِع لقطة الشاشة هذه لمعرفة كيفية ظهور هذه النتائج في واجهة المستخدم.

   

   الشكل 1. نتائج ApkCacheTest.