एक Android प्रोजेक्ट बनाएँ: जंक फ़ाइलों को समाप्त करें

अपनी पहली एंड्रॉइड परियोजना को पूरा करते हुए, मैं रिलीज के निर्माण के दौरान पर्याप्त लचीलापन नहीं होने की समस्या में भाग गया।

प्रारंभ में, चींटी को विधानसभा के लिए इस्तेमाल किया जाना चाहिए। प्रोजेक्ट बनाते समय, प्लेटफ़ॉर्म आपको बिल्ड . xml बनाता है। एक नियम के रूप में, पूरे कॉन्फ़िगरेशन में स्थानीय -प्रोफ़ाइल फ़ाइल में Android-SDK के लिए पथ निर्दिष्ट करना शामिल है। आप कुंजी.स्टोर और की.लियास मापदंडों को भी निर्दिष्ट करना चाह सकते हैं, ताकि विधानसभा के दौरान स्वचालित रूप से आवेदन के संकेत मिलें। Google दस्तावेज़ में ऐसा करने की अनुशंसा नहीं करता है, क्योंकि असेंबली प्रक्रिया के दौरान कुंजी के लिए प्रस्तावित पासवर्ड लॉग में है।

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


यदि आप build.xml के अंदर देखते हैं, तो आप वहां अनुकूलन के लिए कुछ टिप्पणी किए गए तत्व पा सकते हैं:

 <!-- extension targets. Uncomment the ones where you want to do custom work in between standard targets --> <!-- <target name="-pre-build"> </target> <target name="-pre-compile"> </target> [This is typically used for code obfuscation. Compiled code location: ${out.classes.absolute.dir} If this is not done in place, override ${out.dex.input.absolute.dir}] <target name="-post-compile"> </target> --> 

निर्देश के बाद आता है

<setup />

यह एसडीके / उपकरण / चींटी / main_rules.xml की सामग्री का आयात करता है। यदि आप निर्दिष्ट फ़ाइल के अंदर देखते हैं, तो आप परियोजना के निर्माण की पूरी प्रक्रिया देख सकते हैं। दुर्भाग्य से, वहाँ से हम देखते हैं कि -pre-build, -pre-compile या -post-compile का उपयोग करना कार्य के लिए उपयुक्त नहीं है। संपत्ति को एक .apk फ़ाइल में पैक करने की प्रक्रिया इस प्रकार है:

 <target name="-package-resources"> <echo>Packaging resources</echo> <aapt executable="${aapt}" command="package" versioncode="${version.code}" debug="${build.packaging.debug}" manifest="AndroidManifest.xml" assets="${asset.absolute.dir}" androidjar="${android.jar}" apkfolder="${out.absolute.dir}" resourcefilename="${resource.package.file.name}" resourcefilter="${aapt.resource.filter}"> <res path="${resource.absolute.dir}" /> <!-- <nocompress /> forces no compression on any files in assets or res/raw --> <!-- <nocompress extension="xml" /> forces no compression on specific file extensions in assets and res/raw --> </aapt> </target> 
 

<target name="-package-resources"> <echo>Packaging resources</echo> <aapt executable="${aapt}" command="package" versioncode="${version.code}" debug="${build.packaging.debug}" manifest="AndroidManifest.xml" assets="${asset.absolute.dir}" androidjar="${android.jar}" apkfolder="${out.absolute.dir}" resourcefilename="${resource.package.file.name}" resourcefilter="${aapt.resource.filter}"> <res path="${resource.absolute.dir}" /> <!-- <nocompress /> forces no compression on any files in assets or res/raw --> <!-- <nocompress extension="xml" /> forces no compression on specific file extensions in assets and res/raw --> </aapt> </target>


जाहिर है, आपको इस कार्य में कुछ बदलने की आवश्यकता है। तार्किक रूप से, मैंने दो विकल्प देखे:
1. किसी भी तरह अपवाद सेट करें जो पैकेजिंग के दौरान अनावश्यक परिसंपत्तियों को फ़िल्टर करेगा।
2. एक और कदम जोड़ें: एक मौजूदा apk से अनावश्यक फ़ाइलों को हटाना।

सबसे मुश्किल था प्रलेखन पर खोज करना। जाहिर है, कार्य aapt मंच उपकरण पर निर्भर करता है। लेकिन इसके बारे में सब कुछ शेल में एक औपचारिक मदद और प्रलेखन में पाठ का एक टुकड़ा है:

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

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

इसलिए, मैं पैकेज को छोड़ने का फैसला करता हूं जैसा कि यह है, और दूसरा तरीका जाना है: पैकेज के बाद अनावश्यक फ़ाइलों को हटा दें। ऐसा करने के लिए, हमारे build.xml के अंदर कार्य के लिए निर्भरता को फिर से परिभाषित करें
"-पैकेज-रिलीज़" जो पैकेजिंग कार्य पर निर्भर करता है:

 <target name="-package-release" depends="-dex, -package-resources, -package-removetestassets"> <package-helper output.filepath="${out.unsigned.file}"/> </target> 
 

<target name="-package-release" depends="-dex, -package-resources, -package-removetestassets"> <package-helper output.filepath="${out.unsigned.file}"/> </target>


अब यह लक्ष्य main_rules.xml से मूल के बजाय उपयोग किया जाएगा। यह एक नई निर्भरता -पैकेज़-रिमेक्टेसैसेट जोड़ता है । अनावश्यक कार्यों को हटाने वाला सबसे सरल कार्य जोड़ें:

 <target name="-package-removetestassets"> <echo>Excluding test assets from apk</echo> <exec executable="${aapt}"> <arg value="remove"/> <arg value="${out.absolute.dir}/${resource.package.file.name}"/> <arg value="assets/test/*.*"/> </exec> </target> 
 

<target name="-package-removetestassets"> <echo>Excluding test assets from apk</echo> <exec executable="${aapt}"> <arg value="remove"/> <arg value="${out.absolute.dir}/${resource.package.file.name}"/> <arg value="assets/test/*.*"/> </exec> </target>


परिणाम प्राप्त किया जाता है, build.xml में कम से कम संभव परिवर्तन के साथ। और यह बहुत महत्वपूर्ण है, क्योंकि Android के नए संस्करणों में अपग्रेड करते समय जोखिम कम करता है।

मुझे उम्मीद है कि यह पोस्ट सहायक है।