ओटीए का साइज़ कम करें

यह पेज एओएसपी में जोड़े गए बदलावों के बारे में बताता है, ताकि बिल्ड के बीच फ़ाइल में होने वाले ग़ैर-ज़रूरी बदलावों को कम किया जा सके. डिवाइस लागू करने वाले ऐसे लोग जो अपने बिल्ड सिस्टम को मैनेज करते हैं, वे इस जानकारी का इस्तेमाल गाइड के तौर पर कर सकते हैं ओवर द एयर (ओटीए) अपडेट का साइज़ कम करने के लिए किया जा सकता है.

Android OTA अपडेट में कभी-कभी बदली गई फ़ाइलें होती हैं, जो कोड में होने वाले बदलावों के मुताबिक नहीं होती. असल में, ये सिस्टम आर्टफ़ैक्ट बनाते हैं. ऐसा तब हो सकता है, जब एक ही कोड, जो अलग-अलग बार-बार, अलग-अलग डायरेक्ट्री या अलग-अलग मशीनों पर रिकॉर्ड किए गए ज़्यादातर बदलाव फ़ाइलें शामिल हैं. इतनी ज़्यादा फ़ाइलों से ओटीए पैच का साइज़ बढ़ जाता है. इससे यह पता लगाना मुश्किल हो जाता है कौनसा कोड बदला गया.

ओटीए के कॉन्टेंट को ज़्यादा पारदर्शी बनाने के लिए, एओएसपी ने बिल्ड सिस्टम में डिज़ाइन किए गए बदलाव शामिल किए हैं का इस्तेमाल किया जा सकता है. बिल्ड के बीच फ़ाइल में ग़ैर-ज़रूरी बदलाव किए गए हैं को हटा दिया जाता है, और सिर्फ़ पैच से जुड़ी फ़ाइलें ओटीए अपडेट में शामिल होती हैं. AOSP में यह भी शामिल है: build डिफ़रेंस टूल, जो सामान्य बिल्ड से जुड़े डेटा को फ़िल्टर कर देता है ज़्यादा साफ़ बिल्ड फ़ाइल अंतर देने के लिए फ़ाइल में बदलाव करता है, और ब्लॉक मैपिंग टूल की मदद से, डेटा के बंटवारे को ब्लॉक किया जा सकता है एक जैसा.

बिल्ड सिस्टम कई तरीकों से बेवजह बड़े पैच बना सकता है. इसे कम करने के लिए, Android 8.0 और उसके बाद के वर्शन में, हर डिवाइस के पैच का साइज़ कम करने के लिए नई सुविधाएं जोड़ी गई हैं फ़ाइल अंतर. ओटीए-अपडेट पैकेज के साइज़ को कम करने वाले सुधारों में ये शामिल हैं:

  • Brotli का इस्तेमाल ग़ैर-A/B डिवाइस के अपडेट पर इमेज. Brotli को ऑप्टिमाइज़ करने के लिए पसंद के मुताबिक बनाया जा सकता है कंप्रेशन. बड़े अपडेट पर, जिसमें फ़ाइल सिस्टम में दो या उससे ज़्यादा ब्लॉक शामिल होते हैं (इसके लिए उदाहरण, system.img), डिवाइस बनाने वाली कंपनी या पार्टनर अपने फ़ोन नंबर जोड़ सकते हैं कंप्रेशन एल्गोरिदम का इस्तेमाल कर सकता है, और वही अपडेट.
  • पफ़िन रीकम्प्रेशन का इस्तेमाल करना. यह डिफ़्लेट के लिए डिटरमिनिस्टिक पैचिंग टूल है स्ट्रीम, जो A/B OTA अपडेट जनरेट करने के लिए कंप्रेशन और डिफ़रेंस फ़ंक्शन को हैंडल करती है.
  • डेल्टा-जनरेशन टूल के इस्तेमाल में बदलाव, जैसे कि bsdiff लाइब्रेरी का इस्तेमाल पैच कंप्रेस करने के लिए किया जाता है. Android 9 और उसके बाद वाले वर्शन में, bsdiff टूल, उस कंप्रेशन एल्गोरिदम को चुनता है जो पैच के लिए सबसे अच्छे कंप्रेशन नतीजे.
  • update_engine अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है A/B डिवाइस के अपडेट के लिए पैच लागू करने पर, मेमोरी कम खर्च होती है.
  • ब्लॉक-आधारित ओटीए अपडेट के लिए, बड़ी ZIP फ़ाइलों को बांटने के तरीके में सुधार. A मोड चालू है imgdiff अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है एंट्री के नामों के आधार पर, बड़े साइज़ की APK फ़ाइलों को बांटता है. ऐसा करने पर, एक छोटा सा पैच फ़ाइलों को लीनियर तरीके से बांटा जा सकता है और कंप्रेस किया जा सकता है. इसके लिए, bsdiff टूल का इस्तेमाल करें.

यहां दिए गए सेक्शन में ऐसी कई समस्याओं के बारे में बताया गया है जो ओटीए-अपडेट के साइज़, उनके समाधानों, और और AOSP में लागू करने के उदाहरण.

फ़ाइल क्रम

समस्या: फ़ाइलों की सूची मांगे जाने पर, फ़ाइल सिस्टम फ़ाइल के ऑर्डर की गारंटी नहीं देते हैं फ़ाइलों के लिए अलग-अलग हैं, हालांकि एक ही चेकआउट के लिए आम तौर पर एक ही बात होती है. ऐसे टूल ls डिफ़ॉल्ट रूप से नतीजों को क्रम से लगाता है, लेकिन वाइल्डकार्ड फ़ंक्शन का इस्तेमाल ऐसे कमांड क्योंकि find और make क्रम से नहीं लगाते. इन टूल का इस्तेमाल करने से पहले, आपको इन्हें क्रम से लगाना होगा आउटपुट.

समाधान: जब आप find और make वाइल्डकार्ड फ़ंक्शन का इस्तेमाल करके, इन निर्देशों के आउटपुट को क्रम से लगाएं उन्हें. इसमें $(wildcard) या $(shell find) का इस्तेमाल करते समय Android.mk फ़ाइलें, उन्हें भी क्रम से लगाएं. Java जैसे कुछ टूल, इनपुट को क्रम से लगाते हैं. इसलिए फ़ाइलें क्रम से लगाने से पहले, जांच लें कि इस्तेमाल किए जा रहे टूल ने पहले ऐसा नहीं किया है.

उदाहरण: कई इंस्टेंस को बिल्टइन all-*-files-under मैक्रो, जिसमें यह शामिल है all-cpp-files-under (क्योंकि अन्य मेकफ़ाइल में कई परिभाषाएं दी गई थीं). जानकारी के लिए, यहां दी गई जानकारी देखें:

डायरेक्ट्री बनाएं

समस्या: जिस डायरेक्ट्री में चीज़ें बनाई जाती हैं उसे बदलने पर अलग-अलग होने चाहिए. Android बिल्ड में ज़्यादातर पाथ मिलते-जुलते पाथ होते हैं, इसलिए C/C++ में __FILE__ में समस्या नहीं है. हालांकि, डीबग सिंबल पाथ का नाम डिफ़ॉल्ट रूप से सेट किया जाता है और .note.gnu.build-id, प्री-स्ट्रिप्ड बाइनरी, ताकि डीबग सिंबल बदलने पर यह बदल जाए.

समाधान: एओएसपी अब डीबग पाथ को रिलेटिव बनाता है. जानकारी के लिए, CL देखें: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.

टाइमस्टैंप

समस्या: बिल्ड आउटपुट में टाइमस्टैंप की वजह से, फ़ाइल में ग़ैर-ज़रूरी बदलाव होते हैं. ऐसा इन जगहों पर हो सकता है:

  • C या C++ कोड में __DATE__/__TIME__/__TIMESTAMP__ मैक्रो.
  • ज़िप-आधारित संग्रहों में एम्बेड किए गए टाइमस्टैंप.

समाधान/उदाहरण: बिल्ड आउटपुट से टाइमस्टैंप हटाने के लिए, इस लेख में नीचे दिए गए निर्देश __DATE__/__TIME__/__TIMESTAMP__ C/C++ में. और संग्रह में एम्बेड किए गए टाइमस्टैंप.

C/C++ में __DATE__/__TIME__/__TIMESTAMP__

ये मैक्रो अलग-अलग बिल्ड के लिए हमेशा अलग-अलग आउटपुट देते हैं. इसलिए, इनका इस्तेमाल न करें. यहां इन मैक्रो को हटाने के कुछ विकल्प हैं:

संग्रह में एम्बेड किए गए टाइमस्टैंप (zip, जार)

Android 7.0 ने ज़िप संग्रहों में एम्बेड किए गए टाइमस्टैंप की समस्या को zip निर्देश के सभी इस्तेमाल के लिए -X. इससे ज़िप फ़ाइल से बढ़ाया गया यूनिक्स टाइमस्टैंप.

एक नया टूल, ziptime (इसमें मौजूद है /platform/build/+/main/tools/ziptime/) ज़िप हेडर में सामान्य टाइमस्टैंप रीसेट करता है. जानकारी के लिए, इसे देखें README फ़ाइल

signapk टूल, APK फ़ाइलों के लिए टाइमस्टैंप सेट करता है. ये टाइमस्टैंप, सर्वर का टाइमज़ोन. जानकारी के लिए, CL देखें https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

वर्शन स्ट्रिंग

समस्या: APK वर्शन स्ट्रिंग में अक्सर BUILD_NUMBER जुड़ा होता था हार्डकोड वर्शन में बदल सकते हैं. भले ही APK में कुछ और न बदला गया हो, नतीजे के तौर पर, APK अलग होगी.

समाधान: APK वर्शन स्ट्रिंग से बिल्ड नंबर हटाएं.

उदाहरणः

उपयोगकर्ता के डिवाइस पर वेरिटी का हिसाब लगाने की सुविधा चालू करें

अगर dm-verity यह सुविधा आपके डिवाइस पर चालू रहती है, तो ओटीए टूल आपके वेरिटी कॉन्फ़िगरेशन को अपने-आप चुन लेते हैं और डिवाइस पर मौजूद वेरिटी कंप्यूटेशन की सेवा चालू करें. इससे Android पर वेरिटी ब्लॉक का हिसाब लगाने में मदद मिलती है का इस्तेमाल कर सकते हैं. वेरिटी ब्लॉक इस्तेमाल कर सकते हैं 2 जीबी के पार्टीशन के लिए करीब 16 एमबी.

हालांकि, डिवाइस पर वेरिटी की गिनती करने में ज़्यादा समय लग सकता है. खास तौर पर, फ़ॉरवर्ड गड़बड़ी-सुधार कोड में ज़्यादा समय लग सकता है. Pixel डिवाइसों पर, आम तौर पर 10 बार मिनट. कम कीमत वाले डिवाइसों पर, ज़्यादा समय लग सकता है. अगर आपको डिवाइस पर मौजूद वेरिफ़िकेशन की सुविधा बंद करनी है, तो पर गौर करना होगा, लेकिन फिर भी dm-verity चालू कर सकते हैं, तो आप ota_from_target_files टूल पर --disable_fec_computation OTA अपडेट जनरेट कर रहा है. इस फ़्लैग की मदद से, ओटीए अपडेट के दौरान, डिवाइस पर मौजूद वेरिटी का हिसाब लगाने की सुविधा बंद हो जाती है. इससे ओटीए इंस्टॉल होने में लगने वाला समय कम हो जाता है, लेकिन ओटीए पैकेज का साइज़ बढ़ जाता है. अगर आपके डिवाइस में यह नहीं है, तो dm-verity चालू है, इस फ़्लैग को पास करने से कोई असर नहीं पड़ेगा.

एक ही तरह के बिल्ड टूल

समस्या: इंस्टॉल की गई फ़ाइलें जनरेट करने वाले टूल एक जैसे होने चाहिए (जैसे, इनपुट से हमेशा एक जैसा आउटपुट मिलना चाहिए).

समाधान/उदाहरण: नीचे दिए गए बिल्ड टूल में बदलाव करने ज़रूरी थे:

  • सूचना फ़ाइल बनाने वाला व्यक्ति. सूचना फ़ाइल निर्माता को बनाने के लिए बदला गया था सूचना के कलेक्शन को फिर से बनाया जा सकता है. CL को देखें: https://android.googlesource.com/platform/build/+/8ae4984c2c8009e7a08e2a76b1762c2837ad4f64.
  • Java Android कंपाइलर किट (Jack). जैक टूलचेन को एक अपडेट की ज़रूरत है जनरेट किए गए कंस्ट्रक्टर के क्रम में कभी-कभी होने वाले बदलावों को हैंडल करता है. इसके लिए डिटेमिनिस्टिक ऐक्सेसर टूलचेन में कंस्ट्रक्टर जोड़े गए: https://android.googlesource.com/toolchain/jack/+/056a5425b3ef57935206c19ecb198a89221ca64b.
  • ART AOT कंपाइलर (dex2oat). ART कंपाइलर बाइनरी को एक अपडेट मिला है डिटरमिनिस्टिक इमेज बनाने का विकल्प जोड़ा गया: https://android.googlesource.com/platform/art/+/ace0dc1dd5480ad458e622085e51583653853fb9.
  • libpac.so फ़ाइल (V8). हर बिल्ड एक अलग तरीके का /system/lib/libpac.so फ़ाइल अपलोड करता है, क्योंकि हर बिल्ड के लिए V8 स्नैपशॉट बदल जाता है. कॉन्टेंट बनाने समाधान स्नैपशॉट निकालना था: https://android.googlesource.com/platform/external/v8/+/e537f38c36600fd0f3026adba6b3f4cbcee1fb29.
  • ऐप्लिकेशन प्री-dexopt (.odex) फ़ाइलें. प्री-डेक्सऑप्ट (.odex) फ़ाइलें 64-बिट सिस्टम पर शुरू न की गई पैडिंग (जगह) शामिल है. इसे ठीक कर दिया गया था: https://android.googlesource.com/platform/art/+/34ed3 मुश्किल41820c72a3c0ab9770be66b6668aa029.

बिल्ड डिफ़रेंस टूल का इस्तेमाल करना

ऐसे मामलों में जहां बिल्ड से जुड़े फ़ाइल बदलावों को खत्म करना संभव नहीं है, एओएसपी में डिफ़रेंस टूल का इस्तेमाल किया जा सकता है. target_files_diff.py अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है का इस्तेमाल दो फ़ाइल पैकेज की तुलना करने के लिए किया जाता है. यह टूल दो चार्ट के बीच बार-बार होने वाला अंतर बिल्ड. इनमें बिल्ड से जुड़े सामान्य बदलाव शामिल नहीं होते हैं, जैसे कि

  • बिल्ड आउटपुट में अनुमानित बदलाव (उदाहरण के लिए, बिल्ड नंबर में बदलाव की वजह से).
  • मौजूदा बिल्ड सिस्टम में पहले से मालूम समस्याओं की वजह से बदलाव.

बिल्ड डिफ़रेंस टूल का इस्तेमाल करने के लिए, नीचे दिए गए कमांड चलाएं:

target_files_diff.py dir1 dir2

dir1 और dir2 ऐसी बेस डायरेक्ट्री हैं जिनमें एक्सट्रैक्ट किया गया टारगेट शामिल है फ़ाइलें शामिल की जा सकती हैं.

ब्लॉक ऐलोकेशन को एक जैसा रखें

किसी फ़ाइल के लिए, दो बिल्ड के बीच का कॉन्टेंट एक जैसा होने के बावजूद, असल ब्लॉक जिनमें डेटा होल्ड करने वाला डेटा बदल गया होगा. इस वजह से, अपडेटर को गैर-ज़रूरी I/O फ़ंक्शन इस्तेमाल करने होंगे OTA अपडेट के लिए ब्लॉक को चारों ओर ले जाएँ.

वर्चुअल A/B ओटीए अपडेट में, ग़ैर-ज़रूरी I/O की वजह से स्टोरेज में काफ़ी जगह खाली हो सकती है कॉपी-ऑन-राइट स्नैपशॉट संग्रहित करने के लिए. नॉन-A/B OTA अपडेट में, ब्लॉक को एक जगह से दूसरी जगह ले जाना ओटीए अपडेट से, समय को अपडेट करने में मदद मिलती है, क्योंकि ब्लॉक को एक जगह से दूसरी जगह ले जाने की वजह से, I/O का समय बढ़ जाता है.

इस समस्या को हल करने के लिए, Google ने Android 7.0 में, make_ext4fs टूल को सभी बिल्ड में ब्लॉक ऐलोकेशन को एक जैसा बनाए रखने में मदद मिलती है. make_ext4fs टूल, एक वैकल्पिक -d base_fs फ़्लैग, जो उन्हीं ब्लॉक में फ़ाइलों को असाइन करने की कोशिश करता है ext4 इमेज जनरेट करते समय ज़रूरी है. ब्लॉक मैपिंग फ़ाइलें एक्सट्रैक्ट की जा सकती हैं, जैसे कि (base_fs) मैप फ़ाइलें) ZIP फ़ाइल में शामिल हो. हर एक के लिए ext4 पार्टीशन, इसमें .map फ़ाइल है IMAGES डायरेक्ट्री (उदाहरण के लिए, IMAGES/system.map system विभाजन). इसके बाद, इन base_fs फ़ाइलों की जांच की जा सकती है और PRODUCT_<partition>_BASE_FS_PATH के ज़रिए बताया गया है, जैसा कि इस उदाहरण में बताया गया है: 

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

इससे ओटीए पैकेज का साइज़ कम नहीं होता, लेकिन इससे ओटीए अपडेट बेहतर होता है की परफ़ॉर्मेंस को कम करने के लिए, I/O की मात्रा को कम किया जा सकता है. वर्चुअल A/B अपडेट के लिए, यह ओटीए का इस्तेमाल करने के लिए स्टोरेज में कितनी जगह बची है.

ऐप्लिकेशन अपडेट करने से बचें

बिल्ड के अंतर को कम करने के अलावा, अपडेट को हटाकर, ओटीए अपडेट का साइज़ कम किया जा सकता है ऐप स्टोर से अपडेट पाने वाले ऐप्लिकेशन के लिए. APKs आम तौर पर, अलग-अलग सेगमेंट में बांटा जा सकता है. इसमें ऐप्लिकेशन के नए वर्शन के हिसाब से अपडेट किए जाने वाले ऐप्लिकेशन शामिल हैं ओटीए अपडेट में मौजूद स्टोर की वजह से, ओटीए पैकेज पर काफ़ी ज़्यादा असर पड़ सकता है और कम उपयोगकर्ता फ़ायदा. जब उपयोगकर्ताओं को ओटीए पैकेज मिलता है, तब हो सकता है कि उनके पास पहले से ही अपडेट किया गया ऐप्लिकेशन हो या इससे भी नया वर्शन मिलता है, जो सीधे ऐप स्टोर से मिलता है.