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

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

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

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

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

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

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

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

परिवर्तन तोड़ें

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

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

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

प्रवास पथ

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

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

   PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true

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

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 सेट करें। बिल्ड-टाइम सुसंगतता जांच अभी भी की जाती है, लेकिन चेक विफलता का मतलब बिल्ड विफलता नहीं है। इसके बजाय, एक चेक विफलता बिल्ड सिस्टम को dexpreopt में verify के लिए dex2oat कंपाइलर फ़िल्टर को डाउनग्रेड कर देती है, जो इस मॉड्यूल के लिए 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 प्रॉपर्टी में गुम लाइब्रेरी को देखें। यदि यह वहां है, तो इन विशेष मामलों को छोड़कर, सूंग आमतौर पर ऐसी लाइब्रेरी स्वचालित रूप से जोड़ता है:

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

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

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

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

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

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

LOCAL_ENFORCE_USES_LIBRARIES := false
LOCAL_DEX_PREOPT := false

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

बिल्ड त्रुटि: लाइब्रेरी निर्भरता गायब है

मॉड्यूल Y के मेनिफेस्ट से <uses-library>

यह 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> टैग में सूचीबद्ध लाइब्रेरी को शीर्ष-स्तरीय सीएलसी तत्वों के रूप में जोड़ता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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