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

इस दस्तावेज़ में .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 फ़ाइलें, कंटेनर में मौजूद किसी भी नए डेटा का रेफ़रंस दे सकती हैं. हालांकि, वे पुराने डेटा का रेफ़रंस नहीं दे सकतीं. इससे 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 10.0 रिलीज़ में, फ़ॉर्मैट के 040 वर्शन के लिए सहायता जोड़ी गई थी. इससे 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) और मेथड हैंडल के लिए डेटा जोड़ा गया है.

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

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

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

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

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 स्ट्रिंग की तुलना करने का सबसे आसान तरीका यह है कि उन्हें वर्ण के हिसाब से डिकोड करें और डिकोड की गई वैल्यू की तुलना करें. हालांकि, इसे और बेहतर तरीके से लागू किया जा सकता है.

कैरेक्टर एन्कोडिंग के बारे में ज़्यादा जानकारी के लिए, कृपया यूनिकोड स्टैंडर्ड देखें. असल में, MUTF-8, UTF-8 के मुकाबले CESU-8 एन्कोडिंग से ज़्यादा मिलता-जुलता है. हालांकि, CESU-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

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

अलाइनमेंट: 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 से प्रेरित बाइट कोड वाली स्टेट मशीन तय करता है. इसे समझने पर, code_item के लिए पोज़िशन टेबल और (संभावित रूप से) लोकल वैरिएबल की जानकारी मिलती है. यह क्रम, वैरिएबल-लेंथ हेडर से शुरू होता है. इसकी लंबाई, तरीके के पैरामीटर की संख्या पर निर्भर करती है. इसके बाद, स्टेट मशीन के बाइटकोड आते हैं और DBG_END_SEQUENCE बाइट के साथ खत्म होते हैं.

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

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

सिस्टम से जुड़े एनोटेशन

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

सिस्टम एनोटेशन, .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() जैसे रिफ़्लेक्शन के तरीके, रनटाइम पर डिफ़ॉल्ट व्यवहार पर वापस आ जाएंगे.

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

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

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

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

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

dalvik.annotation.Throws

इन पर दिखता है

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