ART कॉन्फ़िगर करें

इस पेज पर, Android रनटाइम (ART) को कॉन्फ़िगर करने और उसे कंपाइल करने के विकल्पों के बारे में बताया गया है. विषय यहां इसके बारे में बताया गया है. इसमें सिस्टम इमेज के प्रीकंपाइलेशन का कॉन्फ़िगरेशन शामिल है, dex2oat कंपाइलेशन के विकल्प उपलब्ध हैं. साथ ही, सिस्टम पार्टिशन स्पेस, डेटा पार्टिशन स्पेस, और परफ़ॉर्मेंस.

ART के साथ काम करने के लिए ART और Delvik और Dalvik का एक्ज़ीक्यूटेबल फ़ॉर्मैट देखें. पुष्टि करने का तरीका देखें यह पक्का करने के लिए कि आपके ऐप्लिकेशन सही तरीके से काम करें, Android रनटाइम (ART) पर ऐप्लिकेशन व्यवहार सही तरीके से.

एआरटी कैसे काम करता है

ART, टाइम-ऑफ़-टाइम (एओटी) कंपाइलेशन का इस्तेमाल करता है. Android 7 की शुरुआत से, यह AOT कंपाइलेशन, जस्ट-इन-टाइम (JIT) कंपाइलेशन, और इंटरप्रेटेशन के हाइब्रिड कॉम्बिनेशन का इस्तेमाल करता है. और एओटी कंपाइलेशन का इस्तेमाल प्रोफ़ाइल में किया जा सकता है. ये सभी एक्ज़ीक्यूशन मोड एक साथ लागू होते हैं कॉन्फ़िगर किया जा सकता है और इस सेक्शन में इनके बारे में चर्चा की जाएगी. उदाहरण के लिए, Pixel डिवाइसों को काम नीचे दिया गया है:

  1. किसी ऐप्लिकेशन को शुरुआत में, dex मेटाडेटा (.dm) फ़ाइल के साथ इंस्टॉल किया जाता है Play Store, जिसमें क्लाउड प्रोफ़ाइल मौजूद हो. ART AOT, क्लाउड में बताए गए तरीकों को कंपाइल करता है प्रोफ़ाइल. अगर ऐप्लिकेशन को डेक्स मेटाडेटा फ़ाइल के बिना इंस्टॉल किया जाता है, तो एओटी को कंपाइल नहीं किया जाता प्रदर्शन किया.
  2. जब शुरुआत में कुछ बार ऐप्लिकेशन चलाया जाता है, तो उन तरीकों को समझा जाता है जो एओटी से कंपाइल नहीं किए गए हैं. आम तौर पर, जिन मेथडों को एक्ज़ीक्यूट किया जाता है उनमें JIT को कंपाइल किया जाता है. एआरटी प्रोग्राम के तहत काम करने के हिसाब से, एक लोकल प्रोफ़ाइल जनरेट करता है और उसे क्लाउड प्रोफ़ाइल (अगर लागू हो) के साथ जोड़ता है मौजूद है).
  3. जब डिवाइस कुछ समय से इस्तेमाल में न हो और चार्ज हो रहा हो, तो ऐप्लिकेशन को फिर से कंपाइल करने के लिए, कंपाइलेशन डीमन चलता है यह डेटा, सर्वे की शुरुआत के कुछ समय के दौरान जनरेट हुई मिली-जुली प्रोफ़ाइल के आधार पर जनरेट किया गया है.
  4. ऐप्लिकेशन के बाद में चलाए जाने पर, ART कंपाइलेशन से जनरेट किए गए आर्टफ़ैक्ट का इस्तेमाल करता है डेमोन के दौरान, जनरेट हुए कोड की तुलना में, ज़्यादा एओटी से कंपाइल किया गया कोड होता है जिन तरीकों को एओटी से कंपाइल नहीं किया जाता उन्हें अब भी इंटरप्रेटेड या JIT से कंपाइल किया जाता है. ART प्रोफ़ाइल को अपडेट करता है और उसके बाद के चरण के आधार पर प्रोफ़ाइल को चुना जाएगा. कंपाइलेशन डीमन.

ART में एक कंपाइलर (dex2oat टूल) और एक रनटाइम शामिल होता है (libart.so) है जो बूट के दौरान लोड होता है. कॉन्टेंट बनाने dex2oat टूल एक APK फ़ाइल लेता है और एक या एक से ज़्यादा APK फ़ाइल जनरेट करता है कंपाइलेशन आर्टफ़ैक्ट फ़ाइलें, जिन्हें रनटाइम लोड करता है. फ़ाइलों की संख्या, उनकी एक्सटेंशन और नाम रिलीज़ में बदल सकते हैं, लेकिन Android 8 रिलीज़ होने पर, ये फ़ाइलें जनरेट होती हैं:

  • .vdex: इसमें, पुष्टि की प्रक्रिया को तेज़ करने के लिए कुछ अतिरिक्त मेटाडेटा शामिल होता है. कभी-कभी ऐसा भी हो सकता है APK के बिना कंप्रेस किए DEX कोड के साथ.
  • .odex: इसमें तरीकों के लिए एओटी से कंपाइल किया गया कोड शामिल होता है: APK के साथ काम करता है.
  • .art (optional) में ART आंतरिक शामिल है APK में शामिल कुछ स्ट्रिंग और क्लास की जानकारी दिखाई जाती है. इसका इस्तेमाल तेज़ी से करने के लिए किया जाता है ऐप स्टार्टअप हो सकता है.

कंपाइलेशन के विकल्प

एआरटी के लिए कंपाइलेशन विकल्पों की दो कैटगरी हैं:

  1. सिस्टम ROM कॉन्फ़िगरेशन: फ़ाइल बनाते समय एओटी कौनसा कोड इकट्ठा करता है सिस्टम इमेज.
  2. रनटाइम कॉन्फ़िगरेशन: एआरटी, टाइम आउट के दौरान ऐप्लिकेशन को कैसे कंपाइल और रन करता है डिवाइस.

कंपाइलर फ़िल्टर

इन दो कैटगरी को कॉन्फ़िगर करने के लिए, ART का एक मुख्य विकल्प कंपाइलर है फ़िल्टर. कंपाइलर फ़िल्टर से यह पता चलता है कि एआरटी, DEX कोड को कैसे कंपाइल करता है और विकल्प dex2oat टूल को पास किया गया. Android 8 और इसके बाद के वर्शन में, आधिकारिक तौर पर काम करने वाले चार फ़िल्टर उपलब्ध हैं:

  • verify: सिर्फ़ DEX कोड की पुष्टि करें (एओटी कंपाइलेशन नहीं है).
  • quicken: (Android 11 तक के लिए) DEX कोड चलाएं और बेहतर अनुवादक मोड के लिए कुछ DEX निर्देशों को ऑप्टिमाइज़ करें.
  • speed: DEX कोड की पुष्टि करें और सभी तरीकों को AOT-कंपाइल करें.
  • speed-profile: DEX कोड की पुष्टि और एओटी-कंपाइल तरीके चलाएं प्रोफ़ाइल फ़ाइल में मौजूद होता है.

सिस्टम ROM कॉन्फ़िगरेशन

पहले से इंस्टॉल की गई लाइब्रेरी और ऐप्लिकेशन, सिस्टम इमेज बनने के दौरान एओटी से कंपाइल किए जाते हैं. यह प्रक्रिया को dexpreopt कहते हैं. सभी डिपेंडेंसी होने पर ही, कंपाइल की गई ऐसी फ़ाइलों का इस्तेमाल किया जा सकता है कोई बदलाव नहीं किया जाएगा, खास तौर पर बूट क्लासपाथ.

ध्यान दें: अगर डिवाइस सिस्टम मॉड्यूल अपडेट करता है तो बूट क्लासपाथ बहुत के अगले अपडेट में बदल जाने की संभावना है, जिससे सभी dexpreopt फ़ाइलें पुरानी हो जाती हैं और उनका उपयोग नहीं किया जा सकता है.

dexpreopt को कॉन्फ़िगर करने के लिए कई ART बिल्ड विकल्प उपलब्ध हैं. कॉन्फ़िगर करने का तरीका ये विकल्प, सिस्टम इमेज के लिए उपलब्ध स्टोरेज स्पेस और पहले से इंस्टॉल किए गए ऐप्लिकेशन होते हैं. सिस्टम ROM में इकट्ठा किए जाने वाले JAR/APK को चार में बांटा जा सकता है श्रेणियां:

  • बूट क्लासपाथ कोड: speed-profile कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है डिफ़ॉल्ट.
  • सिस्टम सर्वर कोड (PRODUCT_SYSTEM_SERVER_JARS देखें, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, इस दस्तावेज़ में PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS आगे दिया गया है):
    • (Android 14 और उसके बाद के वर्शन) speed-profile के साथ कंपाइल किए गए हैं डिफ़ॉल्ट रूप से कंपाइलर फ़िल्टर या speed कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है, अगर प्रोफ़ाइल उपलब्ध नहीं कराई गई है.
    • (Android 13 और उससे पहले वाले वर्शन के लिए) speed के साथ कंपाइल किया गया है डिफ़ॉल्ट रूप से कंपाइलर फ़िल्टर.
    PRODUCT_SYSTEM_SERVER_COMPILER_FILTER के ज़रिए कॉन्फ़िगर किया जा सकता है (इसे बाद में देखें दस्तावेज़).
  • प्रॉडक्ट के हिसाब से बने मुख्य ऐप्लिकेशन (इस लेख में PRODUCT_DEXPREOPT_SPEED_APPS को बाद में देखें दस्तावेज़: डिफ़ॉल्ट रूप से, speed कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है.
  • अन्य सभी ऐप्लिकेशन: डिफ़ॉल्ट रूप से, speed-profile कंपाइलर फ़िल्टर के साथ कंपाइल किए जाते हैं, या प्रोफ़ाइल न मिलने पर, verify कंपाइलर फ़िल्टर की मदद से कंपाइल किया जाता है.

    PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER के ज़रिए कॉन्फ़िगर किया जा सकता है (बाद में इसमें देखें दस्तावेज़).

मेकफ़ाइल के विकल्प

  • WITH_DEXPREOPT

    • सिस्टम इमेज पर इंस्टॉल किए गए DEX कोड पर, dex2oat को शुरू किया जाता है या नहीं. यह सुविधा डिफ़ॉल्ट रूप से चालू होती है.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 और उसके बाद वाले वर्शन के लिए)

    • DONT_DEXPREOPT_PREBUILTS को चालू करने से, पहले से बनाए गए एलिमेंट नहीं दिखेंगे जिसमें सुधार किया गया है. इन ऐप्लिकेशन में include $(BUILD_PREBUILT) है उनके Android.mk में मौजूद है. स्किप करना पहले से बने ऐसे ऐप्लिकेशन जिन्हें Google Play से अपडेट किया जा सकता है यह सिस्टम की इमेज में जगह बचाती है. हालांकि, डिवाइस के पहली बार चालू होने के समय में बढ़ोतरी होती है. ध्यान दें कि इस विकल्प से कोई असर नहीं पड़ता Android.bp में बताए गए, पहले से बने ऐप्लिकेशन के हिसाब से.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 वर्शन) और उच्च)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER, डिफ़ॉल्ट कंपाइलर फ़िल्टर के बारे में बताता है dexpreopted ऐप्स के लिए. इन ऐप्लिकेशन के बारे में Android.bp में बताया गया है या इनमें include $(BUILD_PREBUILT) की जानकारी अपने Android.mk में दी गई है. अगर इसके बारे में जानकारी न दी गई हो, डिफ़ॉल्ट मान speed-profile है, या अगर मान न दिया गया हो, तो verify है और प्रोफ़ाइल उपलब्ध नहीं कराई गई है.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 8 MR1 के बाद से)

    • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY को सक्षम करने से केवल बूट क्लासपाथ और सिस्टम सर्वर जार.

  • LOCAL_DEX_PREOPT

    • Dexpreopt को हर ऐप्लिकेशन के हिसाब से चालू या बंद किया जा सकता है. इसके लिए मॉड्यूल की परिभाषा में, LOCAL_DEX_PREOPT विकल्प को तय करके. इसकी मदद से, उन ऐप्लिकेशन के लिए खोज बंद करने की सुविधा को बंद किया जा सकता है जिन्हें तुरंत ऐक्सेस किया जा सकता है Google Play के अपडेट मिलेंगे, क्योंकि अपडेट करने पर सिस्टम इमेज में मौजूद कोड पुराना हो गया है. यह मुख्य विषयों पर जगह बचाने में भी मदद करता है को अपग्रेड करने का विकल्प होता है, क्योंकि हो सकता है कि उपयोगकर्ताओं के पास डेटा विभाजन.

    LOCAL_DEX_PREOPT, true या false वैल्यू के साथ काम करता है, ताकि dexpreopt को क्रम से चालू या बंद करना. इसके अलावा, nostripping यह कर सकता है: अगर dexpreopt को classes.dex को स्ट्रिप करना नहीं चाहिए, तो बताया जाना चाहिए फ़ाइल से लिया गया है. आम तौर पर इस फ़ाइल को हटा दिया जाता है क्योंकि यह कोई dexpreopt के बाद ज़्यादा आवश्यक है, लेकिन यह अंतिम विकल्प तीसरे पक्ष के APK हस्ताक्षरों को मान्य रहने दें.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • इमेज के बूट की स्थिति को कंट्रोल करने के लिए, dex2oat को विकल्प देता है कंपाइल किया गया. इसका इस्तेमाल, पसंद के मुताबिक बनाई गई इमेज क्लास की सूचियों के बारे में बताने के लिए किया जा सकता है. क्लास की सूची, और कंपाइलर फ़िल्टर का इस्तेमाल किया जा सकता है.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • यह सेटिंग, dex2oat को विकल्प देती है. इससे यह कंट्रोल किया जा सकता है कि बूट इमेज को कंपाइल किया जाता है.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • किसी खास क्वेरी के लिए, dex2oat विकल्प पास करने की सुविधा मिलती है मॉड्यूल और प्रॉडक्ट कॉन्फ़िगरेशन की ज़रूरत होती है. यह किसी प्रॉडक्ट के $(call add-product-dex-preopt-module-config,<modules>,<option>) की device.mk फ़ाइल जहां <modules>, LOCAL_MODULE और JAR और APK फ़ाइलों के लिए, LOCAL_PACKAGE नाम.

  • PRODUCT_DEXPREOPT_SPEED_APPS (Android 8 के बाद से)

    • उन ऐप्लिकेशन की सूची जिनकी पहचान प्रॉडक्ट के मुख्य ऐप्लिकेशन के तौर पर की गई है और जिन्हें speed कंपाइलर फ़िल्टर के साथ कंपाइल किया जा सकता है. इसके लिए उदाहरण के लिए, SystemUI जैसे स्थायी ऐप्लिकेशन को केवल अगले रीबूट पर प्रोफ़ाइल-निर्देशित कंपाइलेशन, इसलिए यह प्रॉडक्ट को हमेशा एओटी-कंपाइलेटेड बनाने के लिए किया जा सकता है.

  • PRODUCT_SYSTEM_SERVER_APPS (Android 8 के बाद से)

    • सिस्टम सर्वर से लोड किए गए ऐप्लिकेशन की सूची. ये ऐप्लिकेशन इन्हें speed कंपाइलर फ़िल्टर के साथ डिफ़ॉल्ट रूप से कंपाइल किया जाता है.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (Android के बाद से 8)

    • क्या डिवाइस पर ART के डीबग वर्शन को शामिल करना है. डिफ़ॉल्ट रूप से, यह है यह यूज़र डीबग और इंजीनियरिंग बिल्ड के लिए चालू है. व्यवहार को स्पष्ट रूप से बदला जा सकता है true या false पर सेट करना है.

    डिफ़ॉल्ट रूप से, यह डिवाइस, नॉन-डीबग वर्शन (libart.so) का इस्तेमाल करता है. स्विच करने के लिए, सिस्टम प्रॉपर्टी persist.sys.dalvik.vm.lib.2 को libartd.so.

  • WITH_DEXPREOPT_PIC (Android 7 तक)

    • Android 5.1.0 से Android 6.0.1 तक, WITH_DEXPREOPT_PIC ये काम कर सकता है: स्थिति-स्वतंत्र कोड (PIC) को सक्षम करने के लिए बताया जाना चाहिए. इसके साथ, कंपाइल किए गए इमेज में मौजूद कोड को दूसरी जगह ले जाने की ज़रूरत नहीं है /system, /data/dalvik-cache में. इससे डेटा पार्टिशन में जगह खाली हो रही है. हालांकि, रनटाइम का थोड़ा असर होता है, क्योंकि इससे ऑप्टिमाइज़ेशन की सुविधा बंद हो जाती है. की जगह पर निर्भर करता है. आम तौर पर, वे डिवाइस जो /data में जगह बचाना चाहते हैं को पीआईसी कंपाइलेशन चालू करना चाहिए.

    Android 7.0 में, PIC कंपाइलेशन डिफ़ॉल्ट रूप से चालू था.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (Android 7 तक MR1)

    • इस विकल्प को WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY से बदल दिया गया था जो सिस्टम सर्वर के JAR को भी शामिल करती है.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • यह विकल्प, सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर के बारे में बताता है.

    • (Android 14 और उसके बाद के वर्शन) अगर साफ़ तौर पर नहीं बताया गया है, तो speed-profile कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है. अगर प्रोफ़ाइल नहीं है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है दिया गया है.
    • (Android 13 और उससे पहले वाले वर्शन के लिए) अगर जानकारी नहीं दी गई है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर इस नीति को speed पर सेट किया जाता है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर speed-profile पर सेट किया जाता है, तो speed-profile कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है, या प्रोफ़ाइल न होने पर verify कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर इस नीति को verify पर सेट किया जाता है, तो verify कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.

  • PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • सिस्टम सर्वर से लोड किए जाने वाले JAR की सूचियां नीचे दी गई हैं. JAR को PRODUCT_SYSTEM_SERVER_COMPILER_FILTER से तय किया गया कंपाइलर फ़िल्टर

    • (ज़रूरी है) PRODUCT_SYSTEM_SERVER_JARS: सिस्टम सर्वर क्लासपाथ JAR की सूची एक प्लैटफ़ॉर्म है (जो SYSTEMSERVERCLASSPATH के हिस्से के तौर पर है). सिस्टम सर्वर जोड़ा जा रहा है इस सूची के लिए क्लासपाथ JAR ज़रूरी हैं. सूची में सिस्टम सर्वर क्लासपाथ JAR नहीं जोड़े जा सके इससे वे JAR लोड नहीं होंगे.
    • (ज़रूरी है) PRODUCT_APEX_SYSTEM_SERVER_JARS: सिस्टम सर्वर क्लासपाथ JAR की सूची APEX के साथ डिलीवर किया गया (यानी कि SYSTEMSERVERCLASSPATH के हिस्से के रूप में). फ़ॉर्मैट यह है <apex name>:<jar name>. APEX सिस्टम सर्वर क्लासपाथ JAR जोड़ें यह सूची ज़रूरी है. इस सूची में APEX सिस्टम सर्वर क्लासपाथ JAR नहीं जोड़ने पर, ये नतीजे मिलेंगे वे JAR लोड नहीं हो रहे हैं.
    • (ज़रूरी नहीं है. Android 13 और उससे पहले के वर्शन के लिए) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: सिस्टम सर्वर लोड किए जाने वाले JAR की सूची अलग-अलग क्लासलोडर का इस्तेमाल करके (इसके ज़रिए SystemServiceManager.startServiceFromJar). इसमें स्टैंडअलोन सिस्टम सर्वर JAR जोड़े जा रहे हैं यह सूची ज़रूरी नहीं है, लेकिन इसे ज़रूरी दिया गया है, क्योंकि यह JAR को कंपाइल करता है और इसलिए, रनटाइम का परफ़ॉर्मेंस अच्छा रहता है.
    • (Android 13 और इसके बाद के वर्शन में उपलब्ध है) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: इनकी सूची APEX के साथ डिलीवर किए गए JARs, जिन्हें सिस्टम सर्वर अलग-अलग क्लासलोडर का इस्तेमाल करके डाइनैमिक तौर पर लोड करता है ( SystemServiceManager.startServiceFromJar के माध्यम से या इस रूप में घोषित किया गया है <apex-system-service>). फ़ॉर्मैट यह है <apex name>:<jar name>. इसमें स्टैंडअलोन APEX सिस्टम सर्वर JARs जोड़े जा रहे हैं यह सूची ज़रूरी है. इस सूची में स्टैंडअलोन APEX सिस्टम सर्वर JAR नहीं जोड़ने पर, ये नतीजे मिलेंगे चालू नहीं हो सका.

    बूट क्लासपाथ कॉन्फ़िगरेशन

    पहले से लोड की गई क्लास की सूची, उन क्लास की सूची है जिन्हें Zygote शुरू करता है शुरू करें. इससे हर ऐप्लिकेशन को क्लास शुरू करने वाले ये टूल चलाने की ज़रूरत नहीं पड़ती इससे उन्हें तेज़ी से शुरू करने और मेमोरी में पेजों को शेयर करने में मदद मिलती है. कॉन्टेंट बनाने पहले से लोड की गई क्लास की सूची वाली फ़ाइल, frameworks/base/config/preloaded-classes पर मौजूद है डिफ़ॉल्ट रूप से होता है, और इसमें एक ऐसी सूची होती है जो सामान्य फ़ोन उपयोग के लिए ट्यून की जाती है. यह हो सकता है अन्य डिवाइसों के लिए अलग हो, जैसे कि पहने जाने वाले डिवाइस. साथ ही, इसे ट्यून किया जाना चाहिए उसी के हिसाब से. इसे ट्यून करते समय सावधान रहें; कई क्लास कचरे को रीसाइकल करना इस्तेमाल न की गई क्लास लोड होने पर मेमोरी. बहुत कम क्लास जोड़ने से हर ऐप्लिकेशन को उसकी अपनी कॉपी नहीं होती है, जिससे फिर से मेमोरी बर्बाद हो जाती है.

    इस्तेमाल के उदाहरण (प्रॉडक्ट के device.mk में):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

    ध्यान दें: आपको पहले यह लाइन रखनी होगी किसी भी प्रॉडक्ट कॉन्फ़िगरेशन को इनहेरिट करने से, ऐसी फ़ाइलें बन जाती हैं जिन्हें डिफ़ॉल्ट तौर पर build/target/product/base.mk.

    रनटाइम कॉन्फ़िगरेशन

    JIT के विकल्प

    ये विकल्प, Android की उन रिलीज़ पर असर डालते हैं जिनमें ART JIT कंपाइलर काम करता है उपलब्ध है.

    • dalvik.vm.usejit: JIT चालू है या नहीं.
    • dalvik.vm.jitinitialsize (डिफ़ॉल्ट 64K): शुरुआती कपैसिटी कोड कैश मेमोरी में सेव किया जा सकता है. कोड कैश मेमोरी को समय-समय पर इस्तेमाल किया जाएगा. साथ ही, ज़रूरत पड़ने पर इसे बढ़ाया जाएगा.
    • dalvik.vm.jitmaxsize (डिफ़ॉल्ट 64M): कोड की कैश मेमोरी की ज़्यादा से ज़्यादा क्षमता.
    • dalvik.vm.jitthreshold (डिफ़ॉल्ट 10000): वह थ्रेशोल्ड जिस पर "हॉटनेस" काउंटर ऑफ़ हो जाने पर, JIT-कंपाइलेशन के लिए इस्तेमाल किया जाता है. "हॉटनेस" काउंटर एक आंतरिक मेट्रिक है के लिए इस्तेमाल किया जा सकता है. इसमें कॉल, बैकवर्ड ब्रांच की संख्या, और अन्य फ़ैक्टर.
    • dalvik.vm.usejitprofiles (Android 13 तक के लिए): क्या JIT की प्रोफ़ाइलें चालू नहीं हैं; इसका इस्तेमाल तब भी किया जा सकता है, जब dalvik.vm.usejit गलत हो. ध्यान दें कि अगर यह वैल्यू गलत है, तो कंपाइलर फ़िल्टर speed-profile किसी भी तरीके को एओटी-कंपाइल नहीं करता और यह verify के बराबर है. से Android 14 और JIT प्रोफ़ाइलें हमेशा चालू रहती हैं और इन्हें बंद नहीं किया जा सकता.
    • dalvik.vm.jitprithreadweight (डिफ़ॉल्ट रूप से यह होता है dalvik.vm.jitthreshold / 20): JIT "सैंपल" का वज़न ऐप्लिकेशन यूज़र इंटरफ़ेस (यूआई) थ्रेड के लिए (jitthreshold देखें). कंपाइलेशन की स्पीड बढ़ाने के लिए इसका इस्तेमाल करें के साथ इंटरैक्ट करते समय उपयोगकर्ता अनुभव को सीधे तौर पर प्रभावित करते हैं. है.
    • dalvik.vm.jittransitionweight (डिफ़ॉल्ट रूप से यह होता है dalvik.vm.jitthreshold / 10): तरीके का महत्व यह कंपाइल कोड और इंटरप्रेटर के बीच ट्रांज़िशन करता है. इससे मदद मिली पक्का कर लें कि इसमें शामिल तरीकों को कंपाइल किया गया है, ताकि ट्रांज़िशन को कम किया जा सके (जो महंगा).

    डेक्स2ओट के विकल्प

    ये विकल्प, उपयोगकर्ता के डिवाइस पर मौजूद डेटा को कंपाइल करने की प्रोसेस पर असर डालते हैं. जैसे, dexopt. साथ ही, कुछ विकल्पों से dexpreopt में शामिल किया गया है, जबकि सिर्फ़ ऊपर दिए गए सिस्टम ROM कॉन्फ़िगरेशन सेक्शन में बताए गए विकल्प dexpreopt को प्रभावित करता है.

    संसाधन के इस्तेमाल को कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (Android 11 तक के लिए): थ्रेड की संख्या और सीपीयू कोर का सेट (देखें (नीचे) बूट इमेज के लिए इस्तेमाल किया जाएगा.
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • (Android 11 तक के वर्शन) थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें) बूट चित्र के अलावा अन्य सभी चीज़ों के लिए बूट समय के दौरान उपयोग करने के लिए.
      • (Android 12 के बाद से) थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें) बूट चित्र सहित हर चीज़ के लिए बूट समय के दौरान उपयोग करने के लिए.
        • खास तौर पर, Android 14 के बाद से, यह ART सेवा में प्राथमिकता श्रेणी PRIORITY_BOOT.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (Android 11 और Android 13 के बाद के वर्शन पर) क्लाउड से डेटा वापस पाने के लिए थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें) बैकअप लें.
      • (Android 14 के बाद से) थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें) ऐसी सभी चीज़ों के लिए इस्तेमाल किया जाएगा जो सामान्य से ज़्यादा इंतज़ार के समय के लिए संवेदनशील हैं. इसमें ये शामिल हैं क्लाउड बैकअप से पुनर्स्थापित करना.
        • खास तौर पर, यह प्रायॉरिटी क्लास के बारे में है एआरटी सेवा में PRIORITY_INTERACTIVE_FAST.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (Android 14 के बाद से): थ्रेड की संख्या और सीपीयू कोर का सेट (देखें का इस्तेमाल करें).
      • खास तौर पर, यह इस इवेंट की प्राथमिकता क्लास PRIORITY_BACKGROUND से मेल खाता है एआरटी सेवा.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: बाकी सभी चीज़ों के लिए इस्तेमाल किए जाने वाले थ्रेड की संख्या और सीपीयू कोर का सेट.

    सीपीयू कोर के सेट को, कॉमा लगाकर अलग किए गए सीपीयू आईडी की सूची के तौर पर बताया जाना चाहिए. उदाहरण के लिए: CPU कोर 0-3 पर dex2oat के लिए, सेट करें:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3

    हमारा सुझाव है कि सीपीयू अफ़िनिटी प्रॉपर्टी को सेट करते समय, ग़ैर-ज़रूरी मेमोरी और I/O से बचने के लिए, चुने गए सीपीयू की संख्या से मैच करने के लिए dex2oat थ्रेड की संख्या विवाद: 

    dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

    ऊपर दी गई सिस्टम प्रॉपर्टी के अलावा, टास्क प्रोफ़ाइल का इस्तेमाल करके, dex2oat के संसाधन का इस्तेमाल (Cgroup ऐब्स्ट्रैक्शन लेयर देखें).

    इन टास्क प्रोफ़ाइलों का इस्तेमाल किया जा सकता है:

    • Dex2OatBackground अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 14 के बाद के वर्शन) (डिफ़ॉल्ट रूप से, Dex2OatBootComplete को इनहेरिट करता है): यह नीति बैकग्राउंड में इस्तेमाल करने के लिए, संसाधनों को कंट्रोल करती है.
      • खास तौर पर, यह इस इवेंट की प्राथमिकता क्लास PRIORITY_BACKGROUND से मेल खाता है एआरटी सेवा.
    • Dex2OatBootComplete:
      • (Android 13 तक के लिए) संसाधन को कंट्रोल करता है, ताकि हर काम के लिए उसका इस्तेमाल किया जा सके बूट के बाद.
      • (Android 14 के बाद के वर्शन) सभी कामों के लिए इस्तेमाल किए जाने वाले संसाधन को कंट्रोल करता है बैकग्राउंड में नहीं, बल्कि चालू होने के बाद भी.
        • खास तौर पर, यह प्रायॉरिटी क्लास के बारे में है एआरटी में PRIORITY_INTERACTIVE_FAST और PRIORITY_INTERACTIVE सेवा.

    जब सिस्टम प्रॉपर्टी और टास्क प्रोफ़ाइल, दोनों तय किए जाते हैं, तो दोनों काम करते हैं.

    हीप के साइज़ को कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-Xms: बूट इमेज के लिए शुरुआती हीप साइज़.
    • dalvik.vm.image-dex2oat-Xmx: बूट इमेज के लिए ज़्यादा से ज़्यादा हीप साइज़.
    • dalvik.vm.dex2oat-Xms: बाकी सभी चीज़ों के लिए शुरुआती हीप साइज़.
    • dalvik.vm.dex2oat-Xmx: बाकी सभी चीज़ों के लिए ज़्यादा से ज़्यादा हीप साइज़.

    वे विकल्प जो इसके लिए शुरुआती और ज़्यादा से ज़्यादा हीप साइज़ को कंट्रोल करते हैं dex2oat को कम नहीं करना चाहिए, क्योंकि इससे क्या ऐप्लिकेशन को कंपाइल किया जा सकता है.

    कंपाइलर फ़िल्टर को कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-filter (Android 11 तक के लिए): बूट इमेज के लिए कंपाइलर फ़िल्टर. Android 12 के बाद से, कंपाइलर बूट इमेज का फ़िल्टर हमेशा speed-profile होता है और इसे बदला नहीं जा सकता.
    • dalvik.vm.systemservercompilerfilter (Android 13 के बाद के वर्शन): सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर. देखें PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
    • dalvik.vm.systemuicompilerfilter (Android 13 के बाद के वर्शन): सिस्टम यूज़र इंटरफ़ेस (यूआई) पैकेज के लिए कंपाइलर फ़िल्टर.
    • dalvik.vm.dex2oat-filter (Android 6 तक): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर.
    • pm.dexopt.<reason> (Android 7 के बाद वाले वर्शन के लिए): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर. यहां जाएं: Android के लिए ART सेवा कॉन्फ़िगरेशन 14 साल और उससे ज़्यादा उम्र के बच्चों के लिए या के लिए पैकेज मैनेजर कॉन्फ़िगरेशन Android 13 और इससे पहले के वर्शन के लिए.

    बूट इमेज के अलावा सभी चीज़ों के कंपाइलेशन को कंट्रोल करने के अन्य विकल्प:

    • dalvik.vm.dex2oat-very-large (Android 7.1 के बाद वाले वर्शन के लिए): डेक्स फ़ाइल का कम से कम कुल साइज़ बाइट डालें.
    • dalvik.vm.dex2oat-swap (Android 7.1 के बाद वाले वर्शन के साथ) (डिफ़ॉल्ट: सही): स्वैप करने की अनुमति देता है dex2oat के लिए फ़ाइल डाउनलोड करें. इससे, स्टोरेज खत्म होने की वजह से होने वाले क्रैश से बचा जा सकता है. ध्यान दें कि भले ही यह विकल्प यह सुविधा चालू होने पर, dex2oat सिर्फ़ कुछ स्थितियों में स्वैप फ़ाइल का इस्तेमाल करेगा. उदाहरण के लिए, dex फ़ाइलें बड़ी होती हैं और इनकी शर्तों में बदलाव हो सकता है.
    • dalvik.vm.ps-min-first-save-ms (Android 12 के बाद के वर्शन के लिए): रनटाइम के ज़रिए ऐप्लिकेशन की प्रोफ़ाइल जनरेट करने से पहले, इंतज़ार करने में लगने वाला कम से कम समय ऐप्लिकेशन लॉन्च हो जाता है.
    • dalvik.vm.ps-min-save-period-ms (Android 12 के बाद के वर्शन के लिए): ऐप्लिकेशन की प्रोफ़ाइल अपडेट करने में कम से कम समय लगेगा.
    • dalvik.vm.dex2oat64.enabled अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 11 के बाद के वर्शन) (डिफ़ॉल्ट: false): dex2oat का 64-बिट वर्शन इस्तेमाल करना है या नहीं.
    • dalvik.vm.bgdexopt.new-classes-percent अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 12 के बाद के वर्शन) (डिफ़ॉल्ट: 20): फिर से कंपाइलेशन ट्रिगर करने के लिए, किसी प्रोफ़ाइल में नई क्लास का कम से कम प्रतिशत. यह संख्या 0 से 100 के बीच होती है. सिर्फ़ प्रोफ़ाइल के हिसाब से डेटा को इकट्ठा करने की सुविधा (speed-profile) पर लागू होता है, जो आम तौर पर बैकग्राउंड डीक्ज़ॉप्ट. ध्यान दें कि क्लास के अतिरिक्त कम से कम 50 नए क्लास का थ्रेशोल्ड भी मौजूद है प्रतिशत की सीमा होती है और इसे कॉन्फ़िगर नहीं किया जा सकता.
    • dalvik.vm.bgdexopt.new-methods-percent अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 12 के बाद के वर्शन) (डिफ़ॉल्ट: 20): फिर से कंपाइलेशन ट्रिगर करने के लिए प्रोफ़ाइल में नई तरीकों का कम से कम प्रतिशत, जो 0 से 100 के बीच होता है. सिर्फ़ प्रोफ़ाइल के हिसाब से डेटा को इकट्ठा करने की सुविधा (speed-profile) पर लागू होता है, जो आम तौर पर बैकग्राउंड डीक्ज़ॉप्ट. ध्यान दें कि इसके अलावा कम से कम 100 नए तरीकों के थ्रेशोल्ड भी मौजूद हैं है और इसे कॉन्फ़िगर नहीं किया जा सकता.
    • dalvik.vm.dex2oat-max-image-block-size अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 10 के बाद के वर्शन) (डिफ़ॉल्ट: 524288) कंप्रेस की गई इमेज के लिए ब्लॉक का ज़्यादा से ज़्यादा साइज़. बड़ी इमेज को सॉलिड के सेट में बांटा गया है इस तरह ब्लॉक कर दें कि कोई भी ब्लॉक अधिकतम आकार से बड़ा न हो.
    • dalvik.vm.dex2oat-resolve-startup-strings अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 10 के बाद के वर्शन) (डिफ़ॉल्ट: सही) अगर सही है, तो dex2oat से उन सभी कॉन्स्ट-स्ट्रिंग को ठीक किया जाता है जिन्हें इस तौर पर मार्क किए गए तरीकों से रेफ़र किया गया है "स्टार्टअप" प्रोफ़ाइल में.
    • debug.generate-debug-info अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (डिफ़ॉल्ट: गलत) नेटिव डीबगिंग के लिए डीबग की जानकारी जनरेट करनी है या नहीं, जैसे कि स्टैक अनंडिंग जानकारी, ईएलएफ़ सिंबल, और बौनों के सेक्शन.
    • dalvik.vm.dex2oat-minidebuginfo अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (Android 9 के बाद से) (डिफ़ॉल्ट: सही) इस बात के लिए ज़रूरी है कि LZMA की कंप्रेस की गई डीबग जानकारी कम से कम जनरेट की जाए या नहीं इसे प्रिंट करता है.

    एआरटी सेवा के विकल्प

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

    पैकेज मैनेजर के विकल्प

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

    A/B के लिए खास कॉन्फ़िगरेशन

    ROM कॉन्फ़िगरेशन

    Android 7.0 से, डिवाइस चालू करने के लिए दो सिस्टम पार्टीशन का इस्तेमाल कर सकते हैं A/B सिस्टम अपडेट. सिस्टम पार्टिशन का साइज़ सेव करने के लिए, पहले से इस्तेमाल की गई फ़ाइलों को यहां इंस्टॉल किया जा सकता है दूसरे सिस्टम का दूसरा हिस्सा इस्तेमाल नहीं किया जा सकता. इसके बाद, उन्हें डेटा पार्टिशन में कॉपी किया जाता है पहले बूट पर.

    इस्तेमाल के उदाहरण (device-common.mk में):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    डिवाइस के BoardConfig.mk में:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    ध्यान दें कि बूट क्लासपाथ कोड, सिस्टम सर्वर कोड, और प्रॉडक्ट खास कोर ऐप्लिकेशन हमेशा सिस्टम पार्टिशन में इकट्ठा होते हैं. डिफ़ॉल्ट रूप से, अन्य सभी ऐप्लिकेशन को इस्तेमाल न किए गए दूसरे सिस्टम पार्टीशन में कंपाइल किया जाता है. यह काम किया जा सकता है SYSTEM_OTHER_ODEX_FILTER से कंट्रोल किया जाता है, जिसकी वैल्यू इसका डिफ़ॉल्ट:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    बैकग्राउंड में लागू होने वाले ओटीए डेक्सऑप्ट

    A/B सक्षम डिवाइस पर, रीबूट से पहले ऐप्लिकेशन को नया सिस्टम इमेज. ऐप्लिकेशन कंपाइलेशन इसमें देखें बैकग्राउंड का भी इस्तेमाल किया जा सकता है. कॉन्टेंट बनाने इस कंपाइलेशन के लिए इस्तेमाल किया गया फ़िल्टर, इससे कंट्रोल किया जाता है:

    pm.dexopt.ab-ota=speed-profile

    अगर आपको प्रोफ़ाइल गाइड का इस्तेमाल करना है, तो हमारा सुझाव है कि आप speed-profile का इस्तेमाल करें और स्टोरेज पर बचत करने के लिए किया जा सकता है.

    JDWP के विकल्प

    यूज़र डीबग बिल्ड में Java डीबग वायर प्रोटोकॉल (JDWP) थ्रेड बनाने को इसके ज़रिए कंट्रोल किया जाता है persist.debug.dalvik.vm.jdwp.enabled सिस्टम प्रॉपर्टी. डिफ़ॉल्ट रूप से, यह प्रॉपर्टी सेट नहीं है और JDWP थ्रेड सिर्फ़ डीबग किए जा सकने वाले ऐप्लिकेशन के लिए बनाए जाते हैं. दोनों के लिए JDWP थ्रेड चालू करने के लिए डीबग करने लायक और डीबग नहीं किए जा सकने वाले ऐप्लिकेशन, persist.debug.dalvik.vm.jdwp.enabled सेट करें 1 तक. प्रॉपर्टी में किए गए बदलावों को लागू करने के लिए, डिवाइस को फिर से चालू करना होगा.

    यूज़रडीबग बिल्ड पर डीबग करने लायक ऐप्लिकेशन को डीबग करने के लिए, नीचे दिए गए निर्देश अपनाकर JDWP को चालू करें आदेश:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Android 13 और उससे पहले के वर्शन वाले डिवाइसों के लिए, रनटाइम JDWP बनाता है userdebug बिल्ड पर डीबग करने लायक और न डीबग करने लायक ऐप्लिकेशन के लिए थ्रेड. इसका मतलब है कि यह मुमकिन है कि का इस्तेमाल, डीबगर को अटैच करने या userडीबग बिल्ड पर किसी ऐप्लिकेशन की प्रोफ़ाइल करने के लिए किया होगा.