قالب اجرایی Dalvik

این سند طرح‌بندی و محتوای فایل‌های .dex را شرح می‌دهد که برای نگهداری مجموعه‌ای از تعاریف کلاس و داده‌های الحاقی مرتبط با آن‌ها استفاده می‌شود.

راهنمای انواع

LEB128

‫LEB128 («Little-Endian Base 128») یک کدبندی با طول متغیر برای مقادیر صحیح علامت‌دار یا بدون علامت دلخواه است. قالب از مشخصات DWARF3 اقتباس شده است. در فایل .dex، از LEB128 فقط برای کدبندی مقادیر ۳۲ بیتی استفاده می‌شود.

هر مقدار کدگذاری‌شده LEB128 از یک تا پنج بایت تشکیل شده است که باهم یک مقدار ۳۲ بیتی را نشان می‌دهند. هر بایت به‌جز بایت آخر در توالی، بیت باارزش خود را تنظیم می‌کند، درحالی‌که بایت آخر بیت باارزش خود را پاک می‌کند. هفت بیت باقی‌مانده از هر بایت بار مفید هستند، با کمترین هفت بیت معنی‌دار مقدار در بایت اول، هفت بیت بعدی در بایت دوم و غیره. در مورد LEB128 امضادار (sleb128)، مهم‌ترین بیت بار نهایی در توالی به‌صورت امضادار گسترش می‌یابد تا مقدار نهایی تولید شود. در حالت بدون علامت (uleb128)، هر بیت که به‌طور صریح نشان داده نشده باشد به‌صورت 0 تفسیر می‌شود.

از متغیر uleb128p1 برای نمایش مقدار علامت‌دار استفاده می‌شود، که در آن نمایش مقدار به‌علاوه یک است که به‌صورت uleb128 کدبندی شده است. This makes the encoding of -1 (alternatively thought of as the unsigned value 0xffffffff) — but no other negative number — a single byte, and is useful in exactly those cases where the represented number must either be non-negative or -1 (or 0xffffffff), and where no other negative values are allowed (or where large unsigned values are unlikely to be needed).

در اینجا چند نمونه از قالب‌ها آورده شده است:

چیدمان فایل

قالب محتوی

نسخه ۴۱ قالب جدیدی برای داده‌های 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"

توجه: پشتیبانی از نسخه 041 قالب در نسخه Android 16 برای آزمایش قالب محفظه آزمایشی است. بااین‌حال، نباید از نسخه 041 برای کد تولید استفاده شود.

توجه: پشتیبانی از نسخه 040 قالب در نسخه Android 10.0 اضافه شد که مجموعه نویسه‌های مجاز در SimpleNames را گسترش داد.

توجه: پشتیبانی از نسخه 039 قالب در نسخه Android 9.0 اضافه شد که دو کدبایت جدید، const-method-handle و const-method-type، را معرفی کرد. (هریک از این موارد در جدول خلاصه مجموعه بایت‌کد توضیح داده شده است.) در Android 10، نسخه 039 قالب فایل DEX را گسترش می‌دهد تا اطلاعات API پنهان را که فقط برای فایل‌های DEX در مسیر کلاس راه‌اندازی قابل‌اعمال است دربرگیرد.

توجه: پشتیبانی از نسخه 038 این قالب در نسخه Android 8.0 اضافه شد. نسخه 038 کدهای بایت جدیدی (invoke-polymorphic و invoke-custom) و داده‌هایی برای مدیریت روش اضافه کرد.

توجه: پشتیبانی از نسخه 037 این قالب در نسخه Android 7.0 اضافه شد. قبل‌از نسخه 037، اکثر نسخه‌های Android از نسخه 035 قالب استفاده کرده‌اند. تنها تفاوت بین نسخه‌های 035 و 037 افزودن روش‌های پیش‌فرض و اصلاح invoke است.

توجه: حداقل چند نسخه قبلی از این قالب در نسخه‌های نرم‌افزار عمومی که به‌طور گسترده دردسترس هستند استفاده شده است. برای مثال، نسخه 009 برای نسخه‌های پخش M3 پلاتفرم Android (نوامبر–دسامبر ۲۰۰۷) استفاده شد، و نسخه 013 برای نسخه‌های پخش M5 پلاتفرم Android (فوریه–مارس ۲۰۰۸) استفاده شد. از چند جهت، این نسخه‌های قدیمی‌تر قالب تفاوت قابل‌توجهی با نسخه شرح‌داده‌شده در این سند دارند.

ENDIAN_CONSTANT و REVERSE_ENDIAN_CONSTANT

جاسازی‌شده در header_item

از ثابت ENDIAN_CONSTANT برای نشان دادن ترتیب بایت‌های فایل استفاده می‌شود. اگرچه قالب استاندارد .dex little-endian است، پیاده‌سازی‌ها ممکن است مبادله بایت را انتخاب کنند. اگر پیاده‌سازی به سراغ سرایندی برود که endian_tag آن REVERSE_ENDIAN_CONSTANT به‌جای ENDIAN_CONSTANT باشد، متوجه می‌شود که فایل از شکل موردانتظار خود جابه‌جا شده است.

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

بدون نمایه

در class_def_item و debug_info_item جاسازی‌شده است

از ثابت NO_INDEX برای نشان دادن اینکه مقدار شاخص وجود ندارد استفاده می‌شود.

توجه: این مقدار به‌عنوان 0 تعریف نشده است، زیرا درواقع معمولاً نمایه‌ای معتبر است.

مقدار انتخابی برای NO_INDEX در کدبندی uleb128p1 می‌تواند به‌عنوان یک بایت واحد نمایش داده شود.

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

تعاریف پرچم‌های دسترسی

جاسازی‌شده در 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 است، به‌جای اینکه یک قالب کدبندی مستقیم‌تر برای نویسه‌های Unicode باشد.

دو مورد آخر در بالا به‌طور هم‌زمان امکان گنجاندن نقطه کد U+0000 را در رشته و همچنان دستکاری کردن آن را به‌عنوان رشته پایان‌یافته با تهی به سبک C فراهم می‌کنند.

بااین‌حال، کدبندی ویژه U+0000 به این معنا است که برخلاف UTF-8 معمولی، نتیجه فراخوانی تابع استاندارد C strcmp() روی یک جفت رشته MUTF-8 همیشه نشان‌دهنده نتیجه مقایسه رشته‌های نابرابر با علامت صحیح نیست. وقتی ترتیب (نه فقط برابری) اهمیت دارد، ساده‌ترین راه برای مقایسه رشته‌های MUTF-8 این است که آن‌ها را نویسه به نویسه رمزگشایی کنید و مقادیر رمزگشایی‌شده را مقایسه کنید. (بااین‌حال، پیاده‌سازی‌های هوشمندانه‌تر نیز امکان‌پذیر است.)

برای اطلاعات بیشتر درباره کدبندی نویسه، لطفاً به استاندارد یونیکد مراجعه کنید. MUTF-8 درواقع به کدبندی (نسبتاً کمتر شناخته‌شده) CESU-8 نزدیک‌تر است تا به خود UTF-8.

کدبندی encoded_value

در annotation_element و encoded_array_item جاسازی شده است

encoded_value قطعه‌ای کدگذاری‌شده از داده‌های ساختاریافته سلسله‌مراتبی (تقریباً) دلخواه است. هدف از این کدبندی این است که هم فشرده باشد و هم تجزیه آن ساده باشد.

قالب‌های مقدار

قالب encoded_array

قالب encoded_annotation

قالب عنصر گزارمان

نحو رشته

چندین نوع مورد در فایل .dex وجود دارد که درنهایت به یک رشته اشاره می‌کنند. تعاریف سبک BNF زیر نحو قابل‌قبول برای این رشته‌ها را نشان می‌دهد.

SimpleName

SimpleName پایه دستورگان نام‌های دیگر چیزها است. قالب .dex در اینجا (بسیار بیشتر از اکثر زبان‌های منبع رایج) آزادی عمل زیادی می‌دهد. به‌طور خلاصه، نام ساده از هر نویسه الفبایی یا رقم ASCII پایین، چند نماد ASCII پایین خاص، و بیشتر نقاط کد غیر ASCII که نویسه کنترلی، فاصله، یا نویسه خاص نیستند تشکیل شده است. از نسخه 040 این قالب علاوه‌براین نویسه‌های فاصله (دسته Zs یونی‌کد) را مجاز می‌کند. توجه داشته باشید که کدپوینت‌های جانشین (در محدوده U+d800 … U+dfff) به‌خودی خود به‌عنوان نویسه‌های نام معتبر درنظر گرفته نمی‌شوند، اما نویسه‌های تکمیلی «یونی‌کد» معتبر هستند (که با جایگزین نهایی قانون برای SimpleNameChar نشان داده می‌شوند)، و باید در فایل به‌صورت جفت کدپوینت جانشین در کدبندی MUTF-8 نشان داده شوند.

نام عضو

استفاده‌شده توسط field_id_item و method_id_item

MemberName نام یکی از اعضای کلاس است، اعضا شامل فیلدها، روش‌ها، و کلاس‌های داخلی می‌شود.

نام کامل کلاس

FullClassName نام کلاس کاملاً واجدشرایطی است که شامل مشخص‌کننده بسته اختیاری و به‌دنبال آن نام الزامی است.

TypeDescriptor

مورداستفاده type_id_item

TypeDescriptor نمایانگر هر نوعی است، ازجمله انواع اولیه، کلاس‌ها، آرایه‌ها، و void. برای اطلاع از معنای نسخه‌های مختلف، به زیر مراجعه کنید.

ShortyDescriptor

‫proto_id_item از آن استفاده کرده است

ShortyDescriptor نمایش فرم کوتاه نمونه اولیه روش است، ازجمله انواع بازگشت و پارامتر، به‌جز اینکه هیچ تمایزی بین انواع مختلف مرجع (کلاس یا آرایه) وجود ندارد. درعوض، همه انواع مرجع با یک نویسه 'L' نمایش داده می‌شوند.

معناشناسی TypeDescriptor

این معنی هریک از متغیرهای TypeDescriptor است.

موارد و ساختارهای مرتبط

این بخش شامل تعاریف مربوط به هریک از موارد سطح بالا است که ممکن است در فایل .dex ظاهر شود.

header_item

در بخش سرایند ظاهر می‌شود

تراز: ۴ بایت

map_list

در بخش داده‌ها نشان داده می‌شود

ارجاع‌شده از header_item

تراز: ۴ بایت

این فهرستی از کل محتوای یک فایل به‌ترتیب است. این کلاس تاحدی با header_item هم‌پوشانی دارد اما هدف از آن ارائه فرمی آسان برای تکرار روی کل فایل است. نوع داده معینی باید حداکثر یک‌بار در نقشه ظاهر شود، اما هیچ محدودیتی در ترتیب ظاهر شدن انواع داده وجود ندارد، به‌جز محدودیت‌های ضمنی ناشی از بقیه قالب (برای نمونه، بخش header باید اول ظاهر شود و پس‌از آن بخش string_ids و غیره). علاوه‌براین، ورودی‌های نقشه باید براساس افست اولیه مرتب شوند و نباید هم‌پوشانی داشته باشند.

قالب عنصر نقشه

تایپ کردن کدها

string_id_item

در بخش string_ids نشان داده می‌شود

تراز: ۴ بایت

string_data_item

در بخش داده‌ها نشان داده می‌شود

تراز: هیچ (تراز بایت)

type_id_item

در بخش type_ids ظاهر می‌شود

تراز: ۴ بایت

proto_id_item

در بخش proto_ids نشان داده می‌شود

تراز: ۴ بایت

field_id_item

در بخش field_ids نشان داده می‌شود

تراز: ۴ بایت

method_id_item

در بخش method_ids ظاهر می‌شود

تراز: ۴ بایت

class_def_item

در بخش class_defs ظاهر می‌شود

تراز: ۴ بایت

call_site_id_item

در بخش call_site_ids نشان داده می‌شود

تراز: ۴ بایت

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 نشان داده می‌شود

تراز: ۴ بایت

کدهای نوع دسته روش

class_data_item

ارجاع‌شده از class_def_item

در بخش داده‌ها نشان داده می‌شود

تراز: هیچ (تراز بایت)

توجه: همه نمونه‌های عنصر field_id و method_id باید به کلاس تعریف‌کننده یکسانی ارجاع دهند.

قالب encoded_field

قالب encoded_method

type_list

ارجاع‌شده از class_def_item و proto_id_item

در بخش داده‌ها نشان داده می‌شود

تراز: ۴ بایت

قالب type_item

code_item

ارجاع‌شده از encoded_method

در بخش داده‌ها نشان داده می‌شود

تراز: ۴ بایت

قالب 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 نشان‌دهنده جبران دستورالعمل در insns_item مرتبط در واحدهای کد ۱۶ بیتی است. ثبت address از 0 در ابتدای هر توالی debug_info شروع می‌شود و فقط باید به‌صورت یکنواخت افزایش یابد. ثبت line نشان می‌دهد که شماره خط منبع باید با ورودی جدول موقعیت‌های بعدی که توسط ماشین حالت منتشر می‌شود مرتبط باشد. این مقدار در سرایند توالی مقداردهی اولیه می‌شود و ممکن است در جهت مثبت یا منفی تغییر کند، اما هرگز نباید کمتر از 1 باشد. ثبت source_file نشان‌دهنده فایل منبعی است که ورودی‌های شماره خط به آن ارجاع می‌دهند. با مقدار source_file_idx در class_def_item مقداردهی اولیه می‌شود. دو متغیر دیگر، 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

در بخش داده‌ها نشان داده می‌شود

تراز: ۴ بایت

توجه: همه نمونه‌های field_id و method_id عناصر باید به یک کلاس تعریف‌کننده ارجاع دهند.

قالب field_annotation

قالب method_annotation

قالب parameter_annotation

annotation_set_ref_list

ارجاع‌شده از parameter_annotations_item

در بخش داده‌ها نشان داده می‌شود

تراز: ۴ بایت

قالب annotation_set_ref_item

annotation_set_item

ارجاع‌شده از annotations_directory_item،‏ field_annotations_item،‏ method_annotations_item، و annotation_set_ref_item

در بخش داده‌ها نشان داده می‌شود

تراز: ۴ بایت

قالب annotation_off_item

مورد_گزارمان

ارجاع‌شده از annotation_set_item

در بخش داده‌ها نشان داده می‌شود

تراز: هیچ (تراز بایت)

مقادیر رؤیت‌پذیری

این‌ها گزینه‌های فیلد visibility در annotation_item هستند:

encoded_array_item

ارجاع‌شده از class_def_item

در بخش داده‌ها نشان داده می‌شود

تراز: هیچ (تراز بایت)

hiddenapi_class_data_item

این بخش حاوی داده‌های مربوط به میاناهای محدودشده‌ای است که هر کلاس استفاده می‌کند.

توجه: ویژگی میانای برنامه‌سازی کاربردی پنهان در Android 10.0 معرفی شد و فقط برای فایل‌های DEX کلاس‌ها در مسیر کلاس راه‌اندازی قابل‌اجرا است. فهرست پرچم‌های شرح‌داده‌شده در زیر ممکن است در نسخه‌های آینده Android گسترش یابد. برای اطلاعات بیشتر، محدودیت‌های مربوط به میاناهای غیر کیت توسعه نرم‌افزار را ببینید.

انواع پرچم محدودیت:

حاشیه‌نویسی‌های سیستم

حاشیه‌نویسی‌های سیستم برای نمایش بخش‌های مختلف اطلاعات بازتابی درباره کلاس‌ها (و روش‌ها و فیلدها) استفاده می‌شود. این اطلاعات معمولاً فقط به‌طور غیرمستقیم توسط کد مشتری (غیرسیستم) قابل دسترسی است.

گزارمان‌های سیستم در فایل‌های .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 نسخه ۷.۱ اضافه شده است. وجود آن در نسخه‌های پخش قدیمی‌تر Android نادیده گرفته خواهد شد.

حاشیه‌نویسی MethodParameters اختیاری است و می‌تواند برای ارائه فراداده پارامتر مانند نام پارامتر و اصلاح‌کننده استفاده شود.

وقتی فراداده پارامتر در زمان اجرا موردنیاز نباشد، می‌توان حاشیه‌نویسی را به‌طور ایمن از روش یا سازنده حذف کرد. java.lang.reflect.Parameter.isNamePresent() را می‌توان برای بررسی اینکه آیا فراداده برای پارامتری وجود دارد یا نه استفاده کرد، و روش‌های بازتاب مرتبط مانند java.lang.reflect.Parameter.getName() در زمان اجرا، اگر اطلاعات وجود نداشته باشد، به رفتار پیش‌فرض برمی‌گردند.

هنگام افزودن فراداده پارامتر، کامپایلرها باید اطلاعات مربوط به کلاس‌های تولیدشده مثل شمارشی‌ها را اضافه کنند، زیرا فراداده پارامتر شامل این می‌شود که آیا پارامتر مصنوعی یا اجباری است یا نه.

یک شرح 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 به هر کلاس، فیلد، یا روشی که براساس نوع پیچیده‌تری تعریف شده است که با type_id_item قابل‌نمایش نیست پیوست می‌شود. قالب .dex قالب امضاها را تعریف نمی‌کند؛ صرفاً برای این است که بتواند هر امضایی را که زبان منبع برای پیاده‌سازی موفق معناشناسی آن زبان نیاز دارد نشان دهد. به‌همین دلیل، امضاها معمولاً توسط پیاده‌سازی‌های ماشین مجازی تجزیه (یا درستی‌سنجی) نمی‌شوند. امضاها به‌سادگی به میاناهای برنامه‌سازی کاربردی و ابزارهای سطح بالاتر (مانند اشکال‌زداها) واگذار می‌شوند. بنابراین، هرگونه استفاده از امضا باید به‌گونه‌ای نوشته شود که هیچ فرضی درباره دریافت امضاهای معتبر نداشته باشد و صریحاً خود را دربرابر احتمال مواجهه با امضای نامعتبر ازنظر نحوی محافظت کند.

چون رشته‌های امضا معمولاً محتوای تکراری زیادی دارند، حاشیه‌نویسی Signature به‌عنوان آرایه‌ای از رشته‌ها تعریف می‌شود که در آن عناصر تکراری طبیعتاً به همان داده‌های اساسی ارجاع می‌دهند و امضا به‌عنوان الحاق همه رشته‌ها در آرایه درنظر گرفته می‌شود. هیچ قانونی درباره نحوه جدا کردن امضا به رشته‌های جداگانه وجود ندارد؛ این کاملاً به ابزارهایی که فایل‌های .dex را تولید می‌کنند بستگی دارد.

dalvik.annotation.Throws

در روش‌ها نشان داده می‌شود

یک Throws گزارمان به هر روشی که اعلام شده است یک یا چند نوع استثنا را ایجاد می‌کند پیوست می‌شود.