हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

Delvik एक्ज़ीक्यूटेबल फ़ॉर्मैट
संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

टाइप की गाइड

नाम	ब्यौरा
बाइट	8-बिट का साइन वाला इंटिजर
ubyte	8-बिट बिना साइन वाला int
छोटा	16-बिट साइन वाला इंटिजर, लिटल-इंडियन
ushort	16-बिट बिना हस्ताक्षर वाला इंटिजर, लिटल-इंडियन
आईएनटी	32-बिट साइन वाला इंटिजर, लिटल-इंडियन
uint	32-बिट बिना हस्ताक्षर वाला इंटिजर, लिटल-इंडियन
लंबा	64-बिट वाला साइन किया गया इंटिजर, लिटल-इंडियन
ulong	64-बिट बिना साइन वाला int, लिटल-इंडियन
sleb128	साइन किया गया LEB128, वैरिएबल-लेंथ (नीचे देखें)
uleb128	बिना साइन वाला LEB128, वैरिएबल-लेंथ (नीचे देखें)
uleb128p1	बिना साइन वाला LEB128 प्लस `1`, वैरिएबल-लेंथ (नीचे देखें)

LEB128

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

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

दो बाइट वाले LEB128 वैल्यू का बिटवाइज़ डायग्राम
पहला बाइट								दूसरा बाइट
`1`	बिट₆	bit₅	बिट₄	बिट₃	बिट₂	बिट₁	बिट₀	`0`	bit₁₃	bit₁₂	बिट₁₁	bit₁₀	बिट₉	बिट₈	बिट₇

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

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

कोड में बदला गया क्रम	`sleb128` के तौर पर	`uleb128` के तौर पर	`uleb128p1` के तौर पर
00	0	0	-1
01	1	1	0
7f	-1	127	126
80 7f	-128	16256	16255

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

नाम	फ़ॉर्मैट	ब्यौरा
हेडर	header_item	हेडर
string_ids	string_id_item[]	स्ट्रिंग आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में इस्तेमाल की गई सभी स्ट्रिंग के आइडेंटिफ़ायर हैं. इनका इस्तेमाल, इंटरनल नेमिंग (जैसे, टाइप डिस्क्रिप्टर) के लिए या कोड से रेफ़र किए गए कॉन्स्टेंट ऑब्जेक्ट के तौर पर किया जाता है. इस सूची को स्ट्रिंग कॉन्टेंट के हिसाब से क्रम में लगाया जाना चाहिए. इसके लिए, UTF-16 कोड पॉइंट वैल्यू का इस्तेमाल किया जाना चाहिए, न कि स्थानीय भाषा के हिसाब से. साथ ही, इसमें कोई डुप्लीकेट एंट्री नहीं होनी चाहिए.
type_ids	type_id_item[]	टाइप आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में बताए गए सभी टाइप (क्लास, कलेक्शन या प्राइमिटिव टाइप) के आइडेंटिफ़ायर हैं. भले ही, फ़ाइल में इनकी जानकारी दी गई हो या नहीं. इस सूची को `string_id` इंडेक्स के हिसाब से क्रम में लगाया जाना चाहिए. साथ ही, इसमें कोई डुप्लीकेट एंट्री नहीं होनी चाहिए.
proto_ids	proto_id_item[]	प्रोटोटाइप आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में बताए गए सभी प्रोटोटाइप के आइडेंटिफ़ायर हैं. इस सूची को रिटर्न-टाइप (`type_id` इंडेक्स के हिसाब से) के मुख्य क्रम में और फिर आर्ग्युमेंट की सूची (लेक्सिकोग्राफ़िक क्रम, अलग-अलग आर्ग्युमेंट `type_id` इंडेक्स के हिसाब से क्रम में) के हिसाब से क्रम में लगाया जाना चाहिए. सूची में डुप्लीकेट एंट्री नहीं होनी चाहिए.
field_ids	field_id_item[]	फ़ील्ड आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में बताए गए सभी फ़ील्ड के आइडेंटिफ़ायर हैं. भले ही, फ़ाइल में इनकी जानकारी दी गई हो या नहीं. इस सूची को क्रम से लगाया जाना चाहिए. इसमें, `type_id` इंडेक्स के हिसाब से तय किया गया टाइप सबसे ज़्यादा क्रम में, `string_id` इंडेक्स के हिसाब से फ़ील्ड का नाम बीच में, और `type_id` इंडेक्स के हिसाब से टाइप सबसे कम क्रम में होना चाहिए. सूची में कोई डुप्लीकेट एंट्री नहीं होनी चाहिए.
method_ids	method_id_item[]	तरीकों के आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में बताए गए सभी तरीकों के आइडेंटिफ़ायर हैं. भले ही, उन्हें फ़ाइल में बताया गया हो या नहीं. इस सूची को क्रम से लगाना ज़रूरी है. इसमें, `type_id` इंडेक्स के हिसाब से, तय किए गए टाइप को सबसे पहले, `string_id` इंडेक्स के हिसाब से, तरीके के नाम को बीच में, और `proto_id` इंडेक्स के हिसाब से, तरीके के प्रोटोटाइप को सबसे आखिर में रखा जाता है. सूची में डुप्लीकेट एंट्री नहीं होनी चाहिए.
class_defs	class_def_item[]	क्लास की परिभाषाओं की सूची. क्लास को इस तरह से क्रम में लगाया जाना चाहिए कि किसी क्लास का सुपरक्लास और लागू किए गए इंटरफ़ेस, सूची में रेफ़र करने वाली क्लास से पहले दिखें. इसके अलावा, एक ही नाम वाली क्लास की डेफ़िनिशन, सूची में एक से ज़्यादा बार दिखना अमान्य है.
call_site_ids	call_site_id_item[]	कॉल साइट आइडेंटिफ़ायर की सूची. ये इस फ़ाइल में बताई गई सभी कॉल साइटों के आइडेंटिफ़ायर हैं. भले ही, फ़ाइल में इनकी जानकारी दी गई हो या नहीं. इस सूची को `call_site_off` के बढ़ते क्रम में क्रम से लगाया जाना चाहिए.
method_handles	method_handle_item[]	method हैंडल की सूची. इस फ़ाइल में बताए गए सभी तरीकों के हैंडल की सूची, भले ही वे फ़ाइल में बताए गए हों या नहीं. इस सूची को क्रम से नहीं लगाया जाता और इसमें डुप्लीकेट शामिल हो सकते हैं. ये डुप्लीकेट, अलग-अलग तरीके के हैंडल इंस्टेंस से जुड़े होते हैं.
डेटा	ubyte[]	डेटा एरिया, जिसमें ऊपर दी गई टेबल के लिए सहायता से जुड़ा सारा डेटा होता है. अलग-अलग आइटम के लिए अलाइनमेंट की अलग-अलग ज़रूरतें होती हैं. साथ ही, सही अलाइनमेंट पाने के लिए, ज़रूरत पड़ने पर हर आइटम के पहले पैडिंग बाइट डाले जाते हैं.
link_data	ubyte[]	स्टैटिक तौर पर लिंक की गई फ़ाइलों में इस्तेमाल किया गया डेटा. इस दस्तावेज़ में, इस सेक्शन में मौजूद डेटा के फ़ॉर्मैट के बारे में नहीं बताया गया है. अनलिंक की गई फ़ाइलों में यह सेक्शन खाली होता है. साथ ही, रनटाइम लागू करने वाले लोग या ग्रुप, इस सेक्शन का इस्तेमाल अपनी ज़रूरत के हिसाब से कर सकते हैं.

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

वर्शन 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` ऐनोटेशन) के लिए	फ़ील्ड के लिए	तरीकों के लिए
ACC_PUBLIC	0x1	`public`: सभी जगह दिखने वाला	`public`: सभी जगह दिखने वाला	`public`: सभी जगह दिखने वाला
ACC_PRIVATE	0x2	* `private`: सिर्फ़ तय की गई क्लास को दिखता है	`private`: सिर्फ़ तय की गई क्लास को दिखता है	`private`: सिर्फ़ तय की गई क्लास को दिखता है
ACC_PROTECTED	0x4	* `protected`: पैकेज और सबक्लास के लिए दिखता है	`protected`: पैकेज और सब-क्लास के लिए दिखता है	`protected`: पैकेज और सब-क्लास के लिए दिखता है
ACC_STATIC	0x8	* `static`: बाहरी `this` रेफ़रंस के साथ नहीं बनाया गया है	`static`: global से defining class	`static`: `this` आर्ग्युमेंट नहीं लेता
ACC_FINAL	0x10	`final`: सबक्लास नहीं किया जा सकता	`final`: कॉन्स्ट्रक्शन के बाद बदला नहीं जा सकता	`final`: बदला नहीं जा सकता
ACC_SYNCHRONIZED	0x20			`synchronized`: इस तरीके को कॉल करने पर, इससे जुड़ा लॉक अपने-आप हासिल हो जाता है. ध्यान दें: इसे सिर्फ़ तब सेट किया जा सकता है, जब `ACC_NATIVE` भी सेट हो.
ACC_VOLATILE	0x40		`volatile`: थ्रेड की सुरक्षा के लिए, ऐक्सेस से जुड़े खास नियम
ACC_BRIDGE	0x40			ब्रिज का तरीका, कंपाइलर के ज़रिए अपने-आप जोड़ा जाता है, ताकि वह टाइप-सेफ़ ब्रिज के तौर पर काम कर सके
ACC_TRANSIENT	0x80		`transient`: डिफ़ॉल्ट रूप से सीरियलाइज़ेशन की सुविधा से सेव नहीं किया जाना चाहिए
ACC_VARARGS	0x80			कंपाइलर को आखिरी आर्ग्युमेंट को "बाकी" आर्ग्युमेंट के तौर पर इस्तेमाल करना चाहिए
ACC_NATIVE	0x100			`native`: नेटिव कोड में लागू किया गया
ACC_INTERFACE	0x200	`interface`: कई बार लागू की जा सकने वाली ऐब्स्ट्रैक्ट क्लास
ACC_ABSTRACT	0x400	`abstract`: सीधे तौर पर इंस्टैंशिएबल नहीं है		`abstract`: इस क्लास में लागू नहीं किया गया
ACC_STRICT	0x800			`strictfp`: फ़्लोटिंग-पॉइंट अंकगणित के लिए सख्त नियम
ACC_SYNTHETIC	0x1000	सीधे सोर्स कोड में तय नहीं किया गया है	सीधे सोर्स कोड में तय नहीं किया गया है	सीधे सोर्स कोड में तय नहीं किया गया है
ACC_ANNOTATION	0x2000	एनोटेशन क्लास के तौर पर घोषित किया गया हो
ACC_ENUM	0x4000	एनोटेट किया गया हो	एनुमरेशन वैल्यू के तौर पर तय की गई हो
(इस्तेमाल नहीं किया गया)	0x8000
ACC_CONSTRUCTOR	0x10000			कंस्ट्रक्टर का तरीका (क्लास या इंस्टेंस को शुरू करने वाला)
ACC_DECLARED_ SYNCHRONIZED	0x20000			`synchronized` एलिमेंट का एलान किया है. ध्यान दें: इस फ़्लैग के दिखने के अलावा, इससे प्रोसेस पर कोई असर नहीं पड़ता.

* सिर्फ़ 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, (लगभग) मनमुताबिक क्रम में व्यवस्थित किए गए स्ट्रक्चर्ड डेटा का कोड में बदला गया हिस्सा होता है. कोड को छोटा और आसानी से पार्स किया जा सकने वाला होना चाहिए.

नाम	फ़ॉर्मैट	ब्यौरा
(value_arg << 5) \| value_type	ubyte	बाइट, जो अगले `value` के टाइप के बारे में बताता है. साथ ही, इसमें सबसे ऊपर के तीन बिट में, ज़्यादा जानकारी देने वाला वैकल्पिक आर्ग्युमेंट भी होता है. `value` की अलग-अलग परिभाषाएं जानने के लिए, नीचे देखें. ज़्यादातर मामलों में, `value_arg`, इसके बाद वाले `value` की लंबाई को बाइट में `(size - 1)` के तौर पर कोड में बदलता है. उदाहरण के लिए, `0` का मतलब है कि वैल्यू के लिए एक बाइट की ज़रूरत है और `7` का मतलब है कि इसके लिए आठ बाइट की ज़रूरत है. हालांकि, यहां बताई गई स्थितियों में ये नियम लागू नहीं होते.
मान	ubyte[]	वैल्यू दिखाने वाले बाइट, जिनकी लंबाई अलग-अलग होती है और जिन्हें अलग-अलग `value_type` बाइट के लिए अलग-अलग तरीके से समझा जाता है. हालांकि, ये हमेशा लिटल-एंडियन होते हैं. ज़्यादा जानकारी के लिए, वैल्यू की अलग-अलग परिभाषाएं यहां देखें.

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

नाम लिखें	`value_type`	`value_arg` फ़ॉर्मैट	`value` फ़ॉर्मैट	ब्यौरा
VALUE_BYTE	0x00	(कोई नहीं; `0` होनी चाहिए)	ubyte[1]	साइन वाली एक-बाइट की पूर्णांक वैल्यू
VALUE_SHORT	0x02	साइज़ - 1 (0…1)	ubyte[size]	साइन वाली दो-बाइट पूर्णांक वैल्यू, साइन-एक्सटेंडेड
VALUE_CHAR	0x03	साइज़ - 1 (0…1)	ubyte[size]	साइन न किया गया दो-बाइट पूर्णांक वैल्यू, शून्य-एक्सटेंडेड
VALUE_INT	0x04	साइज़ - 1 (0…3)	ubyte[size]	साइन वाली चार-बाइट पूर्णांक वैल्यू, साइन-एक्सटेंडेड
VALUE_LONG	0x06	साइज़ - 1 (0…7)	ubyte[size]	साइन वाली आठ-बाइट पूर्णांक वैल्यू, साइन-एक्सटेंडेड
VALUE_FLOAT	0x10	साइज़ - 1 (0…3)	ubyte[size]	चार बाइट का बिट पैटर्न, दाईं ओर शून्य तक बढ़ाया गया, और इसे IEEE754 32-बिट फ़्लोटिंग पॉइंट वैल्यू के तौर पर समझा गया
VALUE_DOUBLE	0x11	साइज़ - 1 (0…7)	ubyte[size]	आठ-बाइट का बिट पैटर्न, दाईं ओर शून्य तक बढ़ाया गया, और इसे IEEE754 64-बिट फ़्लोटिंग पॉइंट वैल्यू के तौर पर समझा गया
VALUE_METHOD_TYPE	0x15	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाली (शून्य से बड़ी) चार-बाइट की पूर्णांक वैल्यू, जिसे `proto_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो तरीका टाइप की वैल्यू दिखाती है
VALUE_METHOD_HANDLE	0x16	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाली (शून्य से बड़ी) चार बाइट की पूर्णांक वैल्यू, जिसे `method_handles` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो एक मेथड हैंडल वैल्यू को दिखाती है
VALUE_STRING	0x17	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाला (शून्य से बड़ा) चार-बाइट पूर्णांक वैल्यू, जिसे `string_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो स्ट्रिंग वैल्यू दिखाती है
VALUE_TYPE	0x18	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाली (शून्य से बड़ी) चार-बाइट की पूर्णांक वैल्यू, जिसे `type_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो रिफ़्लेक्टिव टाइप/क्लास वैल्यू दिखाती है
VALUE_FIELD	0x19	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाला (शून्य से बड़ा) चार-बाइट पूर्णांक वैल्यू, जिसे `field_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो रिफ़्लेक्टिव फ़ील्ड वैल्यू को दिखाता है
VALUE_METHOD	0x1a	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाली (शून्य से बड़ी) चार-बाइट की पूर्णांक वैल्यू, जिसे `method_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो रिफ़्लेक्टिव मेथड की वैल्यू दिखाती है
VALUE_ENUM	0x1b	साइज़ - 1 (0…3)	ubyte[size]	बिना साइन वाली (शून्य से बड़ी) चार-बाइट की पूर्णांक वैल्यू, जिसे `field_ids` सेक्शन में इंडेक्स के तौर पर समझा जाता है और जो सूची वाले टाइप की कॉन्स्टेंट की वैल्यू दिखाती है
VALUE_ARRAY	0x1c	(कोई नहीं; `0` होनी चाहिए)	encoded_array	वैल्यू का कलेक्शन, जो यहां दिए गए "`encoded_array` फ़ॉर्मैट" में होना चाहिए. `value` का साइज़, एन्कोडिंग में शामिल होता है.
VALUE_ANNOTATION	0x1d	(कोई नहीं; `0` होनी चाहिए)	encoded_annotation	सब-एनोटेशन, जो यहां दिए गए "`encoded_annotation` फ़ॉर्मैट" में हो. `value` का साइज़, एन्कोडिंग में शामिल होता है.
VALUE_NULL	0x1e	(कोई नहीं; `0` होनी चाहिए)	(कोई नहीं)	`null` रेफ़रंस वैल्यू
VALUE_BOOLEAN	0x1f	बूलियन (0…1)	(कोई नहीं)	एक-बिट वैल्यू; `false` के लिए `0` और `true` के लिए `1`. बिट को `value_arg` में दिखाया जाता है.

encoded_array फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uleb128	कलेक्शन में मौजूद एलिमेंट की संख्या
वैल्यू	encoded_value[size]	इस सेक्शन में बताए गए फ़ॉर्मैट में, `size` `encoded_value` बाइट के क्रम से जोड़े गए sequências की सीरीज़.

encoded_annotation फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
type_idx	uleb128	एनोटेशन का टाइप. यह क्लास (ऐरे या प्राइमिटिव नहीं) टाइप का होना चाहिए.
साइज़	uleb128	इस एनोटेशन में नाम-वैल्यू मैपिंग की संख्या
एलिमेंट	annotation_element[size]	एनोटेशन के एलिमेंट, सीधे इन-लाइन (ऑफ़सेट के तौर पर नहीं) में दिखाए जाते हैं. एलिमेंट को `string_id` इंडेक्स के हिसाब से, बढ़ते क्रम में क्रम से लगाया जाना चाहिए.

annotation_element फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
name_idx	uleb128	एलिमेंट का नाम, जिसे `string_ids` सेक्शन में इंडेक्स के तौर पर दिखाया जाता है. स्ट्रिंग, ऊपर बताए गए MemberName के सिंटैक्स के मुताबिक होनी चाहिए.
मान	encoded_value	एलिमेंट की वैल्यू

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

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

SimpleName

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

SimpleName →
	SimpleNameChar (SimpleNameChar)*
SimpleNameChar →
	`'A'` … `'Z'`
\|	`'a'` … `'z'`
\|	`'0'` … `'9'`
\|	`' '`	DEX के 040 वर्शन के बाद से
\|	`'$'`
\|	`'-'`
\|	`'_'`
\|	`U+00a0`	DEX के 040 वर्शन के बाद से
\|	`U+00a1` … `U+1fff`
\|	`U+2000` … `U+200a`	DEX के 040 वर्शन के बाद से
\|	`U+2010` … `U+2027`
\|	`U+202f`	DEX के 040 वर्शन के बाद से
\|	`U+2030` … `U+d7ff`
\|	`U+e000` … `U+ffef`
\|	`U+10000` … `U+10ffff`

MemberName

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

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

MemberName →
	SimpleName
\|	`'<'` SimpleName `'>'`

FullClassName

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

FullClassName →
	OptionalPackagePrefix SimpleName
OptionalPackagePrefix →
	(SimpleName `'/'`)*

TypeDescriptor

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

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

TypeDescriptor →
	`'V'`
\|	FieldTypeDescriptor
FieldTypeDescriptor →
	NonArrayFieldTypeDescriptor
\|	(`'['` * 1…255) NonArrayFieldTypeDescriptor
NonArrayFieldTypeDescriptor→
	`'Z'`
\|	`'B'`
\|	`'S'`
\|	`'C'`
\|	`'I'`
\|	`'J'`
\|	`'F'`
\|	`'D'`
\|	`'L'` FullClassName `';'`

ShortyDescriptor

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

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

ShortyDescriptor →
	ShortyReturnType (ShortyFieldType)*
ShortyReturnType →
	`'V'`
\|	ShortyFieldType
ShortyFieldType →
	`'Z'`
\|	`'B'`
\|	`'S'`
\|	`'C'`
\|	`'I'`
\|	`'J'`
\|	`'F'`
\|	`'D'`
\|	`'L'`

TypeDescriptor के सिमेंटिक

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

वाक्य-विन्यास	मतलब
V	`void`; सिर्फ़ सामान लौटाने के तरीकों के लिए मान्य है
Z	`boolean`
B	`byte`
S	`short`
C	`char`
I	`int`
J	`long`
F	`float`
D	`double`
Lfully/qualified/Name;	क्लास `fully.qualified.Name`
[descriptor	`descriptor` का ऐरे, जिसका इस्तेमाल ऐरे-ऑफ़-ऐरे के लिए बार-बार किया जा सकता है. हालांकि, इसमें 255 से ज़्यादा डाइमेंशन होने पर, यह अमान्य हो जाता है.

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

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

header_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
जादू	ubyte[8] = DEX_FILE_MAGIC	मैजिक वैल्यू. ज़्यादा जानकारी के लिए, ऊपर "`DEX_FILE_MAGIC`" में दी गई चर्चा देखें.
चेकसम	uint	बाकी फ़ाइल का adler32 चेकसम (`magic` और इस फ़ील्ड को छोड़कर बाकी सभी चीज़ें); इसका इस्तेमाल, फ़ाइल में हुए नुकसान का पता लगाने के लिए किया जाता है
हस्ताक्षर	ubyte[20]	फ़ाइल के बाकी हिस्से का SHA-1 सिग्नेचर (हैश) (`magic`, `checksum`, और इस फ़ील्ड को छोड़कर बाकी सभी चीज़ें); इसका इस्तेमाल, फ़ाइलों की यूनीक पहचान करने के लिए किया जाता है
file_size	uint	पूरी फ़ाइल का साइज़ (हेडर के साथ), बाइट में (v40 या उससे पहले के वर्शन) इस हेडर की शुरुआत से अगले हेडर या पूरी फ़ाइल (कंटेनर) के आखिर तक की दूरी, बाइट में. (v41 या उसके बाद का वर्शन)
header_size	uint	हेडर (पूरे सेक्शन) का साइज़, बाइट में. इससे, फ़ॉर्मैट को अमान्य किए बिना, कम से कम कुछ हद तक पुराने/नए वर्शन के साथ काम करने की सुविधा मिलती है. 0x70 (112) बाइट होना चाहिए (v40 या उससे पहले के वर्शन) 0x78 (120) बाइट होना चाहिए (v41 या उसके बाद के वर्शन)
endian_tag	uint = ENDIAN_CONSTANT	endianness टैग. ज़्यादा जानकारी के लिए, ऊपर "`ENDIAN_CONSTANT` और `REVERSE_ENDIAN_CONSTANT`" में दी गई चर्चा देखें.
link_size	uint	लिंक सेक्शन का साइज़ या `0`, अगर यह फ़ाइल स्टैटिक तौर पर लिंक नहीं की गई है
link_off	uint	फ़ाइल की शुरुआत से लिंक सेक्शन तक का ऑफ़सेट या `link_size == 0` होने पर `0`. अगर ऑफ़सेट शून्य नहीं है, तो वह `link_data` सेक्शन में मौजूद किसी ऑफ़सेट से होना चाहिए. इस दस्तावेज़ में, जिस डेटा को रेफ़र किया गया है उसके फ़ॉर्मैट के बारे में नहीं बताया गया है. इस हेडर फ़ील्ड (और पिछले फ़ील्ड) को, रनटाइम लागू करने के लिए हुक के तौर पर छोड़ा गया है.
map_off	uint	फ़ाइल की शुरुआत से मैप आइटम तक का ऑफ़सेट. ऑफ़सेट, `data` सेक्शन में होना चाहिए. यह ऑफ़सेट, शून्य से अलग होना चाहिए. साथ ही, डेटा यहां दिए गए "`map_list`" में बताए गए फ़ॉर्मैट में होना चाहिए.
string_ids_size	uint	स्ट्रिंग आइडेंटिफ़ायर की सूची में स्ट्रिंग की संख्या
string_ids_off	uint	फ़ाइल की शुरुआत से स्ट्रिंग आइडेंटिफ़ायर की सूची तक का ऑफ़सेट या `0` अगर `string_ids_size == 0` (यह एक ऐसा मामला है जो आम तौर पर नहीं होता). अगर ऑफ़सेट शून्य नहीं है, तो यह `string_ids` सेक्शन की शुरुआत में होना चाहिए.
type_ids_size	uint	टाइप आइडेंटिफ़ायर की सूची में एलिमेंट की संख्या, ज़्यादा से ज़्यादा 65,535
type_ids_off	uint	फ़ाइल की शुरुआत से आइडेंटिफ़ायर की सूची तक का ऑफ़सेट या `0` अगर `type_ids_size == 0` (यह एक ऐसा मामला है जो आम तौर पर नहीं होता). अगर ऑफ़सेट शून्य नहीं है, तो यह `type_ids` सेक्शन के शुरू में होना चाहिए.
proto_ids_size	uint	प्रोटोटाइप आइडेंटिफ़ायर की सूची में मौजूद एलिमेंट की संख्या, ज़्यादा से ज़्यादा 65,535 हो सकती है
proto_ids_off	uint	फ़ाइल की शुरुआत से प्रोटोटाइप आइडेंटिफ़ायर की सूची तक का ऑफ़सेट या `0` अगर `proto_ids_size == 0` (यह एक अजीब एज केस है). अगर ऑफ़सेट शून्य नहीं है, तो यह `proto_ids` सेक्शन के शुरू में होना चाहिए.
field_ids_size	uint	फ़ील्ड आइडेंटिफ़ायर की सूची में एलिमेंट की संख्या
field_ids_off	uint	फ़ाइल की शुरुआत से फ़ील्ड आइडेंटिफ़ायर की सूची तक का ऑफ़सेट या `field_ids_size == 0` होने पर `0`. अगर ऑफ़सेट शून्य नहीं है, तो यह `field_ids` सेक्शन के शुरू में होना चाहिए.
method_ids_size	uint	मेथड आइडेंटिफ़ायर की सूची में एलिमेंट की संख्या
method_ids_off	uint	फ़ाइल की शुरुआत से लेकर, मेथड आइडेंटिफ़ायर की सूची तक का ऑफ़सेट या `method_ids_size == 0` होने पर `0`. अगर ऑफ़सेट शून्य नहीं है, तो यह `method_ids` सेक्शन के शुरू में होना चाहिए.
class_defs_size	uint	क्लास की परिभाषाओं की सूची में एलिमेंट की संख्या
class_defs_off	uint	फ़ाइल की शुरुआत से क्लास डेफ़िनिशन की सूची तक का ऑफ़सेट या `0` अगर `class_defs_size == 0` (यह एक अजीब एज केस है). अगर ऑफ़सेट शून्य नहीं है, तो यह `class_defs` सेक्शन की शुरुआत में होना चाहिए.
data_size	uint	`data` सेक्शन का साइज़, बाइट में. यह sizeof(uint) का कोई सम गुणक होना चाहिए. (v40 या उससे पहले का वर्शन) इस्तेमाल नहीं किया गया (v41 या उसके बाद के वर्शन)
data_off	uint	फ़ाइल की शुरुआत से `data` सेक्शन की शुरुआत तक का ऑफ़सेट (v40 या उससे पहले के वर्शन) इस्तेमाल नहीं किया गया (v41 या उसके बाद के वर्शन)
container_size	uint	यह फ़ील्ड मौजूद नहीं है. इसे `file_size` के बराबर माना जा सकता है. (v40 या उससे पहले का वर्शन) पूरी फ़ाइल का साइज़ (इसमें अन्य dex हेडर और उनका डेटा भी शामिल है). (v41 या उसके बाद का वर्शन)
header_offset	uint	यह फ़ील्ड मौजूद नहीं है. इसे `0` के बराबर माना जा सकता है. (v40 या उससे पहले का वर्शन) फ़ाइल की शुरुआत से इस हेडर की शुरुआत तक का ऑफ़सेट. (v41 या उसके बाद का वर्शन)

map_list

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

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uint	सूची का साइज़, एंट्री में
सूची	map_item[size]	सूची के एलिमेंट

map_item फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
टाइप	ushort	आइटम का टाइप; नीचे दी गई टेबल देखें
unused	ushort	(इस्तेमाल नहीं किया गया)
साइज़	uint	बताए गए ऑफ़सेट पर मिलने वाले आइटम की संख्या
ऑफ़सेट	uint	फ़ाइल की शुरुआत से लेकर, उन आइटम तक का ऑफ़सेट

कोड टाइप करना

आइटम का प्रकार	कॉन्स्टेंट	वैल्यू	आइटम का साइज़, बाइट में
header_item	TYPE_HEADER_ITEM	0x0000	0x70
string_id_item	TYPE_STRING_ID_ITEM	0x0001	0x04
type_id_item	TYPE_TYPE_ID_ITEM	0x0002	0x04
proto_id_item	TYPE_PROTO_ID_ITEM	0x0003	0x0c
field_id_item	TYPE_FIELD_ID_ITEM	0x0004	0x08
method_id_item	TYPE_METHOD_ID_ITEM	0x0005	0x08
class_def_item	TYPE_CLASS_DEF_ITEM	0x0006	0x20
call_site_id_item	TYPE_CALL_SITE_ID_ITEM	0x0007	0x04
method_handle_item	TYPE_METHOD_HANDLE_ITEM	0x0008	0x08
map_list	TYPE_MAP_LIST	0x1000	4 + (item.size * 12)
type_list	TYPE_TYPE_LIST	0x1001	4 + (item.size * 2)
annotation_set_ref_list	TYPE_ANNOTATION_SET_REF_LIST	0x1002	4 + (item.size * 4)
annotation_set_item	TYPE_ANNOTATION_SET_ITEM	0x1003	4 + (item.size * 4)
class_data_item	TYPE_CLASS_DATA_ITEM	0x2000	इंप्लिसिट; पार्स करना ज़रूरी है
code_item	TYPE_CODE_ITEM	0x2001	इंप्लिसिट; पार्स करना ज़रूरी है
string_data_item	TYPE_STRING_DATA_ITEM	0x2002	इंप्लिसिट; पार्स करना ज़रूरी है
debug_info_item	TYPE_DEBUG_INFO_ITEM	0x2003	इंप्लिसिट; पार्स करना ज़रूरी है
annotation_item	TYPE_ANNOTATION_ITEM	0x2004	इंप्लिसिट; पार्स करना ज़रूरी है
encoded_array_item	TYPE_ENCODED_ARRAY_ITEM	0x2005	इंप्लिसिट; पार्स करना ज़रूरी है
annotations_directory_item	TYPE_ANNOTATIONS_DIRECTORY_ITEM	0x2006	इंप्लिसिट; पार्स करना ज़रूरी है
hiddenapi_class_data_item	TYPE_HIDDENAPI_CLASS_DATA_ITEM	0xF000	इंप्लिसिट; पार्स करना ज़रूरी है

string_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
string_data_off	uint	इस आइटम के लिए, फ़ाइल की शुरुआत से स्ट्रिंग डेटा तक का ऑफ़सेट. ऑफ़सेट, `data` सेक्शन में किसी जगह पर होना चाहिए. साथ ही, डेटा यहां दिए गए "`string_data_item`" में बताए गए फ़ॉर्मैट में होना चाहिए. ऑफ़सेट के लिए अलाइनमेंट की ज़रूरत नहीं होती.

string_data_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
utf16_size	uleb128	UTF-16 कोड यूनिट में इस स्ट्रिंग का साइज़ (यह कई सिस्टम में "स्ट्रिंग की लंबाई" होती है). इसका मतलब है कि यह स्ट्रिंग की डिकोड की गई लंबाई है. (कोड में बदली गई लंबाई, `0` बाइट की पोज़िशन से पता चलती है.)
डेटा	ubyte[]	MUTF-8 कोड यूनिट (जिन्हें ऑक्टेट या बाइट भी कहा जाता है) की एक सीरीज़ के बाद, वैल्यू `0` का बाइट. डेटा फ़ॉर्मैट के बारे में जानकारी और चर्चा के लिए, ऊपर दिए गए "MUTF-8 (बदली गई UTF-8) कोड" देखें. ध्यान दें: ऐसी स्ट्रिंग स्वीकार की जा सकती है जिसमें यूनिकोड को UTF-16 में एन्कोड करने के सामान्य तरीके के हिसाब से, UTF-16 सरोगेट कोड यूनिट (`U+d800` … `U+dfff`) को अलग से या गलत क्रम में शामिल किया गया हो. अगर ज़रूरी हो, तो स्ट्रिंग के बेहतर लेवल के इस्तेमाल पर निर्भर करता है कि इस तरह के अमान्य कोड को अस्वीकार किया जाए या नहीं.

type_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
descriptor_idx	uint	इस तरह की डिस्क्रिप्टर स्ट्रिंग के लिए, `string_ids` सूची में इंडेक्स करें. स्ट्रिंग, ऊपर बताए गए TypeDescriptor के सिंटैक्स के मुताबिक होनी चाहिए.

proto_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
shorty_idx	uint	इस प्रोटोटाइप के छोटे वर्शन के ब्यौरे वाली स्ट्रिंग के लिए, `string_ids` सूची में इंडेक्स करें. स्ट्रिंग, ऊपर बताए गए ShortyDescriptor के सिंटैक्स के मुताबिक होनी चाहिए. साथ ही, यह इस आइटम के रिटर्न टाइप और पैरामीटर से मेल खानी चाहिए.
return_type_idx	uint	इस प्रोटोटाइप के रिटर्न टाइप के लिए, `type_ids` सूची में इंडेक्स करें
parameters_off	uint	फ़ाइल की शुरुआत से इस प्रोटोटाइप के लिए पैरामीटर टाइप की सूची तक का ऑफ़सेट या `0`, अगर इस प्रोटोटाइप में कोई पैरामीटर नहीं है. अगर यह ऑफ़सेट शून्य नहीं है, तो यह `data` सेक्शन में होना चाहिए. साथ ही, वहां मौजूद डेटा, नीचे दिए गए `"type_list"` में बताए गए फ़ॉर्मैट में होना चाहिए. इसके अलावा, सूची में `void` टाइप का कोई रेफ़रंस नहीं होना चाहिए.

field_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
class_idx	ushort	इंडेक्स को इस फ़ील्ड के लिए, `type_ids` सूची में शामिल किया गया है. यह क्लास टाइप होना चाहिए, न कि कलेक्शन या प्राइमिटिव टाइप.
type_idx	ushort	इस फ़ील्ड के टाइप के लिए, `type_ids` सूची में इंडेक्स करें
name_idx	uint	इस फ़ील्ड के नाम के लिए, `string_ids` सूची में इंडेक्स करें. स्ट्रिंग, ऊपर बताए गए MemberName के सिंटैक्स के मुताबिक होनी चाहिए.

method_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
class_idx	ushort	इस तरीके को तय करने वाले के लिए, `type_ids` सूची में इंडेक्स करें. यह प्राइमटिव टाइप के बजाय, क्लास या कलेक्शन टाइप होना चाहिए.
proto_idx	ushort	इस तरीके के प्रोटोटाइप के लिए, `proto_ids` सूची में इंडेक्स
name_idx	uint	इस तरीके के नाम के लिए, `string_ids` सूची में इंडेक्स करें. स्ट्रिंग, ऊपर बताए गए MemberName के सिंटैक्स के मुताबिक होनी चाहिए.

class_def_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
class_idx	uint	इस क्लास के लिए `type_ids` सूची में इंडेक्स करें. यह क्लास टाइप होना चाहिए, न कि कलेक्शन या प्राइमिटिव टाइप.
access_flags	uint	क्लास के लिए ऐक्सेस फ़्लैग (`public`, `final` वगैरह). ज़्यादा जानकारी के लिए, "`access_flags` परिभाषाएं" देखें.
superclass_idx	uint	सुपरक्लास के लिए `type_ids` सूची में इंडेक्स या अगर इस क्लास का कोई सुपरक्लास नहीं है, तो स्थिर वैल्यू `NO_INDEX` (यानी, यह `Object` जैसी रूट क्लास है). अगर मौजूद है, तो यह क्लास टाइप होना चाहिए, न कि कलेक्शन या प्राइमिटिव टाइप.
interfaces_off	uint	फ़ाइल की शुरुआत से इंटरफ़ेस की सूची तक का ऑफ़सेट या `0`, अगर कोई इंटरफ़ेस नहीं है. यह ऑफ़सेट `data` सेक्शन में होना चाहिए. साथ ही, वहां मौजूद डेटा, यहां दिए गए "`type_list`" में बताए गए फ़ॉर्मैट में होना चाहिए. सूची के हर एलिमेंट का टाइप, क्लास होना चाहिए, न कि कलेक्शन या प्राइमिटिव. साथ ही, सूची में कोई डुप्लीकेट एलिमेंट नहीं होना चाहिए.
source_file_idx	uint	`string_ids` सूची में, इस क्लास के लिए (कम से कम ज़्यादातर) ओरिजनल सोर्स वाली फ़ाइल के नाम के लिए इंडेक्स करें या इस जानकारी के न होने की जानकारी देने के लिए, खास वैल्यू `NO_INDEX` डालें. किसी भी तरीके का `debug_info_item`, इस सोर्स फ़ाइल को बदल सकता है. हालांकि, उम्मीद है कि ज़्यादातर क्लास सिर्फ़ एक सोर्स फ़ाइल से आएंगी.
annotations_off	uint	इस क्लास के लिए एनोटेशन स्ट्रक्चर के लिए, फ़ाइल की शुरुआत से लेकर एनोटेशन के बीच का ऑफ़सेट या `0`, अगर इस क्लास पर कोई एनोटेशन नहीं है. अगर यह ऑफ़सेट शून्य नहीं है, तो यह `data` सेक्शन में होना चाहिए. साथ ही, वहां मौजूद डेटा, नीचे दिए गए "`annotations_directory_item`" में बताए गए फ़ॉर्मैट में होना चाहिए. साथ ही, सभी आइटम इस क्लास को डेफ़ाइनर के तौर पर रेफ़र करते होने चाहिए.
class_data_off	uint	फ़ाइल की शुरुआत से, इस आइटम के लिए इससे जुड़े क्लास डेटा तक का ऑफ़सेट या `0`, अगर इस क्लास के लिए कोई क्लास डेटा नहीं है. उदाहरण के लिए, ऐसा तब हो सकता है, जब यह क्लास मार्कर इंटरफ़ेस हो. अगर ऑफ़सेट शून्य नहीं है, तो वह `data` सेक्शन में होना चाहिए. साथ ही, वहां मौजूद डेटा, नीचे दिए गए "`class_data_item`" में बताए गए फ़ॉर्मैट में होना चाहिए. साथ ही, सभी आइटम इस क्लास को डेफ़ाइनर के तौर पर रेफ़र करते होने चाहिए.
static_values_off	uint	फ़ाइल की शुरुआत से लेकर `static` फ़ील्ड की शुरुआती वैल्यू की सूची तक का ऑफ़सेट या अगर कोई वैल्यू नहीं है, तो `0` (और सभी `static` फ़ील्ड को `0` या `null` से शुरू किया जाना है). यह ऑफ़सेट, `data` सेक्शन में होना चाहिए और वहां मौजूद डेटा, नीचे दिए गए "`encoded_array_item`" में बताए गए फ़ॉर्मैट में होना चाहिए. ऐरे का साइज़, इस क्लास में बताए गए `static` फ़ील्ड से ज़्यादा नहीं होना चाहिए. साथ ही, एलिमेंट उसी क्रम में `static` फ़ील्ड से जुड़े होने चाहिए जिस क्रम में संबंधित `field_list` में बताया गया है. हर ऐरे एलिमेंट का टाइप, उसके फ़ील्ड के एलान किए गए टाइप से मेल खाना चाहिए. अगर ऐरे में एलिमेंट की संख्या, `static` फ़ील्ड से कम है, तो बचे हुए फ़ील्ड को टाइप के हिसाब से `0` या `null` से शुरू किया जाता है.

call_site_id_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
call_site_off	uint	साइट डेफ़िनिशन को कॉल करने के लिए, फ़ाइल की शुरुआत से ऑफ़सेट. ऑफ़सेट, डेटा सेक्शन में होना चाहिए. साथ ही, वहां मौजूद डेटा, यहां दिए गए "call_site_item" फ़ॉर्मैट में होना चाहिए.

call_site_item

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

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

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

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

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

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

java.lang.invoke.Lookup
java.lang.String
java.lang.invoke.MethodType

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

method_handle_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
method_handle_type	ushort	मेथड हैंडल का टाइप; नीचे दी गई टेबल देखें
unused	ushort	(इस्तेमाल नहीं किया गया)
field_or_method_id	ushort	फ़ील्ड या मेथड आईडी. यह इस बात पर निर्भर करता है कि मेथड हैंडल टाइप, ऐक्सेसर है या मेथड इनवॉकर
unused	ushort	(इस्तेमाल नहीं किया गया)

मेथड हैंडल टाइप कोड

कॉन्स्टेंट	वैल्यू	ब्यौरा
METHOD_HANDLE_TYPE_STATIC_PUT	0x00	मेथड हैंडल, स्टैटिक फ़ील्ड सेटर (ऐक्सेसर) है
METHOD_HANDLE_TYPE_STATIC_GET	0x01	मेथड हैंडल, स्टैटिक फ़ील्ड पाने वाला (ऐक्सेस करने वाला) तरीका है
METHOD_HANDLE_TYPE_INSTANCE_PUT	0x02	मेथड हैंडल, इंस्टेंस फ़ील्ड सेटर (ऐक्सेसर) है
METHOD_HANDLE_TYPE_INSTANCE_GET	0x03	मेथड हैंडल, इंस्टेंस फ़ील्ड का गेट्टर (ऐक्सेस करने वाला) है
METHOD_HANDLE_TYPE_INVOKE_STATIC	0x04	मेथड हैंडल, स्टैटिक मेथड इनवॉकर है
METHOD_HANDLE_TYPE_INVOKE_INSTANCE	0x05	मेथड हैंडल, इंस्टेंस मेथड को कॉल करने वाला होता है
METHOD_HANDLE_TYPE_INVOKE_CONSTRUCTOR	0x06	मेथड हैंडल, कन्स्ट्रक्टर मेथड को कॉल करने वाला होता है
METHOD_HANDLE_TYPE_INVOKE_DIRECT	0x07	मेथड हैंडल, सीधे तौर पर मेथड को कॉल करने वाला होता है
METHOD_HANDLE_TYPE_INVOKE_INTERFACE	0x08	मेथड हैंडल, इंटरफ़ेस मेथड को कॉल करने वाला होता है

class_data_item

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
static_fields_size	uleb128	इस आइटम में तय किए गए स्टैटिक फ़ील्ड की संख्या
instance_fields_size	uleb128	इस आइटम में तय किए गए इंस्टेंस फ़ील्ड की संख्या
direct_methods_size	uleb128	इस आइटम में तय किए गए डायरेक्ट तरीके की संख्या
virtual_methods_size	uleb128	इस आइटम में तय किए गए वर्चुअल तरीकों की संख्या
static_fields	encoded_field[static_fields_size]	तय किए गए स्टैटिक फ़ील्ड, जिन्हें एलिमेंट के क्रम के तौर पर दिखाया जाता है. फ़ील्ड को `field_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाना चाहिए.
instance_fields	encoded_field[instance_fields_size]	तय किए गए इंस्टेंस फ़ील्ड, जिन्हें एन्कोड किए गए एलिमेंट के क्रम के तौर पर दिखाया जाता है. फ़ील्ड को `field_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाना चाहिए.
direct_methods	encoded_method[direct_methods_size]	तय किए गए डायरेक्ट (`static`, `private` या कॉन्स्ट्रक्टर में से कोई भी) तरीके, जिन्हें कोड में बदले गए एलिमेंट के क्रम के तौर पर दिखाया जाता है. तरीकों को `method_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाया जाना चाहिए.
virtual_methods	encoded_method[virtual_methods_size]	तय किए गए वर्चुअल (`static`, `private` या कंस्ट्रक्टर में से कोई नहीं) तरीके, जिन्हें एन्कोड किए गए एलिमेंट के क्रम के तौर पर दिखाया जाता है. इस सूची में, इनहेरिट किए गए तरीकों को तब तक शामिल नहीं करना चाहिए, जब तक कि इस आइटम को दिखाने वाली क्लास से उन्हें बदला न गया हो. तरीकों को `method_idx` के हिसाब से, बढ़ते क्रम में लगाया जाना चाहिए. वर्चुअल तरीके का `method_idx`, किसी भी डायरेक्ट तरीके से अलग होना चाहिए.

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

encoded_field फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
field_idx_diff	uleb128	इस फ़ील्ड की पहचान के लिए `field_ids` सूची में इंडेक्स (इसमें नाम और डिस्क्रिप्टर शामिल है), जिसे सूची में पिछले एलिमेंट के इंडेक्स से अलग दिखाया गया है. किसी सूची में पहले एलिमेंट का इंडेक्स, सीधे तौर पर दिखाया जाता है.
access_flags	uleb128	फ़ील्ड के लिए ऐक्सेस फ़्लैग (`public`, `final` वगैरह). ज़्यादा जानकारी के लिए, "`access_flags` परिभाषाएं" देखें.

encoded_method फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
method_idx_diff	uleb128	इस तरीके की पहचान के लिए, `method_ids` सूची में इंडेक्स (इसमें नाम और डिस्क्रिप्टर शामिल है), जिसे सूची में पिछले एलिमेंट के इंडेक्स से अलग दिखाया गया है. किसी सूची में पहले एलिमेंट का इंडेक्स, सीधे तौर पर दिखाया जाता है.
access_flags	uleb128	तरीके के लिए ऐक्सेस फ़्लैग (`public`, `final` वगैरह). ज़्यादा जानकारी के लिए, "`access_flags` परिभाषाएं" देखें.
code_off	uleb128	इस तरीके के लिए, फ़ाइल की शुरुआत से कोड स्ट्रक्चर तक का ऑफ़सेट या `0`, अगर यह तरीका `abstract` या `native` है. ऑफ़सेट, `data` सेक्शन में मौजूद किसी जगह का होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`code_item`" से तय होता है.

type_list

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uint	सूची का साइज़, एंट्री में
सूची	type_item[size]	सूची के एलिमेंट

type_item फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
type_idx	ushort	`type_ids` सूची में इंडेक्स करें

code_item

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
registers_size	ushort	इस कोड का इस्तेमाल करके रजिस्टर किए गए उपयोगकर्ताओं की संख्या
ins_size	ushort	उस तरीके में आने वाले आर्ग्युमेंट के शब्दों की संख्या जिसके लिए यह कोड है
outs_size	ushort	इस कोड के लिए, आउटगोइंग आर्ग्युमेंट स्पेस में शब्दों की संख्या, जो तरीका शुरू करने के लिए ज़रूरी है
tries_size	ushort	इस इंस्टेंस के लिए `try_item` की संख्या. अगर वैल्यू शून्य से ज़्यादा है, तो यह वैल्यू इस इंस्टेंस में `insns` के ठीक बाद `tries` कलेक्शन के तौर पर दिखती है.
debug_info_off	uint	इस कोड के लिए, फ़ाइल की शुरुआत से डीबग जानकारी (लाइन नंबर + स्थानीय वैरिएबल की जानकारी) के क्रम तक का ऑफ़सेट या `0`, अगर कोई जानकारी नहीं है. अगर ऑफ़सेट शून्य नहीं है, तो यह `data` सेक्शन में किसी जगह पर होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`debug_info_item`" से तय होता है.
insns_size	uint	निर्देशों की सूची का साइज़, 16-बिट कोड यूनिट में
insns	ushort[insns_size]	बाइटकोड का असल कलेक्शन. `insns` कलेक्शन में मौजूद कोड का फ़ॉर्मैट, साथ में दिए गए दस्तावेज़ में बताए गए Dalvik बाइटकोड से तय होता है. ध्यान दें कि इसे `ushort` के ऐरे के तौर पर परिभाषित किया गया है. हालांकि, कुछ इंटरनल स्ट्रक्चर में चार बाइट के अलाइनमेंट का इस्तेमाल किया जाता है. इसके अलावा, अगर यह endian-swap की गई फ़ाइल में होता है, तो स्वैप करने की प्रोसेस सिर्फ़ अलग-अलग `ushort` इंस्टेंस पर की जाती है, न कि बड़े इंटरनल स्ट्रक्चर पर.
पैडिंग	ushort (ज़रूरी नहीं) = 0	`tries` को चार बाइट अलाइन करने के लिए, पैडिंग के दो बाइट. यह एलिमेंट सिर्फ़ तब मौजूद होता है, जब `tries_size` शून्य से अलग हो और `insns_size` विषम हो.
कोशिश करता है	try_item[tries_size] (ज़रूरी नहीं)	ऐरे, जिसमें यह जानकारी होती है कि कोड में अपवाद कहां पकड़े जाते हैं और उन्हें कैसे मैनेज किया जाता है. ऐरे के एलिमेंट, रेंज में ओवरलैप नहीं होने चाहिए और कम से ज़्यादा पते के क्रम में होने चाहिए. यह एलिमेंट सिर्फ़ तब मौजूद होता है, जब `tries_size` की वैल्यू शून्य से ज़्यादा हो.
हैंडलर	encoded_catch_handler_list (ज़रूरी नहीं)	बाइट, जो कैच टाइप और उनसे जुड़े हैंडलर पतों की सूचियों की सूची दिखाते हैं. इस स्ट्रक्चर में, हर `try_item` के लिए बाइट के हिसाब से ऑफ़सेट होता है. यह एलिमेंट सिर्फ़ तब मौजूद होता है, जब `tries_size` शून्य से ज़्यादा हो.

try_item फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
start_addr	uint	इस एंट्री में शामिल कोड ब्लॉक का स्टार्ट पता. पते का मतलब है, कोड में शामिल पहले निर्देश की शुरुआत तक 16-बिट कोड यूनिट की गिनती.
insn_count	ushort	इस एंट्री में शामिल 16-बिट कोड यूनिट की संख्या. आखिरी कोड यूनिट (इसमें शामिल) `start_addr + insn_count - 1` है.
handler_off	ushort	इस एंट्री के लिए, इससे जुड़े `encoded_catch_hander_list` की शुरुआत से लेकर `encoded_catch_handler` तक के बाइट में ऑफ़सेट. यह `encoded_catch_handler` के शुरू होने के लिए, ऑफ़सेट होना चाहिए.

encoded_catch_handler_list फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uleb128	इस सूची का साइज़, एंट्री में
सूची	encoded_catch_handler[handlers_size]	हैंडलर की सूचियों की असल सूची, सीधे तौर पर दिखाई गई (ऑफ़सेट के तौर पर नहीं), और क्रम से जोड़ी गई

encoded_catch_handler फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	sleb128	इस सूची में कैच टाइप की संख्या. अगर यह वैल्यू पॉज़िटिव नहीं है, तो यह वैल्यू, कैच टाइप की संख्या के उलट होती है. साथ ही, कैच के बाद कैच-ऑल हैंडलर होता है. उदाहरण के लिए: `0` का `size` इसका मतलब है कि कैच-ऑल है, लेकिन साफ़ तौर पर टाइप किए गए कैच नहीं हैं. `2` का `size` का मतलब है कि साफ़ तौर पर लिखे गए दो कैच हैं और कोई कैच-ऑल नहीं है. `-1` का `size` का मतलब है कि कैच-ऑल के साथ एक टाइप किया गया कैच है.
हैंडलर	encoded_type_addr_pair[abs(size)]	`abs(size)` एन्कोड किए गए आइटम की स्ट्रीम, पकड़े गए हर तरह के आइटम के लिए एक, उसी क्रम में जिस क्रम में आइटम की जांच की जानी है.
catch_all_addr	uleb128 (ज़रूरी नहीं)	कैच-ऑल हैंडलर का बाइटकोड पता. यह एलिमेंट सिर्फ़ तब मौजूद होता है, जब `size` की वैल्यू नॉन-पॉज़िटिव हो.

encoded_type_addr_pair फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
type_idx	uleb128	`type_ids` सूची में इंडेक्स, जिस तरह के अपवाद को पकड़ना है
addr	uleb128	अपवाद हैंडलर से जुड़ा बाइटकोड पता

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 कोड के लिए, हर रजिस्टर में मौजूद आखिरी लोकल वैरिएबल के नाम और टाइप को भी ट्रैक करना चाहिए.

हेडर इस तरह का होता है:

नाम	फ़ॉर्मैट	ब्यौरा
line_start	uleb128	स्टेट मशीन के `line` रजिस्टर की शुरुआती वैल्यू. इसमें असल पोज़िशन की जानकारी नहीं दी गई है.
parameters_size	uleb128	कोड में बदले गए पैरामीटर के नामों की संख्या. हर मेथड पैरामीटर के लिए एक होना चाहिए. अगर कोई इंस्टेंस मेथड है, तो उसके `this` को छोड़कर.
parameter_names	uleb128p1[parameters_size]	मेथड पैरामीटर के नाम का स्ट्रिंग इंडेक्स. `NO_INDEX` की कोड में बदली गई वैल्यू से पता चलता है कि इससे जुड़े पैरामीटर के लिए कोई नाम उपलब्ध नहीं है. टाइप डिस्क्रिप्टर और हस्ताक्षर, तरीका डिस्क्रिप्टर और हस्ताक्षर से पता चलते हैं.

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

नाम	वैल्यू	फ़ॉर्मैट करें	तर्क	ब्यौरा
DBG_END_SEQUENCE	0x00		(कोई नहीं)	`code_item` के लिए डीबग की जानकारी वाले क्रम को खत्म करता है
DBG_ADVANCE_PC	0x01	uleb128 addr_diff	`addr_diff`: पते के रजिस्टर में जोड़ने के लिए रकम	पोज़िशन एंट्री को उत्सर्जित किए बिना, पते के रजिस्टर को आगे बढ़ाता है
DBG_ADVANCE_LINE	0x02	sleb128 line_diff	`line_diff`: लाइन रजिस्टर में बदलाव करने के लिए रकम	पोज़िशन एंट्री को उत्सर्जित किए बिना लाइन रजिस्टर को आगे बढ़ाता है
DBG_START_LOCAL	0x03	uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx	`register_num`: वह रजिस्टर जिसमें लोकल शामिल होगा `name_idx`: नाम का स्ट्रिंग इंडेक्स `type_idx`: टाइप का टाइप इंडेक्स	मौजूदा पते पर एक लोकल वैरिएबल जोड़ता है. वैल्यू के अज्ञात होने का पता लगाने के लिए, `name_idx` या `type_idx` में से किसी एक को `NO_INDEX` पर सेट किया जा सकता है.
DBG_START_LOCAL_EXTENDED	0x04	uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx uleb128p1 sig_idx	`register_num`: रजिस्टर में लोकल शामिल होगा `name_idx`: नाम का स्ट्रिंग इंडेक्स `type_idx`: टाइप का टाइप इंडेक्स `sig_idx`: टाइप हस्ताक्षर का स्ट्रिंग इंडेक्स	मौजूदा पते पर, टाइप हस्ताक्षर के साथ एक लोकल पेश करता है. `name_idx`, `type_idx` या `sig_idx` में से किसी भी वैल्यू को `NO_INDEX` के तौर पर सेट किया जा सकता है, ताकि यह पता चल सके कि वैल्यू की जानकारी नहीं है. (अगर `sig_idx` `-1` है, तो ऑपरेंड `DBG_START_LOCAL` का इस्तेमाल करके, उसी डेटा को ज़्यादा बेहतर तरीके से दिखाया जा सकता है.) ध्यान दें: हस्ताक्षर मैनेज करने के बारे में सावधानियों के लिए, यहां दिए गए "`dalvik.annotation.Signature`" में दी गई चर्चा देखें.
DBG_END_LOCAL	0x05	uleb128 register_num	`register_num`: वह रजिस्टर जिसमें स्थानीय टाइमज़ोन शामिल है	मौजूदा समय में काम कर रहे लोकल वैरिएबल को मौजूदा पते पर, दायरे से बाहर के तौर पर मार्क करता है
DBG_RESTART_LOCAL	0x06	uleb128 register_num	`register_num`: रीस्टार्ट करने के लिए रजिस्टर करें	मौजूदा पते पर एक स्थानीय वैरिएबल फिर से लागू करता है. नाम और टाइप, तय किए गए रजिस्टर में मौजूद आखिरी लोकल के नाम और टाइप के जैसे ही होने चाहिए.
DBG_SET_PROLOGUE_END	0x07		(कोई नहीं)	`prologue_end` स्टेट मशीन रजिस्टर को सेट करता है, जिससे पता चलता है कि जोड़ी गई अगली पोज़िशन एंट्री को, किसी मेथड के प्रॉलोग (मेथड ब्रेकपॉइंट के लिए सही जगह) के आखिर में माना जाना चाहिए. `prologue_end` रजिस्टर को किसी खास (`>= 0x0a`) ऑपकोड से रीसेट किया जाता है.
DBG_SET_EPILOGUE_BEGIN	0x08		(कोई नहीं)	`epilogue_begin` स्टेट मशीन रजिस्टर को सेट करता है, जिससे पता चलता है कि जोड़ी गई अगली पोज़िशन एंट्री को, किसी मेथड के एपिलॉग की शुरुआत माना जाना चाहिए (यह मेथड से बाहर निकलने से पहले, प्रोसेस को निलंबित करने के लिए सही जगह है). `epilogue_begin` रजिस्टर को किसी भी खास ऑपकोड (`>= 0x0a`) से मिटाया जाता है.
DBG_SET_FILE	0x09	uleb128p1 name_idx	`name_idx`: सोर्स फ़ाइल के नाम का स्ट्रिंग इंडेक्स; `NO_INDEX` अगर नाम पता न हो	का मतलब है कि इसके बाद की सभी लाइन नंबर एंट्री, `code_item` में बताए गए डिफ़ॉल्ट नाम के बजाय, इस सोर्स फ़ाइल के नाम का रेफ़रंस देती हैं
खास ऑपरेंड कोड	0x0a…0xff		(कोई नहीं)	`line` और `address` रजिस्टर को आगे बढ़ाता है, पोज़िशन एंट्री को दिखाता है, और `prologue_end` और `epilogue_begin` को मिटा देता है. जानकारी के लिए नीचे देखें.

खास ऑपरेंड कोड

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 बाइट

नाम	फ़ॉर्मैट	ब्यौरा
class_annotations_off	uint	फ़ाइल की शुरुआत से लेकर क्लास पर सीधे तौर पर किए गए एनोटेशन तक का ऑफ़सेट या `0`, अगर क्लास में कोई सीधा एनोटेशन नहीं है. अगर ऑफ़सेट शून्य नहीं है, तो यह `data` सेक्शन में किसी जगह पर होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`annotation_set_item`" से तय होता है.
fields_size	uint	इस आइटम से एनोटेट किए गए फ़ील्ड की संख्या
annotated_methods_size	uint	इस आइटम से एनोटेट किए गए तरीकों की संख्या
annotated_parameters_size	uint	इस आइटम से एनोटेट की गई, तरीके के पैरामीटर की सूचियों की संख्या
field_annotations	field_annotation[fields_size] (ज़रूरी नहीं)	उससे जुड़े फ़ील्ड एनोटेशन की सूची. सूची के एलिमेंट को `field_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाना ज़रूरी है.
method_annotations	method_annotation[methods_size] (ज़रूरी नहीं)	उससे जुड़े तरीके के एनोटेशन की सूची. सूची के एलिमेंट को `method_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाना ज़रूरी है.
parameter_annotations	parameter_annotation[parameters_size] (ज़रूरी नहीं)	इससे जुड़े तरीके के पैरामीटर एनोटेशन की सूची. सूची के एलिमेंट को `method_idx` के हिसाब से, बढ़ते क्रम में क्रम से लगाया जाना चाहिए.

field_annotation का फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
field_idx	uint	एनोटेट किए जा रहे फ़ील्ड की पहचान के लिए, `field_ids` सूची में इंडेक्स
annotations_off	uint	फ़ील्ड के लिए, एनोटेशन की सूची में फ़ाइल की शुरुआत से लेकर ऑफ़सेट, `data` सेक्शन में मौजूद किसी जगह पर होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`annotation_set_item`" से तय होता है.

method_annotation फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
method_idx	uint	एनोटेट किए जा रहे तरीके की पहचान के लिए, `method_ids` सूची में इंडेक्स
annotations_off	uint	ऑफ़सेट, फ़ाइल की शुरुआत से लेकर एनोटेशन की सूची तक है. ऑफ़सेट, `data` सेक्शन में मौजूद किसी जगह का होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`annotation_set_item`" से तय होता है.

parameter_annotation फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
method_idx	uint	उस तरीके की पहचान के लिए `method_ids` सूची में इंडेक्स करना जिसके पैरामीटर को एनोटेट किया जा रहा है
annotations_off	uint	ऑफ़सेट, फ़ाइल की शुरुआत से लेकर, तरीकों के पैरामीटर के लिए एनोटेशन की सूची तक है. ऑफ़सेट, `data` सेक्शन में मौजूद किसी जगह का होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`annotation_set_ref_list`" से तय होता है.

annotation_set_ref_list

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uint	सूची का साइज़, एंट्री में
सूची	annotation_set_ref_item[size]	सूची के एलिमेंट

annotation_set_ref_item फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
annotations_off	uint	फ़ाइल की शुरुआत से रेफ़रंस वाले एनोटेशन सेट तक का ऑफ़सेट या `0`, अगर इस एलिमेंट के लिए कोई एनोटेशन नहीं है. अगर ऑफ़सेट शून्य नहीं है, तो यह `data` सेक्शन में किसी जगह पर होना चाहिए. डेटा का फ़ॉर्मैट, यहां दिए गए "`annotation_set_item`" से तय होता है.

annotation_set_item

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uint	एंट्री में सेट का साइज़
एंट्री	annotation_off_item[size]	एलिमेंट. एलिमेंट को `type_idx` के हिसाब से, बढ़ते क्रम में लगाया जाना चाहिए.

annotation_off_item फ़ॉर्मैट

नाम	फ़ॉर्मैट	ब्यौरा
annotation_off	uint	फ़ाइल की शुरुआत से किसी एनोटेशन तक का ऑफ़सेट. ऑफ़सेट, `data` सेक्शन में किसी जगह पर होना चाहिए. साथ ही, उस जगह पर मौजूद डेटा का फ़ॉर्मैट, नीचे दिए गए "`annotation_item`" से तय होता है.

annotation_item

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
कैसा दिखाई दे	ubyte	इस एनोटेशन को किस तरह से दिखाना है (यहां देखें)
टिप्‍पणी	encoded_annotation	एनोटेशन का कोड में बदला गया कॉन्टेंट, ऊपर दिए गए "`encoded_value` कोड में बदलना" में बताए गए "`encoded_annotation` फ़ॉर्मैट" में.

किसको दिखे की वैल्यू

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

नाम	वैल्यू	ब्यौरा
VISIBILITY_BUILD	0x00	सिर्फ़ बिल्ड के समय दिखने के लिए है (उदाहरण के लिए, दूसरे कोड को संकलित करने के दौरान)
VISIBILITY_RUNTIME	0x01	रनटाइम के दौरान दिखने के लिए
VISIBILITY_SYSTEM	0x02	रनटाइम के दौरान दिखने के लिए, लेकिन सिर्फ़ मौजूदा सिस्टम के लिए (न कि सामान्य उपयोगकर्ता कोड के लिए)

encoded_array_item

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	encoded_array	कोड में बदली गई ऐरे वैल्यू को दिखाने वाले बाइट, जो ऊपर "`encoded_value` कोड में बदलना" में "`encoded_array` फ़ॉर्मैट" से तय किए गए फ़ॉर्मैट में होते हैं.

hiddenapi_class_data_item

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

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

नाम	फ़ॉर्मैट	ब्यौरा
साइज़	uint	सेक्शन का कुल साइज़
ऑफ़सेट	uint[]	`class_idx` से इंडेक्स किए गए ऑफ़सेट का कलेक्शन. इंडेक्स `class_idx` में शून्य वाली ऐरे एंट्री का मतलब है कि या तो इस `class_idx` के लिए कोई डेटा नहीं है या छिपाए गए सभी एपीआई फ़्लैग शून्य हैं. अगर ऐसा नहीं है, तो ऐरे एंट्री शून्य नहीं है और इसमें सेक्शन की शुरुआत से लेकर इस `class_idx` के लिए, छिपे हुए एपीआई फ़्लैग के ऐरे तक का ऑफ़सेट शामिल होता है.
फ़्लैग	uleb128[]	हर क्लास के लिए, छिपे हुए एपीआई फ़्लैग के कनेक्शन वाले ऐरे. फ़्लैग की संभावित वैल्यू के बारे में नीचे दी गई टेबल में बताया गया है. फ़्लैग को उसी क्रम में कोड में बदला जाता है जिस क्रम में क्लास डेटा में फ़ील्ड और तरीके कोड में बदले जाते हैं.

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

नाम	वैल्यू	ब्यौरा
व्हाइटलिस्ट	0	ऐसे इंटरफ़ेस जिन्हें आसानी से इस्तेमाल किया जा सकता है और जिन्हें आधिकारिक तौर पर दस्तावेज़ में दर्ज Android फ़्रेमवर्क के पैकेज इंडेक्स के हिस्से के तौर पर इस्तेमाल किया जा सकता है.
संदिग्ध आइटम की सूची	1	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल, ऐप्लिकेशन के टारगेट एपीआई लेवल के बावजूद किया जा सकता है.
प्रतिबंधित करें	2	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल, ऐप्लिकेशन के टारगेट एपीआई लेवल के बावजूद नहीं किया जा सकता. इनमें से किसी एक इंटरफ़ेस को ऐक्सेस करने पर, रनटाइम में गड़बड़ी होती है.
greylist‑max‑o	3	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल Android 8.x और इससे पहले के वर्शन के लिए किया जा सकता है. हालांकि, ऐसा तब तक किया जा सकता है, जब तक उन पर पाबंदी न लगी हो.
greylist‑max‑p	4	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल Android 9.x के लिए तब तक किया जा सकता है, जब तक उन पर पाबंदी न लगाई गई हो.
greylist‑max‑q	5	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल Android 10.x के लिए तब तक किया जा सकता है, जब तक उन पर पाबंदी न लगाई गई हो.
greylist‑max‑r	6	ऐसे गैर-SDK इंटरफ़ेस जिनका इस्तेमाल Android 11.x के लिए तब तक किया जा सकता है, जब तक उन पर पाबंदी न लगी हो.

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

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

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

dalvik.annotation.AnnotationDefault

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

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

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

dalvik.annotation.EnclosingClass

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

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	कक्षा	वह क्लास जो इस क्लास के लेक्सिकल स्कोप से सबसे ज़्यादा मिलती-जुलती हो

dalvik.annotation.EnclosingMethod

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

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	Method	वह तरीका जो इस क्लास को लेक्सिकल तौर पर सबसे ज़्यादा स्कोप करता है

dalvik.annotation.InnerClass

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

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

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

dalvik.annotation.MemberClasses

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

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	Class[]	सदस्यों की कैटगरी का कलेक्शन

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 में, एनोटेशन टाइप पाने वाले उन पैरामीटर के बारे में भी कोई जानकारी शामिल नहीं होगी जो असल तरीके के हस्ताक्षर में मौजूद नहीं हैं.

नाम	फ़ॉर्मैट	ब्यौरा
नाम	String[]	इससे जुड़े तरीके के लिए, फ़ॉर्मल पैरामीटर के नाम. ऐरे का वैल्यू शून्य नहीं होना चाहिए. हालांकि, अगर कोई फ़ॉर्मल पैरामीटर नहीं है, तो ऐरे खाली होना चाहिए. अगर उस इंडेक्स वाले फ़ॉर्मल पैरामीटर का कोई नाम नहीं है, तो ऐरे में मौजूद वैल्यू शून्य होनी चाहिए. अगर पैरामीटर के नाम की स्ट्रिंग खाली हैं या उनमें '.', ';', '[' या '/' शामिल हैं, तो रनटाइम के दौरान एक `java.lang.reflect.MalformedParametersException` जनरेट होगा.
accessFlags	int[]	इससे जुड़े तरीके के लिए, फ़ॉर्मल पैरामीटर के ऐक्सेस फ़्लैग. ऐरे का वैल्यू शून्य नहीं होना चाहिए. हालांकि, अगर कोई फ़ॉर्मल पैरामीटर नहीं है, तो ऐरे खाली होना चाहिए. यह वैल्यू एक बिट मास्क है, जिसमें ये वैल्यू होती हैं: 0x0010 : फ़ाइनल, पैरामीटर को फ़ाइनल घोषित किया गया था 0x1000 : सिंथेटिक, पैरामीटर को कंपाइलर ने जोड़ा था 0x8000 : ज़रूरी है, यह पैरामीटर सिंथेटिक है, लेकिन भाषा के लिए तय की गई शर्तों से भी यह पता चलता है अगर इस सेट के बाहर कोई बिट सेट किया जाता है, तो रनटाइम के दौरान एक `java.lang.reflect.MalformedParametersException` थ्रो किया जाएगा.

dalvik.annotation.Signature

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

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

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	String[]	इस क्लास या सदस्य का हस्ताक्षर, स्ट्रिंग के ऐसे ऐरे के तौर पर जिसे एक साथ जोड़ना है

dalvik.annotation.Throws

इन पर दिखता है

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

नाम	फ़ॉर्मैट	ब्यौरा
मान	Class[]	थ्रो किए गए अपवाद टाइप का कलेक्शन