इस दस्तावेज़ में तेज़ी से इंस्टॉल करने के लिए, APK कैश मेमोरी के समाधान के डिज़ाइन के बारे में बताया गया है ऐप्लिकेशन, जो A/B पार्टिशन की सुविधा वाले डिवाइस में पहले से लोड किए गए ऐप्लिकेशन के साथ काम करते हैं.
OEM, सुरक्षित मोड में सेव की गई APK कैश मेमोरी में, पहले से लोड किए गए और लोकप्रिय ऐप्लिकेशन को इंस्टॉल कर सकता है नए A/B-पार्टिशन डिवाइसों में खाली B पार्टीशन, जो बिना किसी बदलाव को ऐक्सेस करने में मदद मिलेगी. डिवाइस में APK कैश मेमोरी उपलब्ध कराके, नए या हाल ही में फ़ैक्ट्री रीसेट किए गए डिवाइस करीब-करीब तुरंत इस्तेमाल के लिए तैयार हो जाते हैं. Google Play से APK फ़ाइलें डाउनलोड करने की ज़रूरत होती है.
इस्तेमाल के उदाहरण
- तेज़ी से सेटअप करने के लिए, पहले से लोड किए गए ऐप्लिकेशन को B पार्टिशन में सेव करें
- तेज़ी से डेटा वापस पाने के लिए, लोकप्रिय ऐप्लिकेशन को B पार्टीशन में सेव करें
ज़रूरी शर्तें
इस सुविधा का इस्तेमाल करने के लिए, डिवाइस में ये चीज़ें होनी चाहिए:
- Android 8.1 (O MR1) रिलीज़ इंस्टॉल किया गया
- A/B विभाजन लागू किया गया
पहले से लोड किए गए कॉन्टेंट को सिर्फ़ पहली बार चालू करने के दौरान कॉपी किया जा सकता है. ऐसा इसलिए होता है, क्योंकि कुछ डिवाइस पर A/B सिस्टम अपडेट काम करते हैं, तो B पार्टिशन असल में रीटेल डेमो रिसोर्स जैसे पहले से लोड किए गए कॉन्टेंट के बजाय, सिस्टम की इमेज फ़ाइलें OAT फ़ाइलें और APK की कैश मेमोरी. /data में संसाधन कॉपी होने के बाद पार्टिशन (यह पहले बूट पर होता है), B पार्टिशन का इस्तेमाल ओवर-द-एयर (OTA) किया जाएगा) अपडेट: सिस्टम इमेज के अपडेट किए गए वर्शन डाउनलोड करने के लिए.
इसलिए, APK की कैश मेमोरी को ओटीए की मदद से अपडेट नहीं किया जा सकता; इसे सिर्फ़ पहले से लोड किया जा सकता है कारखाने में दिलचस्पी है. फ़ैक्ट्री रीसेट करने से सिर्फ़ /data पार्टिशन पर असर पड़ता है. सिस्टम B पार्टिशन में पहले से लोड किया गया कॉन्टेंट तब तक मौजूद रहता है, जब तक ओटीए इमेज डाउनलोड नहीं हो जाती. फ़ैक्ट्री रीसेट करने के बाद, सिस्टम पहली बार फिर से चालू होगा. इसका मतलब APK अगर ओटीए इमेज को B पार्टिशन में डाउनलोड किया जाता है, तो कैश मेमोरी में डेटा सेव करने की सुविधा उपलब्ध नहीं होगी. तो डिवाइस को फ़ैक्ट्री रीसेट कर दिया जाता है.
लागू करना
तरीका 1. कॉन्टेंट चालू है सिस्टम_अन्य पार्टिशन
Pro: फ़ैक्ट्री रीसेट करने के बाद, पहले से लोड किया गया कॉन्टेंट नहीं मिटता - यह को फिर से चालू करने के बाद, B पार्टिशन से कॉपी किया जाएगा.
कॉन: B पार्टिशन पर स्पेस की ज़रूरत होती है. फ़ैक्ट्री रीसेट करने के बाद चालू करें पहले से लोड किए गए कॉन्टेंट को कॉपी करने में ज़्यादा समय लगेगा.
सिस्टम, पहली बार बूट होने के दौरान प्रीलोड को कॉपी करने के लिए स्क्रिप्ट को कॉल करता है
/system/bin/preloads_copy.sh
में. स्क्रिप्ट को
आर्ग्युमेंट (system_b
के लिए, रीड-ओनली माउंट पॉइंट का पाथ
विभाजन):
इस सुविधा को लागू करने के लिए, डिवाइस से जुड़े ये बदलाव करें. यहाँ है मार्लिन का उदाहरण:
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-
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 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- डोमेन को नए
में रजिस्टर करें फ़ाइल:/sepolicy/file_contexts /system/bin/preloads_copy\.sh u:object_r:preloads_copy_exec:s0
SELinux कॉन्टेक्स्ट फ़ाइल का उदाहरण यहां देखें: device/google/marlin/sepolicy/preloads_copy.te - बिल्ड के समय, पहले से लोड किए गए कॉन्टेंट वाली डायरेक्ट्री को
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 कैश को कॉपी करने की अनुमति देता है के संसाधन उपलब्ध कराना चाहते थे (हमारे मामले में यह वेंडर/google_devices/marlin/preloads) में शामिल करें. जिसे बाद में पहली बार डिवाइस को बूट करते समय /data/preloads पर कॉपी किया जाएगा समय. यह स्क्रिप्ट सिस्टम_other इमेज तैयार करने के लिए बिल्ड के समय चलती है. इसकी उम्मीद है पहले से लोड किया गया कॉन्टेंट, वेंडर/google_devices/marlin/preloads में उपलब्ध रहेगा. ओईएम डेटा स्टोर करने की जगह का असल नाम/पाथ चुना जा सकता है. - APK कैश मेमोरी,
/data/preloads/file_cache
में मौजूद है और उसमें निम्न लेआउट:/data/preloads/file_cache/ app.package.name.1/ file1 fileN app.package.name.N/
यह डिवाइसों पर होने वाली डायरेक्ट्री का आखिरी स्ट्रक्चर है. OEM को चुना जा सकता है को लागू करने का कोई भी तरीका तब तक आज़माएं, जब तक कि आखिरी फ़ाइल स्ट्रक्चर जैसा ऊपर बताया गया है.
तरीका 2. उपयोगकर्ता के डेटा में मौजूद कॉन्टेंट फ़ैक्ट्री में इमेज का फ़्लैश
इस विकल्प के हिसाब से यह माना जाता है कि पहले से लोड किया गया कॉन्टेंट, Google Ads में पहले से ही शामिल है
/data
पार्टीशन में /data/preloads
डायरेक्ट्री.
Pro: सबसे हटके काम करता है - डिवाइस बनाने की ज़रूरत नहीं है
पहले बूट पर फ़ाइलें कॉपी करने के लिए कस्टमाइज़ेशन. सामग्री पहले से ही
/data
विभाजन.
नुकसान: फ़ैक्ट्री रीसेट करने के बाद, पहले से लोड किया गया कॉन्टेंट मिट जाता है. हालांकि यह कुछ लोगों के लिए सही हो सकता है, लेकिन हो सकता है कि यह फ़ैक्ट्री बनाने वाले OEM के लिए हमेशा काम न करे क्वालिटी कंट्रोल की जांच करने के बाद, डिवाइस रीसेट कर सकते हैं.
एक नई @SystemApi विधि, getPreloadsFileCache()
, को इसमें जोड़ा गया है
android.content.Context
. यह
ऐप्लिकेशन की खास डायरेक्ट्री मौजूद होनी चाहिए.
IPackageManager.deletePreloadsFileCache
नाम का एक नया तरीका जोड़ा गया
इस तरह, पहले से लोड की गई डायरेक्ट्री को मिटाया जा सकता है. इससे, पूरा स्पेस फिर से पाने में मदद मिलती है. इस तरीके से ये काम किए जा सकते हैं
इसे सिर्फ़ system_UID वाले ऐप्लिकेशन, जैसे कि सिस्टम सर्वर या सेटिंग ही कॉल करें.
ऐप्लिकेशन तैयार करना
सिर्फ़ खास ऐप्लिकेशन, पहले से लोड की गई कैश डायरेक्ट्री को ऐक्सेस कर सकते हैं. इसके लिए
ऐक्सेस न हो, तो ऐप्लिकेशन /system/priv-app
डायरेक्ट्री में इंस्टॉल होने चाहिए.
पुष्टि करें
- पहली बार बूट करने के बाद, डिवाइस में
/data/preloads/file_cache
डायरेक्ट्री. file_cache/
डायरेक्ट्री का कॉन्टेंट मिटाना ज़रूरी है, अगर: डिवाइस में कम स्टोरेज है.
ApkcacheTest उदाहरण का इस्तेमाल करें APK कैश मेमोरी की जांच करने के लिए ऐप्लिकेशन.
- रूट डायरेक्ट्री से इस निर्देश को चलाकर, ऐप्लिकेशन बनाएं:
make ApkCacheTest
- ऐप्लिकेशन को खास लोगों के लिए उपलब्ध ऐप्लिकेशन के तौर पर इंस्टॉल करें. (याद रखें, 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
- ज़रूरत होने पर, फ़ाइल की कैश मेमोरी और उसके कॉन्टेंट को सिम्युलेट करें (इसके लिए, रूट के अधिकार भी ज़रूरी हैं):
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"
- ऐप्लिकेशन का परीक्षण करें. ऐप्लिकेशन इंस्टॉल करने और टेस्ट
file_cache
डायरेक्ट्री बनाने के बाद, ApkcacheTest ऐप्लिकेशन खोलें. एक फ़ाइलtest.txt
और उसका कॉन्टेंट दिखना चाहिए. यह स्क्रीनशॉट देखें और जानें कि ये नतीजे यूज़र इंटरफ़ेस में कैसे दिखते हैं. पहला डायग्राम. ApkcacheTest के नतीजे.