डेक्सप्रोप्ट और <उपयोग-लाइब्रेरी> चेक

एंड्रॉइड 12 ने जावा मॉड्यूल के लिए डीईएक्स फाइलों (डेक्सप्रॉप्ट) के एओटी संकलन में सिस्टम परिवर्तन का निर्माण किया है जिसमें <uses-library> निर्भरताएं हैं। कुछ मामलों में ये बिल्ड सिस्टम परिवर्तन बिल्ड को तोड़ सकते हैं। टूटने की तैयारी के लिए इस पृष्ठ का उपयोग करें, और उन्हें ठीक करने और कम करने के लिए इस पृष्ठ पर व्यंजनों का पालन करें।

Dexpreopt जावा पुस्तकालयों और ऐप्स के समय-समय पर संकलन की प्रक्रिया है। Dexpreopt बिल्ड समय पर ऑन-होस्ट होता है (जैसा कि dexopt के विपरीत होता है, जो ऑन-डिवाइस होता है)। जावा मॉड्यूल (लाइब्रेरी या ऐप) द्वारा उपयोग की जाने वाली साझा लाइब्रेरी निर्भरता की संरचना को इसके क्लास लोडर संदर्भ (सीएलसी) के रूप में जाना जाता है। डेक्सप्रॉप्ट की शुद्धता की गारंटी के लिए, बिल्ड-टाइम और रन-टाइम सीएलसी का मेल होना चाहिए। बिल्ड-टाइम CLC वह है जो dex2oat कंपाइलर dexpreopt समय पर उपयोग करता है (यह ODEX फाइलों में दर्ज है), और रन-टाइम CLC वह संदर्भ है जिसमें डिवाइस पर प्रीकंपील्ड कोड लोड होता है।

इन बिल्ड-टाइम और रन-टाइम सीएलसी को शुद्धता और प्रदर्शन दोनों के कारणों से मेल खाना चाहिए। शुद्धता के लिए, डुप्लिकेट कक्षाओं को संभालना आवश्यक है। यदि रनटाइम पर साझा लाइब्रेरी निर्भरताएँ संकलन के लिए उपयोग की जाने वाली निर्भरता से भिन्न होती हैं, तो कुछ कक्षाएं अलग तरह से हल हो सकती हैं, जिससे सूक्ष्म रनटाइम बग हो सकते हैं। डुप्लिकेट कक्षाओं के लिए रनटाइम जाँच से प्रदर्शन भी प्रभावित होता है।

प्रभावित उपयोग के मामले

पहला बूट मुख्य उपयोग का मामला है जो इन परिवर्तनों से प्रभावित होता है: यदि एआरटी बिल्ड-टाइम और रन-टाइम सीएलसी के बीच एक बेमेल का पता लगाता है, तो यह डेक्सप्रॉप्ट कलाकृतियों को अस्वीकार करता है और इसके बजाय डेक्सॉप्ट चलाता है। बाद के बूटों के लिए यह ठीक है क्योंकि ऐप्स को पृष्ठभूमि में डेक्सॉप्ट किया जा सकता है और डिस्क पर संग्रहीत किया जा सकता है।

Android के प्रभावित क्षेत्र

यह उन सभी जावा ऐप्स और लाइब्रेरी को प्रभावित करता है जिनकी अन्य जावा लाइब्रेरी पर रनटाइम निर्भरताएँ होती हैं। एंड्रॉइड में हजारों ऐप्स हैं, और उनमें से सैकड़ों साझा पुस्तकालयों का उपयोग करते हैं। पार्टनर भी प्रभावित होते हैं, क्योंकि उनकी अपनी लाइब्रेरी और ऐप होते हैं।

ब्रेकिंग परिवर्तन

डेक्सप्रॉप्ट बिल्ड नियम बनाने से पहले बिल्ड सिस्टम को <uses-library> निर्भरता जानने की जरूरत है। हालांकि, यह सीधे मैनिफेस्ट तक नहीं पहुंच सकता है और इसमें <uses-library> टैग पढ़ सकता है, क्योंकि बिल्ड सिस्टम को मनमाने ढंग से फ़ाइलों को पढ़ने की अनुमति नहीं है जब यह बिल्ड नियम (प्रदर्शन कारणों से) उत्पन्न करता है। इसके अलावा, मेनिफेस्ट को एपीके या प्रीबिल्ट के अंदर पैक किया जा सकता है। इसलिए, बिल्ड फ़ाइलों ( Android.bp या Android.mk ) में <uses-library> जानकारी मौजूद होनी चाहिए।

पहले ART ने एक वर्कअराउंड का उपयोग किया था जो साझा लाइब्रेरी निर्भरता ( &-classpath के रूप में जाना जाता है) को अनदेखा करता था। यह असुरक्षित था और सूक्ष्म बग का कारण बना, इसलिए एंड्रॉइड 12 में वर्कअराउंड हटा दिया गया था।

परिणामस्वरूप, जावा मॉड्यूल जो अपनी बिल्ड फ़ाइलों में सही <uses-library> जानकारी प्रदान नहीं करते हैं, बिल्ड ब्रेकेज (बिल्ड-टाइम सीएलसी मिसमैच के कारण) या फर्स्ट-बूट टाइम रिग्रेशन (बूट-टाइम सीएलसी के कारण) का कारण बन सकते हैं। बेमेल के बाद डेक्सॉप्ट)।

प्रवासन पथ

टूटे हुए निर्माण को ठीक करने के लिए इन चरणों का पालन करें:

  1. सेटिंग द्वारा किसी विशेष उत्पाद के लिए वैश्विक स्तर पर बिल्ड-टाइम चेक अक्षम करें

    PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true

    उत्पाद मेकफ़ाइल में। यह बिल्ड त्रुटियों को ठीक करता है (विशेष मामलों को छोड़कर, फिक्सिंग ब्रेकेज अनुभाग में सूचीबद्ध)। हालाँकि, यह एक अस्थायी समाधान है, और यह बूट-टाइम CLC बेमेल और उसके बाद dexopt का कारण बन सकता है।

  2. उन मॉड्यूल को ठीक करें जो आपके द्वारा वैश्विक रूप से अक्षम करने से पहले बिल्ड-टाइम चेक को उनकी बिल्ड फ़ाइलों में आवश्यक <uses-library> जानकारी जोड़कर अक्षम कर दिया गया था (विवरण के लिए फिक्सिंग ब्रेकेज देखें)। अधिकांश मॉड्यूल के लिए इसके लिए Android.bp , या Android.mk में कुछ पंक्तियाँ जोड़ने की आवश्यकता होती है।

  3. प्रति-मॉड्यूल के आधार पर समस्याग्रस्त मामलों के लिए बिल्ड-टाइम चेक और डेक्सप्रॉप्ट को अक्षम करें। डेक्सप्रॉप्ट को अक्षम करें ताकि आप उन कलाकृतियों पर निर्माण समय और भंडारण बर्बाद न करें जो बूट पर खारिज हो जाते हैं।

  4. चरण 1 में सेट किए गए PRODUCT_BROKEN_VERIFY_USES_LIBRARIES को अनसेट करके वैश्विक स्तर पर बिल्ड-टाइम चेक को फिर से सक्षम करें; इस परिवर्तन के बाद बिल्ड विफल नहीं होना चाहिए (चरण 2 और 3 के कारण)।

  5. चरण 3 में आपके द्वारा अक्षम किए गए मॉड्यूल को ठीक करें, एक बार में एक, फिर dexpreopt को पुन: सक्षम करें और <uses-library> चेक करें। यदि आवश्यक हो तो फ़ाइल बग।

एंड्रॉइड 12 में बिल्ड-टाइम <uses-library> चेक लागू किए गए हैं।

फिक्सिंग टूटना

निम्नलिखित अनुभाग आपको बताते हैं कि विशिष्ट प्रकार के टूट-फूट को कैसे ठीक किया जाए।

बिल्ड त्रुटि: सीएलसी बेमेल

बिल्ड सिस्टम Android.bp या Android.mk फ़ाइलों और मेनिफ़ेस्ट में जानकारी के बीच बिल्ड-टाइम सुसंगतता जाँच करता है। बिल्ड सिस्टम मैनिफ़ेस्ट को नहीं पढ़ सकता है, लेकिन यह मैनिफ़ेस्ट को पढ़ने के लिए बिल्ड रूल्स जेनरेट कर सकता है (यदि आवश्यक हो तो इसे एपीके से निकाल सकता है), और मेनिफेस्ट में <uses-library> टैग्स की तुलना में <uses-library> जानकारी से करें। बिल्ड फाइलें। यदि चेक विफल हो जाता है, तो त्रुटि इस तरह दिखती है:

error: mismatch in the <uses-library> tags between the build system and the manifest:
    - required libraries in build system: []
                     vs. in the manifest: [org.apache.http.legacy]
    - optional libraries in build system: []
                     vs. in the manifest: [com.x.y.z]
    - tags in the manifest (.../X_intermediates/manifest/AndroidManifest.xml):
        <uses-library android:name="com.x.y.z"/>
        <uses-library android:name="org.apache.http.legacy"/>

note: the following options are available:
    - to temporarily disable the check on command line, rebuild with RELAX_USES_LIBRARY_CHECK=true (this will set compiler filter "verify" and disable AOT-compilation in dexpreopt)
    - to temporarily disable the check for the whole product, set PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true in the product makefiles
    - to fix the check, make build system properties coherent with the manifest
    - see build/make/Changes.md for details

जैसा कि त्रुटि संदेश से पता चलता है, तात्कालिकता के आधार पर कई समाधान हैं:

  • एक अस्थायी उत्पाद-व्यापी सुधार के लिए, उत्पाद मेकफ़ाइल में PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true सेट करें। बिल्ड-टाइम सुसंगतता जांच अभी भी की जाती है, लेकिन चेक विफलता का मतलब बिल्ड विफलता नहीं है। इसके बजाय, एक चेक विफलता बिल्ड सिस्टम को dex2oat कंपाइलर फ़िल्टर को dexpreopt में verify करने के लिए डाउनग्रेड कर देती है, जो इस मॉड्यूल के लिए AOT-संकलन को पूरी तरह से अक्षम कर देता है।
  • एक त्वरित, वैश्विक कमांड-लाइन फिक्स के लिए, पर्यावरण चर RELAX_USES_LIBRARY_CHECK=true का उपयोग करें। इसका प्रभाव PRODUCT_BROKEN_VERIFY_USES_LIBRARIES जैसा ही है, लेकिन कमांड-लाइन पर उपयोग के लिए अभिप्रेत है। पर्यावरण चर उत्पाद चर को ओवरराइड करता है।
  • मूल-कारण के समाधान के लिए त्रुटि को ठीक करें, बिल्ड सिस्टम को मेनिफेस्ट में <uses-library> टैग से अवगत कराएं। त्रुटि संदेश के निरीक्षण से पता चलता है कि कौन से पुस्तकालय समस्या का कारण बनते हैं (जैसा कि AndroidManifest.xml या एपीके के अंदर मेनिफेस्ट का निरीक्षण करता है जिसे ` aapt dump badging $APK | grep uses-library के साथ जांचा जा सकता है)।

Android.bp मॉड्यूल के लिए:

  1. मॉड्यूल की libs संपत्ति में लापता पुस्तकालय की तलाश करें। यदि यह वहां है, तो इन विशेष मामलों को छोड़कर, सूंग सामान्य रूप से स्वचालित रूप से ऐसे पुस्तकालयों को जोड़ता है:

    • पुस्तकालय एक एसडीके पुस्तकालय नहीं है (इसे java_sdk_library के बजाय java_library के रूप में परिभाषित किया java_sdk_library है)।
    • लाइब्रेरी का मॉड्यूल नाम (बिल्ड सिस्टम में) से अलग लाइब्रेरी नाम (मेनिफेस्ट में) है।

    इसे अस्थायी रूप से ठीक करने के लिए, Android.bp लाइब्रेरी परिभाषा में Provides_uses_lib provides_uses_lib: "<library-name>" जोड़ें। दीर्घकालिक समाधान के लिए, अंतर्निहित समस्या को ठीक करें: लाइब्रेरी को SDK लाइब्रेरी में बदलें, या इसके मॉड्यूल का नाम बदलें।

  2. यदि पिछले चरण ने कोई समाधान प्रदान नहीं किया, uses_libs: ["<library-module-name>"] आवश्यक पुस्तकालयों के लिए, या optional_uses_libs: ["<library-module-name>"] Android.bp मॉड्यूल की Android.bp परिभाषा। ये गुण मॉड्यूल नामों की सूची स्वीकार करते हैं। सूची में पुस्तकालयों का सापेक्ष क्रम मैनिफेस्ट में क्रम के समान होना चाहिए।

Android.mk मॉड्यूल के लिए:

  1. जांचें कि क्या पुस्तकालय के मॉड्यूल नाम (बिल्ड सिस्टम में) से एक अलग पुस्तकालय नाम (मेनिफेस्ट में) है। अगर ऐसा होता है, तो लाइब्रेरी की Android.mk फ़ाइल में LOCAL_PROVIDES_USES_LIBRARY := <library-name> जोड़कर इसे अस्थायी रूप से ठीक करें, या लाइब्रेरी की Android.bp फ़ाइल (दोनों स्थितियों में) में Provide_uses_lib: provides_uses_lib: "<library-name>" जोड़ें। संभव है क्योंकि Android.mk मॉड्यूल Android.bp लाइब्रेरी पर निर्भर हो सकता है)। दीर्घकालिक समाधान के लिए, अंतर्निहित समस्या को ठीक करें: लाइब्रेरी मॉड्यूल का नाम बदलें।

  2. LOCAL_USES_LIBRARIES := <library-module-name> आवश्यक पुस्तकालयों के लिए; मॉड्यूल की Android.mk परिभाषा में वैकल्पिक पुस्तकालयों के लिए LOCAL_OPTIONAL_USES_LIBRARIES := <library-module-name> जोड़ें। ये गुण मॉड्यूल नामों की सूची स्वीकार करते हैं। सूची में पुस्तकालयों का सापेक्ष क्रम मैनिफेस्ट के समान होना चाहिए।

बिल्ड त्रुटि: अज्ञात पुस्तकालय पथ

यदि बिल्ड सिस्टम को <uses-library> DEX जार (या तो बिल्ड-टाइम पथ ऑन-होस्ट या इंस्टॉल पथ ऑन-डिवाइस) के लिए पथ नहीं मिल रहा है, तो यह आमतौर पर बिल्ड को विफल कर देता है। पथ खोजने में विफलता यह संकेत दे सकती है कि पुस्तकालय किसी अप्रत्याशित तरीके से कॉन्फ़िगर किया गया है। समस्याग्रस्त मॉड्यूल के लिए dexpreopt को अक्षम करके बिल्ड को अस्थायी रूप से ठीक करें।

Android.bp (मॉड्यूल गुण):

enforce_uses_libs: false,
dex_preopt: {
    enabled: false,
},

Android.mk (मॉड्यूल चर):

LOCAL_ENFORCE_USES_LIBRARIES := false
LOCAL_DEX_PREOPT := false

किसी भी असमर्थित परिदृश्य की जांच के लिए बग फ़ाइल करें।

बिल्ड त्रुटि: अनुपलब्ध लाइब्रेरी निर्भरता

मॉड्यूल Y के मेनिफेस्ट से Y के लिए बिल्ड फ़ाइल में <uses-library> X जोड़ने का प्रयास अनुपलब्ध निर्भरता, X के कारण बिल्ड त्रुटि में परिणाम हो सकता है।

यह Android.bp मॉड्यूल के लिए एक नमूना त्रुटि संदेश है:

"Y" depends on undefined module "X"

यह Android.mk मॉड्यूल के लिए एक नमूना त्रुटि संदेश है:

'.../JAVA_LIBRARIES/com.android.X_intermediates/dexpreopt.config', needed by '.../APPS/Y_intermediates/enforce_uses_libraries.status', missing and no known rule to make it

ऐसी त्रुटियों का एक सामान्य स्रोत तब होता है जब किसी पुस्तकालय का नाम उसके संगत मॉड्यूल से भिन्न होता है जिसे बिल्ड सिस्टम में नामित किया जाता है। उदाहरण के लिए, यदि मेनिफेस्ट <uses-library> प्रविष्टि com.android.X है, लेकिन लाइब्रेरी मॉड्यूल का नाम केवल X है, तो यह एक त्रुटि का कारण बनता है। इस मामले को हल करने के लिए, बिल्ड सिस्टम को बताएं कि X नाम का मॉड्यूल com.android.X नाम का एक <uses-library> प्रदान करता है।

यह Android.bp लाइब्रेरी (मॉड्यूल प्रॉपर्टी) के लिए एक उदाहरण है:

provides_uses_lib: “com.android.X”,

यह Android.mk पुस्तकालयों (मॉड्यूल चर) के लिए एक उदाहरण है:

LOCAL_PROVIDES_USES_LIBRARY := com.android.X

बूट-टाइम सीएलसी बेमेल

पहले बूट पर, सीएलसी बेमेल से संबंधित संदेशों के लिए लॉगकैट खोजें, जैसा कि नीचे दिखाया गया है:

$ adb wait-for-device && adb logcat \
  | grep -E 'ClassLoaderContext [a-z ]+ mismatch' -A1

आउटपुट में यहां दिखाए गए फॉर्म के संदेश हो सकते हैं:

[...] W system_server: ClassLoaderContext shared library size mismatch Expected=..., found=... (PCL[]... | PCL[]...)
[...] I PackageDexOptimizer: Running dexopt (dexoptNeeded=1) on: ...

यदि आपको सीएलसी बेमेल चेतावनी मिलती है, तो दोषपूर्ण मॉड्यूल के लिए डेक्सॉप्ट कमांड देखें। इसे ठीक करने के लिए, सुनिश्चित करें कि मॉड्यूल के लिए बिल्ड-टाइम चेक पास हो गया है। यदि वह काम नहीं करता है, तो आपका एक विशेष मामला हो सकता है जो बिल्ड सिस्टम द्वारा समर्थित नहीं है (जैसे कोई ऐप जो अन्य एपीके लोड करता है, लाइब्रेरी नहीं)। बिल्ड सिस्टम सभी मामलों को हैंडल नहीं करता है, क्योंकि बिल्ड टाइम पर यह निश्चित रूप से जानना असंभव है कि ऐप रनटाइम पर क्या लोड करता है।

क्लास लोडर संदर्भ

सीएलसी एक पेड़ जैसी संरचना है जो क्लास-लोडर पदानुक्रम का वर्णन करती है। निर्माण प्रणाली एक संकीर्ण अर्थ में सीएलसी का उपयोग करती है (इसमें केवल पुस्तकालय शामिल हैं, एपीके या कस्टम-क्लास लोडर नहीं): यह पुस्तकालयों का एक पेड़ है जो पुस्तकालय या ऐप के सभी <uses-library> निर्भरताओं के ट्रांजिटिव क्लोजर का प्रतिनिधित्व करता है। सीएलसी के शीर्ष स्तर के तत्व प्रत्यक्ष <uses-library> निर्भरताएं हैं जो मैनिफेस्ट (क्लासपाथ) में निर्दिष्ट हैं। सीएलसी ट्री का प्रत्येक नोड एक <uses-library> नोड होता है जिसका अपना <uses-library> उप-नोड्स हो सकता है।

क्योंकि <uses-library> निर्भरता एक निर्देशित चक्रीय ग्राफ है, और जरूरी नहीं कि एक पेड़ हो, सीएलसी में एक ही पुस्तकालय के लिए कई उप-वृक्ष हो सकते हैं। दूसरे शब्दों में, सीएलसी एक पेड़ के लिए "खुला" निर्भरता ग्राफ है। दोहराव केवल तार्किक स्तर पर है; वास्तविक अंतर्निहित वर्ग लोडर डुप्लीकेट नहीं हैं (रनटाइम पर प्रत्येक लाइब्रेरी के लिए एक सिंगल क्लास लोडर इंस्टेंस होता है)।

लाइब्रेरी या ऐप द्वारा उपयोग की जाने वाली जावा कक्षाओं को हल करते समय सीएलसी पुस्तकालयों के लुकअप ऑर्डर को परिभाषित करता है। लुकअप ऑर्डर महत्वपूर्ण है क्योंकि पुस्तकालयों में डुप्लिकेट कक्षाएं हो सकती हैं, और कक्षा को पहले मैच के लिए हल किया जाता है।

डिवाइस पर (रन-टाइम) सीएलसी

PackageManager ( frameworks/base में) जावा मॉड्यूल को डिवाइस पर लोड करने के लिए एक सीएलसी बनाता है। यह मॉड्यूल के मेनिफेस्ट में <uses-library> टैग में सूचीबद्ध पुस्तकालयों को शीर्ष-स्तरीय सीएलसी तत्वों के रूप में जोड़ता है।

प्रत्येक उपयोग की गई <uses-library> के लिए, PackageManager को उसकी सभी निर्भरताएँ मिलती हैं (उस लाइब्रेरी के मेनिफेस्ट में टैग के रूप में निर्दिष्ट) और प्रत्येक निर्भरता के लिए एक नेस्टेड CLC जोड़ता है। यह प्रक्रिया पुनरावर्ती रूप से तब तक जारी रहती है जब तक कि निर्मित सीएलसी ट्री के सभी लीफ नोड्स <uses-library> निर्भरता के बिना पुस्तकालय नहीं होते हैं।

PackageManager केवल साझा पुस्तकालयों के बारे में जानता है। इस उपयोग में साझा की परिभाषा इसके सामान्य अर्थ से भिन्न होती है (जैसा कि साझा बनाम स्थिर में)। एंड्रॉइड में, जावा साझा पुस्तकालय वे हैं जो एक्सएमएल कॉन्फ़िगरेशन में सूचीबद्ध हैं जो डिवाइस पर स्थापित हैं ( /system/etc/permissions/platform.xml )। प्रत्येक प्रविष्टि में एक साझा लाइब्रेरी का नाम, उसकी DEX जार फ़ाइल का पथ, और निर्भरता की एक सूची (अन्य साझा लाइब्रेरी जो यह रनटाइम पर उपयोग करता है, और इसके मेनिफेस्ट में <uses-library> टैग में निर्दिष्ट करता है) शामिल है।

दूसरे शब्दों में, जानकारी के दो स्रोत हैं जो PackageManager को रनटाइम पर सीएलसी बनाने की अनुमति देते हैं: मेनिफेस्ट में टैग, और एक्सएमएल कॉन्फ़िगरेशन में साझा <uses-library> निर्भरता।

ऑन-होस्ट (बिल्ड-टाइम) सीएलसी

लाइब्रेरी या ऐप लोड करते समय केवल सीएलसी की आवश्यकता नहीं होती है, बल्कि किसी एक को संकलित करते समय भी इसकी आवश्यकता होती है। संकलन या तो ऑन-डिवाइस (डेक्सॉप्ट) या बिल्ड (डेक्सप्रॉप्ट) के दौरान हो सकता है। चूंकि डेक्सॉप्ट ऑन-डिवाइस होता है, इसमें PackageManager (प्रकट और साझा लाइब्रेरी निर्भरता) जैसी ही जानकारी होती है। हालाँकि, Dexpreopt ऑन-होस्ट और पूरी तरह से अलग वातावरण में होता है, और इसे बिल्ड सिस्टम से समान जानकारी प्राप्त करनी होती है।

इस प्रकार, डेक्सप्रॉप्ट द्वारा उपयोग किए जाने वाले बिल्ड-टाइम सीएलसी और PackageManager द्वारा उपयोग किए जाने वाले रन-टाइम सीएलसी एक ही चीज हैं, लेकिन दो अलग-अलग तरीकों से गणना की जाती है।

बिल्ड-टाइम और रन-टाइम CLC का मेल होना चाहिए , अन्यथा dexpreopt द्वारा बनाया गया AOT-संकलित कोड अस्वीकार कर दिया जाता है। बिल्ड-टाइम और रन-टाइम CLCs की समानता की जाँच करने के लिए, dex2oat कंपाइलर *.odex फाइल्स (OAT फाइल हेडर के classpath फील्ड में) में बिल्ड-टाइम CLC रिकॉर्ड करता है। संग्रहीत सीएलसी को खोजने के लिए, इस आदेश का उपयोग करें:

oatdump --oat-file=<FILE> | grep '^classpath = '

बूट के दौरान लॉगकैट में बिल्ड-टाइम और रन-टाइम CLC बेमेल की सूचना दी गई है। इस आदेश के साथ इसे खोजें:

logcat | grep -E 'ClassLoaderContext [az ]+ mismatch'

बेमेल प्रदर्शन के लिए खराब है, क्योंकि यह लाइब्रेरी या ऐप को या तो डेक्सॉप्टेड होने के लिए मजबूर करता है, या अनुकूलन के बिना चलाने के लिए (उदाहरण के लिए, ऐप के कोड को एपीके से मेमोरी में निकालने की आवश्यकता हो सकती है, एक बहुत महंगा ऑपरेशन)।

एक साझा पुस्तकालय या तो वैकल्पिक या आवश्यक हो सकता है। डेक्सप्रॉप्ट के दृष्टिकोण से, निर्माण के समय एक आवश्यक पुस्तकालय मौजूद होना चाहिए (इसकी अनुपस्थिति एक बिल्ड त्रुटि है)। एक वैकल्पिक पुस्तकालय या तो मौजूद हो सकता है या निर्माण के समय अनुपस्थित हो सकता है: यदि मौजूद है, तो इसे सीएलसी में जोड़ा जाता है, dex2oat को पास किया जाता है, और *.odex फ़ाइल में दर्ज किया जाता है। यदि कोई वैकल्पिक पुस्तकालय अनुपस्थित है, तो इसे छोड़ दिया जाता है और इसे सीएलसी में नहीं जोड़ा जाता है। यदि बिल्ड-टाइम और रन-टाइम स्थिति के बीच कोई मेल नहीं है (वैकल्पिक लाइब्रेरी एक मामले में मौजूद है, लेकिन दूसरे में नहीं), तो बिल्ड-टाइम और रन-टाइम सीएलसी मेल नहीं खाते हैं और संकलित कोड अस्वीकार कर दिया जाता है।

उन्नत बिल्ड सिस्टम विवरण (मेनिफेस्ट फिक्सर)

कभी-कभी <uses-library> टैग किसी लाइब्रेरी या ऐप के सोर्स मेनिफेस्ट से गायब होते हैं। ऐसा हो सकता है, उदाहरण के लिए, यदि लाइब्रेरी या ऐप की ट्रांजिटिव डिपेंडेंसी में से कोई एक दूसरे <uses-library> टैग का उपयोग करना शुरू कर देता है, और लाइब्रेरी या ऐप के मेनिफेस्ट को इसे शामिल करने के लिए अपडेट नहीं किया जाता है।

सूंग किसी दी गई लाइब्रेरी या ऐप के लिए कुछ गुम <uses-library> टैग की स्वचालित रूप से गणना कर सकता है, जैसे कि लाइब्रेरी या ऐप के ट्रांजिटिव डिपेंडेंसी क्लोजर में एसडीके लाइब्रेरी। बंद करने की आवश्यकता है क्योंकि पुस्तकालय (या ऐप) एक स्थिर पुस्तकालय पर निर्भर हो सकता है जो एक एसडीके पुस्तकालय पर निर्भर करता है, और संभवतः फिर से किसी अन्य पुस्तकालय के माध्यम से संक्रमणीय रूप से निर्भर हो सकता है।

सभी <uses-library> टैग की गणना इस तरह से नहीं की जा सकती है, लेकिन जब संभव हो, सोंग को स्वचालित रूप से मेनिफेस्ट प्रविष्टियां जोड़ने देना बेहतर है; यह कम त्रुटि-प्रवण है और रखरखाव को सरल करता है। उदाहरण के लिए, जब कई ऐप एक स्थिर लाइब्रेरी का <uses-library> करते हैं जो एक नई निर्भरता जोड़ता है, तो सभी ऐप को अपडेट किया जाना चाहिए, जिसे बनाए रखना मुश्किल है।