Формат исполняемого файла Dalvik

В этом документе описывается структура и содержимое файлов .dex , которые используются для хранения набора определений классов и связанных с ними дополнительных данных.

Руководство по типам

ЛЕБ128

LEB128 (« Little - Endian Base 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 формата была добавлена ​​в выпуске 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 (ноябрь – декабрь 2007 г.), а версия 013 использовалась для выпусков M5 платформы Android (февраль – март 2008 г.). В некоторых отношениях эти более ранние версии формата существенно отличаются от версии, описанной в этом документе.

ENDIAN_CONSTANT и REVERSE_ENDIAN_CONSTANT

Встроено в header_item

Константа ENDIAN_CONSTANT используется для указания порядка байтов файла, в котором она находится. Хотя стандартный формат .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 .

Модифицированная кодировка 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 — это декодировать их посимвольно и сравнить декодированные значения. (Однако возможны и более умные реализации.)

Дополнительную информацию о кодировке символов см. в стандарте Unicode . MUTF-8 на самом деле ближе к (относительно менее известной) кодировке CESU-8, чем к UTF-8 как таковой.

кодировка encoded_value

Встроен в annotation_element и encoded_array_item.

encoded_value — это закодированный фрагмент (почти) произвольных иерархически структурированных данных. Кодировка должна быть компактной и простой для анализа.

Форматы значений

формат закодированного_массива

формат закодированной_аннотации

формат annotation_element

Строковый синтаксис

В файле .dex есть несколько типов элементов, которые в конечном итоге относятся к строке. Следующие определения в стиле BNF указывают приемлемый синтаксис для этих строк.

Простое имя

SimpleName является основой синтаксиса имен других вещей. Формат .dex предоставляет здесь достаточную свободу действий (намного большую, чем большинство распространенных исходных языков). Короче говоря, простое имя состоит из любого буквенного символа или цифры младшего ASCII, нескольких конкретных символов младшего ASCII и большинства кодовых точек, отличных от ASCII, которые не являются управляющими, пробелами или специальными символами. Начиная с версии 040 формат дополнительно допускает пробелы (категория Unicode Zs ). Обратите внимание, что суррогатные кодовые точки (в диапазоне U+d800 … U+dfff ) не считаются допустимыми символами имени сами по себе, но допустимы дополнительные символы Unicode (которые представлены последней альтернативой правила для SimpleNameChar ), и они должны быть представлены в файле как пары суррогатных кодовых точек в кодировке MUTF-8.

Имя участника

используется field_id_item и Method_id_item

MemberName — это имя члена класса, членами которого являются поля, методы и внутренние классы.

ПолноеИмяКласса

FullClassName — это полное имя класса, включающее необязательный спецификатор пакета, за которым следует обязательное имя.

Типдескриптор

Используется type_id_item

TypeDescriptor — это представление любого типа, включая примитивы, классы, массивы и void . Ниже описано значение различных версий.

КоротышкаДескриптор

Используется proto_id_item

ShortyDescriptor — это краткое представление прототипа метода, включая типы возвращаемых значений и параметров, за исключением того, что нет различия между различными типами ссылок (класс или массив). Вместо этого все ссылочные типы представлены одним символом 'L' .

Семантика дескриптора типа

В этом смысл каждого из вариантов TypeDescriptor .

Предметы и связанные структуры

В этом разделе приведены определения для каждого элемента верхнего уровня, который может присутствовать в файле .dex .

заголовок_элемент

Появляется в разделе заголовка

Выравнивание: 4 байта

список_карт

Появляется в разделе данных

Ссылка из 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 байта

метод_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

Типы параметров любых дополнительных аргументов определяются по их постоянным значениям.

метод_handle_item

Появляется в разделе Method_handles.

Выравнивание: 4 байта

Коды типа метода

class_data_item

Ссылка на class_def_item

Появляется в разделе данных

Выравнивание: нет (выровненная байтовая)

Примечание. Все экземпляры Elements ' field_id и method_id должны относиться к одному и тому же определяющему классу.

Формат кодировки

Кодированный формат

type_list

Ссылка на Class_def_item и Proto_id_item

Появляется в разделе данных

Выравнивание: 4 байта

формат type_item

code_item

Ссылка на кодировку

Появляется в разделе данных

Выравнивание: 4 байта

Format try_item

Encoded_catch_handler_list Format

Encoded_catch_handler Format

incoded_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 .

Заголовок заключается в следующем:

Значения кода байта следующие:

Специальные опкоды

Опыты со значениями между 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 байта

Примечание. Все экземпляры Elements ' field_id и method_id должны относиться к одному и тому же определяющему классу.

Field_annotation Format

method_annotation format

FARATER_ANNOTATION FORMAT

Annotation_set_ref_list

Ссылка на Parameter_annotations_item

Появляется в разделе данных

Выравнивание: 4 байта

Annotation_set_ref_item Format

Annotation_set_item

Ссылка на Annotations_directory_item, Field_annotations_item, method_annotations_item и Annotation_set_ref_item

Появляется в разделе данных

Выравнивание: 4 байта

Annotation_off_item Format

Annotation_Item

Ссылка на Annotation_set_item

Появляется в разделе данных

Выравнивание: нет (выровненная байтовая)

Значения видимости

Это варианты поля visibility в annotation_item :

Encoded_array_item

Ссылка на class_def_item

Появляется в разделе данных

Выравнивание: нет (выровненная байтовая)

hiddenapi_class_data_item

Этот раздел содержит данные о ограниченных интерфейсах, используемых каждым классом.

ПРИМЕЧАНИЕ. Функция скрытой API была введена в Android 10.0 и применима только к файлам DEX классов в пути класса загрузки. Список флагов, описанных ниже, может быть расширен в будущих выпусках Android. Для получения дополнительной информации см. Ограничения на не-SDK-интерфейсы .

Ограничение типы флага:

Системные аннотации

Системные аннотации используются для представления различных фрагментов рефлексивной информации о классах (и методах и полях). Эта информация, как правило, доступна только косвенно по клиентскому (несистемному) коду.

Системные аннотации представлены в файлах .dex в виде аннотаций с видимостью, установленными на VISIBILITY_SYSTEM .

dalvik.annotation.annotationdefault

Появляется на методах в интерфейсах аннотации

Аннотация AnnotationDefault прикреплена к каждому интерфейсу аннотации, который хочет указать привязки по умолчанию.

dalvik.annotation.inclosingclass

Появляется на классах

Аннотация EnclosingClass прилагается к каждому классу, который либо определяется как член другого класса, как таковой, либо анонимна, но не определяется в теле метода (например, синтетический внутренний класс). Каждый класс, у которого есть эта аннотация, также должен иметь аннотацию InnerClass . Кроме того, класс не должен иметь как EnclosingClass , так и аннотацию EnclosingMethod .

dalvik.annotation.inclosingmethod

Появляется на классах

Аннотация EnclosingMethod прикреплена к каждому классу, который определяется внутри тела метода. Каждый класс, у которого есть эта аннотация, также должен иметь аннотацию InnerClass . Кроме того, класс не должен иметь как EnclosingClass , так и аннотацию EnclosingMethod .

dalvik.annotation.innerclass

Появляется на классах

Аннотация InnerClass прикреплена к каждому классу, который определяется в лексическом объеме определения другого класса. Любой класс, который имеет эту аннотацию, также должен иметь либо аннотацию EnclosingClass , либо аннотация EnclosingMethod .

dalvik.annotation.memberclasses

Появляется на классах

Аннотация MemberClasses прилагается к каждому классу, который объявляет классы участников. (Класс участников - это прямой внутренний класс, который имеет имя.)

dalvik.annotation.methodparameters

Появляется на методах

Примечание. Эта аннотация была добавлена ​​после Android 7.1. Его присутствие в более ранних выпусках Android будет проигнорировано.

Аннотация MethodParameters является необязательным и может использоваться для предоставления параметров метаданных, таких как имена параметров и модификаторы.

Аннотация может быть безопасно пропущена из метода или конструктора, когда метаданные параметра не требуются во время выполнения. java.lang.reflect.Parameter.isNamePresent() может использоваться для проверки того, присутствуют ли метаданные для параметра, и связанные с ними методы отражения, такие как java.lang.reflect.Parameter.getName() вернутся к поведению по умолчанию во время выполнения. Если информация отсутствует.

При включении метаданных параметров компиляторы должны включать информацию для сгенерированных классов, таких как перечисление, поскольку метаданные параметры включают, является ли параметр синтетическим или обязательным.

Аннотация MethodParameters описывает только отдельные параметры метода. Следовательно, компиляторы могут полностью пропустить аннотацию для конструкторов и методов, которые не имеют параметров, ради эффективности размера кода и времени выполнения.

Массивы, зарегистрированные ниже, должны быть тем же размером, что и для структуры Dex 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 также не будет включать какую -либо информацию о параметрах приемника типа, которые не существуют в фактической подписи метода.

Dalvik.annotation.Signature

Появляется на классах, полях и методах

Аннотация Signature прикреплена к каждому классу, полю или методу, который определяется в терминах более сложного типа, чем представляется type_id_item . Формат .dex не определяет формат для подписей; Он просто предназначен для того, чтобы иметь возможность представлять любые подписи, которые требуют исходного языка для успешной реализации семантики этого языка. Таким образом, подписи, как правило, не проанализируются (или проверяются) с помощью реализаций виртуальных машин. Подписи просто передаются API и инструментам более высокого уровня (например, отладчики). Следовательно, любое использование подписи должно быть написано, чтобы не делать никаких предположений о получении только действительных подписей, явных охраняющихся от возможности столкновения с синтаксически недействительной.

Поскольку строки подписи, как правило, имеют много дублированного контента, аннотация Signature определяется как массив строк, где дублированные элементы естественным образом относятся к одни и те же основные данные, и подпись рассматривается как сознание всех строк в массиве . Нет никаких правил о том, как разместить подпись в отдельные строки; Это полностью зависит от инструментов, которые генерируют файлы .dex .

dalvik.annotation.throws

Появляется на методах

Аннотация Throws прикреплена к каждому методу, который объявляется, чтобы бросить один или несколько типов исключений.