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

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

رمزگذاری MUTF-8 (تغییر یافته 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. A method type corresponding to the type of the method name to be resolved (VALUE_METHOD_TYPE).

Any additional arguments are constant values passed to the bootstrap linker method. These arguments are passed in order and without any type conversions.

The method handle representing the bootstrap linker method must have return type java.lang.invoke.CallSite . The first three parameter types are:

1. java.lang.invoke.Lookup
2. java.lang.String
3. java.lang.invoke.MethodType

The parameter types of any additional arguments are determined from their constant values.

method_handle_item

appears in the method_handles section

alignment: 4 bytes

Method Handle Type Codes

class_data_item

referenced from class_def_item

appears in the data section

alignment: none (byte-aligned)

Note: All elements' field_id s and method_id s must refer to the same defining class.

encoded_field format

encoded_method format

type_list

referenced from class_def_item and proto_id_item

appears in the data section

alignment: 4 bytes

type_item format

code_item

referenced from encoded_method

appears in the data section

alignment: 4 bytes

try_item format

encoded_catch_handler_list format

encoded_catch_handler format

encoded_type_addr_pair format

debug_info_item

referenced from code_item

appears in the data section

alignment: none (byte-aligned)

Each debug_info_item defines a DWARF3-inspired byte-coded state machine that, when interpreted, emits the positions table and (potentially) the local variable information for a code_item . The sequence begins with a variable-length header (the length of which depends on the number of method parameters), is followed by the state machine bytecodes, and ends with an DBG_END_SEQUENCE byte.

The state machine consists of five registers. The address register represents the instruction offset in the associated insns_item in 16-bit code units. The address register starts at 0 at the beginning of each debug_info sequence and must only monotonically increase. The line register represents what source line number should be associated with the next positions table entry emitted by the state machine. It is initialized in the sequence header, and may change in positive or negative directions but must never be less than 1 . The source_file register represents the source file that the line number entries refer to. It is initialized to the value of source_file_idx in class_def_item . The other two variables, prologue_end and epilogue_begin , are boolean flags (initialized to false ) that indicate whether the next position emitted should be considered a method prologue or epilogue. The state machine must also track the name and type of the last local variable live in each register for the DBG_RESTART_LOCAL code.

The header is as follows:

The byte code values are as follows:

Special opcodes

Opcodes with values between 0x0a and 0xff (inclusive) move both the line and address registers by a small amount and then emit a new position table entry. The formula for the increments are as follows:

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

referenced from class_def_item

appears in the data section

alignment: 4 bytes

Note: All elements' field_id s and method_id s must refer to the same defining class.

field_annotation format

method_annotation format

parameter_annotation format

annotation_set_ref_list

referenced from parameter_annotations_item

appears in the data section

alignment: 4 bytes

annotation_set_ref_item format

annotation_set_item

referenced from annotations_directory_item, field_annotations_item, method_annotations_item, and annotation_set_ref_item

appears in the data section

alignment: 4 bytes

annotation_off_item format

annotation_item

referenced from annotation_set_item

appears in the data section

alignment: none (byte-aligned)

Visibility values

These are the options for the visibility field in an annotation_item :

encoded_array_item

referenced from class_def_item

appears in the data section

alignment: none (byte-aligned)

hiddenapi_class_data_item

This section contains data on restricted interfaces used by each class.

Note: The hidden API feature was introduced in Android 10.0 and is only applicable to the DEX files of classes in the boot class path. The list of flags described below may be extended in the future releases of Android. For more information, see restrictions on non-SDK interfaces .

Restriction flag types:

System annotations

System annotations are used to represent various pieces of reflective information about classes (and methods and fields). This information is generally only accessed indirectly by client (non-system) code.

System annotations are represented in .dex files as annotations with visibility set to VISIBILITY_SYSTEM .

dalvik.annotation.AnnotationDefault

appears on methods in annotation interfaces

An AnnotationDefault annotation is attached to each annotation interface which wishes to indicate default bindings.

dalvik.annotation.EnclosingClass

appears on classes

An EnclosingClass annotation is attached to each class which is either defined as a member of another class, per se, or is anonymous but not defined within a method body (eg, a synthetic inner class). Every class that has this annotation must also have an InnerClass annotation. Additionally, a class must not have both an EnclosingClass and an EnclosingMethod annotation.

dalvik.annotation.EnclosingMethod

appears on classes

An EnclosingMethod annotation is attached to each class which is defined inside a method body. Every class that has this annotation must also have an InnerClass annotation. Additionally, a class must not have both an EnclosingClass and an EnclosingMethod annotation.

dalvik.annotation.InnerClass

appears on classes

An InnerClass annotation is attached to each class which is defined in the lexical scope of another class's definition. Any class which has this annotation must also have either an EnclosingClass annotation or an EnclosingMethod annotation.

dalvik.annotation.MemberClasses

appears on classes

A MemberClasses annotation is attached to each class which declares member classes. (A member class is a direct inner class that has a name.)

dalvik.annotation.MethodParameters

appears on methods

Note: This annotation was added after Android 7.1. Its presence on earlier Android releases will be ignored.

A MethodParameters annotation is optional and can be used to provide parameter metadata such as parameter names and modifiers.

The annotation can be omitted from a method or constructor safely when the parameter metadata is not required at runtime. java.lang.reflect.Parameter.isNamePresent() can be used to check whether metadata is present for a parameter, and the associated reflection methods such as java.lang.reflect.Parameter.getName() will fall back to default behavior at runtime if the information is not present.

When including parameter metadata, compilers must include information for generated classes such as enums, since the parameter metadata includes whether or not a parameter is synthetic or mandated.

A MethodParameters annotation describes only individual method parameters. Therefore, compilers may omit the annotation entirely for constructors and methods that have no parameters, for the sake of code-size and runtime efficiency.

The arrays documented below must be the same size as for the method_id_item dex structure associated with the method, otherwise a java.lang.reflect.MalformedParametersException will be thrown at runtime.

That is: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size must be the same as names().length and accessFlags().length .

Because MethodParameters describes all formal method parameters, even those not explicitly or implicitly declared in source code, the size of the arrays may differ from the Signature or other metadata information that is based only on explicit parameters declared in source code. MethodParameters will also not include any information about type annotation receiver parameters that do not exist in the actual method signature.

dalvik.annotation.Signature

appears on classes, fields, and methods

A Signature annotation is attached to each class, field, or method which is defined in terms of a more complicated type than is representable by a type_id_item . The .dex format does not define the format for signatures; it is merely meant to be able to represent whatever signatures a source language requires for successful implementation of that language's semantics. As such, signatures are not generally parsed (or verified) by virtual machine implementations. The signatures simply get handed off to higher-level APIs and tools (such as debuggers). Any use of a signature, therefore, should be written so as not to make any assumptions about only receiving valid signatures, explicitly guarding itself against the possibility of coming across a syntactically invalid signature.

Because signature strings tend to have a lot of duplicated content, a Signature annotation is defined as an array of strings, where duplicated elements naturally refer to the same underlying data, and the signature is taken to be the concatenation of all the strings in the array. There are no rules about how to pull apart a signature into separate strings; that is entirely up to the tools that generate .dex files.

dalvik.annotation.Throws

appears on methods

A Throws annotation is attached to each method which is declared to throw one or more exception types.