Dieses Dokument beschreibt das Layout und den Inhalt von .dex
Dateien, die zum Speichern einer Reihe von Klassendefinitionen und der zugehörigen Zusatzdaten verwendet werden.
Leitfaden zu Typen
Name | Beschreibung |
---|---|
Byte | 8-Bit-Int. mit Vorzeichen |
ubyte | 8-Bit-Int ohne Vorzeichen |
kurz | 16-Bit-Int mit Vorzeichen, Little-Endian |
ushort | 16-Bit-Ganzzahl ohne Vorzeichen, Little-Endian |
int | 32-Bit-Int mit Vorzeichen, Little-Endian |
uint | 32-Bit-Int ohne Vorzeichen, Little-Endian |
lang | 64-Bit-Int mit Vorzeichen, Little-Endian |
ulong | 64-Bit-Int ohne Vorzeichen, Little-Endian |
sleb128 | signiert LEB128, variable Länge (siehe unten) |
uleb128 | unsigned LEB128, variable Länge (siehe unten) |
uleb128p1 | unsigned LEB128 plus 1 , variable Länge (siehe unten) |
LEB128
LEB128 („ Little - Endian Base 128 “) ist eine Codierung variabler Länge für beliebige vorzeichenbehaftete oder vorzeichenlose ganzzahlige Größen. Das Format wurde der DWARF3 -Spezifikation entlehnt. In einer .dex
Datei wird LEB128 immer nur zum Codieren von 32-Bit-Größen verwendet.
Jeder LEB128-codierte Wert besteht aus einem bis fünf Bytes, die zusammen einen einzelnen 32-Bit-Wert darstellen. Für jedes Byte ist das höchstwertige Bit gesetzt, mit Ausnahme des letzten Bytes in der Sequenz, dessen höchstwertiges Bit gelöscht ist. Die verbleibenden sieben Bits jedes Bytes sind Nutzdaten, wobei die niedrigstwertigen sieben Bits der Menge im ersten Byte, die nächsten sieben im zweiten Byte usw. liegen. Im Fall eines vorzeichenbehafteten LEB128 ( sleb128
) wird das höchstwertige Nutzlastbit des letzten Bytes in der Sequenz vorzeichenerweitert, um den endgültigen Wert zu erzeugen. Im vorzeichenlosen Fall ( uleb128
) werden alle nicht explizit dargestellten Bits als 0
interpretiert.
Bitweises Diagramm eines Zwei-Byte-LEB128-Werts | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Erstes Byte | Zweites Byte | ||||||||||||||
1 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 | 0 | Bit 13 | Bit 12 | Bit 11 | Bit 10 | Bit 9 | Bit 8 | Bit 7 |
Die Variante uleb128p1
wird zur Darstellung eines vorzeichenbehafteten Werts verwendet, wobei die Darstellung aus dem Wert plus eins besteht, der als uleb128
codiert ist. Dies macht die Codierung von -1
(alternativ als vorzeichenloser Wert 0xffffffff
gedacht) – aber keiner anderen negativen Zahl – zu einem einzelnen Byte und ist genau in den Fällen nützlich, in denen die dargestellte Zahl entweder nicht negativ oder -1
sein muss (oder 0xffffffff
) und wo keine anderen negativen Werte zulässig sind (oder wo große vorzeichenlose Werte wahrscheinlich nicht erforderlich sind).
Hier einige Beispiele für die Formate:
Verschlüsselte Sequenz | Als sleb128 | Als uleb128 | Als uleb128p1 |
---|---|---|---|
00 | 0 | 0 | -1 |
01 | 1 | 1 | 0 |
7f | -1 | 127 | 126 |
80 7f | -128 | 16256 | 16255 |
Dateilayout
Name | Format | Beschreibung |
---|---|---|
Header | header_item | die Kopfzeile |
string_ids | string_id_item[] | Liste der Zeichenfolgenbezeichner. Dies sind Bezeichner für alle von dieser Datei verwendeten Zeichenfolgen, entweder zur internen Benennung (z. B. Typdeskriptoren) oder als konstante Objekte, auf die im Code verwiesen wird. Diese Liste muss nach Zeichenfolgeninhalten unter Verwendung von UTF-16-Codepunktwerten sortiert sein (nicht auf gebietsschemaabhängige Weise) und darf keine doppelten Einträge enthalten. |
type_ids | type_id_item[] | Typ-ID-Liste. Dies sind Bezeichner für alle Typen (Klassen, Arrays oder primitive Typen), auf die diese Datei verweist, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss nach dem Index string_id sortiert sein und darf keine doppelten Einträge enthalten. |
proto_ids | proto_id_item[] | Liste der Methodenprototyp-IDs. Dies sind Kennungen für alle Prototypen, auf die in dieser Datei verwiesen wird. Diese Liste muss in der Hauptreihenfolge des Rückgabetyps (nach type_id Index) und dann nach Argumentliste (lexikografische Reihenfolge, einzelne Argumente nach type_id Index sortiert) sortiert werden. Die Liste darf keine doppelten Einträge enthalten. |
field_ids | field_id_item[] | Liste der Feldbezeichner. Dies sind Bezeichner für alle Felder, auf die diese Datei verweist, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss sortiert werden, wobei der definierende Typ (nach type_id Index) die Hauptreihenfolge, der Feldname (nach string_id Index) die Zwischenreihenfolge und der Typ (nach type_id Index) die Nebenreihenfolge darstellt. Die Liste darf keine doppelten Einträge enthalten. |
method_ids | method_id_item[] | Liste der Methodenbezeichner. Dies sind Bezeichner für alle Methoden, auf die diese Datei verweist, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss sortiert werden, wobei der definierende Typ (nach type_id Index) die Hauptreihenfolge, der Methodenname (nach string_id Index) die Zwischenreihenfolge und der Methodenprototyp (nach proto_id Index) die Nebenreihenfolge ist. Die Liste darf keine doppelten Einträge enthalten. |
class_defs | class_def_item[] | Liste der Klassendefinitionen. Die Klassen müssen so angeordnet sein, dass die Superklasse und implementierten Schnittstellen einer bestimmten Klasse in der Liste früher erscheinen als die verweisende Klasse. Darüber hinaus ist es ungültig, wenn eine Definition für die gleichnamige Klasse mehr als einmal in der Liste erscheint. |
call_site_ids | call_site_id_item[] | Liste der Anruf-Site-Identifikatoren. Dabei handelt es sich um Kennungen für alle Aufrufstellen, auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss in aufsteigender Reihenfolge von call_site_off sortiert werden. |
method_handles | method_handle_item[] | Methode behandelt Liste. Eine Liste aller Methodenhandles, auf die diese Datei verweist, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste ist nicht sortiert und kann Duplikate enthalten, die logisch verschiedenen Methodenhandle-Instanzen entsprechen. |
Daten | ubyte[] | Datenbereich, der alle Supportdaten für die oben aufgeführten Tabellen enthält. Unterschiedliche Elemente haben unterschiedliche Ausrichtungsanforderungen und Füllbytes werden bei Bedarf vor jedem Element eingefügt, um eine ordnungsgemäße Ausrichtung zu erreichen. |
link_data | ubyte[] | Daten, die in statisch verknüpften Dateien verwendet werden. Das Format der Daten in diesem Abschnitt wird in diesem Dokument nicht spezifiziert. Dieser Abschnitt ist in nicht verknüpften Dateien leer und kann von Laufzeitimplementierungen nach eigenem Ermessen verwendet werden. |
Bitfeld-, String- und Konstantendefinitionen
DEX_FILE_MAGIC
eingebettet in header_item
Das konstante Array/String DEX_FILE_MAGIC
ist die Liste der Bytes, die am Anfang einer .dex
Datei stehen müssen, damit sie als solche erkannt wird. Der Wert enthält absichtlich eine neue Zeile ( "\n"
oder 0x0a
) und ein Nullbyte ( "\0"
oder 0x00
), um die Erkennung bestimmter Formen der Korruption zu erleichtern. Der Wert kodiert auch eine Formatversionsnummer als drei Dezimalstellen, die voraussichtlich mit der Zeit monoton ansteigen, wenn 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 Formats wurde in der Version Android 9.0 hinzugefügt, die zwei neue Bytecodes einführte: const-method-handle
und const-method-type
. (Diese werden jeweils in der Tabelle „Zusammenfassung der Bytecode-Sets“ beschrieben.) In Android 10 erweitert Version 039
das DEX-Dateiformat um versteckte API-Informationen, die nur für DEX-Dateien im Boot-Klassenpfad gelten.
Hinweis: Unterstützung für Version 038
des Formats wurde in der Android 8.0-Version hinzugefügt. Version 038
fügte neue Bytecodes ( invoke-polymorphic
und invoke-custom
) und Daten für Methodenhandles hinzu.
Hinweis: Unterstützung für Version 037
des Formats wurde in der Android 7.0-Version hinzugefügt. Vor Version 037
verwendeten die meisten Android-Versionen Version 035
des Formats. Der einzige Unterschied zwischen den Versionen 035
und 037
besteht in der Hinzufügung von Standardmethoden und der Anpassung des invoke
.
Hinweis: Mindestens einige frühere Versionen des Formats wurden in allgemein verfügbaren öffentlichen Softwareversionen verwendet. Beispielsweise wurde Version 009
für die M3-Versionen der Android-Plattform (November–Dezember 2007) und Version 013
für die M5-Versionen der Android-Plattform (Februar–März 2008) verwendet. In mehrfacher Hinsicht unterscheiden sich diese früheren Versionen des Formats erheblich von der in diesem Dokument beschriebenen Version.
ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT
eingebettet in header_item
Die Konstante ENDIAN_CONSTANT
wird verwendet, um die Endianness der Datei anzugeben, in der sie gefunden wird. Obwohl das standardmäßige .dex
Format Little-Endian ist, können sich Implementierungen dafür entscheiden, einen Byte-Austausch durchzuführen. Sollte eine Implementierung auf einen Header stoßen, dessen endian_tag
REVERSE_ENDIAN_CONSTANT
anstelle von ENDIAN_CONSTANT
lautet, weiß sie, dass die Datei in der erwarteten Form byteweise ausgetauscht wurde.
uint ENDIAN_CONSTANT = 0x12345678; uint REVERSE_ENDIAN_CONSTANT = 0x78563412;
NO_INDEX
eingebettet in class_def_item und debug_info_item
Die Konstante NO_INDEX
wird verwendet, um anzuzeigen, dass ein Indexwert fehlt.
Hinweis: Dieser Wert ist nicht als 0
definiert, da dies normalerweise ein gültiger Index ist.
Der gewählte Wert für NO_INDEX
kann als einzelnes Byte in der uleb128p1
Kodierung dargestellt werden.
uint NO_INDEX = 0xffffffff; // == -1 if treated as a signed int
access_flags-Definitionen
eingebettet in class_def_item, encoded_field, encoded_method und InnerClass
Bitfelder dieser Flags werden verwendet, um die Zugänglichkeit und allgemeine Eigenschaften von Klassen und Klassenmitgliedern anzuzeigen.
Name | Wert | Für Klassen (und InnerClass -Anmerkungen) | Für Felder | Für Methoden |
---|---|---|---|---|
ACC_PUBLIC | 0x1 | public : überall sichtbar | public : überall sichtbar | public : überall sichtbar |
ACC_PRIVATE | 0x2 | private : nur für die definierende Klasse sichtbar | private : nur für die definierende Klasse sichtbar | private : nur für die definierende Klasse sichtbar |
ACC_PROTECTED | 0x4 | protected : sichtbar für Paket und Unterklassen | protected : sichtbar für Paket und Unterklassen | protected : sichtbar für Paket und Unterklassen |
ACC_STATIC | 0x8 | static : wird nicht mit einer äußeren this Referenz erstellt | static : global für die definierende Klasse | static : akzeptiert this Argument nicht |
ACC_FINAL | 0x10 | final : nicht unterklassierbar | final : unveränderlich nach der Konstruktion | final : nicht überschreibbar |
ACC_SYNCHRONIZED | 0x20 | synchronized : Zugehörige Sperre, die beim Aufruf dieser Methode automatisch erworben wird. Hinweis: Dies ist nur gültig, wenn | ||
ACC_VOLATILE | 0x40 | volatile : Spezielle Zugriffsregeln zur Unterstützung der Thread-Sicherheit | ||
ACC_BRIDGE | 0x40 | Bridge-Methode, die vom Compiler automatisch als typsichere Bridge hinzugefügt wird | ||
ACC_TRANSIENT | 0x80 | transient : Wird nicht standardmäßig bei der Serialisierung gespeichert | ||
ACC_VARARGS | 0x80 | Das letzte Argument sollte vom Compiler als „Rest“-Argument behandelt werden | ||
ACC_NATIVE | 0x100 | native : in nativem Code implementiert | ||
ACC_INTERFACE | 0x200 | interface : mehrfach implementierte abstrakte Klasse | ||
ACC_ABSTRACT | 0x400 | abstract : nicht direkt instanziierbar | abstract : von dieser Klasse nicht implementiert | |
ACC_STRICT | 0x800 | strictfp : strenge Regeln für Gleitkomma-Arithmetik | ||
ACC_SYNTHETIC | 0x1000 | nicht direkt im Quellcode definiert | nicht direkt im Quellcode definiert | nicht direkt im Quellcode definiert |
ACC_ANNOTATION | 0x2000 | als Annotationsklasse deklariert | ||
ACC_ENUM | 0x4000 | als Aufzählungstyp deklariert | als Aufzählungswert deklariert | |
(ungebraucht) | 0x8000 | |||
ACC_CONSTRUCTOR | 0x10000 | Konstruktormethode (Klassen- oder Instanzinitialisierer) | ||
ACC_DECLARED_ SYNCHRONISIERT | 0x20000 | synchronized deklariert.Hinweis: Dies hat keine Auswirkungen auf die Ausführung (außer in der Widerspiegelung dieses Flags an sich). |
InnerClass
Annotationen zulässig und darf niemals in einem class_def_item
aktiviert sein.
MUTF-8-Kodierung (modifiziertes UTF-8).
Als Zugeständnis an eine einfachere Legacy-Unterstützung kodiert das .dex
Format seine Zeichenfolgendaten in einer de-facto-standardisierten, modifizierten UTF-8-Form, im Folgenden als MUTF-8 bezeichnet. Dieses Formular ist mit dem Standard-UTF-8 identisch, außer:
- Es werden nur die Ein-, Zwei- und Drei-Byte-Kodierungen verwendet.
- Codepunkte im Bereich
U+10000
…U+10ffff
werden als Ersatzpaar codiert, von denen jeder als drei Byte codierter Wert dargestellt wird. - Der Codepunkt
U+0000
wird in Zwei-Byte-Form codiert. - Ein einfaches Nullbyte (Wert
0
) gibt das Ende einer Zeichenfolge an, wie es bei der Standardinterpretation der C-Sprache der Fall ist.
Die ersten beiden Punkte oben lassen sich wie folgt zusammenfassen: MUTF-8 ist ein Codierungsformat für UTF-16 und kein direkteres Codierungsformat für Unicode-Zeichen.
Die letzten beiden oben genannten Elemente ermöglichen es gleichzeitig, den Codepunkt U+0000
in eine Zeichenfolge einzuschließen und ihn dennoch als nullterminierte Zeichenfolge im C-Stil zu bearbeiten.
Allerdings bedeutet die spezielle Codierung von U+0000
, dass im Gegensatz zu normalem UTF-8 das Ergebnis des Aufrufs der Standard-C-Funktion strcmp()
für ein Paar von MUTF-8-Strings nicht immer das ordnungsgemäß vorzeichenbehaftete Ergebnis des Vergleichs ungleicher Strings anzeigt . Wenn die Reihenfolge (nicht nur die Gleichheit) von Bedeutung ist, besteht der einfachste Weg, MUTF-8-Zeichenfolgen zu vergleichen, darin, sie Zeichen für Zeichen zu dekodieren und die dekodierten Werte zu vergleichen. (Es sind jedoch auch cleverere Implementierungen möglich.)
Weitere Informationen zur Zeichenkodierung finden Sie im Unicode-Standard . MUTF-8 ähnelt tatsächlich eher der (relativ weniger bekannten) Kodierung CESU-8 als UTF-8 an sich.
encoded_value-Kodierung
eingebettet in annotation_element und encoded_array_item
Ein encoded_value
ist ein kodierter Teil (fast) beliebiger hierarchisch strukturierter Daten. Die Kodierung soll sowohl kompakt als auch einfach zu analysieren sein.
Name | Format | Beschreibung |
---|---|---|
(value_arg << 5) | Werttyp | ubyte | Byte, das den Typ des unmittelbar nachfolgenden value angibt, zusammen mit einem optionalen klärenden Argument in den höherwertigen drei Bits. Nachfolgend finden Sie die verschiedenen value . In den meisten Fällen kodiert value_arg die Länge des unmittelbar nachfolgenden value in Bytes, als (size - 1) , z. B. 0 bedeutet, dass der Wert ein Byte erfordert, und 7 bedeutet, dass er acht Bytes erfordert; Es gibt jedoch Ausnahmen, wie unten aufgeführt. |
Wert | ubyte[] | Bytes, die den Wert darstellen, in der Länge variabel sind und für verschiedene value_type Bytes unterschiedlich interpretiert werden, jedoch immer Little-Endian. Weitere Informationen finden Sie in den verschiedenen Wertdefinitionen unten. |
Wertformate
Modellname | value_type | value_arg -Format | value | Beschreibung |
---|---|---|---|---|
VALUE_BYTE | 0x00 | (keine; muss 0 sein) | ubyte[1] | vorzeichenbehafteter Ein-Byte-Ganzzahlwert |
VALUE_SHORT | 0x02 | Größe - 1 (0…1) | ubyte[Größe] | vorzeichenbehafteter Zwei-Byte-Ganzzahlwert, vorzeichenerweitert |
VALUE_CHAR | 0x03 | Größe - 1 (0…1) | ubyte[Größe] | vorzeichenloser Zwei-Byte-Ganzzahlwert, durch Null erweitert |
VALUE_INT | 0x04 | Größe - 1 (0…3) | ubyte[Größe] | vorzeichenbehafteter 4-Byte-Ganzzahlwert, vorzeichenerweitert |
VALUE_LONG | 0x06 | Größe - 1 (0…7) | ubyte[Größe] | Acht-Byte-Ganzzahlwert mit Vorzeichen, vorzeichenerweitert |
VALUE_FLOAT | 0x10 | Größe - 1 (0…3) | ubyte[Größe] | Vier-Byte-Bitmuster, nach rechts durch Null erweitert und als IEEE754-32-Bit-Gleitkommawert interpretiert |
VALUE_DOUBLE | 0x11 | Größe - 1 (0…7) | ubyte[Größe] | Acht-Byte-Bitmuster, nach rechts durch Null erweitert und als IEEE754-64-Bit-Gleitkommawert interpretiert |
VALUE_METHOD_TYPE | 0x15 | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt proto_ids interpretiert wird und einen Methodentypwert darstellt |
VALUE_METHOD_HANDLE | 0x16 | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt method_handles interpretiert wird und einen Methoden-Handle-Wert darstellt |
VALUE_STRING | 0x17 | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt string_ids interpretiert wird und einen Zeichenfolgenwert darstellt |
WERTTYP | 0x18 | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt type_ids interpretiert wird und einen reflektierenden Typ-/Klassenwert darstellt |
VALUE_FIELD | 0x19 | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt field_ids interpretiert wird und einen reflektierenden Feldwert darstellt |
VALUE_METHOD | 0x1a | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt method_ids interpretiert wird und einen reflektierenden Methodenwert darstellt |
VALUE_ENUM | 0x1b | Größe - 1 (0…3) | ubyte[Größe] | Vorzeichenloser (durch Null erweiterter) Vier-Byte-Ganzzahlwert, der als Index im Abschnitt field_ids interpretiert wird und den Wert einer Aufzählungstypkonstanten darstellt |
VALUE_ARRAY | 0x1c | (keine; muss 0 sein) | encoded_array | ein Array von Werten in dem unten durch „ encoded_array format“ angegebenen Format. Die Größe des value ist implizit in der Codierung enthalten. |
VALUE_ANNOTATION | 0x1d | (keine; muss 0 sein) | encoded_annotation | eine Unteranmerkung in dem unten durch „ encoded_annotation format“ angegebenen Format. Die Größe des value ist implizit in der Codierung enthalten. |
VALUE_NULL | 0x1e | (keine; muss 0 sein) | (keiner) | null Referenzwert |
VALUE_BOOLEAN | 0x1f | Boolescher Wert (0…1) | (keiner) | Ein-Bit-Wert; 0 für false und 1 für true . Das Bit wird im value_arg dargestellt. |
encoded_array-Format
Name | Format | Beschreibung |
---|---|---|
Größe | uleb128 | Anzahl der Elemente im Array |
Werte | codierter_Wert[Größe] | eine Reihe von size encoded_value Bytesequenzen im in diesem Abschnitt angegebenen Format, sequentiell verkettet. |
encoded_annotation-Format
Name | Format | Beschreibung |
---|---|---|
type_idx | uleb128 | Art der Anmerkung. Dies muss ein Klassentyp (kein Array- oder Primitivtyp) sein. |
Größe | uleb128 | Anzahl der Name-Wert-Zuordnungen in dieser Annotation |
Elemente | annotation_element[Größe] | Elemente der Anmerkung, direkt inline dargestellt (nicht als Offsets). Elemente müssen in aufsteigender Reihenfolge nach dem string_id Index sortiert werden. |
annotation_element-Format
Name | Format | Beschreibung |
---|---|---|
name_idx | uleb128 | Elementname, dargestellt als Index im Abschnitt string_ids . Die Zeichenfolge muss der oben definierten Syntax für MemberName entsprechen. |
Wert | codierter_Wert | Elementwert |
String-Syntax
Es gibt verschiedene Arten von Elementen in einer .dex
Datei, die letztendlich auf eine Zeichenfolge verweisen. Die folgenden Definitionen im BNF-Stil geben die akzeptable Syntax für diese Zeichenfolgen an.
SimpleName
Ein SimpleName ist die Grundlage für die Syntax der Namen anderer Dinge. Das .dex
Format bietet hier einen erheblichen Spielraum (viel mehr als die meisten gängigen Quellsprachen). Kurz gesagt besteht ein einfacher Name aus einem beliebigen Low-ASCII-alphabetischen Zeichen oder einer beliebigen Ziffer, einigen spezifischen Low-ASCII-Symbolen und den meisten Nicht-ASCII-Codepunkten, bei denen es sich nicht um Steuerzeichen, Leerzeichen oder Sonderzeichen handelt. Ab Version 040
erlaubt das Format zusätzlich Leerzeichen (Kategorie Unicode Zs
). Beachten Sie, dass Ersatzcodepunkte (im Bereich U+d800
… U+dfff
) per se nicht als gültige Namenszeichen gelten, Unicode-Ergänzungszeichen jedoch gültig sind (die durch die letzte Alternative der Regel für SimpleNameChar dargestellt werden) und sie sollten in einer Datei als Paare von Ersatzcodepunkten in der MUTF-8-Codierung dargestellt werden.
SimpleName → | ||
SimpleNameChar ( SimpleNameChar )* | ||
SimpleNameChar → | ||
'A' … 'Z' | ||
| | 'a' … 'z' | |
| | '0' … '9' | |
| | ' ' | seit DEX-Version 040 |
| | '$' | |
| | '-' | |
| | '_' | |
| | U+00a0 | seit DEX-Version 040 |
| | U+00a1 … U+1fff | |
| | U+2000 … U+200a | seit DEX-Version 040 |
| | U+2010 … U+2027 | |
| | U+202f | seit DEX-Version 040 |
| | U+2030 … U+d7ff | |
| | U+e000 … U+ffef | |
| | U+10000 … U+10ffff |
Mitgliedsname
Wird von field_id_item und method_id_item verwendet
Ein MemberName ist der Name eines Mitglieds einer Klasse, wobei die Mitglieder Felder, Methoden und innere Klassen sind.
Mitgliedsname → | |
SimpleName | |
| | '<' SimpleName '>' |
Vollständiger Klassenname
Ein FullClassName ist ein vollständig qualifizierter Klassenname, einschließlich eines optionalen Paketspezifizierers, gefolgt von einem erforderlichen Namen.
Vollständiger Klassenname → | |
OptionalPackagePrefix SimpleName | |
OptionalPackagePrefix → | |
( SimpleName '/' )* |
TypeDescriptor
Wird von type_id_item verwendet
Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich Grundelementen, Klassen, Arrays und void
. Die Bedeutung der verschiedenen Versionen finden Sie weiter unten.
TypeDescriptor → | |
'V' | |
| | FieldTypeDescriptor |
FieldTypeDescriptor → | |
NonArrayFieldTypeDescriptor | |
| | ( '[' * 1…255) NonArrayFieldTypeDescriptor |
NonArrayFieldTypeDescriptor → | |
'Z' | |
| | 'B' |
| | 'S' |
| | 'C' |
| | 'I' |
| | 'J' |
| | 'F' |
| | 'D' |
| | 'L' FullClassName ';' |
ShortyDescriptor
Wird von proto_id_item verwendet
Ein ShortyDescriptor ist die Kurzformdarstellung eines Methodenprototyps, einschließlich Rückgabe- und Parametertypen, mit der Ausnahme, dass zwischen verschiedenen Referenztypen (Klasse oder Array) nicht unterschieden wird. Stattdessen werden alle Referenztypen durch ein einzelnes 'L'
-Zeichen dargestellt.
ShortyDescriptor → | |
ShortyReturnType ( ShortyFieldType )* | |
ShortyReturnType → | |
'V' | |
| | ShortyFieldType |
ShortyFieldType → | |
'Z' | |
| | 'B' |
| | 'S' |
| | 'C' |
| | 'I' |
| | 'J' |
| | 'F' |
| | 'D' |
| | 'L' |
TypeDescriptor -Semantik
Dies ist die Bedeutung jeder Variante von TypeDescriptor .
Syntax | Bedeutung |
---|---|
V | void ; nur gültig für Rückgabetypen |
Z | boolean |
B | byte |
S | short |
C | char |
ICH | int |
J | long |
F | float |
D | double |
L voll/qualifiziert/Name ; | die Klasse fully.qualified.Name |
[ Beschreibung | Array von descriptor , rekursiv für Arrays von Arrays verwendbar, es ist jedoch ungültig, mehr als 255 Dimensionen zu haben. |
Elemente und zugehörige Strukturen
Dieser Abschnitt enthält Definitionen für jedes Element der obersten Ebene, das in einer .dex
Datei erscheinen kann.
header_item
erscheint im Kopfbereich
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
Magie | ubyte[8] = DEX_FILE_MAGIC | magischer Wert. Weitere Einzelheiten finden Sie in der Diskussion oben unter „ DEX_FILE_MAGIC “. |
Prüfsumme | uint | adler32-Prüfsumme des Rests der Datei (alles außer magic und dieses Feld); Wird zur Erkennung von Dateibeschädigungen verwendet |
Unterschrift | ubyte[20] | SHA-1-Signatur (Hash) des Rests der Datei (alles außer magic , checksum und dieses Feld); Wird zur eindeutigen Identifizierung von Dateien verwendet |
Dateigröße | uint | Größe der gesamten Datei (einschließlich Header) in Bytes |
header_size | uint = 0x70 | Größe des Headers (dieser gesamte Abschnitt) in Bytes. Dies ermöglicht zumindest eine begrenzte Abwärts-/Vorwärtskompatibilität, ohne das Format ungültig zu machen. |
endian_tag | uint = ENDIAN_CONSTANT | Endianness-Tag. Weitere Einzelheiten finden Sie in der Diskussion oben unter „ ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT “. |
link_size | uint | Größe des Linkabschnitts oder 0 , wenn diese Datei nicht statisch verlinkt ist |
link_off | uint | Offset vom Anfang der Datei zum Linkabschnitt oder 0 , wenn link_size == 0 . Wenn der Offset ungleich Null ist, sollte er ein Offset im Abschnitt link_data sein. Das Format der Daten, auf die verwiesen wird, wird in diesem Dokument nicht spezifiziert; Dieses Header-Feld (und das vorherige) bleiben als Hooks für die Verwendung durch Laufzeitimplementierungen übrig. |
map_off | uint | Offset vom Anfang der Datei zum Kartenelement. Der Offset, der ungleich Null sein darf, sollte ein Offset in den data sein und die Daten sollten in dem unten durch „ map_list “ angegebenen Format vorliegen. |
string_ids_size | uint | Anzahl der Zeichenfolgen in der Liste der Zeichenfolgenbezeichner |
string_ids_off | uint | Offset vom Anfang der Datei zur Liste der Zeichenfolgenbezeichner oder 0 , wenn string_ids_size == 0 (zugegebenermaßen ein seltsamer Randfall). Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts string_ids liegen. |
type_ids_size | uint | Anzahl der Elemente in der Typ-ID-Liste, höchstens 65535 |
type_ids_off | uint | Offset vom Anfang der Datei zur Typ-ID-Liste oder 0 , wenn type_ids_size == 0 (zugegebenermaßen ein seltsamer Randfall). Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts type_ids liegen. |
proto_ids_size | uint | Anzahl der Elemente in der Prototyp-ID-Liste, höchstens 65535 |
proto_ids_off | uint | Offset vom Anfang der Datei zur Liste der Prototyp-Identifikatoren oder 0 , wenn proto_ids_size == 0 (zugegebenermaßen ein seltsamer Randfall). Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts proto_ids liegen. |
field_ids_size | uint | Anzahl der Elemente in der Feldbezeichnerliste |
field_ids_off | uint | Offset vom Anfang der Datei zur Feldbezeichnerliste oder 0 , wenn field_ids_size == 0 . Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts field_ids liegen. |
method_ids_size | uint | Anzahl der Elemente in der Methoden-ID-Liste |
method_ids_off | uint | Offset vom Anfang der Datei zur Methoden-ID-Liste oder 0 , wenn method_ids_size == 0 . Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts method_ids liegen. |
class_defs_size | uint | Anzahl der Elemente in der Klassendefinitionsliste |
class_defs_off | uint | Offset vom Anfang der Datei zur Klassendefinitionsliste oder 0 , wenn class_defs_size == 0 (zugegebenermaßen ein seltsamer Randfall). Wenn der Offset ungleich Null ist, sollte er am Anfang des Abschnitts class_defs liegen. |
data_size | uint | Größe des data in Bytes. Muss ein gerades Vielfaches von sizeof(uint) sein. |
data_off | uint | Offset vom Anfang der Datei zum Anfang des data . |
Kartenliste
erscheint im Datenbereich
referenziert von header_item
Ausrichtung: 4 Bytes
Dies ist eine Liste des gesamten Inhalts einer Datei in der Reihenfolge. Es enthält eine gewisse Redundanz in Bezug auf header_item
, soll aber eine einfache Form sein, die zum Durchlaufen einer gesamten Datei verwendet werden kann. Ein bestimmter Typ darf höchstens einmal in einer Karte vorkommen, es gibt jedoch keine Einschränkung hinsichtlich der Reihenfolge, in der Typen erscheinen dürfen, abgesehen von den Einschränkungen, die durch den Rest des Formats impliziert werden (z. B. muss zuerst ein header
Abschnitt erscheinen, gefolgt von string_ids
. Abschnitt usw.). Darüber hinaus müssen die Karteneinträge nach anfänglichem Offset sortiert sein und dürfen sich nicht überschneiden.
Name | Format | Beschreibung |
---|---|---|
Größe | uint | Größe der Liste in Einträgen |
Liste | map_item[Größe] | Elemente der Liste |
map_item-Format
Name | Format | Beschreibung |
---|---|---|
Typ | ushort | Art der Artikel; siehe Tabelle unten |
ungebraucht | ushort | (ungebraucht) |
Größe | uint | Zählung der Anzahl der Elemente, die am angegebenen Offset gefunden werden sollen |
versetzt | uint | Offset vom Anfang der Datei zu den betreffenden Elementen |
Typencodes
Gegenstandsart | Konstante | Wert | Elementgröße in Bytes |
---|---|---|---|
header_item | TYPE_HEADER_ITEM | 0x0000 | 0x70 |
string_id_item | TYPE_STRING_ID_ITEM | 0x0001 | 0x04 |
type_id_item | TYPE_TYPE_ID_ITEM | 0x0002 | 0x04 |
proto_id_item | TYPE_PROTO_ID_ITEM | 0x0003 | 0x0c |
field_id_item | TYPE_FIELD_ID_ITEM | 0x0004 | 0x08 |
method_id_item | TYPE_METHOD_ID_ITEM | 0x0005 | 0x08 |
class_def_item | TYPE_CLASS_DEF_ITEM | 0x0006 | 0x20 |
call_site_id_item | TYPE_CALL_SITE_ID_ITEM | 0x0007 | 0x04 |
method_handle_item | TYPE_METHOD_HANDLE_ITEM | 0x0008 | 0x08 |
Kartenliste | TYPE_MAP_LIST | 0x1000 | 4 + (Artikelgröße * 12) |
type_list | TYPE_TYPE_LIST | 0x1001 | 4 + (Artikelgröße * 2) |
annotation_set_ref_list | TYPE_ANNOTATION_SET_REF_LIST | 0x1002 | 4 + (Artikelgröße * 4) |
annotation_set_item | TYPE_ANNOTATION_SET_ITEM | 0x1003 | 4 + (Artikelgröße * 4) |
class_data_item | TYPE_CLASS_DATA_ITEM | 0x2000 | implizit; muss analysieren |
code_item | TYPE_CODE_ITEM | 0x2001 | implizit; muss analysieren |
string_data_item | TYPE_STRING_DATA_ITEM | 0x2002 | implizit; muss analysieren |
debug_info_item | TYPE_DEBUG_INFO_ITEM | 0x2003 | implizit; muss analysieren |
annotation_item | TYPE_ANNOTATION_ITEM | 0x2004 | implizit; muss analysieren |
encoded_array_item | TYPE_ENCODED_ARRAY_ITEM | 0x2005 | implizit; muss analysieren |
annotations_directory_item | TYPE_ANNOTATIONS_DIRECTORY_ITEM | 0x2006 | implizit; muss analysieren |
verstecktapi_class_data_item | TYPE_HIDDENAPI_CLASS_DATA_ITEM | 0xF000 | implizit; muss analysieren |
string_id_item
erscheint im Abschnitt string_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
string_data_off | uint | Offset vom Anfang der Datei zu den String-Daten für dieses Element. Der Offset sollte sich auf eine Position im data beziehen und die Daten sollten das unten durch „ string_data_item “ angegebene Format haben. Für den Versatz ist keine Ausrichtung erforderlich. |
string_data_item
erscheint im Datenbereich
Ausrichtung: keine (Byte-ausgerichtet)
Name | Format | Beschreibung |
---|---|---|
utf16_size | uleb128 | Größe dieser Zeichenfolge in UTF-16-Codeeinheiten (was in vielen Systemen die „Stringlänge“ ist). Das heißt, dies ist die dekodierte Länge der Zeichenfolge. (Die codierte Länge wird durch die Position des 0 -Bytes impliziert.) |
Daten | ubyte[] | eine Reihe von MUTF-8-Codeeinheiten (auch bekannt als Oktette, auch bekannt als Bytes), gefolgt von einem Byte mit dem Wert 0 . Einzelheiten und Erläuterungen zum Datenformat finden Sie oben unter „MUTF-8-Codierung (modifiziertes UTF-8)“. Hinweis: Es ist akzeptabel, eine Zeichenfolge zu haben, die (die codierte Form von) UTF-16-Ersatzcodeeinheiten (d. h. |
type_id_item
erscheint im Abschnitt type_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
descriptor_idx | uint | Index in die string_ids Liste für die Deskriptorzeichenfolge dieses Typs. Die Zeichenfolge muss der oben definierten Syntax für TypeDescriptor entsprechen. |
proto_id_item
erscheint im Abschnitt proto_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
shorty_idx | uint | Index in die string_ids Liste für die Kurzdeskriptorzeichenfolge dieses Prototyps. Die Zeichenfolge muss der oben definierten Syntax für ShortyDescriptor entsprechen und dem Rückgabetyp und den Parametern dieses Elements entsprechen. |
return_type_idx | uint | Index in die Liste type_ids für den Rückgabetyp dieses Prototyps ein |
Parameter_off | uint | Offset vom Anfang der Datei zur Liste der Parametertypen für diesen Prototyp oder 0 , wenn dieser Prototyp keine Parameter hat. Wenn dieser Offset ungleich Null ist, sollte er sich im data befinden und die Daten dort sollten in dem unten durch "type_list" angegebenen Format vorliegen. Darüber hinaus sollte in der Liste kein Verweis auf den Typ void enthalten sein. |
field_id_item
erscheint im Abschnitt field_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
class_idx | ushort | Index in die Liste type_ids für den Definierer dieses Felds ein. Dies muss ein Klassentyp sein und kein Array oder primitiver Typ. |
type_idx | ushort | Index in die Liste type_ids für den Typ dieses Felds ein |
name_idx | uint | Index in die string_ids Liste für den Namen dieses Felds. Die Zeichenfolge muss der oben definierten Syntax für MemberName entsprechen. |
method_id_item
erscheint im Abschnitt method_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
class_idx | ushort | Index in die Liste type_ids für den Definierer dieser Methode ein. Dies muss ein Klassen- oder Array-Typ und kein primitiver Typ sein. |
proto_idx | ushort | Index in die proto_ids Liste für den Prototyp dieser Methode |
name_idx | uint | Index in die string_ids Liste für den Namen dieser Methode. Die Zeichenfolge muss der oben definierten Syntax für MemberName entsprechen. |
class_def_item
erscheint im Abschnitt class_defs
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
class_idx | uint | Index in die Liste type_ids für diese Klasse ein. Dies muss ein Klassentyp sein und kein Array oder primitiver Typ. |
access_flags | uint | Zugriffsflags für die Klasse ( public , final usw.). Weitere Informationen finden Sie unter „ access_flags Definitionen“. |
superclass_idx | uint | index in die Liste type_ids “ für die Superklasse ein, oder den konstanten Wert NO_INDEX wenn diese Klasse keine Superklasse hat (d. h. es sich um eine Stammklasse wie Object handelt). Falls vorhanden, muss es sich um einen Klassentyp und nicht um ein Array oder einen primitiven Typ handeln. |
interfaces_off | uint | Offset vom Anfang der Datei zur Liste der Schnittstellen oder 0 , wenn keine vorhanden sind. Dieser Offset sollte im data liegen und die Daten dort sollten in dem Format vorliegen, das unten durch „ type_list “ angegeben wird. Jedes der Elemente der Liste muss ein Klassentyp sein (kein Array oder primitiver Typ) und es dürfen keine Duplikate vorhanden sein. |
source_file_idx | uint | Index in die string_ids Liste für den Namen der Datei, die die Originalquelle für (zumindest den größten Teil) dieser Klasse enthält, oder den Sonderwert NO_INDEX , um das Fehlen dieser Informationen darzustellen. Das debug_info_item einer bestimmten Methode kann diese Quelldatei überschreiben, es wird jedoch erwartet, dass die meisten Klassen nur aus einer Quelldatei stammen. |
annotations_off | uint | Offset vom Anfang der Datei zur Annotationsstruktur für diese Klasse oder 0 , wenn es keine Annotationen für diese Klasse gibt. Wenn dieser Offset ungleich Null ist, sollte er sich im data befinden und die Daten dort sollten in dem Format vorliegen, das unten durch „ annotations_directory_item “ angegeben wird, wobei alle Elemente auf diese Klasse als Definierer verweisen. |
class_data_off | uint | Offset vom Anfang der Datei zu den zugehörigen Klassendaten für dieses Element oder 0 , wenn für diese Klasse keine Klassendaten vorhanden sind. (Dies kann beispielsweise der Fall sein, wenn es sich bei dieser Klasse um eine Markierungsschnittstelle handelt.) Der Offset sollte, wenn er ungleich Null ist, im data liegen und die Daten dort sollten in dem durch „ class_data_item “ unten angegebenen Format vorliegen. wobei alle Elemente auf diese Klasse als Definierer verweisen. |
static_values_off | uint | Offset vom Anfang der Datei zur Liste der Anfangswerte für static Felder oder 0 , wenn keine vorhanden sind (und alle static Felder mit 0 oder null initialisiert werden müssen). Dieser Offset sollte sich im data befinden und die Daten dort sollten in dem Format vorliegen, das unten durch „ encoded_array_item “ angegeben wird. Die Größe des Arrays darf nicht größer sein als die Anzahl der von dieser Klasse deklarierten static Felder, und die Elemente entsprechen den static Feldern in derselben Reihenfolge, wie sie in der entsprechenden field_list deklariert sind. Der Typ jedes Array-Elements muss mit dem deklarierten Typ des entsprechenden Felds übereinstimmen. Wenn das Array weniger Elemente enthält als static Felder vorhanden sind, werden die verbleibenden Felder mit einer typgerechten 0 oder null initialisiert. |
call_site_id_item
erscheint im Abschnitt call_site_ids
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
call_site_off | uint | Offset vom Anfang der Datei, um die Site-Definition aufzurufen. Der Offset sollte im Datenabschnitt liegen und die Daten dort sollten in dem unten durch „call_site_item“ angegebenen Format vorliegen. |
call_site_item
erscheint im Datenbereich
Ausrichtung: keine (Byte-ausgerichtet)
Das call_site_item ist ein encoded_array_item, dessen Elemente den Argumenten entsprechen, die einer Bootstrap-Linker-Methode bereitgestellt werden. Die ersten drei Argumente sind:
- Ein Methodenhandle, das die Bootstrap-Linker-Methode darstellt (VALUE_METHOD_HANDLE).
- Ein Methodenname, den der Bootstrap-Linker auflösen soll (VALUE_STRING).
- Ein Methodentyp, der dem Typ des aufzulösenden Methodennamens entspricht (VALUE_METHOD_TYPE).
Alle zusätzlichen Argumente sind konstante Werte, die an die Bootstrap-Linker-Methode übergeben werden. Diese Argumente werden der Reihe nach und ohne Typkonvertierungen übergeben.
Das Methodenhandle, das die Bootstrap-Linker-Methode darstellt, muss den Rückgabetyp java.lang.invoke.CallSite
haben. Die ersten drei Parametertypen sind:
-
java.lang.invoke.Lookup
-
java.lang.String
-
java.lang.invoke.MethodType
Die Parametertypen aller zusätzlichen Argumente werden aus ihren konstanten Werten bestimmt.
method_handle_item
erscheint im Abschnitt „method_handles“.
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
method_handle_type | ushort | Typ des Methodenhandles; siehe Tabelle unten |
ungebraucht | ushort | (ungebraucht) |
field_or_method_id | ushort | Feld- oder Methoden -ID, je nachdem, ob der Methode -Handy -Typ ein Accessor oder ein Methode -Invoker ist |
ungebraucht | Ushort | (ungebraucht) |
Methodenhandel -Typ -Codes
Konstante | Wert | Beschreibung |
---|---|---|
Method_handle_type_static_put | 0x00 | Method -Handle ist ein statischer Feld Setter (Accessor) |
Method_handle_type_static_get | 0x01 | Method -Handle ist ein statischer Feld Getter (Accessor) |
Method_handle_type_instance_put | 0x02 | Method -Handle ist ein Instanzfeld Setter (Accessor) |
Method_handle_type_instance_get | 0x03 | Method -Handle ist ein Instanzfeld Getter (Accessor) |
Method_handle_type_invoke_static | 0x04 | Method -Handle ist eine statische Methode Invoker |
Method_handle_type_invoke_instance | 0x05 | Method -Handle ist eine Instanzmethode Invoker |
Method_handle_type_invoke_constructor | 0x06 | Method -Handle ist eine Konstruktor -Methode Invoker |
Method_handle_type_invoke_direct | 0x07 | Method -Handle ist eine direkte Methode Invoker |
Method_handle_type_invoke_interface | 0x08 | Method -Handle ist eine Schnittstellenmethode Invoker |
class_data_item
Referenziert aus class_def_item
erscheint im Datenabschnitt
Ausrichtung: Keine (Byte-ausgerichtet)
Name | Format | Beschreibung |
---|---|---|
static_fields_size | Uleb128 | Die Anzahl der in diesem Artikel definierten statischen Felder |
Instance_fields_Size | Uleb128 | Die Anzahl der in diesem Artikel definierten Instanzfelder |
DICIRE_METHODS_SIZE | Uleb128 | Die Anzahl der in diesem Artikel definierten direkten Methoden |
virtual_methods_size | Uleb128 | Die Anzahl der in diesem Element definierten virtuellen Methoden |
static_fields | coded_field [static_fields_size] | Die definierten statischen Felder, dargestellt als Abfolge codierter Elemente. Die Felder müssen in zunehmender Reihenfolge nach field_idx sortiert werden. |
Instance_Fields | coded_field [Instance_fields_size] | Die definierten Instanzfelder, dargestellt als Abfolge codierter Elemente. Die Felder müssen in zunehmender Reihenfolge nach field_idx sortiert werden. |
Direct_Methods | coded_method [Direct_methods_Size] | Die definierten direkten (einer der static , private oder Konstruktor-) Methoden, die als Folge codierter Elemente dargestellt wurden. Die Methoden müssen in zunehmender Reihenfolge nach method_idx sortiert werden. |
virtual_methods | coded_method [virtual_methods_size] | Die definierten virtuellen (keine static , private oder Konstruktor -Methoden), die als Folge codierter Elemente dargestellt wurden. Diese Liste sollte nicht ererbte Methoden enthalten, es sei denn, die Klasse, die dieses Element darstellt, überschrieben. Die Methoden müssen in zunehmender Reihenfolge nach method_idx sortiert werden. Die method_idx einer virtuellen Methode darf nicht mit jeder direkten Methode gleich sein. |
Hinweis: Alle Elemente ' field_id
S und method_id
S müssen sich auf dieselbe definierende Klasse beziehen.
Coded_field -Format
Name | Format | Beschreibung |
---|---|---|
field_idx_diff | Uleb128 | Index in die Liste field_ids für die Identität dieses Feldes (enthält den Namen und den Deskriptor), der als Differenz aus dem Index des vorherigen Elements in der Liste dargestellt wird. Der Index des ersten Elements in einer Liste wird direkt dargestellt. |
access_flags | Uleb128 | Zugangsflaggen für das Feld ( public , final usw.). Details " access_flags Definitionen" finden Sie. |
coded_method Format
Name | Format | Beschreibung |
---|---|---|
method_idx_diff | Uleb128 | Index in die Liste method_ids für die Identität dieser Methode (enthält den Namen und den Deskriptor), der als Differenz aus dem Index des vorherigen Elements in der Liste dargestellt wird. Der Index des ersten Elements in einer Liste wird direkt dargestellt. |
access_flags | Uleb128 | Zugriffsflaggen für die Methode ( public , final usw.). Details " access_flags Definitionen" finden Sie. |
code_off | Uleb128 | Versatz von Beginn der Datei zur Codestruktur für diese Methode oder 0 , wenn diese Methode entweder abstract oder native ist. Der Offset sollte an einem Ort im data erfolgen. Das Format der Daten wird von " code_item " unten angegeben. |
Typ_List
Bezogen von class_def_item und proto_id_item
erscheint im Datenabschnitt
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
Größe | uint | Größe der Liste in Einträgen |
Liste | Typ_item [Größe] | Elemente der Liste |
Typ_item -Format
Name | Format | Beschreibung |
---|---|---|
type_idx | Ushort | Index in die Liste type_ids |
code_item
Referenziert aus coded_method
erscheint im Datenabschnitt
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
Register_Size | Ushort | Die Anzahl der von diesem Code verwendeten Register |
INS_SIZE | Ushort | Die Anzahl der Wörter eingehender Argumente an die Methode, für die dieser Code gilt |
outs_size | Ushort | Die Anzahl der Wörter aus dem ausgehenden Argumentenraum, die dieser Code für den Methodenaufruf benötigt |
Versuche_Size | Ushort | Die Anzahl der try_item für diese Instanz. Wenn es ungleich Null ist, erscheinen diese als das tries kurz nach den insns in diesem Fall. |
DEBUG_INFO_OFF | uint | Offset vom Beginn der Datei in die Debug -Info (Zeilennummern + lokale Variable -Info) für diesen Code oder 0 , wenn einfach keine Informationen vorhanden sind. Der Offset sollte, falls ungleich Null, an einem Ort im data stattfinden. Das Format der Daten wird unten durch " debug_info_item " angegeben. |
insns_size | uint | Größe der Anweisungsliste in 16-Bit-Code-Einheiten |
Inns | uShort [insns_size] | Tatsächliche Array von Bytecode. Das Format von Code in einem insns -Array wird durch das Begleitdokument Dalvik -Bytecode angegeben. Beachten Sie, dass dies zwar als ein Array von ushort definiert ist, es einige interne Strukturen gibt, die eine Vier-Byte-Ausrichtung bevorzugen. Wenn dies in einer endianverwickten Datei liegt, erfolgt der Austausch nur an einzelnen ushort und nicht auf den größeren internen Strukturen. |
Polsterung | Ushort (optional) = 0 | Zwei Bytes Polster, um tries mit vier Byte ausgerichtet zu machen. Dieses Element ist nur vorhanden, wenn tries_size ungleich Null und insns_size ungerade ist. |
versucht | try_item [TRIES_SIZE] (optional) | Array, das angibt, wo in den Code -Ausnahmen gefangen werden und wie man mit ihnen umgeht. Die Elemente des Arrays müssen in Reichweite nicht überlappend sein und von niedriger bis hoher Adresse. Dieses Element ist nur vorhanden, wenn tries_size ungleich Null ist. |
Handler | coded_catch_handler_list (optional) | Bytes, die eine Liste von Listen von Fangtypen und zugehörigen Handleradressen darstellen. Jeder try_item verfügt über einen Byte-Hinweis in diese Struktur. Dieses Element ist nur vorhanden, wenn tries_size ungleich Null ist. |
Try_item -Format
Name | Format | Beschreibung |
---|---|---|
start_addr | uint | Startadresse des von diesem Eintrags abgedeckten Codeblocks. Die Adresse ist eine Anzahl von 16-Bit-Code-Einheiten zum Beginn der ersten abgedeckten Anweisung. |
Inn_Count | Ushort | Anzahl der 16-Bit-Codeeinheiten, die durch diesen Eintrag abgedeckt sind. Die letzte Codeeinheit, die (inklusive) abgedeckt ist, ist start_addr + insn_count - 1 . |
Handler_off | Ushort | Offset in Bytes vom Start des zugehörigen encoded_catch_hander_list an die encoded_catch_handler für diesen Eintrag. Dies muss ein Offset für den Beginn eines encoded_catch_handler sein. |
coded_catch_handler_list Format
Name | Format | Beschreibung |
---|---|---|
Größe | Uleb128 | Größe dieser Liste in Einträgen |
Liste | coded_catch_handler [handlers_size] | Tatsächliche Liste der Handlerlisten, direkt dargestellt (nicht als Offsets) und nacheinander verkettet |
coded_catch_handler Format
Name | Format | Beschreibung |
---|---|---|
Größe | Sleb128 | Anzahl der Fangtypen in dieser Liste. Wenn nicht positiv, ist dies das Negativ der Anzahl der Fangtypen, und auf die Fänge folgen ein Catch-All-Handler. Zum Beispiel: Eine size von 0 bedeutet, dass es einen Fall gibt, aber keine explizit getippten Fänge. Eine size von 2 bedeutet, dass es zwei explizit typisierte Fänge und keinen Fall gibt. Und eine size von -1 bedeutet, dass ein typisierter Fang zusammen mit einem Haftstrafe vorhanden ist. |
Handler | coded_type_addr_pair [ABS (Größe)]] | Stream of abs(size) codierte Elemente, eine für jeden gefangenen Typ, in der Reihenfolge, in der die Typen getestet werden sollten. |
catch_all_addr | ULEB128 (optional) | Bytecode-Adresse des Catch-All-Handlers. Dieses Element ist nur vorhanden, wenn size nicht positiv ist. |
Coded_type_addr_pair Format
Name | Format | Beschreibung |
---|---|---|
type_idx | Uleb128 | Index in die Liste type_ids für den Typ der Ausnahme zu fangen |
ADDR | Uleb128 | Bytecodeadresse des zugehörigen Ausnahmehandlers |
DEBUG_INFO_ITEM
Referenziert aus Code_Item
erscheint im Datenabschnitt
Ausrichtung: Keine (Byte-ausgerichtet)
Jedes debug_info_item
definiert eine von DWARF3-inspirierte Byt-codierte Statusmaschine, die bei der Interpretation die Tabelle der Positionen ausgibt und (möglicherweise) die lokalen Variableninformationen für ein code_item
. Die Sequenz beginnt mit einem Header mit variabler Länge (deren Länge von der Anzahl der Methodenparameter abhängt), folgt von den Statusmaschinen-Bytecodes und endet mit einem Byte DBG_END_SEQUENCE
.
Die Staatsmaschine besteht aus fünf Registern. Das address
repräsentiert den Anweisungsversatz in der zugehörigen insns_item
in 16-Bit-Codeeinheiten. Das address
beginnt bei 0
zu Beginn jeder debug_info
-Sequenz und darf nur monoton erhöhen. Das line
stellt dar, welche Quellliniennummer mit dem von der Statusmaschine emittierten Tabelleneintrag für die nächsten Positionen zugeordnet werden soll. Es wird im Sequenzheader initialisiert und kann sich in positiven oder negativen Richtungen ändern, dürfen jedoch niemals weniger als 1
sein. Das Register source_file
repräsentiert die Quelldatei, auf die sich die Zeilennummer -Einträge beziehen. Es wird auf den Wert von source_file_idx
in class_def_item
initialisiert. Die beiden anderen Variablen, prologue_end
und epilogue_begin
, sind boolesche Flaggen (infitiert zu false
), die angeben, ob die nächste emittierte Position als Methode -Prolog oder Epilog betrachtet werden sollte. Die Statusmaschine muss auch den Namen und die Art der letzten lokalen Variablen live in jedem Register für den Code DBG_RESTART_LOCAL
verfolgen.
Der Header ist wie folgt:
Name | Format | Beschreibung |
---|---|---|
line_start | Uleb128 | Der Anfangswert für das line der Statusmaschine. Repräsentiert keinen tatsächlichen Positionseintrag. |
Parameter_Size | Uleb128 | Die Anzahl der codierten Parameternamen. Es sollte einen Parameter pro Methode geben, ohne dass eine Instanzmethode this , falls vorhanden. |
parameter_names | ULEB128P1 [Parameter_Size] | String -Index des Parameternamens der Methode. Ein codierter Wert von NO_INDEX gibt an, dass für den zugehörigen Parameter kein Name verfügbar ist. Der Typ -Deskriptor und die Signatur sind aus dem Methodendeskriptor und der Signatur impliziert. |
Die Byte -Code -Werte sind wie folgt:
Name | Wert | Format | Argumente | Beschreibung |
---|---|---|---|---|
Dbg_end_sequence | 0x00 | (keiner) | Beendet eine Debug -Info -Sequenz für einen code_item | |
Dbg_advance_pc | 0x01 | ULEB128 adDr_diff | addr_diff : Betrag zum Adressregister hinzuzufügen | Fördert das Adressregister, ohne einen Positionseintrag abzugeben |
Dbg_advance_line | 0x02 | Sleb128 Line_diff | line_diff : Betragen Sie das Leitungsregister nach | Fördert das Leitungsregister, ohne einen Positionseintrag abzugeben |
Dbg_start_local | 0x03 | ULEB128 Register_Num ULEB128P1 NAME_IDX ULEB128P1 type_idx | register_num : Register, die lokal enthältname_idx : String -Index des Namenstype_idx : Typindex des Typs Typ | führt eine lokale Variable an der aktuellen Adresse ein. BECAST name_idx oder type_idx ist möglicherweise NO_INDEX , um anzuzeigen, dass dieser Wert unbekannt ist. |
Dbg_start_local_extended | 0x04 | ULEB128 Register_Num ULEB128P1 NAME_IDX ULEB128P1 type_idx ULEB128P1 SIG_IDX | register_num : Register, die lokal enthältname_idx : String -Index des Namenstype_idx : Typindex des Typs Typsig_idx : String -Index der Typ Signatur | führt einen lokalen mit einer Typsignatur an der aktuellen Adresse ein. Eine von name_idx , type_idx oder sig_idx ist möglicherweise NO_INDEX um anzuzeigen, dass dieser Wert unbekannt ist. (Wenn sig_idx jedoch -1 ist, könnten die gleichen Daten mit dem Opcode DBG_START_LOCAL effizienter dargestellt werden.) Hinweis: Siehe die Diskussion unter " |
Dbg_end_local | 0x05 | ULEB128 Register_Num | register_num : Register, die lokal enthielt | markiert eine derzeit lebende lokale Variable, die an der aktuellen Adresse aus dem Spielraum hinausgeht |
Dbg_restart_local | 0x06 | ULEB128 Register_Num | register_num : Registrieren Sie sich, um neu zu starten | Führen Sie eine lokale Variable an der aktuellen Adresse erneut auf. Der Name und der Typ sind die gleichen wie die letzte lokale, die im angegebenen Register lebte. |
Dbg_set_pologue_end | 0x07 | (keiner) | Legt das Register des prologue_end -Statusautomats fest, was darauf hinweist, dass der hinzugefügte nächste Positionseintrag als Ende eines Methodenprologs (ein geeigneter Ort für einen Methoden -Haltepunkt) betrachtet werden sollte. Das prologue_end -Register wird von einem beliebigen ( >= 0x0a ) Opcode gelöscht. | |
Dbg_set_epilogue_begin | 0x08 | (keiner) | Legt das Register des epilogue_begin State Machine fest, was darauf hinweist, dass der hinzugefügte nächste Positionseintrag als Beginn eines Methode -Epilogs betrachtet werden sollte (ein geeigneter Ort zur Ausführung der Ausführung vor dem Methodenausgang). Das epilogue_begin -Register wird von einem beliebigen ( >= 0x0a ) Opcode gelöscht. | |
Dbg_set_file | 0x09 | ULEB128P1 NAME_IDX | name_idx : String -Index des Quelldateinamens; NO_INDEX wenn unbekannt | Gibt an, dass alle nachfolgenden Zeilennummereinträge auf diesen Quelldateinamen anstelle des in code_item angegebenen Standardnamens verweisen |
Spezielle Opcodes | 0x0a… 0xff | (keiner) | Fördert die line und address , gibt einen Positionseintrag aus und löscht prologue_end und epilogue_begin . Siehe unten für Beschreibung. |
Spezielle Opcodes
Opcodes mit Werten zwischen 0x0a
und 0xff
(inklusive) verschieben sowohl die line
als auch address
um einen geringen Betrag und geben dann einen neuen Eintragstabelle aus. Die Formel für die Schritte 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)
Annotationen_Directory_Item
Referenziert aus class_def_item
erscheint im Datenabschnitt
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
class_annotations_off | uint | Versatz von Beginn der Datei zu den direkten Anmerkungen, die direkt in der Klasse erstellt wurden, oder 0 , wenn die Klasse keine direkten Annotationen hat. Der Offset sollte, falls ungleich Null, an einem Ort im data stattfinden. Das Format der Daten wird unten durch " annotation_set_item " angegeben. |
fields_size | uint | Zählung der von diesem Artikel kommentierten Felder |
Annotated_methods_Size | uint | Anzahl der mit diesem Artikel kommunischen Methoden zählen |
Annotated_parameters_Size | uint | Anzahl der von diesem Element kommentierten Methodenparameterlisten listen |
FELD_ANNOTATIONS | field_annotation [fields_size] (optional) | Liste der zugehörigen Feldanmerkungen. Die Elemente der Liste müssen in zunehmender Reihenfolge nach field_idx sortiert werden. |
method_annotations | method_annotation [methoden_size] (optional) | Liste der zugehörigen Methodenanmerkungen. Die Elemente der Liste müssen in zunehmender Reihenfolge nach method_idx sortiert werden. |
Parameter_annotationen | parameter_annotation [parameters_size] (optional) | Liste der zugeordneten Methodenparameteranmerkungen. Die Elemente der Liste müssen in zunehmender Reihenfolge nach method_idx sortiert werden. |
Hinweis: Alle Elemente ' field_id
S und method_id
S müssen sich auf dieselbe definierende Klasse beziehen.
Field_annotation Format
Name | Format | Beschreibung |
---|---|---|
field_idx | uint | Index in die Liste field_ids für die Identität des Felds, das kommentiert wird |
Annotationen_off | uint | Versatz von Beginn der Datei in die Liste der Anmerkungen für das Feld. Der Offset sollte an einem Ort im data erfolgen. Das Format der Daten wird unten durch " annotation_set_item " angegeben. |
Method_annotation Format
Name | Format | Beschreibung |
---|---|---|
method_idx | uint | Index in die Liste method_ids für die Identität der mit Annotation der Methode angegebenen Methode |
Annotationen_off | uint | Versatz von Beginn der Datei in die Liste der Anmerkungen für die Methode. Der Offset sollte an einem Ort im data erfolgen. Das Format der Daten wird unten durch " annotation_set_item " angegeben. |
Parameter_annotation Format
Name | Format | Beschreibung |
---|---|---|
method_idx | uint | Index in die Liste method_ids für die Identität der Methode, deren Parameter kommentiert werden |
Annotationen_off | uint | Versatz von Beginn der Datei in die Liste der Anmerkungen für die Methodenparameter. Der Offset sollte an einem Ort im data erfolgen. Das Format der Daten wird unten durch " annotation_set_ref_list " angegeben. |
Annotation_Set_ref_List
Bezogen aus Parameter_annotations_Item
erscheint im Datenabschnitt
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
Größe | uint | Größe der Liste in Einträgen |
Liste | Annotation_set_ref_item [Größe] | Elemente der Liste |
Annotation_Set_ref_item Format
Name | Format | Beschreibung |
---|---|---|
Annotationen_off | uint | Versatz von Beginn der Datei auf den referenzierten Annotationssatz oder 0 , wenn es keine Anmerkungen für dieses Element gibt. Der Offset sollte, falls ungleich Null, an einem Ort im data stattfinden. Das Format der Daten wird unten durch " annotation_set_item " angegeben. |
Annotation_set_item
Verweis auf Annotations_Directory_Item, field_annotations_item, method_annotations_item und Annotation_set_ref_item
erscheint im Datenabschnitt
Ausrichtung: 4 Bytes
Name | Format | Beschreibung |
---|---|---|
Größe | uint | Größe des Satzes in Einträgen |
Einträge | Annotation_off_item [Größe] | Elemente des Sets. Die Elemente müssen in zunehmender Reihenfolge nach type_idx sortiert werden. |
Annotation_off_item Format
Name | Format | Beschreibung |
---|---|---|
Annotation_off | uint | Offset von Beginn der Datei bis zu einer Annotation. Der Offset sollte zu einem Ort im data erfolgen, und das Format der Daten an diesem Ort wird durch " annotation_item " unten angegeben. |
Annotation_Item
Bezogen von Annotation_set_item
erscheint im Datenabschnitt
Ausrichtung: Keine (Byte-ausgerichtet)
Name | Format | Beschreibung |
---|---|---|
Sichtweite | UBYTE | beabsichtigte Sichtbarkeit dieser Annotation (siehe unten) |
Anmerkung | coded_annotation | codierte Annotationsinhalte, in dem von " encoded_annotation Format" unter " encoded_value codierung" beschriebenen Format oben. |
Sichtbarkeitswerte
Dies sind die Optionen für das Feld visibility
in einem annotation_item
:
Name | Wert | Beschreibung |
---|---|---|
Sichtbarkeit_Build | 0x00 | Nur zum Bauzeit zu sichtbar sein (z. B. während der Zusammenstellung anderer Code) |
Sichtbarkeit_Runtime | 0x01 | zur Laufzeit sichtbar zu sichtbar |
Sichtbarkeit_System | 0x02 | Sichtbar zur Laufzeit, aber nur für das zugrunde liegende System (und nicht für den regulären Benutzercode) |
coded_array_item
Referenziert aus class_def_item
erscheint im Datenabschnitt
Ausrichtung: Keine (Byte-ausgerichtet)
Name | Format | Beschreibung |
---|---|---|
Wert | coded_array | Bytes, die den codierten Array -Wert darstellen, im Format " encoded_array " unter " encoded_value codierung" oben angegeben. |
hiddenapi_class_data_item
Dieser Abschnitt enthält Daten zu eingeschränkten Schnittstellen, die von jeder Klasse verwendet werden.
Hinweis: Die versteckte API -Funktion wurde in Android 10.0 eingeführt und ist nur für die DEX -Klassendateien im Startklassenpfad anwendbar. Die unten beschriebene Liste der nachstehend beschriebenen Flaggen kann in den zukünftigen Veröffentlichungen von Android erweitert werden. Weitere Informationen finden Sie unter Beschränkungen der Non-SDK-Schnittstellen .
Name | Format | Beschreibung |
---|---|---|
Größe | uint | Gesamtgröße des Abschnitts |
Offsets | uint [] | Array von Offsets, die von class_idx indiziert sind. Ein Null -Array -Eintrag bei Index class_idx bedeutet, dass entweder keine Daten für diese class_idx vorhanden sind oder alle versteckten API -Flags Null sind. Andernfalls ist der Array-Eintrag ungleich Null und enthält einen Versatz vom Beginn des Abschnitts zu einem Array von versteckten API-Flags für diese class_idx . |
Flaggen | Uleb128 [] | verkettete Arrays versteckter API -Flags für jede Klasse. Mögliche Flag -Werte sind in der folgenden Tabelle beschrieben. Flags sind in der gleichen Reihenfolge wie Felder codiert und Methoden werden in Klassendaten codiert. |
Restriktionsflaggentypen:
Name | Wert | Beschreibung |
---|---|---|
Whitelist | 0 | Schnittstellen, die frei verwendet werden können und im Rahmen des offiziell dokumentierten Android -Framework -Paket -Index unterstützt werden. |
Grauliste | 1 | Nicht-SDK-Schnittstellen, die unabhängig von der Ziel-API-Ebene der Anwendung verwendet werden können. |
schwarze Liste | 2 | Nicht-SDK-Schnittstellen, die unabhängig von der Ziel-API-Ebene der Anwendung nicht verwendet werden können. Der Zugriff auf eine dieser Schnittstellen führt zu einem Laufzeitfehler . |
GreyList -Max -o | 3 | Nicht-SDK-Schnittstellen, die für Android 8.x und darunter verwendet werden können, es sei denn, sie sind eingeschränkt. |
GreyList -Max -P | 4 | Nicht-SDK-Schnittstellen, die für Android 9.x verwendet werden können, es sei denn, sie sind eingeschränkt. |
GreyList -Max -Q | 5 | Nicht-SDK-Schnittstellen, die für Android 10.x verwendet werden können, es sei denn, sie sind eingeschränkt. |
GreyList -Max -R | 6 | Nicht-SDK-Schnittstellen, die für Android 11.x verwendet werden können, es sei denn, sie sind eingeschränkt. |
Systemanmerkungen
Systemanmerkungen werden verwendet, um verschiedene reflektierende Informationen über Klassen (und Methoden und Felder) darzustellen. Diese Informationen werden im Allgemeinen nur nach dem Client-Code (Nicht-System) indirekt zugegriffen.
Systemanmerkungen werden in .dex
-Dateien als Annotationen mit Sichtbarkeit auf VISIBILITY_SYSTEM
dargestellt.
Dalvik.annotation.AnnotationDefault
erscheint auf Methoden in Annotationsschnittstellen
Eine AnnotationDefault
-Annotation ist an jede Annotationsschnittstelle beigefügt, die Standardbindungen angeben möchte.
Name | Format | Beschreibung |
---|---|---|
Wert | Anmerkung | Die Standardbindungen für diese Annotation, die als Annotation dieser Art dargestellt werden. Die Annotation muss nicht alle Namen enthalten, die durch die Annotation definiert sind. Fehlende Namen haben einfach keine Standardeinstellungen. |
Dalvik.annotation.enclosingClass
erscheint auf Klassen
Eine Annotation der EnclosingClass
-Annotation ist an jede Klasse beigefügt, die entweder als Mitglied einer anderen Klasse an sich definiert ist oder anonym, aber in einem Methodenkörper nicht definiert ist (z. B. eine synthetische innere Klasse). Jede Klasse, die diese Annotation hat, muss auch eine Annotation InnerClass
haben. Zusätzlich darf eine Klasse nicht sowohl eine EnclosingClass
als auch eine Annotation EnclosingMethod
haben.
Name | Format | Beschreibung |
---|---|---|
Wert | Klasse | Die Klasse, die diese Klasse am besten lexikalisch leitet |
Dalvik.annotation.enclosingMethod
erscheint auf Klassen
An jeder Klasse, die in einem Methodenkörper definiert ist, ist eine EnclosingMethod
-Annotation beigefügt. Jede Klasse, die diese Annotation hat, muss auch eine Annotation InnerClass
haben. Zusätzlich darf eine Klasse nicht sowohl eine EnclosingClass
als auch eine Annotation EnclosingMethod
haben.
Name | Format | Beschreibung |
---|---|---|
Wert | Methode | Die Methode, die diese Klasse am besten lexikalisch abgebildet hat |
Dalvik.annotation.innnerClass
erscheint auf Klassen
Eine Annotation InnerClass
ist an jede Klasse beigefügt, die im lexikalischen Bereich der Definition einer anderen Klasse definiert ist. Jede Klasse, die diese Annotation hat, muss entweder entweder eine Annotation für die Annotation EnclosingClass
oder eine Annotation EnclosingMethod
haben.
Name | Format | Beschreibung |
---|---|---|
Name | Zeichenfolge | Der ursprünglich deklarierte einfache Name dieser Klasse (ohne Paketpräfix). Wenn diese Klasse anonym ist, dann ist der Name null . |
AccessFlags | int | Die ursprünglich deklarierten Zugriffsflags der Klasse (die sich von den effektiven Flags aufgrund einer Nichtübereinstimmung zwischen den Ausführungsmodellen der Quellsprache und der virtuellen Zielmaschine unterscheiden kann) |
dalvik.annotation.memberclasses
erscheint auf Klassen
Eine Annotation MemberClasses
ist an jede Klasse beigefügt, die Mitgliedsklassen deklariert. (Eine Mitgliedsklasse ist eine direkte innere Klasse, die einen Namen hat.)
Name | Format | Beschreibung |
---|---|---|
Wert | Klasse[] | Array der Mitgliedsklassen |
Dalvik.annotation.methodParameters
erscheint auf Methoden
Hinweis: Diese Annotation wurde nach Android 7.1 hinzugefügt. Die Anwesenheit früherer Android -Veröffentlichungen wird ignoriert.
Eine MethodParameters
-Annotation ist optional und kann verwendet werden, um Parametermetadaten wie Parameternamen und Modifikatoren bereitzustellen.
Die Annotation kann sicher aus einer Methode oder einem Konstruktor weggelassen werden, wenn die Parametermetadaten zur Laufzeit nicht erforderlich sind. java.lang.reflect.Parameter.getName()
java.lang.reflect.Parameter.isNamePresent()
kann verwendet werden, um zu überprüfen Wenn die Informationen nicht vorhanden sind.
Bei der Einbeziehung von Parametermetadaten müssen Compiler Informationen für generierte Klassen wie Enums enthalten, da die Parametermetadaten enthält, ob ein Parameter synthetisch oder vorgeschrieben ist oder nicht.
Eine MethodParameters
-Annotation beschreibt nur einzelne Methodenparameter. Daher können Compiler die Annotation ausschließlich für Konstruktoren und Methoden mit keinen Parametern auslassen, um die Effizienz von Codegröße und Laufzeit zu willen.
Die unten dokumentierten Arrays müssen die gleiche Größe haben wie für die mit der Methode zugeordnete method_id_item
Dex -Struktur, ansonsten wird eine java.lang.reflect.MalformedParametersException
zur Laufzeit geworfen.
Das heißt: method_id_item.proto_idx
-> proto_id_item.parameters_off
-> type_list.size
muss übereinstimmen wie names().length
und accessFlags().length
.
Da MethodParameters
alle formalen Methodenparameter beschreibt, können selbst diejenigen, die nicht explizit oder implizit in Quellcode deklariert sind, die Größe der Arrays von der Signatur oder anderen Metadateninformationen unterscheidet, die nur auf expliziten Parametern basieren, die in Quellcode deklariert sind. MethodParameters
enthält auch keine Informationen zu den Parametern des Typs Annotationsempfänger, die in der tatsächlichen Methodensignatur nicht vorhanden sind.
Name | Format | Beschreibung |
---|---|---|
Namen | String [] | Die Namen formaler Parameter für die zugehörige Methode. Das Array darf nicht null sein, sondern muss leer sein, wenn es keine formalen Parameter gibt. Ein Wert im Array muss null sein, wenn der formale Parameter mit diesem Index keinen Namen hat. Wenn der Parametername leer oder enthält '.', ';', '[' Oder ', dann wird eine java.lang.reflect.MalformedParametersException zur Laufzeit geworfen. |
AccessFlags | int [] | Die Zugriffsflaggen der formalen Parameter für die zugehörige Methode. Das Array darf nicht null sein, sondern muss leer sein, wenn es keine formalen Parameter gibt. Der Wert ist eine Bitmaske mit den folgenden Werten:
java.lang.reflect.MalformedParametersException zur Laufzeit geworfen. |
dalvik.annotation.signature
erscheint auf Klassen, Feldern und Methoden
Eine Signature
ist an jede Klasse, jedes Feld oder die Methode beigefügt, die in Bezug auf einen komplizierteren Typ definiert ist als durch ein type_id_item
dargestellt werden. Das .dex
-Format definiert das Format für Unterschriften nicht; Es soll lediglich in der Lage sein, die Signaturen darzustellen, die eine Quellsprache für eine erfolgreiche Implementierung der Semantik dieser Sprache erfordert. Daher werden Unterschriften durch virtuelle Maschinenimplementierungen im Allgemeinen nicht analysiert (oder verifiziert). Die Unterschriften werden einfach auf höhere APIs und Tools (wie Debugger) übergeben. Jede Verwendung einer Signatur sollte daher geschrieben werden, um keine Annahmen über die Erhalt gültiger Unterschriften zu treffen, was sich ausdrücklich vor der Möglichkeit schützt, auf eine syntaktisch ungültige Signatur zu stoßen.
Da die Signature
tendenziell viele doppelte Inhalte aufweisen . Es gibt keine Regeln, wie man eine Signatur in getrennte Saiten auseinanderzieht. Dies entspricht ganz den Tools, die .dex
-Dateien generieren.
Name | Format | Beschreibung |
---|---|---|
Wert | String [] | Die Signatur dieser Klasse oder dieses Mitglieds als eine Reihe von Strings, die miteinander verkettet werden soll |
dalvik.annotation.throws
erscheint auf Methoden
An jeder Methode wird eine Annotation Throws
, die erklärt wird, dass sie einen oder mehrere Ausnahmetypen werfen.
Name | Format | Beschreibung |
---|---|---|
Wert | Klasse[] | Die Ausnahmeartypen geworfen |