APK ক্যাশিং

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

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

ব্যবহারের ক্ষেত্রে

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

পূর্বশর্ত

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

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

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

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

বাস্তবায়ন

পদ্ধতি ১. system_other পার্টিশনের বিষয়বস্তু

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

অসুবিধা : 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. 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. 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;
   

   /device/google/marlin/+/android16-qpr1-release/sepolicy/preloads_copy.te ঠিকানায় একটি উদাহরণ SELinux ডোমেইন ফাইল খুঁজুন।
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-এর পরিবর্তনের উদাহরণ যা বিক্রেতার Git রিপোজিটরি (আমাদের ক্ষেত্রে এটি ছিল vendor/google_devices/marlin/preloads) থেকে APK ক্যাশে রিসোর্সগুলিকে system_other পার্টিশনের অবস্থানে অনুলিপি করার অনুমতি দেয় যা পরে ডিভাইসটি প্রথমবার বুট করার সময় /data/preloads-এ অনুলিপি করা হবে। এই স্ক্রিপ্টটি system_other ইমেজ প্রস্তুত করার জন্য বিল্ড টাইমে চলে। এটি আশা করে যে প্রিলোড করা কন্টেন্ট vendor/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 গুলি যেকোনো বাস্তবায়ন পদ্ধতি বেছে নিতে স্বাধীন, যদি চূড়ান্ত ফাইল কাঠামো উপরে বর্ণিত পদ্ধতির প্রতিলিপি তৈরি করে।

পদ্ধতি ২। কারখানায় ব্যবহারকারীর ডেটা চিত্রের বিষয়বস্তু ফ্ল্যাশ করা হয়েছে

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

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

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

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

একটি নতুন পদ্ধতি, 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. অ্যাপটি পরীক্ষা করুন। অ্যাপটি ইনস্টল করার পর এবং test file_cache ডিরেক্টরি তৈরি করার পর, ApkCacheTest অ্যাপটি খুলুন। এটিতে test.txt ফাইল এবং এর বিষয়বস্তু দেখানো উচিত। ইউজার ইন্টারফেসে এই ফলাফলগুলি কীভাবে প্রদর্শিত হয় তা দেখতে এই স্ক্রিনশটটি দেখুন।

   

   চিত্র ১. ApkCacheTest ফলাফল।