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

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

टाइप के बारे में गाइड

LEB128

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

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

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

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

फ़ाइल का लेआउट

कंटेनर फ़ॉर्मैट

वर्शन 41 में, DEX डेटा के लिए नया कंटेनर फ़ॉर्मैट पेश किया गया है. इसका मकसद जगह बचाना है. इस कंटेनर फ़ॉर्मैट की मदद से, कई लॉजिकल DEX फ़ाइलों को एक फ़िज़िकल फ़ाइल में जोड़ा जा सकता है. नया फ़ॉर्मैट, पिछले फ़ॉर्मैट में मौजूद फ़ाइलों को एक साथ जोड़ने का एक आसान तरीका है. हालांकि, इसमें कुछ अंतर हैं:

• file_size लॉजिकल फ़ाइल का साइज़ है, न कि फ़िज़िकल फ़ाइल का. इसका इस्तेमाल, कंटेनर में मौजूद सभी लॉजिकल फ़ाइलों को दोहराने के लिए किया जा सकता है.
• लॉजिकल डेक्स फ़ाइलें, कंटेनर में मौजूद किसी भी नए डेटा का रेफ़रंस दे सकती हैं. हालांकि, वे पुराने डेटा का रेफ़रंस नहीं दे सकतीं. इससे dex फ़ाइलें, एक-दूसरे के साथ स्ट्रिंग जैसे डेटा को शेयर कर पाती हैं.
• सभी ऑफ़सेट, फ़िज़िकल फ़ाइल के हिसाब से होते हैं. हेडर के हिसाब से कोई ऑफ़सेट नहीं है. इससे यह पक्का किया जाता है कि ऑफ़सेट वाले सेक्शन को लॉजिकल फ़ाइलों के बीच शेयर किया जा सकता है.
• हेडर, कंटेनर की सीमाओं के बारे में बताने के लिए दो नए फ़ील्ड जोड़ता है. यह एक अतिरिक्त जांच है, जिससे कोड को नए फ़ॉर्मैट में पोर्ट करना आसान हो जाता है.
• data_size और data_off अब इस्तेमाल नहीं किए जाते. डेटा को कई लॉजिकल फ़ाइलों में फैलाया जा सकता है और यह ज़रूरी नहीं है कि डेटा लगातार हो.

बिटफ़ील्ड, स्ट्रिंग, और कॉन्स्टेंट की परिभाषाएं

DEX_FILE_MAGIC

header_item में एम्बेड किया गया

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

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

ध्यान दें: Android 16 के रिलीज़ होने के बाद, फ़ॉर्मैट के 041 वर्शन के लिए सहायता उपलब्ध कराई गई थी. इसमें कंटेनर फ़ॉर्मैट का इस्तेमाल किया जा सकता है.

ध्यान दें: फ़ॉर्मैट के 040 वर्शन के लिए सहायता, Android 10.0 रिलीज़ में जोड़ी गई थी. इससे SimpleNames में इस्तेमाल किए जा सकने वाले वर्णों का सेट बढ़ गया था.

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

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

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

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

ENDIAN_CONSTANT और REVERSE_ENDIAN_CONSTANT

header_item में एम्बेड किया गया

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

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

NO_INDEX

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

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

ध्यान दें: इस वैल्यू को 0 के तौर पर तय नहीं किया गया है, क्योंकि आम तौर पर यह एक मान्य इंडेक्स होता है.

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

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

ऐक्सेस फ़्लैग की परिभाषाएं

class_def_item, encoded_field, encoded_method, और InnerClass में एम्बेड किया गया

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

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

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

लेगसी सिस्टम के साथ आसानी से काम करने के लिए, .dex फ़ॉर्मैट, स्ट्रिंग डेटा को UTF-8 के स्टैंडर्ड फ़ॉर्म में कोड करता है. इसे MUTF-8 कहा जाता है. यह फ़ॉर्म, स्टैंडर्ड UTF-8 के जैसा ही है. हालांकि, इसमें ये अंतर हैं:

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

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

ऊपर दिए गए आखिरी दो आइटम की वजह से, स्ट्रिंग में कोड पॉइंट U+0000 को शामिल करना और इसे C-स्टाइल वाली नल-टर्मिनेटेड स्ट्रिंग के तौर पर इस्तेमाल करना, दोनों एक साथ मुमकिन हो पाता है.

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

कैरेक्टर एन्कोडिंग के बारे में ज़्यादा जानकारी के लिए, कृपया The Unicode Standard देखें. MUTF-8, UTF-8 के मुकाबले CESU-8 (यह एन्कोडिंग, UTF-8 की तुलना में कम जानी जाती है) के ज़्यादा करीब है.

encoded_value को कोड में बदलने का तरीका

annotation_element और encoded_array_item में एम्बेड किया गया

encoded_value, किसी भी तरह के डेटा का एन्कोड किया गया हिस्सा होता है. यह डेटा, क्रम के हिसाब से व्यवस्थित होता है. इस तरह की एन्कोडिंग का मकसद, डेटा को छोटा और पार्स करने में आसान बनाना है.

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

encoded_array फ़ॉर्मैट

encoded_annotation फ़ॉर्मैट

annotation_element फ़ॉर्मैट

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

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

SimpleName

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

MemberName

इसका इस्तेमाल field_id_item और method_id_item करते हैं

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

FullClassName

FullClassName, पूरी तरह क्वालिफ़ाइड क्लास का नाम होता है. इसमें पैकेज स्पेसिफ़ायर (ज़रूरी नहीं) और उसके बाद ज़रूरी नाम शामिल होता है.

TypeDescriptor

इस कुकी का इस्तेमाल type_id_item करता है

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

ShortyDescriptor

proto_id_item ने इस्तेमाल किया

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

TypeDescriptor सिमैंटिक्स

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

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

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

header_item

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

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

map_list

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

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

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

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

map_item फ़ॉर्मैट

कोड टाइप करना

string_id_item

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

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

string_data_item

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

अलाइनमेंट: कोई नहीं (बाइट के हिसाब से अलाइन किया गया)

type_id_item

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

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

proto_id_item

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

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

field_id_item

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

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

method_id_item

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

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

class_def_item

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

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

call_site_id_item

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

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

call_site_item

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

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

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_handle_item

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

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

तरीके के हैंडल टाइप कोड

class_data_item

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

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

अलाइनमेंट: कोई नहीं (बाइट के हिसाब से अलाइन किया गया)

ध्यान दें: सभी एलिमेंट के field_id और method_id इंस्टेंस, एक ही क्लास को रेफ़रंस करते हों.

encoded_field फ़ॉर्मैट

encoded_method फ़ॉर्मैट

type_list

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

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

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

type_item फ़ॉर्मैट

code_item

encoded_method से रेफ़र किया गया

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

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

try_item फ़ॉर्मैट

encoded_catch_handler_list फ़ॉर्मैट

encoded_catch_handler फ़ॉर्मैट

encoded_type_addr_pair फ़ॉर्मैट

debug_info_item

code_item से रेफ़र किया गया

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

अलाइनमेंट: कोई नहीं (बाइट के हिसाब से अलाइन किया गया)

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

स्टेट मशीन में पांच रजिस्टर होते हैं. address रजिस्टर, 16-बिट कोड यूनिट में, उससे जुड़े insns_item में निर्देश ऑफ़सेट को दिखाता है. debug_info के हर क्रम की शुरुआत में, 0 रजिस्टर 0 से शुरू होता है और इसमें सिर्फ़ बढ़ोतरी होनी चाहिए.address 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)

annotations_directory_item

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

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

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

ध्यान दें: सभी एलिमेंट के field_id और method_id इंस्टेंस, एक ही क्लास को रेफ़रंस करते हों.

field_annotation फ़ॉर्मैट

method_annotation का फ़ॉर्मैट

parameter_annotation फ़ॉर्मैट

annotation_set_ref_list

parameter_annotations_item से रेफ़र किया गया

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

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

annotation_set_ref_item फ़ॉर्मैट

annotation_set_item

annotations_directory_item, field_annotations_item, method_annotations_item, और annotation_set_ref_item से रेफ़र किया गया

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

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

annotation_off_item फ़ॉर्मैट

annotation_item

annotation_set_item से रेफ़र किया गया

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

अलाइनमेंट: कोई नहीं (बाइट के हिसाब से अलाइन किया गया)

विज़िबिलिटी की वैल्यू

annotation_item में visibility फ़ील्ड के लिए ये विकल्प उपलब्ध हैं:

encoded_array_item

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

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

अलाइनमेंट: कोई नहीं (बाइट के हिसाब से अलाइन किया गया)

hiddenapi_class_data_item

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

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

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

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

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

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

dalvik.annotation.AnnotationDefault

एनोटेशन इंटरफ़ेस में मौजूद तरीकों पर दिखता है

AnnotationDefault एनोटेशन, हर उस एनोटेशन इंटरफ़ेस से जुड़ा होता है जो डिफ़ॉल्ट बाइंडिंग के बारे में बताता है.

dalvik.annotation.EnclosingClass

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

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

dalvik.annotation.EnclosingMethod

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

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

dalvik.annotation.InnerClass

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

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 dex स्ट्रक्चर के साइज़ के बराबर होना चाहिए. ऐसा न होने पर, रनटाइम के दौरान 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

क्लास, फ़ील्ड, और तरीकों पर दिखता है

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

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

dalvik.annotation.Throws

इन तरीकों से दिखता है

Throws एनोटेशन, हर उस तरीके से जुड़ा होता है जो एक या उससे ज़्यादा तरह की गड़बड़ियां दिखाता है.