Ausführbares Dalvik-Format

In diesem Dokument werden das Layout und der Inhalt von .dex beschrieben. -Dateien, die eine Reihe von Klassendefinitionen und die zugehörigen Zusatzdaten.

Anleitung zu Typen

LEB128

LEB128 ("Little-Endian Base 128") ist ein Codierung mit variabler Länge für beliebige vorzeichenbehaftete oder vorzeichenlose Ganzzahlen Das Format war von DWARF3 übernommen Spezifikation zu ändern. In einer .dex-Datei wird LEB128 ausschließlich für Folgendes verwendet: 32-Bit-Mengen zu codieren.

Jeder LEB128-codierte Wert besteht aus einem bis fünf Byte, die zusammen einen einzelnen 32-Bit-Wert darstellen. Jedes Bei Byte ist das höchstwertige Bit gesetzt, mit Ausnahme des letzten Byte im -Sequenz, deren wichtigstes Bit klar ist. Die verbleibenden 7 Bits von jedem Byte sind Nutzlasten, wobei die niedrigstwertige sieben der Anzahl im ersten Byte, in den nächsten sieben im zweiten Byte Byte usw. Im Fall eines unterzeichneten LEB128 (sleb128) ist das höchstwertige Nutzlast-Bit des letzten Bytes in der Sequenz, um den Endwert zu erzeugen. Im nicht signierten Fall (uleb128), sind alle nicht explizit dargestellten Bits als 0 interpretiert.

Die Variante uleb128p1 wird für ein signiertes Wert, wobei der codierte Wert plus eins dargestellt wird als uleb128. Dadurch wird die Codierung von -1 (alternativ als vorzeichenloser Wert 0xffffffff angesehen) - aber keine andere negative Zahl - ein einzelnes Byte und ist in denen die dargestellte Zahl entweder nicht negativ oder -1 (oder 0xffffffff) sein, und keine anderen negativen Werte zulässig sind (oder große, vorzeichenlose -Werte wahrscheinlich nicht erforderlich sind).

Hier einige Beispiele für Formate:

Dateilayout

Bitfeld-, String- und Konstantendefinitionen

DEX_DATEI_MAGIC

Eingebettet in „header_item“

Das konstante Array/String DEX_FILE_MAGIC ist die Liste der Byte, die am Anfang einer .dex-Datei stehen müssen damit sie als solche erkannt werden. Der Wert ist bewusst enthält einen Zeilenumbruch ("\n" oder 0x0a) und einen Nullbyte ("\0" oder 0x00) enthält, bei der Erkennung bestimmter Arten von Korruption. Der Wert codiert eine Versionsnummer des Formats mit drei Dezimalstellen, was mit der Zeit kontinuierlich zunehmen, während sich das Format weiterentwickelt.

ubyte[8] DEX_FILE_MAGIC = { 0x64 0x65 0x78 0x0a 0x30 0x33 0x39 0x00 }
                        = "dex\n039\0"

Hinweis: Unterstützung für Version 039 des -Format wurde in der Android-Version 9.0 hinzugefügt, in der zwei neue Bytecodes, const-method-handle und const-method-type (Diese werden im Zusammenfassung des Bytecode-Satzes . In Android 10 wird das DEX-Dateiformat durch Version 039 um versteckte Dateien erweitert API-Informationen, die nur für DEX-Dateien im Bootklassenpfad gelten.

Hinweis: Versionsunterstützung 038 des Formats wurden in Android 8.0 hinzugefügt. Veröffentlichung. Version 038 hat neue Bytecodes hinzugefügt (invoke-polymorphic und invoke-custom) und Daten für Methoden-Handles.

Hinweis: Unterstützung für Version 037 von Das Format wurde in der Android-Version 7.0 hinzugefügt. Vor Version 037 am häufigsten -Versionen von Android haben Version 035 des Formats verwendet. Die einzige Unterschied zwischen den Versionen 035 und 037 ist der Hinzufügung von Standardmethoden und Anpassung der invoke.

Hinweis:Einige frühere Versionen dieses Formats wurden in allgemein verfügbaren öffentlichen Software-Releases verwendet werden. Beispiel: Version 009 wurde für die M3-Releases der Android-Plattform (November bis Dezember 2007), und Version 013 wurde für die M5-Releases von Android Plattform (Februar bis März 2008). In mehrfacher Hinsicht haben diese früheren Versionen des Formats erheblich von der hier beschriebenen Version unterscheiden. Dokument.

ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT

Eingebettet in „header_item“

Mit der Konstante ENDIAN_CONSTANT wird angegeben, Endianität der Datei, in der sie gefunden wurde. Obwohl der Standard Das Format von .dex ist Little-Endian, Implementierungen können gewählt werden um Byte-Swapping durchzuführen. Sollte bei einer Implementierung eine Header, dessen endian_tag REVERSE_ENDIAN_CONSTANT ist statt ENDIAN_CONSTANT würde die Datei wissen, für das erwartete Format mit Byte-Swapping durchgeführt wurde.

uint ENDIAN_CONSTANT = 0x12345678;
uint REVERSE_ENDIAN_CONSTANT = 0x78563412;

NO_INDEX

Eingebettet in class_def_item und debug_info_item

Mit der Konstante NO_INDEX wird angegeben, ein Indexwert fehlt.

Hinweis:Dieser Wert ist nicht als 0, da dies normalerweise ein gültiger Index ist.

Der ausgewählte Wert für NO_INDEX ist als einzelnes Byte in der uleb128p1-Codierung darstellbar.

uint NO_INDEX = 0xffffffff;    // == -1 if treated as a signed int

Definitionen für access_flags

Eingebettet in class_def_item, encoded_field, encoded_method und Innenklasse

Bitfelder dieser Flags werden verwendet, um die Barrierefreiheit und Gesamteigenschaften von Klassen und Klassenmitgliedern.

* Nur zulässig für InnerClass-Annotationen, und darf in einem class_def_item nicht aktiv sein.

Geänderte UTF-8-Codierung

Als Nachlass zur Vereinfachung des Legacy-Supports wurde das .dex-Format codiert seine Zeichenfolgendaten in einer De-facto-Standard-Modifizierte UTF-8-Form. auch als MUTF-8 bezeichnet. Dieses Formular entspricht dem Standard-UTF-8-Code, mit folgenden Ausnahmen:

• Es werden nur die Ein-, Zwei- und Drei-Byte-Codierung verwendet.
• Codepunkte im Bereich U+10000... U+10ffff sind als Ersatzwertpaar codiert, das jeweils die als codierter 3-Byte-Wert dargestellt wird.
• Der Codepunkt U+0000 ist in Zwei-Byte-Form codiert.
• Ein einfaches Nullbyte (Wert 0) zeigt das Ende von Einen String, ebenso wie die Interpretation der Standard-C-Sprache.

Die ersten beiden Elemente oben können wie folgt zusammengefasst werden: MUTF-8 ist ein Codierungsformat für UTF-16. Es ist kein direkter Codierungsformat für Unicode-Zeichen verwenden.

Mit den letzten beiden Punkten oben können Sie den Codepunkt U+0000 in einem String und bearbeiten weiterhin als C-ähnlicher String mit Nullabschluss.

Die spezielle Codierung von U+0000 bedeutet jedoch, dass im Gegensatz zu Normal UTF-8, das Ergebnis des Aufrufs der C-Standardfunktion strcmp() für ein Paar von MUTF-8-Strings bedeutet nicht immer, das richtig signierte Ergebnis des Vergleichs von ungleich-Strings anzeigen. Wenn die Reihenfolge (und nicht nur die Gleichheit) ein Problem ist, MUTF-8-Strings lassen sich Zeichen für Zeichen decodieren. und die decodierten Werte vergleichen. (Klügere Implementierungen sind jedoch ebenfalls möglich.)

Weitere Informationen finden Sie im Artikel Das Unicode- Standard. MUTF-8 ist näher an der (weniger bekannten) Codierung. CESU-8 als in UTF-8 nicht als Ganzes betrachtet.

codierte_Wert-Codierung

Eingebettet in „annotation_element“ und „encoded_array_item“

Ein encoded_value ist ein codiertes Teil eines (fast) beliebige hierarchisch strukturierte Daten. Die Codierung soll sowohl kompakt als auch einfach zu parsen sein.

Wertformate

codiertes_Array-Format

encoded_annotation-Format

Format des Anmerkungselements

String syntax

Eine .dex-Datei enthält verschiedene Arten von Elementen, auf eine Zeichenfolge verweisen. Die folgenden Definitionen im BNF-Stil die akzeptable Syntax für diese Zeichenfolgen an.

Einfacher Name

Ein SimpleName ist die Grundlage für die Syntax der Namen anderer Dinge. Das Format .dex ermöglicht eine hohe Breite (deutlich mehr als die meisten Ausgangssprachen). Kurz gesagt: aus ASCII-Schriftzeichen oder Ziffern, und die meisten Nicht-ASCII-Codepunkte, die nicht Steuer-, Leer- oder Sonderzeichen. Ab Version 040 Das Format lässt zusätzlich Leerzeichen (Unicode Zs Kategorie). Beachten Sie, dass Ersatzcodepunkte (im Bereich U+d800 ... U+dfff) sind nicht als gültige Namenszeichen betrachtet, aber Unicode-Zeichen Zeichen gültig sind (gekennzeichnet durch das der Regel für SimpleNameChar). Außerdem sollten sie in einer Datei als Paare von Ersatzcodepunkten im MUTF-8-Format dargestellt. Codierung.

Mitgliedsname

verwendet von „field_id_item“ und „method_id_item“

Ein MemberName ist der Name eines Gruppenmitglieds. -Feldern, Methoden und inneren Klassen.

Vollständiger Klassenname

Ein FullClassName ist ein vollständig qualifizierter Klassenname, einschließlich eines optionaler Paketspezifizierer gefolgt von einem erforderlichen Namen.

Typdeskriptor

Wird von type_id_item verwendet

Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich Primitiven, Klassen, Arrays und void. Siehe unten für die Bedeutung der verschiedenen Versionen.

Kurzbeschreibung

Wird von proto_id_item verwendet

Ein ShortyDescriptor ist die Kurzform einer Methode. Prototyp einschließlich Rückgabe- und Parametertypen, außer dass es keine Unterscheidung zwischen verschiedenen Referenztypen (Klasse oder Array). Stattdessen Alle Referenztypen werden durch ein einzelnes 'L'-Zeichen dargestellt.

TypeDescriptor-Semantik

Dies entspricht der Bedeutung der einzelnen Varianten von TypeDescriptor.

Elemente und verwandte Strukturen

Dieser Abschnitt enthält Definitionen für alle Elemente der obersten Ebene, die kann in einer .dex-Datei enthalten sein.

Header-Element

Erscheint im Kopfzeilenbereich

Ausrichtung: 4 Byte

Kartenliste

Erscheint im Datenbereich

Verweist von „header_item“

Ausrichtung: 4 Byte

Dies ist eine geordnete Liste des gesamten Inhalts einer Datei. Es enthält eine gewisse Redundanz in Bezug auf header_item ist aber für die Iteration über das gesamte -Datei. Ein bestimmter Typ darf höchstens einmal in einer Karte vorkommen, ist die Einschränkung, in welchen Auftragstypen Einschränkungen, die durch das restliche Format (z.B. eine Der Abschnitt header muss zuerst stehen, gefolgt von einem string_ids usw.). Außerdem müssen die Zuordnungseinträge nach anfänglichem Offset sortiert werden und dürfen sich nicht überschneiden.

Format von „map_item“

Typcodes

String_ID_Element

Erscheint im Abschnitt string_ids

Ausrichtung: 4 Byte

string_data_item

Erscheint im Datenbereich

Ausrichtung: keine (byte-orientiert)

type_id_item [Typ_ID_Artikel]

Erscheint im Abschnitt „type_ids“

Ausrichtung: 4 Byte

proto_id_item

Erscheint im Abschnitt „proto_ids“

Ausrichtung: 4 Byte

Feld_ID_Element

Wird im „field_ids“-Abschnitt angezeigt

Ausrichtung: 4 Byte

method_id_item [method_id_item]

Erscheint im Abschnitt method_ids

Ausrichtung: 4 Byte

class_def_item

Wird im Abschnitt class_defs angezeigt

Ausrichtung: 4 Byte

Anruf-ID-Element

Erscheint im Abschnitt „call_site_ids“

Ausrichtung: 4 Byte

Element_der_Anrufwebsite

Erscheint im Datenbereich

Ausrichtung: keine (byte ausgerichtet)

"call_site_item" ist ein codiertes Arrayelement, dessen Elemente den Argumenten entsprechen. einer Bootstrap-Verknüpfungsmethode übergeben. Die ersten drei Argumente sind:

1. Methoden-Handle, das die Bootstrap-Verknüpfungsmethode (VALUE_METHOD_HANDLE) darstellt.
2. Ein Methodenname, den die Bootstrap-Verknüpfung auflösen soll (VALUE_STRING).
3. Methodentyp, der dem Typ des aufzulösenden Methodennamens entspricht (VALUE_METHOD_TYPE)

Alle zusätzlichen Argumente sind konstante Werte, die an die Bootstrap-Verknüpfungsmethode übergeben werden. Diese Argumente sind werden in der richtigen Reihenfolge ohne Typ-Conversions weitergegeben.

Das Methoden-Handle, das die Bootstrap-Verknüpfungsmethode darstellt, muss den Rückgabetyp java.lang.invoke.CallSite haben. Die ersten drei Parametertypen sind:

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

Die Parametertypen zusätzlicher Argumente werden anhand ihrer konstanten Werte bestimmt.

method_handle_item [Methode_Handle_item]

Erscheint im Abschnitt method_handles

Ausrichtung: 4 Byte

Codes der Methoden-Handle-Typen

class_data_item [Klasse_Datenelement]

Von class_def_item referenziert

Erscheint im Datenbereich

Ausrichtung: keine (byte-orientiert)

Hinweis:Das Attribut „Alle Elemente“ field_id und method_id-Instanzen müssen auf dieselbe definierende Klasse verweisen.

codiertes_Feldformat

encoded_method-Format

Typliste

Verweist von class_def_item und proto_id_item

Erscheint im Datenbereich

Ausrichtung: 4 Byte

type_item-Format

Codeelement

Verweist von encoded_method

Erscheint im Datenbereich

Ausrichtung: 4 Byte

„try_item“-Format

Format „codierter_catch_handler_list“

codiertes_Handler-Format

codiertes_type_addr_pair-Format

Debug-Infoelement

Von „code_item“ referenziert

Erscheint im Datenbereich

Ausrichtung: keine (byte-orientiert)

Jeder debug_info_item definiert einen DWARF3-inspirierten byte-codierten Zustandsautomat, der bei Interpretation die Positionen und ggf. auch die Informationen zu den lokalen Variablen code_item. Die Sequenz beginnt mit einer variablen Länge Header (ihre Länge hängt von der Anzahl der Methoden Parameter) gefolgt von den Bytecodes der Zustandsmaschine und endet mit einem DBG_END_SEQUENCE-Byte.

Der Zustandsautomat besteht aus fünf Registern. Die Das Register address steht für den Anweisungs-Offset im verknüpfte insns_item in 16-Bit-Codeeinheiten. Die address-Registrierungen beginnen jeweils um 0 debug_info-Sequenz und darf nur monoton ansteigen. Das line-Register gibt an, welche Quellzeilennummer sollte mit dem Tabelleneintrag für nächste Positionen verknüpft werden, der von Zustandsautomaten. Sie wird im Sequenzheader initialisiert und kann Änderung in positive oder negative Richtungen, darf aber nie kleiner sein als 1 Das source_file-Register steht für die Quelldatei, auf die sich die Einträge mit der Zeilennummer beziehen. Sie ist initialisiert mit Wert von source_file_idx in class_def_item Die anderen beiden Variablen prologue_end und epilogue_begin sind boolesche Flags (mit false), die angeben, ob die nächste Position sollte als Methodenprolog oder Epilog betrachtet werden. Der Zustandsautomat müssen auch den Namen und den Typ der letzten lokalen Variablen jedes Registers für den DBG_RESTART_LOCAL-Code.

Der Header lautet wie folgt:

Die Bytecodewerte sind:

Spezielle Opcodes

Opcodes mit Werten zwischen 0x0a und 0xff (einschließlich) verschieben sowohl line als auch address registriert und gibt dann einen neuen Positionstabelleneintrag aus. Die Formel für die Inkremente lautet wie folgt:

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)

Anmerkungen_Verzeichniselement

Von class_def_item referenziert

Erscheint im Datenbereich

Ausrichtung: 4 Byte

Hinweis:Das Attribut „Alle Elemente“ field_id und method_id-Instanzen müssen auf dieselbe definierende Klasse verweisen.

Format von „field_annotation“

Format der method_annotation

Format „parameter_annotation“

Annotationssatz_Referenzliste

Verweist von parameter_annotations_item

Erscheint im Datenbereich

Ausrichtung: 4 Byte

Format „annotation_set_ref_item“

Annotationssatzelement

Verweist von „annotations_directory_item“, „field_annotations_item“ method_annotations_item undannotation_set_ref_item

Erscheint im Datenbereich

Ausrichtung: 4 Byte

Format „annotation_off_item“

Anmerkungselement

Verweist von „annotation_set_item“

Erscheint im Datenbereich

Ausrichtung: keine (byte-orientiert)

Sichtbarkeitswerte

Dies sind die Optionen für das Feld visibility in einer annotation_item:

codiertes_Array-Element

Von class_def_item referenziert

Erscheint im Datenbereich

Ausrichtung: keine (byte-orientiert)

verborgenes Datenelement der API-Klasse

Dieser Abschnitt enthält Daten zu eingeschränkten Schnittstellen, die von jeder Klasse verwendet werden.

Hinweis: Die verborgene API-Funktion wurde mit Android 10.0 eingeführt. und gilt nur für die DEX-Dateien von Klassen im Bootklassenpfad. Die Liste der unten beschriebenen Flags wird in zukünftigen Releases möglicherweise erweitert. von Android. Weitere Informationen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.

Arten von Einschränkungs-Flags:

Systemhinweise

Systemanmerkungen stellen verschiedene reflektierende Elemente dar. Informationen zu Klassen (sowie Methoden und Feldern). Diese Informationen sind Der Zugriff erfolgt in der Regel nur indirekt über Client-Code (kein Systemcode).

Systemanmerkungen werden in .dex-Dateien als Anmerkungen, deren Sichtbarkeit auf VISIBILITY_SYSTEM festgelegt ist.

dalvik.annotation.AnnotationDefault

Erscheint bei Methoden in Anmerkungsoberflächen

Jedem Element wird eine Anmerkung AnnotationDefault beigefügt. Anmerkungsoberfläche, in der Standardbindungen angegeben werden sollen.

dalvik.annotation.EnclosureClass

Erscheint in Kursen

Jede Klasse wird mit einer EnclosingClass-Anmerkung versehen. das entweder als Mitglied einer anderen Klasse definiert ist, per se oder anonym, aber nicht innerhalb eines Methodentexts definiert (z.B. eine synthetische innere Klasse). Jeder Kurs mit dieser Anmerkung muss auch einen InnerClass-Anmerkung. Außerdem darf eine Klasse keine sowohl ein EnclosingClass als auch ein EnclosingMethod-Anmerkung.

dalvik.annotation.EnclosureMethod

Erscheint in Kursen

Jede Klasse wird mit einer EnclosingMethod-Anmerkung versehen. der in einem Methodentext definiert ist. In allen Kursen mit dieser -Annotation auch eine InnerClass-Annotation haben. Außerdem darf eine Klasse nicht sowohl einen EnclosingClass-Wert haben als auch und einer EnclosingMethod-Anmerkung.

dalvik.annotation.InnerClass

Erscheint in Kursen

Jede Klasse wird mit einer InnerClass-Anmerkung versehen. der im lexikalischen Bereich der Definition einer anderen Klasse definiert ist. Jede Klasse mit dieser Annotation muss außerdem entweder ein Anmerkung EnclosingClass oder eine EnclosingMethod-Anmerkung.

dalvik.annotation.MemberClass

Erscheint in Kursen

Jedem Kurs wird eine MemberClasses-Anmerkung angehängt. mit der Member-Klassen deklariert werden. (Eine Mitgliederklasse ist eine direkte innere Klasse, das einen Namen hat.)

dalvik.annotation.MethodParameters

Erscheint bei Methoden

Hinweis:Diese Anmerkung wurde nach Android hinzugefügt. 7.1 In früheren Android-Versionen wird die Funktion ignoriert.

Eine MethodParameters-Anmerkung ist optional und kann für Folgendes verwendet werden: Parametermetadaten wie Parameternamen und Modifikatoren bereitstellen.

Die Annotation kann bei einer Methode oder einem Konstruktor sicher weggelassen werden, wenn der Parametermetadaten sind zur Laufzeit nicht erforderlich. Mit java.lang.reflect.Parameter.isNamePresent() kann Folgendes überprüft werden: Ob Metadaten für einen Parameter vorhanden sind, und die zugehörige Reflexion wie java.lang.reflect.Parameter.getName() während der Laufzeit auf das Standardverhalten zurückgesetzt werden, wenn keine Informationen vorhanden sind.

Beim Einbeziehen von Parametermetadaten müssen Compiler Informationen angeben für generierte Klassen wie enums, da die Parameter-Metadaten gibt an, ob ein Parameter synthetisch ist oder erforderlich ist.

Eine MethodParameters-Anmerkung beschreibt nur eine einzelne Methode. Parameter. Daher können Compiler die Annotation unter Umständen ganz für Konstruktoren und Methoden, die keine Parameter haben, aus Gründen der Codegröße und Laufzeiteffizienz.

Die unten dokumentierten Arrays müssen dieselbe Größe wie für den method_id_item dex-Struktur, die der Methode zugeordnet ist, andernfalls wird ein java.lang.reflect.MalformedParametersException Laufzeit.

Das heißt: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size muss mit names().length übereinstimmen und accessFlags().length

Weil MethodParameters alle formalen Methoden beschreibt auch solche, die nicht explizit oder implizit im Quellcode deklariert sind, Die Größe der Arrays kann sich von der Signatur oder anderen Metadaten unterscheiden. Informationen, die nur auf expliziten Parametern basieren, die in der Quelle deklariert wurden Code. MethodParameters gibt auch keine Informationen über -Typanmerkungsempfängerparameter, die in der eigentlichen Methode nicht vorhanden sind. Signatur.

dalvik.annotation.Signatur

Erscheint für Klassen, Felder und Methoden

Jede Klasse wird mit einer Signature-Anmerkung versehen. Feld oder Methode, die im Hinblick auf einen komplizierteren Typ definiert ist, als durch type_id_item dargestellt werden kann. Die Das .dex-Format definiert nicht das Format für Signaturen. sie soll lediglich die Signaturen einer Quelle darstellen. Sprache ist für die erfolgreiche Implementierung des Semantik. Daher werden Signaturen im Allgemeinen nicht geparst (oder verifiziert) durch virtuelle Maschinenimplementierungen. Die Unterschriften werden einfach zugestellt. auf übergeordnete APIs und Tools (wie Debugger) übertragen. Jegliche Verwendung eines Signatur ist daher so zu verfassen, Annahmen darüber, nur gültige Signaturen zu erhalten, expliziter Schutz der Möglichkeit eines syntaktischen ungültige Signatur.

Da Signaturstrings in der Regel viele duplizierte Inhalte enthalten, Eine Signature-Annotation ist definiert als Array aus , bei denen sich duplizierte Elemente naturgemäß auf dasselbe zugrunde liegende Daten und die Signatur ist die Verkettung von alle Zeichenfolgen im Array. Es gibt keine Regeln dazu, wie Signatur in separate Strings aufteilen; die vollständig von der Tools zum Generieren von .dex-Dateien.

dalvik.annotation.wirft

Erscheint bei Methoden

Jeder Methode wird eine Throws-Anmerkung zugeordnet, deklariert, um einen oder mehrere Ausnahmetypen auszulösen.