Delvik एक्ज़ीक्यूटेबल फ़ॉर्मैट

यह दस्तावेज़ .dex के लेआउट और कॉन्टेंट के बारे में बताता है फ़ाइलें जिनका इस्तेमाल क्लास की परिभाषाओं के सेट और उनसे जुड़ी सहायक डेटा.

टाइप के बारे में जानकारी देने वाली गाइड

एलईबी128

LEB128 ("Little-Endian Base 128") के लिए वैरिएबल-लम्बाई एन्कोडिंग मनचाहे तरीके से हस्ताक्षर किए गए या साइन नहीं किए गए पूर्णांक की संख्या. फ़ॉर्मैट था DWARF3 से लिया है स्पेसिफ़िकेशन. .dex फ़ाइल में, LEB128 का इस्तेमाल सिर्फ़ इन कामों के लिए किया जाता है 32-बिट क्वांटिटी को एन्कोड करें.

LEB128 कोड में बदली गई हर वैल्यू में एक से पांच होती हैं बाइट, जो साथ मिलकर एक 32-बिट वैल्यू दिखाते हैं. हर बाइट का बिट सेट अंतिम बाइट को छोड़कर, होता है, जो सबसे ज़्यादा साफ़ तौर पर समझ आता है. शेष हर बाइट के सात बिट पेलोड होते हैं. पहली बाइट में, मात्रा के बिट, दूसरे में अगले सात बाइट वगैरह. हस्ताक्षर किए गए LEB128 (sleb128) के मामले में, क्रम में मौजूद फ़ाइनल बाइट का सबसे अहम पेलोड बिट है अंतिम मान प्राप्त करने के लिए चिह्न-बढ़ाया गया है. साइन नहीं किए गए केस में (uleb128), ऐसा कोई भी बिट जो साफ़ तौर पर नहीं दिखाया गया है 0 के रूप में समझा जाता है.

वैरिएंट uleb128p1 का इस्तेमाल, हस्ताक्षर वाले दस्तावेज़ को दिखाने के लिए किया जाता है वैल्यू, जहां वैल्यू को प्लस वन के तौर पर एन्कोड किया गया है uleb128 के तौर पर. इससे -1 की एन्कोडिंग हो जाती है (इसे अन्य तरीके से, बिना साइन वाली वैल्यू 0xffffffff के तौर पर माना जाता है) — लेकिन कोई अन्य नेगेटिव संख्या नहीं है — सिर्फ़ एक बाइट है, और उन मामलों में उपयोगी है जहां बताई गई संख्या में या तो नेगेटिव या -1 (या 0xffffffff) वाली वैल्यू होनी चाहिए, और जहां किसी अन्य ऋणात्मक मान की अनुमति न हो (या जहां बड़े अहस्ताक्षरित हैं में वैल्यू की ज़रूरत नहीं होती है).

यहां फ़ॉर्मैट के कुछ उदाहरण दिए गए हैं:

फ़ाइल लेआउट

बिटफ़ील्ड, स्ट्रिंग, और कॉन्सटेंट डेफ़िनिशन

DEX_FILE_MAGIC

हेडर_आइटम में एम्बेड किया गया

कॉन्स्टेंट अरे/स्ट्रिंग DEX_FILE_MAGIC, वे बाइट जो .dex फ़ाइल की शुरुआत में दिखनी चाहिए ताकि उसे इस तरह पहचाना जा सके. वैल्यू जान-बूझकर एक नई पंक्ति ("\n" या 0x0a) शामिल है और मदद के लिए शून्य बाइट ("\0" या 0x00) के बारे में पता लगाया जा सकता है. वैल्यू भी फ़ॉर्मैट वर्शन संख्या को तीन दशमलव अंकों के तौर पर कोड में बदलता है. यह जैसे-जैसे फ़ॉर्मैट में बदलाव होगा, समय के साथ इसमें एक सामान्य बढ़ोतरी हो सकती है.

ubyte[8] DEX_FILE_MAGIC = { 0x64 0x65 0x78 0x0a 0x30 0x33 0x39 0x00 }
                        = "dex\n039\0"

नोट: इसके 039 वर्शन के लिए समर्थन फ़ॉर्मैट को Android 9.0 रिलीज़ में जोड़ा गया था. साथ ही, नए बाइट कोड, const-method-handle और const-method-type. (इन दोनों के बारे में, बाइट कोड सेट की खास जानकारी टेबल.) Android 10 के वर्शन 039 में, DEX फ़ाइल फ़ॉर्मैट को छिपाया गया है, ताकि उसे एपीआई की ऐसी जानकारी जो सिर्फ़ बूट क्लास पाथ की DEX फ़ाइलों पर लागू होती है.

ध्यान दें: वर्शन के लिए सहायता फ़ॉर्मैट का 038 को Android 8.0 में जोड़ा गया था रिलीज़. वर्शन 038 में नए बाइट कोड जोड़े गए (invoke-polymorphic और invoke-custom) और तरीके के हैंडल के लिए डेटा.

ध्यान दें: इसके 037 वर्शन के लिए सहायता यह फ़ॉर्मैट, Android 7.0 रिलीज़ में जोड़ा गया था. 037 से पहले के वर्शन में सबसे ज़्यादा Android के वर्शन ने इस फ़ॉर्मैट के 035 वर्शन का इस्तेमाल किया है. सिर्फ़ वर्शन 035 और 037 में यह अंतर है डिफ़ॉल्ट तरीकों को जोड़ना और invoke का अडजस्टमेंट करना.

ध्यान दें: फ़ॉर्मैट के कम से कम कुछ पुराने वर्शन में का इस्तेमाल, सभी के लिए उपलब्ध सार्वजनिक सॉफ़्टवेयर रिलीज़ में किया गया है. उदाहरण के लिए, वर्शन 009 का इस्तेमाल Android प्लैटफ़ॉर्म (नवंबर–दिसंबर 2007), और Android के M5 वर्शन वाली रिलीज़ के लिए, वर्शन 013 का इस्तेमाल किया गया पर लागू होता है (फ़रवरी से मार्च 2008). कई मायनों में, इन पहले का इस फ़ॉर्मैट के वर्शन, यहां बताए गए वर्शन से काफ़ी अलग हैं दस्तावेज़.

ENDIAN_CONSTANT और REVERSE_ENDIAN_CONSTANT

हेडर_आइटम में एम्बेड किया गया

कॉन्स्टेंट ENDIAN_CONSTANT का इस्तेमाल वह फ़ाइल जिसमें वह मौजूद है. हालांकि, स्टैंडर्ड .dex फ़ॉर्मैट छोटा है. हालांकि, इसे लागू करने का विकल्प चुना जा सकता है बाइट-स्वैपिंग करने के लिए. अगर लागू करने पर हेडर, जिसका endian_tag REVERSE_ENDIAN_CONSTANT है ENDIAN_CONSTANT के बजाय, इससे यह पता चलेगा कि फ़ाइल को अपेक्षित फ़ॉर्म से बाइट-स्वैप कर दिया गया है.

uint ENDIAN_CONSTANT = 0x12345678;
uint REVERSE_ENDIAN_CONSTANT = 0x78563412;

नंबर

class_def_item औरdebug_info_item में एम्बेड किया गया

कॉन्स्टेंट NO_INDEX का इस्तेमाल यह बताने के लिए किया जाता है कि इंडेक्स की वैल्यू मौजूद नहीं है.

ध्यान दें: इस वैल्यू को 0 कहा जाता है, क्योंकि असल में यह एक मान्य इंडेक्स है.

NO_INDEX के लिए चुनी गई वैल्यू यह है जिसे uleb128p1 एन्कोडिंग में एक बाइट के रूप में दिखाया जा सकता है.

uint NO_INDEX = 0xffffffff;    // == -1 if treated as a signed int

access_flags की परिभाषाएं

class_def_item, encoded_field, encoded_method, और इनरक्लास

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

* सिर्फ़ InnerClass एनोटेशन के लिए चालू है, और class_def_item में कभी भी चालू न हो.

UTF-8 एन्कोडिंग में बदलाव किया गया

पुराने वर्शन पर सहायता पाने की सुविधा को कम करने के लिए, .dex फ़ॉर्मैट इसके बाद, स्ट्रिंग डेटा को सही तथ्यों के साथ स्टैंडर्ड UTF-8 फ़ॉर्म में एन्कोड करता है. इसे MUTF-8 कहा जाता है. यह फ़ॉर्म, स्टैंडर्ड UTF-8 के जैसा होता है. हालांकि, इसमें ये शामिल नहीं हैं:

• सिर्फ़ एक-, दो- और तीन-बाइट वाली एन्कोडिंग का इस्तेमाल किया जाता है.
• U+10000 रेंज में कोड पॉइंट ... U+10ffff को सरोगेट जोड़े के तौर पर एन्कोड किया गया है. हर कोड में जिसे तीन-बाइट की कोड में बदली गई वैल्यू के तौर पर दिखाया जाता है.
• कोड पॉइंट U+0000 को दो बाइट के रूप में एन्कोड किया गया है.
• एक सादा नल बाइट (मान 0) अंत का संकेत देता है स्ट्रिंग की तरह ही इस्तेमाल करें.

ऊपर दिए गए पहले दो आइटम की खास जानकारी इस तरह से दी जा सकती है: MUTF-8 UTF-16 के लिए कोड में बदलने का फ़ॉर्मैट है, न कि सीधे तौर पर होने वाला यूनिकोड वर्णों के लिए एन्कोडिंग फ़ॉर्मैट.

ऊपर दिए गए अंतिम दो आइटम से एक साथ कई चीज़ें शामिल करना संभव हो जाता है स्ट्रिंग में कोड पॉइंट U+0000 और फिर भी उसमें बदलाव करता है इसे C-स्टाइल खाली-खत्म की गई स्ट्रिंग के तौर पर दिखाता है.

हालांकि, U+0000 की खास एन्कोडिंग का मतलब है कि, सामान्य UTF-8, जो मानक C फ़ंक्शन को कॉल करने का नतीजा होता है MUTF-8 स्ट्रिंग के जोड़े पर strcmp() हमेशा नहीं होता है असमान स्ट्रिंग की तुलना के नतीजे को सही तरीके से दिखाता है. अगर ऑर्डर देना (सिर्फ़ बराबरी का मामला नहीं) है, तो सबसे सीधे तौर पर MUTF-8 स्ट्रिंग की तुलना करने का तरीका यह है कि उन्हें हर वर्ण के हिसाब से डिकोड किया जाए, और डिकोड किए गए वैल्यू की तुलना करें. (हालांकि, इन्हें लागू करने का ज़्यादा बेहतर तरीका है भी संभव है.)

कृपया यूनिकोड देखें वर्ण एन्कोडिंग के बारे में ज़्यादा जानकारी के लिए, मानक सबमिट करें. MUTF-8, एन्कोडिंग के काफ़ी करीब है UTF-8 की तुलना में CESU-8 से ज़्यादा नहीं.

एन्कोडेड_वैल्यू एन्कोडिंग

एनोटेशन_element और encoded_array_item में एम्बेड किया गया

encoded_value (करीब-करीब) एन्कोड किया गया हिस्सा होता है आर्बिट्रेरी हैरारकी के हिसाब से स्ट्रक्चर्ड डेटा. एन्कोडिंग का मकसद पार्स करने में आसान और छोटी, दोनों तरह की होनी चाहिए.

वैल्यू के फ़ॉर्मैट

एन्कोडेड_अरे फ़ॉर्मैट

एन्कोडेड_annotation फ़ॉर्मैट

एनोटेशन_एलिमेंट फ़ॉर्मैट

स्ट्रिंग सिंटैक्स

.dex फ़ाइल में कई तरह के आइटम होते हैं, जो आखिरकार किसी स्ट्रिंग को रेफ़र करता है. बीएनएफ़ शैली की ये परिभाषाएं इन स्ट्रिंग के लिए स्वीकार किया जाने वाला सिंटैक्स बताएं.

सिंपलनाम

SimpleName दूसरे नामों के सिंटैक्स का आधार होता है चीज़ें. .dex फ़ॉर्मैट में अक्षांश को काफ़ी हद तक यहां (सबसे आम स्रोत भाषाओं से बहुत ज़्यादा) देखें. आसान शब्दों में कहें, तो नाम में अक्षर या अंक या लो ASCII अक्षर या अंक शामिल होते हैं, चुनिंदा लो-ASCII सिंबल और ज़्यादातर ऐसे नॉन-ASCII कोड पॉइंट जो कंट्रोल, स्पेस या खास वर्णों का इस्तेमाल कर सकते हैं. 040 वर्शन से शुरू फ़ॉर्मैट में स्पेस के वर्णों (यूनिकोड Zs) की भी अनुमति है श्रेणी). ध्यान दें कि सरोगेट कोड पॉइंट (U+d800 ... U+dfff की रेंज में) नहीं है को मान्य नाम वर्ण माना जाता है, लेकिन यूनिकोड पूरक वर्ण हैं मान्य होते हैं (जिन्हें आखिरी शब्द के ज़रिए दिखाया जाता है) SimpleNameChar के लिए नियम का विकल्प), और उन्हें ऐसा होना चाहिए को एक फ़ाइल में MUTF-8 में सरोगेट कोड पॉइंट के जोड़े के रूप में दिखाया जाता है एन्कोडिंग

सदस्य का नाम

फ़ील्ड_id_item औरmethod_id_item से इस्तेमाल की जाती है

सदस्य का नाम, क्लास के सदस्य का नाम होता है, जो सदस्य फ़ील्ड, मेथड, और इनर क्लास शामिल हैं.

फ़ुलक्लासनाम

FullClassName एक पूरी तरह क्वालिफ़ाइड क्लास का नाम होता है, जिसमें पैकेज की जानकारी देने वाली वैकल्पिक सुविधा, इसके बाद एक ज़रूरी नाम.

टाइपडिस्क्रिप्टर

इसका इस्तेमाल type_id_item में किया जाता है

TypeDescriptor से किसी भी टाइप की जानकारी मिलती है. इसमें ये शामिल हैं प्रिमिटिव, क्लास, अरे, और void. इनके लिए नीचे देखें अलग-अलग वर्शन का मतलब समझने के लिए.

ShortyDescriptor

इसका इस्तेमाल proto_id_item से किया जाता है

ShortyDescriptor, किसी तरीके का छोटा रूप होता है प्रोटोटाइप, जिसमें रिटर्न और पैरामीटर टाइप शामिल हैं, इसके अलावा कई तरह के रेफ़रंस (क्लास या अरे) के बीच कोई अंतर नहीं है. इसके बजाय, सभी तरह के रेफ़रंस, एक 'L' वर्ण से दिखाए जाते हैं.

TypeDescriptor सिमेंटिक्स

TypeDescriptor के हर वैरिएंट का मतलब एक ही होता है.

आइटम और उनसे जुड़े स्ट्रक्चर

इस सेक्शन में, टॉप-लेवल के हर उस आइटम की परिभाषाएं शामिल हैं .dex फ़ाइल में दिख सकता है.

हेडर_आइटम

हेडर सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

मैप की सूची

डेटा सेक्शन में दिखता है

हेडर_आइटम से रेफ़रंस लिया गया

अलाइनमेंट: 4 बाइट

यह फ़ाइल की पूरी सामग्री की एक सूची है, एक क्रम में. यह में header_item के संबंध में कुछ अतिरिक्तता है लेकिन इसे एक ऐसे तरीके के तौर पर इस्तेमाल किया जा सकता है जिसमें पूरी प्रोसेस को दोहराया जा सके फ़ाइल से लिए जाते हैं. मैप में यह टाइप ज़्यादा से ज़्यादा एक बार दिखना चाहिए, लेकिन ऐसा कोई नहीं होता इस बात पर नहीं कि किस तरह के ऑर्डर में शेष प्रारूप द्वारा लगाए गए प्रतिबंध (उदा., एक सबसे पहले header सेक्शन दिखना चाहिए. इसके बाद, string_ids सेक्शन वगैरह). इसके अलावा, मैप में शुरुआती ऑफ़सेट के हिसाब से क्रम में होना चाहिए और ओवरलैप नहीं होना चाहिए.

Maps_item का फ़ॉर्मैट

कोड टाइप करें

स्ट्रिंग_आईडी_आइटम

स्ट्रिंग_id सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

स्ट्रिंग_डेटा_आइटम

डेटा सेक्शन में दिखता है

संरेखण: कोई भी (बाइट-अलाइन)

type_id_item

type_ids सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

Proto_id_item

proto_ids सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

फ़ील्ड_id_item

फ़ील्ड_id सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

[method_id_item]

मेथड_आईडी सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

class_def_item

class_defs सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

call_site_id_item

Call_site_ids सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

कॉल_साइट_आइटम

डेटा सेक्शन में दिखता है

अलाइनमेंट: कोई भी (बाइट अलाइन की गई)

Call_site_item एक encoded_array_item है, जिसके एलिमेंट आर्ग्युमेंट के मुताबिक हैं बूटस्ट्रैप लिंकर मेथड को दिया जाता है. पहले तीन तर्क ये हैं:

1. बूटस्ट्रैप लिंकर मेथड (VALUE_METHOD_HANDLE) को दिखाने वाला मेथड हैंडल.
2. वह तरीका नाम जिससे बूटस्ट्रैप लिंकर को रिज़ॉल्व किया जाना चाहिए (VALUE_STRING).
3. हल किए जाने वाले तरीके के नाम से जुड़ा तरीका (VALUE_METHOD_TYPE).

कोई भी अतिरिक्त आर्ग्युमेंट, बूटस्ट्रैप लिंकर तरीके में पास की जाने वाली कॉन्सटैंट वैल्यू होते हैं. ये तर्क हैं जिसे बिना किसी तरह के कन्वर्ज़न के क्रम में पास किया गया हो.

बूटस्ट्रैप लिंकर वाले तरीके को दिखाने वाले तरीके के हैंडल में, रिटर्न टाइप java.lang.invoke.CallSite होना चाहिए. पहले तीन पैरामीटर टाइप हैं:

1. java.lang.invoke.Lookup
2. java.lang.String
3. java.lang.invoke.MethodType

किसी भी अतिरिक्त आर्ग्युमेंट के पैरामीटर टाइप, उनकी कॉन्सटैंट वैल्यू से तय किए जाते हैं.

मेथड_हैंडल_आइटम

इनकी जानकारी,method_handles सेक्शन में दिखती है

अलाइनमेंट: 4 बाइट

तरीके को हैंडल के टाइप से जुड़े कोड

क्लास_डेटा_आइटम

class_def_item से रेफ़र किया गया है

डेटा सेक्शन में दिखता है

संरेखण: कोई भी (बाइट-अलाइन)

ध्यान दें: सभी एलिमेंट' field_id और method_id इंस्टेंस को एक ही परिभाषित करने वाली क्लास का हवाला देना चाहिए.

एन्कोडेड_फ़ील्ड फ़ॉर्मैट

encoded_method फ़ॉर्मैट

type_list

class_def_item और proto_id_item से रेफ़र किया गया है

डेटा सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

type_item का फ़ॉर्मैट

code_item

एन्कोडेड_method से रेफ़रंस लिया गया

डेटा सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

ट्राइ_आइटम का फ़ॉर्मैट

encoded_catch_handler_list फ़ॉर्मैट

एन्कोडेड_catch_handler फ़ॉर्मैट

एन्कोडेड_type_addr_pair फ़ॉर्मैट

डीबग_info_item

code_item से रेफ़रंस लिया गया

डेटा सेक्शन में दिखता है

संरेखण: कोई भी (बाइट-अलाइन)

हर debug_info_item, DWARF3 से प्रेरित बाइट-कोड के बारे में बताता है यह ऐसी मशीन है जो व्याख्या किए जाने पर स्थितियों को उत्सर्जित करती है टेबल और (संभावित रूप से) code_item. क्रम, वैरिएबल की लंबाई से शुरू होता है हेडर (जिसकी लंबाई, तरीके की संख्या पर निर्भर करती है पैरामीटर), इसके बाद स्टेट मशीन बाइटकोड, और इसके आखिर में DBG_END_SEQUENCE बाइट के साथ.

स्टेट मशीन में पांच रजिस्टर होते हैं. कॉन्टेंट बनाने address रजिस्टर, इसमें दिए गए निर्देशों का ऑफ़सेट दिखाता है 16-बिट कोड यूनिट में संबंधित insns_item. कॉन्टेंट बनाने हर एक तारीख की शुरुआत को 0 पर address रजिस्टर होना शुरू होगा debug_info क्रम होना चाहिए और इसे सिर्फ़ एक क्रम में बढ़ाना चाहिए. line रजिस्टर, किस सोर्स लाइन नंबर को दिखाता है अगली पोज़िशन की टेबल की एंट्री से जुड़ा होना चाहिए, जो इससे उत्सर्जित होती है स्टेट मशीन पर निर्भर है. इसे क्रम के हेडर में शुरू किया जाता है और हो सकता है में कोई बदलाव नहीं आना चाहिए, लेकिन यह कभी भी इससे कम नहीं होना चाहिए 1. source_file रजिस्टर में सोर्स फ़ाइल मिलती है जिसका रेफ़रंस लाइन नंबर में दिया गया है. इसे इसके लिए शुरू किया जाता है class_def_item में source_file_idx की वैल्यू. अन्य दो वैरिएबल, prologue_end और epilogue_begin, बूलियन फ़्लैग होते हैं (इन्हें शुरू किया गया) false) से पता चलता है कि अगली पोज़िशन उत्सर्जित हुई या नहीं को मेथड प्रस्तावना या उपदेश माना जाना चाहिए. स्टेट मशीन इसे लाइव लोकल वैरिएबल के नाम और टाइप को भी ट्रैक करना होगा हर एक ग्राहक, DBG_RESTART_LOCAL कोड के लिए रजिस्टर करता है.

हेडर ऐसा होता है:

बाइट कोड की वैल्यू इस तरह हैं:

खास ऑपकोड

0x0a और 0xff के बीच के मान वाले ओपकोड (शामिल) line और address, दोनों को ले जाएं एक छोटी संख्या से रजिस्टर करता है और फिर नई स्थिति टेबल एंट्री डालता है. बढ़ोतरी का फ़ॉर्मूला यहां दिया गया है:

DBG_FIRST_SPECIAL = 0x0a  // the smallest special opcode
DBG_LINE_BASE   = -4      // the smallest line number increment
DBG_LINE_RANGE  = 15      // the number of line increments represented

adjusted_opcode = opcode - DBG_FIRST_SPECIAL

line += DBG_LINE_BASE + (adjusted_opcode % DBG_LINE_RANGE)
address += (adjusted_opcode / DBG_LINE_RANGE)

एनोटेशन_डायरेक्ट्री_आइटम

class_def_item से रेफ़र किया गया है

डेटा सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

ध्यान दें: सभी एलिमेंट' field_id और method_id इंस्टेंस को एक ही परिभाषित करने वाली क्लास का हवाला देना चाहिए.

फ़ील्ड_एनोटेशन फ़ॉर्मैट

तरीके_एनोटेशन का फ़ॉर्मैट

पैरामीटर_एनोटेशन फ़ॉर्मैट

एनोटेशन_set_ref_list

पैरामीटर_annotations_item से रेफ़रंस लिया गया है

डेटा सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

एनोटेशन_set_ref_item फ़ॉर्मैट

एनोटेशन_सेट_आइटम

एनोटेशन_directory_item, field_annotations_item से रेफ़रंस लिया गया, [method_annotations_item] और एनोटेशन_set_ref_item

डेटा सेक्शन में दिखता है

अलाइनमेंट: 4 बाइट

एनोटेशन_off_item फ़ॉर्मैट

एनोटेशन_आइटम

एनोटेशन_set_item से रेफ़रंस लिया गया

डेटा सेक्शन में दिखता है

संरेखण: कोई भी (बाइट-अलाइन)

प्रॉडक्ट दिखने की जानकारी

यहां visibility फ़ील्ड के लिए विकल्प दिए गए हैं annotation_item:

एन्कोडेड_array_item

class_def_item से रेफ़र किया गया है

डेटा सेक्शन में दिखता है

संरेखण: कोई भी (बाइट-अलाइन)

छिपा हुआapi_class_data_item

इस सेक्शन में, हर क्लास में इस्तेमाल किए जाने वाले प्रतिबंधित इंटरफ़ेस का डेटा होता है.

ध्यान दें: छिपी हुई एपीआई की सुविधा Android 10.0 में शुरू की गई थी और यह सिर्फ़ बूट क्लास पाथ में क्लास की DEX फ़ाइलों पर लागू होता है. यहां दी गई फ़्लैग सूची को आने वाली रिलीज़ में बढ़ाया जा सकता है Android के लिए. ज़्यादा जानकारी के लिए, यह देखें बिना SDK टूल वाले इंटरफ़ेस पर पाबंदियां.

पाबंदी वाले फ़्लैग के टाइप:

सिस्टम एनोटेशन

सिस्टम एनोटेशन का इस्तेमाल रिफ़्लेक्टिव एलिमेंट दिखाने के लिए किया जाता है क्लास (और तरीके, और फ़ील्ड) के बारे में जानकारी. यह जानकारी आम तौर पर, इसे क्लाइंट (नॉन-सिस्टम) कोड से सीधे तौर पर ऐक्सेस नहीं किया जाता.

सिस्टम एनोटेशन को .dex फ़ाइलों में इस तरह दिखाया जाता है विज़िबिलिटी वाली एनोटेशन को VISIBILITY_SYSTEM पर सेट किया गया.

Dalvik.annotation.AnnotationDefault

व्याख्या इंटरफ़ेस में तरीकों पर दिखाई देता है

हर इमेज के साथ एक AnnotationDefault एनोटेशन जुड़ा होता है. व्याख्या इंटरफ़ेस जो डिफ़ॉल्ट बाइंडिंग को दिखाना चाहता है.

Dalvik.annotation.EnclosingClass

क्लास में दिखता है

हर क्लास के साथ एक EnclosingClass एनोटेशन अटैच किया जाता है जिसे या तो किसी अन्य क्लास के सदस्य के रूप में परिभाषित किया जाता है, प्रति se या पहचान छिपाकर फ़ॉलो किया जाता है, लेकिन किसी खास तरीके के तहत तय नहीं किया जाता (जैसे, सिंथेटिक इनर क्लास). हर क्लास में यह एनोटेशन होना ज़रूरी है. InnerClass एनोटेशन. इसके अलावा, क्लास में EnclosingClass और EnclosingMethod एनोटेशन.

Dalvik.annotation.EnclosingMethod

क्लास में दिखता है

हर क्लास के साथ एक EnclosingMethod एनोटेशन अटैच किया जाता है जो कि मेथड के मुख्य भाग में परिभाषित होता है. हर वह क्लास, जिसमें यह है एनोटेशन में InnerClass एनोटेशन भी होना चाहिए. इसके अलावा, क्लास में EnclosingClass और दोनों नहीं होने चाहिए और एक EnclosingMethod एनोटेशन.

Dalvik.annotation.इनरक्लास

क्लास में दिखता है

हर क्लास के साथ एक InnerClass एनोटेशन अटैच किया जाता है जिसे किसी अन्य क्लास की परिभाषा के लेक्सिकल स्कोप में परिभाषित किया गया है. जिस क्लास में यह एनोटेशन होता है उसमें इनमें से कोई भी होना चाहिए EnclosingClass एनोटेशन या EnclosingMethod एनोटेशन.

Dalvik.annotation.MemberClasses

क्लास में दिखता है

हर क्लास के साथ एक MemberClasses एनोटेशन अटैच किया जाता है जिससे मेंबर क्लास के बारे में जानकारी मिलती है. (सदस्य क्लास, सीधे तौर पर अंदरूनी क्लास होती है जिसमें एक नाम हो.)

dalvik.annotation.MethodParameters

तरीकों पर जानकारी दिखाई गई है

ध्यान दें: यह एनोटेशन Android के बाद जोड़ा गया था 7.1. Android के पहले वाले रिलीज़ वर्शन में, इसकी मौजूदगी को अनदेखा कर दिया जाएगा.

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

एनोटेशन को किसी मेथड या कंस्ट्रक्टर से सुरक्षित रूप से हटाया जा सकता है, अगर रनटाइम के दौरान पैरामीटर मेटाडेटा ज़रूरी नहीं होता. java.lang.reflect.Parameter.isNamePresent() का इस्तेमाल करके, यह पता लगाया जा सकता है कि किसी पैरामीटर के लिए मेटाडेटा मौजूद है या नहीं और उससे जुड़ी रिफ़्लेक्शन java.lang.reflect.Parameter.getName() जैसे तरीकों का इस्तेमाल कम हो जाएगा अगर जानकारी मौजूद नहीं है, तो रनटाइम के दौरान डिफ़ॉल्ट व्यवहार पर वापस आ जाता है.

पैरामीटर मेटाडेटा शामिल करते समय, कंपाइलर में जानकारी शामिल होनी चाहिए enum जैसी जनरेट की गई क्लास के लिए अमान्य है, क्योंकि पैरामीटर मेटाडेटा यह भी शामिल है कि पैरामीटर, सिंथेटिक या ज़रूरी है या नहीं.

MethodParameters एनोटेशन से सिर्फ़ अलग-अलग तरीके की जानकारी मिलती है पैरामीटर का इस्तेमाल करें. इसलिए, कंपाइलर व्याख्या को पूरी तरह से छोड़ सकते हैं कोड-साइज़ के लिए, उन कंस्ट्रक्टर और मेथड के लिए जिनके पैरामीटर नहीं हैं और रनटाइम की बचत होती है.

यहां दिए गए अरे का साइज़, तरीके से जुड़ा method_id_item डेक्स स्ट्रक्चर, अन्य मामलों में यहां java.lang.reflect.MalformedParametersException दी जाएगी रनटाइम.

इसका मतलब है: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size, names().length और के बराबर होना चाहिए accessFlags().length.

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

Dalvik.annotation.हस्ताक्षर

दिखता है क्लास, फ़ील्ड, और मेथड

हर क्लास के साथ एक Signature एनोटेशन अटैच किया जाता है. फ़ील्ड या तरीका है, जो ज़्यादा जटिल प्रकार के रूप में परिभाषित किया गया है. को type_id_item से दिखाया जा सकता है. कॉन्टेंट बनाने .dex फ़ॉर्मैट, हस्ताक्षर का फ़ॉर्मैट तय नहीं करता; यह का मतलब सिर्फ़ सोर्स के हस्ताक्षर के बारे में बताने के लिए है को सही तरीके से लागू करने के लिए उस भाषा की सिमेंटिक्स. इसलिए, हस्ताक्षर को आम तौर पर पार्स नहीं किया जाता या उनकी पुष्टि नहीं की जाती वर्चुअल मशीन पर निर्भर करता है. हस्ताक्षर के साथ ही बेहतर लेवल वाले एपीआई और टूल (जैसे, डीबगर) का इस्तेमाल करना. किसी हस्ताक्षर करना ज़रूरी है, ताकि हस्ताक्षर करने के बाद सिर्फ़ मान्य हस्ताक्षर पाने के बारे में लगाए जाने वाले अनुमान, जो साफ़ तौर पर जो वाक्यात्मक रूप से आने की संभावना के बजाय अमान्य हस्ताक्षर.

सिग्नेचर स्ट्रिंग में काफ़ी डुप्लीकेट कॉन्टेंट होता है, इसलिए Signature एनोटेशन को इसकी कलेक्शन के तौर पर परिभाषित किया गया है स्ट्रिंग, जहां डुप्लीकेट एलिमेंट सामान्य रूप से उसी जानकारी को दिखाते हैं शामिल है और हस्ताक्षर को वाक्य के संयोजन के रूप में लिया जाता है. अरे में मौजूद सभी स्ट्रिंग. पुल करने के तरीके के बारे में कोई नियम नहीं है हस्ताक्षर को अलग-अलग स्ट्रिंग में बांटकर अलग करना; कि वह पूरी तरह से .dex फ़ाइलें जनरेट करने वाले टूल.

Dalvik.annotation.थ्रॉ

तरीकों पर जानकारी दिखाई गई है

हर उस तरीके पर Throws एनोटेशन जोड़ा जाता है जो एक या उससे ज़्यादा अपवाद टाइप करने के लिए एलान किया गया है.