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

این سند طرح و محتویات فایل‌های .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 همه عناصر باید به همان کلاس تعریف کننده مراجعه کنند.

قالب ended_field

قالب ended_method

لیست_ه

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

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

تراز: 4 بایت

قالب_تیم

code_item

ارجاع شده از encoded_method

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

تراز: 4 بایت

قالب try_item

قالب ended_catch_handler_list

قالب ended_catch_handler

قالب ended_type_addr_pair

debug_info_item

از code_item ارجاع شده است

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

تراز: هیچکدام (بایت هماهنگ)

هر debug_info_item یک دستگاه حالت کدگذاری شده با کادوی با الهام از DWARF3 را تعریف می کند که در صورت تفسیر ، جدول موقعیت ها و (به طور بالقوه) اطلاعات متغیر محلی را برای یک code_item منتشر می کند. دنباله با یک هدر با طول متغیر شروع می شود (طول آن به تعداد پارامترهای روش بستگی دارد) ، توسط دستگاه های دستگاه BYTECODES دنبال می شود و با یک بایت DBG_END_SEQUENCE به پایان می رسد.

دستگاه دولتی از پنج ثبت نام تشکیل شده است. ثبت address نشان دهنده جبران دستورالعمل در insns_item مرتبط در واحدهای کد 16 بیتی است. ثبت address در ابتدای هر دنباله debug_info از 0 شروع می شود و فقط باید یکنواخت افزایش یابد. ثبت 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

قالب_نوتینگ

فرمت پارامتر_نوتیک

Annotation_Set_Ref_List

ارجاع شده از parameter_annotations_item

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

تراز: 4 بایت

Annotation_set_ref_item فرمت

Annotation_set_item

ارجاع شده از Annotations_directory_item ، field_annotations_item ، method_annotations_item ، و حاشیه نویسی_Set_Ref_Item

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

تراز: 4 بایت

Annotation_Off_Item

حاشیه نویسی_ITEM

ارجاع شده از Annotation_set_item

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

تراز: هیچکدام (بایت هماهنگ)

مقادیر دید

این گزینه ها برای قسمت visibility در annotation_item است:

ended_array_item

ارجاع شده از class_def_item

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

تراز: هیچکدام (بایت هماهنگ)

hiddenapi_class_data_item

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

توجه: ویژگی API پنهان در Android 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

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

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

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

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

dalvik.annotation.throws

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

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