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

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

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

ЛЕБ128

LEB128 (« Little -Endian Base 128 ») — это код переменной длины для произвольных знаковых и беззнаковых целых чисел. Формат был заимствован из спецификации DWARF3 . В .dex файле LEB128 используется только для кодирования 32-битных чисел.

Каждое закодированное значение LEB128 состоит из одного-пяти байтов, которые вместе представляют одно 32-битное значение. У каждого байта установлен старший бит, за исключением последнего байта в последовательности, у которого старший бит сброшен. Остальные семь бит каждого байта составляют полезную нагрузку: младшие семь битов количества находятся в первом байте, следующие семь — во втором байте и так далее. В случае знакового LEB128 ( sleb128 ) старший бит полезной нагрузки последнего байта в последовательности дополняется знаком для получения конечного значения. В случае беззнакового значения ( uleb128 ) любые биты, не представленные явно, интерпретируются как 0 .

Вариант uleb128p1 используется для представления знакового значения, где представление представляет собой значение плюс один, закодированное как uleb128 . Это позволяет кодировать -1 (альтернативно рассматриваемое как беззнаковое значение 0xffffffff ) — но не любое другое отрицательное число — одним байтом и полезно именно в тех случаях, когда представляемое число должно быть либо неотрицательным, либо -1 (или 0xffffffff ), и когда не допускаются другие отрицательные значения (или когда большие беззнаковые значения вряд ли понадобятся).

Вот несколько примеров форматов:

Расположение файла

Формат контейнера

В версии 41 представлен новый формат контейнера для данных 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, поддерживающем формат контейнера .

Примечание: Поддержка версии 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 (ноябрь–декабрь 2007 г.), а версия 013 — для релизов M5 платформы Android (февраль–март 2008 г.). В ряде аспектов эти более ранние версии формата существенно отличаются от версии, описанной в данном документе.

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

определения 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, а не более прямой формат кодирования для символов Unicode.

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

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

формат encoded_array

формат encoded_annotation

формат annotation_element

Синтаксис строки

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

SimpleName

SimpleName является основой синтаксиса имён других вещей. Формат .dex допускает здесь значительную свободу (гораздо большую, чем большинство распространённых исходных языков). Вкратце, простое имя состоит из любого алфавитного символа или цифры из набора low-ASCII, нескольких определённых символов из набора low-ASCII и большинства кодовых точек, не входящих в набор ASCII, которые не являются управляющими, пробелами или специальными символами. Начиная с версии 040 формат дополнительно допускает символы пробела (категория Unicode Zs ). Обратите внимание, что суррогатные кодовые точки (в диапазоне U+d800 … U+dfff ) сами по себе не считаются допустимыми символами имён , но допустимы дополнительные символы Unicode (которые представлены последней альтернативой правила для 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 .

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

Появляется в заголовочном разделе

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

список_карт

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

Ссылка из header_item

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

Это список всего содержимого файла, упорядоченный по порядку. Он содержит некоторую избыточность относительно header_item , но предназначен для удобства использования в качестве итератора по всему файлу. Заданный тип должен встречаться в карте не более одного раза, но нет ограничений на порядок, в котором могут появляться типы, за исключением ограничений, накладываемых остальной частью формата (например, сначала должен идти раздел header , затем раздел string_ids и т. д.). Кроме того, записи карты должны быть упорядочены по начальному смещению и не должны перекрываться.

формат map_item

Тип кодов

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

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

метод_handle_item

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

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

Коды типов дескрипторов методов

class_data_item

Ссылка из class_def_item

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

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

Примечание. Экземпляры field_id и method_id всех элементов должны ссылаться на один и тот же определяющий класс.

формат закодированного_поля

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

список_типов

Ссылка на 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 .

Заголовок следующий:

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

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

Коды операций со значениями от 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 всех элементов должны ссылаться на один и тот же определяющий класс.

формат поля_аннотации

формат метод_аннотации

формат параметра_аннотации

annotation_set_ref_list

Ссылка на параметр_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_set_item

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

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

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

Это параметры поля visibility в annotation_item :

encoded_array_item

Ссылка из class_def_item

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

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

скрытыйapi_class_data_item

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

Примечание. Функция скрытого API была представлена в Android 10.0 и применима только к файлам DEX классов в пути к классам загрузки. Список флагов, описанный ниже, может быть расширен в будущих выпусках Android. Дополнительные сведения см. в разделе ограничения на интерфейсы, не относящиеся к 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. Его присутствие в более ранних версиях 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 прикрепляется к каждому методу, который объявлен как создающий один или несколько типов исключений.