فرمت اجرایی دالویک

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

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

LEB128

LEB128 (" L ittle- Endian B ase 128 ") یک رمزگذاری با طول متغیر برای مقادیر عدد صحیح با امضا یا بدون علامت دلخواه است. فرمت از مشخصات DWARF3 به عاریت گرفته شده است. در یک فایل .dex ، LEB128 فقط برای رمزگذاری مقادیر 32 بیتی استفاده می شود.

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

نوع uleb128p1 برای نشان دادن یک مقدار علامت‌دار استفاده می‌شود، جایی که نمایش مقدار به اضافه یک به‌عنوان uleb128 کدگذاری شده است. این باعث می شود رمزگذاری -1 (که به عنوان مقدار بدون علامت 0xffffffff در نظر گرفته می شود) - اما هیچ عدد منفی دیگری - یک بایت واحد نیست، و دقیقاً در مواردی مفید است که عدد ارائه شده باید غیر منفی یا -1 باشد (یا 0xffffffff )، و در جایی که هیچ مقدار منفی دیگری مجاز نیست (یا جایی که بعید است به مقادیر بزرگ بدون علامت نیاز باشد).

در اینجا چند نمونه از فرمت ها آورده شده است:

طرح بندی فایل

بیت فیلد، رشته و تعاریف ثابت

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"

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

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

توجه: پشتیبانی از فرمت 037 در نسخه اندروید 7.0 اضافه شده است. قبل از نسخه 037 اکثر نسخه های اندروید از نسخه 035 فرمت استفاده می کردند. تنها تفاوت بین نسخه های 035 و 037 اضافه کردن روش های پیش فرض و تنظیم invoke است.

توجه: حداقل چند نسخه قبلی این قالب در نسخه‌های نرم‌افزاری عمومی در دسترس استفاده شده است. برای مثال، نسخه 009 برای نسخه های M3 پلتفرم اندروید (نوامبر تا دسامبر 2007) و نسخه 013 برای نسخه های M5 پلتفرم اندروید (فوریه تا مارس 2008) استفاده شد. از چند جهت، این نسخه‌های قبلی فرمت به طور قابل توجهی با نسخه توصیف‌شده در این سند متفاوت است.

ENDIAN_CONSTANT و REVERSE_ENDIAN_CONSTANT

در header_item تعبیه شده است

ثابت ENDIAN_CONSTANT برای نشان دادن endianness فایلی که در آن یافت می شود استفاده می شود. اگرچه فرمت استاندارد .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 معمولی، نتیجه فراخوانی تابع استاندارد 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

فرمت annotation_element

نحو رشته

انواع مختلفی از آیتم در یک فایل .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

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 ظاهر شود. بخش و غیره). علاوه بر این، ورودی های نقشه باید بر اساس افست اولیه مرتب شوند و نباید با هم تداخل داشته باشند.

قالب نقشه_آیتم

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

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 نشان دهنده تعدیل دستورالعمل در insns_item مرتبط در واحدهای کد 16 بیتی است. ثبت address از 0 در ابتدای هر دنباله debug_info شروع می شود و فقط باید به طور یکنواخت افزایش یابد. ثبت line نشان دهنده شماره خط منبع است که باید با ورودی جدول موقعیت های بعدی منتشر شده توسط ماشین حالت مرتبط باشد. در هدر دنباله مقداردهی اولیه می شود و ممکن است در جهت های مثبت یا منفی تغییر کند اما هرگز نباید کمتر از 1 باشد. رجیستر source_file نشان دهنده فایل منبعی است که ورودی های شماره خط به آن اشاره می کنند. به مقدار source_file_idx در class_def_item مقداردهی اولیه می شود. دو متغیر دیگر، prologue_end و epilogue_begin ، پرچم‌های بولی هستند (ابتدایی به false ) که نشان می‌دهند که آیا موقعیت بعدی منتشر شده باید به عنوان یک پیش درآمد روش در نظر گرفته شود یا پایان. ماشین حالت همچنین باید نام و نوع آخرین متغیر محلی زنده را در هر ثبات برای کد DBG_RESTART_LOCAL ردیابی کند.

سربرگ به شرح زیر است:

مقادیر کد بایت به شرح زیر است:

کدهای عملیاتی ویژه

Opcodes با مقادیر بین 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

فرمت متد_ حاشیه نویسی

فرمت 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 ارجاع شده است

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

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

مقادیر دید

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

encoded_array_item

ارجاع شده از class_def_item

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

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

hiddenapi_class_data_item

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

نکته: قابلیت hidden API در اندروید 10.0 معرفی شده است و فقط برای فایل های DEX کلاس های موجود در مسیر کلاس بوت قابل اجرا است. فهرست پرچم‌هایی که در زیر توضیح داده شده است ممکن است در نسخه‌های آینده اندروید گسترش یابد. برای اطلاعات بیشتر، محدودیت‌ها در رابط‌های غیر 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

روی روش ها ظاهر می شود

توجه: این حاشیه بعد از اندروید 7.1 اضافه شده است. وجود آن در نسخه های قبلی اندروید نادیده گرفته می شود.

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

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

هنگامی که فراداده پارامتر را شامل می شود، کامپایلرها باید اطلاعاتی را برای کلاس های تولید شده مانند enums داشته باشند، زیرا فراداده پارامتر شامل ترکیبی یا اجباری بودن یک پارامتر است.

حاشیه نویسی 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 همه پارامترهای روش رسمی را توصیف می کند، حتی آنهایی که به طور صریح یا ضمنی در کد منبع اعلام نشده اند، اندازه آرایه ها ممکن است با Signature یا سایر اطلاعات فراداده که فقط بر اساس پارامترهای صریح اعلام شده در کد منبع است، متفاوت باشد. MethodParameters همچنین شامل هیچ اطلاعاتی در مورد پارامترهای گیرنده حاشیه نویسی نوع که در امضای روش واقعی وجود ندارد، نخواهد بود.

dalvik.annotation.Signature

در کلاس ها، فیلدها و متدها ظاهر می شود

یک حاشیه نویسی Signature به هر کلاس، فیلد یا متد متصل می شود که بر حسب نوع پیچیده تری نسبت به نوع قابل نمایش توسط type_id_item تعریف شده است. فرمت .dex قالبی را برای امضاها تعریف نمی کند. منظور این است که بتواند هر گونه امضایی را که یک زبان مبدأ برای اجرای موفقیت آمیز معناشناسی آن زبان نیاز دارد، نشان دهد. به این ترتیب، امضاها معمولاً توسط پیاده سازی ماشین مجازی تجزیه (یا تأیید) نمی شوند. امضاها به سادگی به APIها و ابزارهای سطح بالاتر (مانند دیباگرها) واگذار می شوند. بنابراین، هرگونه استفاده از امضا باید به گونه ای نوشته شود که هیچ گونه فرضی در مورد دریافت امضاهای معتبر نداشته باشد، و صریحاً از خود در برابر احتمال برخورد با امضای نامعتبر از لحاظ نحوی محافظت کند.

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

dalvik.annotation.پرتاب

روی روش ها ظاهر می شود

یک حاشیه نویسی Throws به هر روش متصل است که اعلام می شود یک یا چند نوع استثنا را ایجاد می کند.