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

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

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

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

  • تخزين التطبيقات المحمّلة مسبقًا في القسم B لتسريع عملية الإعداد
  • تخزين التطبيقات الرائجة في القسم B لتسريع عملية الاستعادة

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

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

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

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

لذلك، لا يمكن تعديل ذاكرة التخزين المؤقت لحِزم APK من خلال التحديثات عبر اتصال لاسلكي، ولا يمكن تحميلها مسبقًا إلا في المصنع. لا تؤثّر عملية إعادة الضبط على الإعدادات الأصلية إلا في قسم ‎ /data. سيظلّ القسم B من النظام يحتوي على المحتوى المحمّل مسبقًا إلى أن يتم تنزيل صورة التحديث عبر اتصال لاسلكي. بعد إعادة الضبط على الإعدادات الأصلية، سيخضع النظام لعملية التشغيل الأولى مرة أخرى. ويعني ذلك أنّه لا تتوفّر ميزة تخزين حِزم APK مؤقتًا إذا تم تنزيل صورة التحديث عبر الهواء إلى القسم 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/+/android17-release/sepolicy/preloads_copy.te
  4. سجِّل النطاق في ملف جديد باسم /sepolicy/file_contexts file: 
    /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.

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

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

تمت إضافة طريقة جديدة باسم 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