APK ক্যাশিং

এই দস্তাবেজটি A/B পার্টিশন সমর্থন করে এমন একটি ডিভাইসে প্রিলোড করা অ্যাপগুলির দ্রুত ইনস্টলেশনের জন্য একটি APK ক্যাশিং সমাধানের নকশা বর্ণনা করে।

OEMগুলি ব্যবহারকারী-মুখী ডেটা স্থানকে প্রভাবিত না করেই নতুন A/B- পার্টিশন করা ডিভাইসগুলিতে বেশিরভাগ খালি B পার্টিশনে সঞ্চিত APK ক্যাশে প্রিলোড এবং জনপ্রিয় অ্যাপগুলি রাখতে পারে। ডিভাইসে একটি APK ক্যাশে উপলব্ধ থাকার মাধ্যমে, নতুন বা সম্প্রতি ফ্যাক্টরি রিসেট ডিভাইসগুলি প্রায় অবিলম্বে ব্যবহারের জন্য প্রস্তুত, Google Play থেকে APK ফাইলগুলি ডাউনলোড করার প্রয়োজন ছাড়াই৷

কেস ব্যবহার করুন

• দ্রুত সেটআপের জন্য বি পার্টিশনে প্রিলোড করা অ্যাপস সংরক্ষণ করুন
• দ্রুত পুনরুদ্ধারের জন্য B পার্টিশনে জনপ্রিয় অ্যাপ সংরক্ষণ করুন

পূর্বশর্ত

এই বৈশিষ্ট্যটি ব্যবহার করতে, ডিভাইসটির প্রয়োজন:

• Android 8.1 (O MR1) রিলিজ ইনস্টল করা হয়েছে
• A/B পার্টিশন বাস্তবায়িত হয়েছে

প্রিলোড করা কন্টেন্ট শুধুমাত্র প্রথম বুট করার সময় কপি করা যাবে। এর কারণ হল A/B সিস্টেম আপডেট সমর্থন করে এমন ডিভাইসগুলিতে, B পার্টিশন আসলে সিস্টেম ইমেজ ফাইল সংরক্ষণ করে না, বরং রিটেল ডেমো রিসোর্স, OAT ফাইল এবং APK ক্যাশে প্রিলোড করা সামগ্রী। সম্পদগুলি /data পার্টিশনে অনুলিপি করার পরে (এটি প্রথম বুটে ঘটে), সিস্টেম ইমেজের আপডেট সংস্করণগুলি ডাউনলোড করার জন্য B পার্টিশনটি ওভার-দ্য-এয়ার (OTA) আপডেট দ্বারা ব্যবহার করা হবে।

অতএব, APK ক্যাশে OTA এর মাধ্যমে আপডেট করা যাবে না; এটি শুধুমাত্র একটি কারখানায় প্রিলোড করা যেতে পারে। ফ্যাক্টরি রিসেট শুধুমাত্র /ডেটা পার্টিশনকে প্রভাবিত করে। OTA ইমেজ ডাউনলোড না হওয়া পর্যন্ত সিস্টেম B পার্টিশনে প্রিলোড করা কন্টেন্ট থাকে। ফ্যাক্টরি রিসেট করার পরে, সিস্টেমটি আবার প্রথম বুটের মধ্য দিয়ে যাবে। এর মানে হল যদি OTA ইমেজ B পার্টিশনে ডাউনলোড করা হয়, এবং তারপর ডিভাইসটি ফ্যাক্টরি রিসেট হয় তাহলে APK ক্যাশিং পাওয়া যায় না।

বাস্তবায়ন

পদ্ধতি 1. সিস্টেম_অন্যান্য পার্টিশনের বিষয়বস্তু

প্রো : ফ্যাক্টরি রিসেট করার পরে প্রিলোড করা সামগ্রী হারিয়ে যায় না - এটি রিবুট করার পরে B পার্টিশন থেকে অনুলিপি করা হবে।

কন : বি পার্টিশনে স্থান প্রয়োজন। ফ্যাক্টরি রিসেটের পর বুট করার জন্য প্রিলোড করা কন্টেন্ট কপি করার জন্য অতিরিক্ত সময় প্রয়োজন।

প্রথম বুট করার সময় প্রিলোড কপি করার জন্য, সিস্টেম /system/bin/preloads_copy.sh এ একটি স্ক্রিপ্ট কল করে। স্ক্রিপ্টটিকে একটি একক যুক্তি দিয়ে ডাকা হয় ( system_b পার্টিশনের জন্য শুধুমাত্র পঠনযোগ্য মাউন্ট পয়েন্টের পথ):

এই বৈশিষ্ট্যটি বাস্তবায়ন করতে, এই ডিভাইস-নির্দিষ্ট পরিবর্তনগুলি করুন৷ এখানে মার্লিন থেকে একটি উদাহরণ:

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. প্রয়োজনীয় /data/preloads ডিরেক্টরি এবং সাবডিরেক্টরি তৈরি করতে init.common.rc ফাইলটি সম্পাদনা করুন:

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

   ডিভাইস/google/marlin/init.common.rc- এ উদাহরণ init ফাইলের উৎস খুঁজুন
3. preloads_copy.te ফাইলে একটি নতুন SELinux ডোমেন সংজ্ঞায়িত করুন :

   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/+/main/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)
   

   এটি একটি মেকফাইলের পরিবর্তনের একটি উদাহরণ যা বিক্রেতার গিট সংগ্রহস্থল থেকে APK ক্যাশে সংস্থানগুলি অনুলিপি করার অনুমতি দেয় (আমাদের ক্ষেত্রে এটি ছিল vendor/google_devices/marlin/preloads) system_other পার্টিশনের অবস্থানে যা পরে /data/preloads-এ কপি করা হবে যখন ডিভাইস প্রথমবার বুট হয়। সিস্টেম_অন্যান্য ইমেজ প্রস্তুত করতে এই স্ক্রিপ্টটি বিল্ড টাইমে চলে। এটি প্রিলোড করা সামগ্রী বিক্রেতা/google_devices/marlin/preloads-এ উপলব্ধ হবে বলে আশা করে৷ OEM প্রকৃত সংগ্রহস্থলের নাম/পথ বেছে নিতে বিনামূল্যে।
6. APK ক্যাশে /data/preloads/file_cache এ অবস্থিত এবং নিম্নলিখিত লেআউট রয়েছে:

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

   এটি ডিভাইসের চূড়ান্ত ডিরেক্টরি কাঠামো। যতক্ষণ না চূড়ান্ত ফাইল কাঠামো উপরে বর্ণিত একটি প্রতিলিপি করে ততক্ষণ পর্যন্ত OEMগুলি যে কোনও বাস্তবায়ন পদ্ধতি বেছে নিতে মুক্ত।

পদ্ধতি 2. ব্যবহারকারীর ডেটা ইমেজের বিষয়বস্তু কারখানায় ফ্ল্যাশ করে

এই বিকল্প পদ্ধতিটি অনুমান করে যে প্রিলোড করা বিষয়বস্তু ইতিমধ্যে /data পার্টিশনের / /data/preloads ডিরেক্টরিতে অন্তর্ভুক্ত করা হয়েছে।

প্রো : বাক্সের বাইরে কাজ করে - প্রথম বুটে ফাইল কপি করতে ডিভাইস কাস্টমাইজেশন করার দরকার নেই। বিষয়বস্তু ইতিমধ্যেই /data পার্টিশনে রয়েছে।

কন : ফ্যাক্টরি রিসেট করার পর প্রিলোড করা কন্টেন্ট হারিয়ে যায়। যদিও এটি কারও কারও জন্য গ্রহণযোগ্য হতে পারে, এটি সর্বদা OEM-দের জন্য কাজ নাও করতে পারে যারা গুণমান নিয়ন্ত্রণ পরিদর্শন করার পরে ডিভাইসগুলি ফ্যাক্টরি রিসেট করে।

একটি নতুন @SystemApi পদ্ধতি, getPreloadsFileCache() , android.content.Context এ যোগ করা হয়েছে। এটি প্রিলোড করা ক্যাশে একটি অ্যাপ-নির্দিষ্ট ডিরেক্টরিতে একটি পরম পথ ফেরত দেয়।

একটি নতুন পদ্ধতি, IPackageManager.deletePreloadsFileCache , যোগ করা হয়েছে যা সমস্ত স্থান পুনরুদ্ধার করতে প্রিলোড ডিরেক্টরি মুছে ফেলার অনুমতি দেয়। পদ্ধতিটি শুধুমাত্র SYSTEM_UID সহ অ্যাপ্লিকেশনগুলি দ্বারা কল করা যেতে পারে, যেমন সিস্টেম সার্ভার বা সেটিংস৷

অ্যাপ প্রস্তুতি

শুধুমাত্র বিশেষ সুবিধাপ্রাপ্ত অ্যাপই প্রিলোড ক্যাশে ডিরেক্টরি অ্যাক্সেস করতে পারে। সেই অ্যাক্সেসের জন্য, অ্যাপগুলিকে অবশ্যই /system/priv-app ডিরেক্টরিতে ইনস্টল করতে হবে।

বৈধতা

• প্রথম বুট করার পরে, ডিভাইসের /data/preloads/file_cache ডিরেক্টরিতে বিষয়বস্তু থাকা উচিত।
• যদি ডিভাইসের স্টোরেজ কম থাকে তাহলে file_cache/ ডিরেক্টরির বিষয়বস্তু মুছে ফেলতে হবে।

APK ক্যাশে পরীক্ষা করার জন্য উদাহরণ ApkCacheTest অ্যাপটি ব্যবহার করুন।

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 ফলাফল।