Dalvik-Ausführformat

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

Leitfaden zu Typen

Name	Beschreibung
Byte	Vorzeichenbehaftete 8-Bit-Ganzzahl
ubyte	Vorzeichenlose 8-Bit-Ganzzahl
kurz	16-Bit-Ganzzahl mit Vorzeichen, Little Endian
ushort	16-Bit-Ganzzahl ohne Vorzeichen, Little Endian
int	Vorzeichenbehaftete 32-Bit-Ganzzahl, Little Endian
uint	Vorzeichenlose 32-Bit-Ganzzahl, Little-Endian
long	Vorzeichenbehaftete 64-Bit-Ganzzahl, Little-Endian
Oolong	Vorzeichenlose 64-Bit-Ganzzahl, Little-Endian
sleb128	Signierte LEB128-Variable Länge (siehe unten)
uleb128	Vorzeichenlose LEB128-Codierung, variable Länge (siehe unten)
uleb128p1	Vorzeichenloses LEB128 plus 1, variable Länge (siehe unten)

LEB128

LEB128 (Little-Endian Base 128) ist eine Codierung mit variabler Länge für beliebige vorzeichenbehaftete oder vorzeichenlose Ganzzahlen. Das Format wurde aus der DWARF3-Spezifikation übernommen. In einer .dex-Datei wird LEB128 nur zum Codieren von 32-Bit-Werten verwendet.

Jeder LEB128-codierte Wert besteht aus ein bis fünf Byte, die zusammen einen einzelnen 32-Bit-Wert darstellen. Bei jedem Byte ist das höchstwertige Bit gesetzt, mit Ausnahme des letzten Byte in der Sequenz, bei dem das höchstwertige Bit gelöscht ist. Die verbleibenden sieben Bits jedes Byte sind Nutzdaten. Die niedrigstwertigen sieben Bits der Menge befinden sich im ersten Byte, die nächsten sieben im zweiten Byte usw. Bei einem signierten LEB128 (sleb128) wird das wichtigste Nutzlastbit des letzten Byte in der Sequenz vorzeichenerweitert, um den endgültigen Wert zu erzeugen. Im Fall ohne Vorzeichen (uleb128) werden alle Bits, die nicht explizit dargestellt werden, als 0 interpretiert.

Bitweises Diagramm eines Zwei-Byte-LEB128-Werts
Erstes Byte								Zweites Byte
1	Bit6	bit5	bit4	bit3	Bit2	Bit1	Bit0	0	bit13	bit12	Bit11	Bit10	bit9	Bit8	bit7

Die Variante uleb128p1 wird verwendet, um einen signierten Wert darzustellen, wobei die Darstellung des Werts plus eins als uleb128 codiert ist. Dadurch wird die Codierung von -1 (alternativ als der vorzeichenlose Wert 0xffffffff) – aber keiner anderen negativen Zahl – zu einem einzelnen Byte. Das ist genau dann nützlich, wenn die dargestellte Zahl entweder nicht negativ oder -1 (oder 0xffffffff) sein muss und keine anderen negativen Werte zulässig sind (oder wenn große vorzeichenlose Werte wahrscheinlich nicht benötigt werden).

Hier einige Beispiele für die Formate:

Codierte 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
Überschrift	header_item	die Überschrift
string_ids	string_id_item[]	Liste mit String-IDs. Dies sind Kennungen für alle Strings, die von dieser Datei verwendet werden, entweder für die interne Benennung (z.B. Typdeskriptoren) oder als konstante Objekte, auf die im Code verwiesen wird. Diese Liste muss nach Zeichenfolgeinhalten sortiert werden, wobei UTF-16-Codepunktwerte verwendet werden (nicht lokalisierungsabhängig). Sie darf keine doppelten Einträge enthalten.
type_ids	type_id_item[]	Liste der Typ-IDs. Dies sind Kennungen für alle Typen (Klassen, Arrays oder primitive Typen), auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss nach dem string_id-Index 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 zuerst nach Rückgabetyp (nach type_id-Index) und dann nach Argumentliste (lexikografische Sortierung, einzelne Argumente nach type_id-Index sortiert) sortiert werden. Die Liste darf keine doppelten Einträge enthalten.
field_ids	field_id_item[]	Liste der Feldkennungen. Das sind Kennzeichnungen für alle Felder, auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss sortiert werden. Dabei ist der definierende Typ (nach type_id-Index) die primäre Sortierung, der Feldname (nach string_id-Index) die sekundäre Sortierung und der Typ (nach type_id-Index) die tertiäre Sortierung. Die Liste darf keine doppelten Einträge enthalten.
method_ids	method_id_item[]	Liste der Methoden-IDs. Dies sind Kennungen für alle Methoden, auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss sortiert werden. Der definierende Typ (nach type_id-Index) ist die Hauptreihenfolge, der Methodenname (nach string_id-Index) die Zwischenreihenfolge und der Methodenprototyp (nach proto_id-Index) die Nebenreihenfolge. Die Liste darf keine doppelten Einträge enthalten.
class_defs	class_def_item[]	Liste der Klassendefinitionen. Die Klassen müssen so sortiert sein, dass die Oberklasse und die implementierten Schnittstellen einer bestimmten Klasse vor der verweisenden Klasse in der Liste aufgeführt werden. Außerdem darf eine Definition für die gleichnamige Klasse nicht mehr als einmal in der Liste vorkommen.
call_site_ids	call_site_id_item[]	Liste der Website-IDs für Anrufe. Das sind Kennungen für alle Aufrufsites, 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 nach call_site_off sortiert werden.
method_handles	method_handle_item[]	Liste der Methoden-Handles. Eine Liste aller Method Handles, auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste ist nicht sortiert und kann Duplikate enthalten, die logischerweise verschiedenen MethodHandle-Instanzen entsprechen.
Daten	ubyte[]	Datenbereich mit allen unterstützenden Daten für die oben aufgeführten Tabellen. Für die einzelnen Elemente gelten unterschiedliche Ausrichtungsanforderungen. Bei Bedarf werden vor jedem Element Füllbytes eingefügt, um die richtige 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 angegeben. Dieser Abschnitt ist in nicht verknüpften Dateien leer und kann von Laufzeitimplementierungen nach Bedarf verwendet werden.

Container format

In Version 41 wird ein neues Containerformat für DEX-Daten eingeführt, um Speicherplatz zu sparen. Mit diesem Containerformat können mehrere logische DEX-Dateien in einer einzigen physischen Datei kombiniert werden. Das neue Format ist größtenteils nur eine einfache Verkettung von Dateien im vorherigen Format, es gibt jedoch einige Unterschiede:

• Die file_size ist die Größe der logischen Datei, nicht der physischen Datei. Damit können alle logischen Dateien im Container durchlaufen werden.
• Logische DEX-Dateien können auf alle späteren Daten im Container verweisen, aber nicht auf frühere. Dadurch können DEX-Dateien Daten wie Strings gemeinsam nutzen.
• Alle Offsets sind relativ zur physischen Datei. Kein Offset relativ zum Header. So können Abschnitte mit Offsets zwischen logischen Dateien geteilt werden.
• Im Header werden zwei neue Felder hinzugefügt, um die Grenzen des Containers zu beschreiben. Dies ist eine zusätzliche Konsistenzprüfung, die das Portieren von Code in das neue Format erleichtert.
• Die data_size und data_off werden nicht mehr verwendet. Daten können auf mehrere logische Dateien verteilt sein und müssen nicht zusammenhängend sein.

Bitfeld-, String- und Konstantendefinitionen

DEX_FILE_MAGIC

Eingebettet in header_item

Das konstante Array/der konstante 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 einen Zeilenumbruch ("\n" oder 0x0a) und ein Nullbyte ("\0" oder 0x00), um die Erkennung bestimmter Formen von Beschädigung zu erleichtern. Der Wert codiert auch eine Formatversionsnummer als drei Dezimalstellen, die im Laufe der Zeit voraussichtlich monoton ansteigt, wenn sich das Format weiterentwickelt.

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

Hinweis:Die Unterstützung für Version 041 des Formats wurde mit Android 16 eingeführt und unterstützt das Containerformat.

Hinweis:Die Unterstützung für Version 040 des Formats wurde in Android 10.0 hinzugefügt. Dadurch wurde die Menge der zulässigen Zeichen in SimpleNames erweitert.

Hinweis: Die Unterstützung für Version 039 des Formats wurde mit Android 9.0 eingeführt. Dabei wurden zwei neue Bytecodes eingeführt: const-method-handle und const-method-type. Sie werden in der Tabelle Zusammenfassung der Bytecode-Gruppe beschrieben. In Android 10 wird mit Version 039 das DEX-Dateiformat erweitert, um Informationen zu verborgenen APIs aufzunehmen, die nur für DEX-Dateien im Boot-Klassenpfad gelten.

Hinweis:Die Unterstützung für Version 038 des Formats wurde in Android 8.0 hinzugefügt. In Version 038 wurden neue Bytecodes (invoke-polymorphic und invoke-custom) und Daten für Methodenhandles hinzugefügt.

Hinweis:Die Unterstützung für Version 037 des Formats wurde mit Android 7.0 eingeführt. Vor Version 037 wurde in den meisten Android-Versionen Version 035 des Formats verwendet. Der einzige Unterschied zwischen den Versionen 035 und 037 ist das Hinzufügen von Standardmethoden und die Anpassung von invoke.

Hinweis:Mindestens zwei frühere Versionen des Formats wurden in weit verbreiteten öffentlichen Softwareversionen verwendet. Beispielsweise wurde Version 009 für die M3-Releases der Android-Plattform (November bis Dezember 2007) und Version 013 für die M5-Releases der Android-Plattform (Februar bis März 2008) verwendet. In vielerlei 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 gibt die Byte-Reihenfolge der Datei an, in der sie gefunden wird. Das Standardformat .dex ist zwar Little-Endian, Implementierungen können aber auch Byte-Swapping vornehmen. Wenn bei einer Implementierung ein Header mit endian_tag = REVERSE_ENDIAN_CONSTANT anstelle von ENDIAN_CONSTANT gefunden wird, weiß sie, dass die Datei byte-vertauscht 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 anzugeben, dass ein Indexwert fehlt.

Hinweis:Dieser Wert ist nicht als 0 definiert, da dies in der Regel ein gültiger Index ist.

Der ausgewählte Wert für NO_INDEX kann als einzelnes Byte in der uleb128p1-Codierung dargestellt werden.

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

Definitionen von Zugriffsflags

Eingebettet in „class_def_item“, „encoded_field“, „encoded_method“ und „InnerClass“

Bitfelder dieser Flags werden verwendet, um die Zugänglichkeit und die allgemeinen Eigenschaften von Klassen und Klassenmitgliedern anzugeben.

Name	Wert	Für Klassen (und InnerClass-Annotationen)	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: für Paket und Unterklassen sichtbar	protected: für Paket und Unterklassen sichtbar	protected: für Paket und Unterklassen sichtbar
ACC_STATIC	0x8	* static: is not constructed with an outer this reference	static: global bis zur definierenden Klasse	static: akzeptiert kein this-Argument
ACC_FINAL	0x10	final: nicht unterklassifizierbar	final: nach der Erstellung unveränderlich	final: Nicht überschreibbar
ACC_SYNCHRONIZED	0x20			synchronized: Die zugehörige Sperre wird automatisch um den Aufruf dieser Methode herum abgerufen. Hinweis:Dieser Wert kann nur festgelegt werden, wenn auch ACC_NATIVE festgelegt ist.
ACC_VOLATILE	0x40		volatile: Regeln für den speziellen Zugriff, die zur Sicherheit von Threads beitragen
ACC_BRIDGE	0x40			Bridge-Methode, die vom Compiler automatisch als typsichere Bridge hinzugefügt wird
ACC_TRANSIENT	0x80		transient: nicht durch die Standardserialisierung gespeichert werden
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 implementierbare abstrakte Klasse
ACC_ABSTRACT	0x400	abstract: nicht direkt instanziierbar		abstract: von dieser Klasse nicht implementiert
ACC_STRICT	0x800			strictfp: strenge Regeln für die Gleitkommaarithmetik
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
(nicht verwendet)	0x8000
ACC_CONSTRUCTOR	0x10000			Konstruktormethode (Klassen- oder Instanzinitialisierer)
ACC_DECLARED_ SYNCHRONIZED	0x20000			synchronized deklariert. Hinweis:Dies hat keine Auswirkungen auf die Ausführung (außer in Bezug auf dieses Flag an sich).

* Nur für InnerClass-Anmerkungen zulässig und darf niemals in einem class_def_item aktiviert sein.

Modifizierte UTF‑8‑Codierung

Um die Unterstützung älterer Systeme zu erleichtern, werden die Stringdaten im .dex-Format in einer modifizierten UTF-8-Form codiert, die als MUTF-8 bezeichnet wird. Diese Form ist mit dem Standard-UTF-8 identisch, mit folgenden Ausnahmen:

• Es werden nur die Ein-, Zwei- und Drei-Byte-Codierungen verwendet.
• Codepunkte im Bereich U+10000 … U+10ffff werden als Ersatzpaar codiert, wobei jeder Codepunkt als drei Byte codierter Wert dargestellt wird.
• Der Codepunkt U+0000 wird in Form von zwei Byte codiert.
• Ein einfaches Nullbyte (Wert 0) gibt das Ende eines Strings an, wie es in der C-Sprache üblich ist.

Die ersten beiden Punkte oben lassen sich so zusammenfassen: MUTF-8 ist ein Codierungsformat für UTF-16 und kein direktes Codierungsformat für Unicode-Zeichen.

Die letzten beiden Punkte oben ermöglichen es, den Codepunkt U+0000 gleichzeitig in einen String einzufügen und ihn weiterhin als C-String mit Null-Terminierung zu bearbeiten.

Aufgrund der speziellen Codierung von U+0000 gibt das Ergebnis des Aufrufs der Standard-C-Funktion strcmp() für ein Paar von MUTF-8-Strings jedoch nicht immer das korrekt signierte Ergebnis des Vergleichs von ungleichen Strings an, anders als bei normalem UTF-8. Wenn die Reihenfolge (nicht nur die Gleichheit) wichtig ist, ist die einfachste Methode zum Vergleichen von MUTF-8-Strings, sie zeichenweise zu decodieren und die decodierten Werte zu vergleichen. Es sind jedoch auch cleverere Implementierungen möglich.

Weitere Informationen zur Zeichencodierung finden Sie im Unicode-Standard. MUTF-8 ähnelt eher der (relativ unbekannten) Codierung CESU-8 als UTF-8.

Codierung von „encoded_value“

Eingebettet in „annotation_element“ und „encoded_array_item“

Ein encoded_value ist ein codiertes Element mit (fast) beliebigen hierarchisch strukturierten Daten. Die Codierung soll sowohl kompakt als auch einfach zu parsen sein.

Name	Format	Beschreibung
(value_arg << 5) | value_type	ubyte	Byte, das den Typ des unmittelbar nachfolgenden value angibt, zusammen mit einem optionalen erläuternden Argument in den drei höchstwertigen Bits. Unten finden Sie die verschiedenen value-Definitionen. In den meisten Fällen codiert value_arg die Länge des unmittelbar nachfolgenden value in Byte als (size - 1), z.B. 0 bedeutet, dass der Wert ein Byte benötigt, und 7, dass er acht Byte benötigt. Es gibt jedoch Ausnahmen, wie unten beschrieben.
value	ubyte[]	Bytes, die den Wert darstellen, mit variabler Länge und für verschiedene value_type-Bytes unterschiedlich interpretiert, aber immer Little-Endian. Weitere Informationen finden Sie in den verschiedenen Wertdefinitionen unten.

Werteformat

Typname	value_type	value_arg-Format	value-Format	Beschreibung
VALUE_BYTE	0x00	(keine; muss 0 sein)	ubyte[1]	Ganzzahlwert mit Vorzeichen (1 Byte)
VALUE_SHORT	0x02	Größe – 1 (0…1)	ubyte[size]	Vorzeichenbehafteter 2‑Byte-Ganzzahlwert, vorzeichenerweitert
VALUE_CHAR	0x03	Größe – 1 (0…1)	ubyte[size]	Vorzeichenloser 2‑Byte-Ganzzahlwert, mit Nullen aufgefüllt
VALUE_INT	0x04	Größe – 1 (0…3)	ubyte[size]	Vorzeichenbehafteter 4‑Byte-Ganzzahlwert, vorzeichenerweitert
VALUE_LONG	0x06	Größe – 1 (0…7)	ubyte[size]	Vorzeichenbehafteter 8‑Byte-Ganzzahlwert, vorzeichenerweitert
VALUE_FLOAT	0x10	Größe – 1 (0…3)	ubyte[size]	Vier-Byte-Bitmuster, das rechts mit Nullen aufgefüllt und als IEEE754-32-Bit-Gleitkommawert interpretiert wird
VALUE_DOUBLE	0x11	Größe – 1 (0…7)	ubyte[size]	Acht-Byte-Bitmuster, das rechts mit Nullen aufgefüllt und als IEEE754-64-Bit-Gleitkommawert interpretiert wird.
VALUE_METHOD_TYPE	0x15	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den proto_ids-Abschnitt interpretiert wird und einen Methodentypwert darstellt
VALUE_METHOD_HANDLE	0x16	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den method_handles-Abschnitt interpretiert wird und einen Methodenhandle-Wert darstellt
VALUE_STRING	0x17	Größe – 1 (0…3)	ubyte[size]	vorzeichenloser (mit Nullen erweiterter) Vier-Byte-Ganzzahlwert, der als Index in den string_ids-Abschnitt interpretiert wird und einen Stringwert darstellt
VALUE_TYPE	0x18	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den type_ids-Abschnitt interpretiert wird und einen reflektierenden Typ-/Klassenwert darstellt
VALUE_FIELD	0x19	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den field_ids-Abschnitt interpretiert wird und einen reflektierenden Feldwert darstellt
VALUE_METHOD	0x1a	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den method_ids-Abschnitt interpretiert wird und einen reflektierenden Methodenwert darstellt
VALUE_ENUM	0x1b	Größe – 1 (0…3)	ubyte[size]	Vorzeichenloser (mit Nullen erweiterter) 4‑Byte-Ganzzahlwert, der als Index in den field_ids-Abschnitt interpretiert wird und den Wert einer Konstanten vom Aufzählungstyp darstellt
VALUE_ARRAY	0x1c	(keine; muss 0 sein)	encoded_array	ein Array von Werten im Format, das unten unter „encoded_array-Format“ angegeben ist. Die Größe von value ist in der Codierung impliziert.
VALUE_ANNOTATION	0x1d	(keine; muss 0 sein)	encoded_annotation	eine untergeordnete Anmerkung im Format, das unten unter „encoded_annotation-Format“ angegeben ist. Die Größe von value ist in der Codierung impliziert.
VALUE_NULL	0x1e	(keine; muss 0 sein)	(keine)	null-Referenzwert
VALUE_BOOLEAN	0x1f	Boolesch (0…1)	(keine)	1-Bit-Wert; 0 für false und 1 für true. Das Bit wird in der value_arg dargestellt.

Format „encoded_array“

Name	Format	Beschreibung
Größe	uleb128	Anzahl der Elemente im Array
Werte	encoded_value[size]	eine Reihe von size encoded_value-Byte-Sequenzen im Format, das in diesem Abschnitt angegeben ist, die sequenziell verkettet werden.

Format für codierte Anmerkungen

Name	Format	Beschreibung
type_idx	uleb128	Typ der Annotation. Dies muss ein Klassentyp (kein Array oder primitiver Typ) sein.
Größe	uleb128	Anzahl der Name/Wert-Zuordnungen in dieser Anmerkung
Elemente	annotation_element[size]	Elemente der Anmerkung, die direkt inline dargestellt werden (nicht als Offsets). Die Elemente müssen nach dem string_id-Index in aufsteigender Reihenfolge sortiert werden.

annotation_element-Format

Name	Format	Beschreibung
name_idx	uleb128	Elementname, dargestellt als Index im string_ids-Abschnitt. Der String muss der oben definierten Syntax für MemberName entsprechen.
value	encoded_value	Elementwert

String-Syntax

Es gibt verschiedene Arten von Elementen in einer .dex-Datei, die sich letztendlich auf einen String beziehen. Die folgenden Definitionen im BNF-Stil geben die zulässige Syntax für diese Strings an.

SimpleName

Ein SimpleName ist die Grundlage für die Syntax der Namen anderer Elemente. Das .dex-Format bietet hier viel Spielraum (deutlich mehr als die meisten gängigen Ausgangssprachen). Ein einfacher Name besteht aus einem beliebigen Low-ASCII-Buchstaben oder einer beliebigen Low-ASCII-Ziffer, einigen bestimmten Low-ASCII-Symbolen und den meisten Nicht-ASCII-Codepoints, die keine Steuer-, Leerzeichen- oder Sonderzeichen sind. Ab Version 040 sind im Format zusätzlich Leerzeichen (Unicode-Kategorie Zs) zulässig. Ersatzcodepunkte (im Bereich U+d800 … U+dfff) gelten an sich nicht als gültige Namenszeichen, aber Unicode-Zusatzzeichen sind gültig (die durch die letzte Alternative der Regel für SimpleNameChar dargestellt werden) und 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

MemberName

Wird von „field_id_item“ und „method_id_item“ verwendet.

Ein MemberName ist der Name eines Mitglieds einer Klasse. Mitglieder sind Felder, Methoden und innere Klassen.

MemberName →
	SimpleName
|	'<' SimpleName '>'

FullClassName

Ein FullClassName ist ein voll qualifizierter Klassenname, der einen optionalen Paketbezeichner gefolgt von einem erforderlichen Namen enthält.

FullClassName →
	OptionalPackagePrefix SimpleName
OptionalPackagePrefix →
	(SimpleName '/')*

TypeDescriptor

Wird von type_id_item verwendet

Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich Primitiven, Klassen, Arrays und void. Die Bedeutung der verschiedenen Versionen wird unten erläutert.

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 Kurzform eines Methodenprototyps, einschließlich Rückgabe- und Parametertypen, mit der Ausnahme, dass nicht zwischen verschiedenen Referenztypen (Klasse oder Array) 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

Das ist die Bedeutung der einzelnen Varianten von TypeDescriptor.

Syntax	Bedeutung
V	void; nur für Rückgabetypen gültig
Z	boolean
B	byte
S	short
C	char
I	int
J	long
F	float
D	double
Lfully/qualified/Name;	Kurs fully.qualified.Name
[descriptor	Array von descriptor, das rekursiv für Arrays von Arrays verwendet werden kann. Es sind jedoch maximal 255 Dimensionen zulässig.

Elemente und zugehörige Strukturen

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

header_item

Wird im Kopfzeilenbereich angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
Magie	ubyte[8] = DEX_FILE_MAGIC	magischer Wert. Weitere Informationen finden Sie oben im Abschnitt „DEX_FILE_MAGIC“.
Prüfsumme	uint	adler32-Prüfsumme des Rests der Datei (alles außer magic und diesem Feld); wird verwendet, um Dateibeschädigungen zu erkennen
Signatur	ubyte[20]	SHA-1-Signatur (Hash) des Rests der Datei (alles außer magic, checksum und diesem Feld); wird verwendet, um Dateien eindeutig zu identifizieren
file_size	uint	Größe der gesamten Datei (einschließlich des Headers) in Byte (v40 oder früher) Entfernung in Byte vom Anfang dieses Headers zum nächsten Header oder zum Ende der gesamten Datei (des Containers). (Version 41 oder höher)
header_size	uint	Größe des Headers (dieser gesamte Abschnitt) in Byte. So ist zumindest eine begrenzte Abwärts-/Vorwärtskompatibilität möglich, ohne das Format zu ungültig zu machen. muss 0x70 (112) Byte groß sein (Version 40 oder niedriger) muss 0x78 (120) Byte groß sein (v41 oder höher)
endian_tag	uint = ENDIAN_CONSTANT	Endianness-Tag. Weitere Informationen finden Sie oben im Abschnitt „ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT“.
link_size	uint	Größe des Linkbereichs oder 0, wenn diese Datei nicht statisch verknüpft ist
link_off	uint	Offset vom Anfang der Datei zum Link-Abschnitt oder 0, wenn link_size == 0. Der Offset sollte, sofern er nicht null ist, auf einen Offset im Abschnitt link_data verweisen. Das Format der Daten, auf die verwiesen wird, wird in diesem Dokument nicht angegeben. Dieses Headerfeld (und das vorherige) sind Hooks, die von Laufzeitimplementierungen verwendet werden können.
map_off	uint	Versatz vom Anfang der Datei zum Kartenelement. Der Offset, der ungleich null sein muss, sollte auf einen Offset im Abschnitt data verweisen. Die Daten sollten das unten unter „map_list“ angegebene Format haben.
string_ids_size	uint	Anzahl der Strings in der Liste der String-IDs
string_ids_off	uint	Offset vom Anfang der Datei zur Liste der String-IDs oder 0, wenn string_ids_size == 0 (zugegebenermaßen ein seltsamer Grenzfall). Der Offset sollte, sofern er nicht null ist, auf den Beginn des string_ids-Abschnitts verweisen.
type_ids_size	uint	Anzahl der Elemente in der Liste der Typkennzeichnungen, maximal 65.535
type_ids_off	uint	Offset vom Anfang der Datei zur Liste der Typ-IDs oder 0, wenn type_ids_size == 0 (zugegebenermaßen ein seltsamer Grenzfall). Der Offset sollte, sofern er nicht null ist, auf den Beginn des type_ids-Abschnitts verweisen.
proto_ids_size	uint	Anzahl der Elemente in der Liste der Prototypkennungen, maximal 65.535
proto_ids_off	uint	Offset vom Anfang der Datei zur Liste der Prototyp-IDs oder 0, wenn proto_ids_size == 0 (zugegebenermaßen ein seltsamer Grenzfall). Der Offset sollte, sofern er nicht null ist, auf den Beginn des proto_ids-Abschnitts verweisen.
field_ids_size	uint	Anzahl der Elemente in der Liste der Feld-IDs
field_ids_off	uint	Offset vom Anfang der Datei zur Liste der Feldkennungen oder 0, wenn field_ids_size == 0. Der Offset sollte, sofern er nicht null ist, auf den Beginn des field_ids-Abschnitts verweisen.
method_ids_size	uint	Anzahl der Elemente in der Liste der Methoden-IDs
method_ids_off	uint	Offset vom Anfang der Datei zur Liste der Methoden-IDs oder 0, wenn method_ids_size == 0. Der Offset sollte, sofern er nicht null ist, auf den Beginn des method_ids-Abschnitts verweisen.
class_defs_size	uint	Anzahl der Elemente in der Liste der Klassendefinitionen
class_defs_off	uint	Offset vom Anfang der Datei zur Liste der Klassendefinitionen oder 0, wenn class_defs_size == 0 (zugegebenermaßen ein seltsamer Grenzfall). Der Offset sollte, sofern er nicht null ist, auf den Beginn des class_defs-Abschnitts verweisen.
data_size	uint	Größe des data-Abschnitts in Byte. Muss ein gerades Vielfaches von „sizeof(uint)“ sein. (v40 oder älter) Nicht verwendet (v41 oder höher)
data_off	uint	Offset vom Anfang der Datei zum Anfang des Abschnitts data (Version 40 oder früher) Nicht verwendet (v41 oder höher)
container_size	uint	Dieses Feld ist nicht vorhanden. Er kann als gleich file_size angenommen werden. (v40 oder älter) Größe der gesamten Datei (einschließlich anderer DEX-Header und ihrer Daten). (Version 41 oder höher)
header_offset	uint	Dieses Feld ist nicht vorhanden. Er kann als gleich 0 angenommen werden. (v40 oder älter) Offset vom Beginn der Datei zum Beginn dieses Headers. (Version 41 oder höher)

map_list

Wird im Bereich „Daten“ angezeigt

Referenziert von „header_item“

Ausrichtung: 4 Byte

Dies ist eine Liste des gesamten Inhalts einer Datei in der richtigen Reihenfolge. Sie enthält einige Redundanzen in Bezug auf header_item, soll aber eine einfache Möglichkeit bieten, eine gesamte Datei zu durchlaufen. Ein bestimmter Typ darf in einer Karte höchstens einmal vorkommen. Es gibt keine Einschränkungen für die Reihenfolge, in der Typen vorkommen dürfen, mit Ausnahme der Einschränkungen, die sich aus dem Rest des Formats ergeben (z. B. muss zuerst ein header-Abschnitt und dann ein string_ids-Abschnitt usw. folgen). Außerdem müssen die Karteneinträge nach dem anfänglichen 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[size]	Elemente der Liste

map_item-Format

Name	Format	Beschreibung
type	ushort	Typ der Artikel (siehe Tabelle unten)
unused	ushort	(nicht verwendet)
Größe	uint	Anzahl der Elemente, die am angegebenen Offset gefunden werden sollen
kompensiert	uint	Offset vom Anfang der Datei zu den betreffenden Elementen

Typcodes

Artikeltyp	Konstante	Wert	Artikelgröße in Byte
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
map_list	TYPE_MAP_LIST	0x1000	4 + (item.size * 12)
type_list	TYPE_TYPE_LIST	0x1001	4 + (item.size * 2)
annotation_set_ref_list	TYPE_ANNOTATION_SET_REF_LIST	0x1002	4 + (item.size * 4)
annotation_set_item	TYPE_ANNOTATION_SET_ITEM	0x1003	4 + (item.size * 4)
class_data_item	TYPE_CLASS_DATA_ITEM	0x2000	implizit; muss geparst werden
code_item	TYPE_CODE_ITEM	0x2001	implizit; muss geparst werden
string_data_item	TYPE_STRING_DATA_ITEM	0x2002	implizit; muss geparst werden
debug_info_item	TYPE_DEBUG_INFO_ITEM	0x2003	implizit; muss geparst werden
annotation_item	TYPE_ANNOTATION_ITEM	0x2004	implizit; muss geparst werden
encoded_array_item	TYPE_ENCODED_ARRAY_ITEM	0x2005	implizit; muss geparst werden
annotations_directory_item	TYPE_ANNOTATIONS_DIRECTORY_ITEM	0x2006	implizit; muss geparst werden
hiddenapi_class_data_item	TYPE_HIDDENAPI_CLASS_DATA_ITEM	0xF000	implizit; muss geparst werden

string_id_item

Wird im Abschnitt „string_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
string_data_off	uint	Offset vom Anfang der Datei zu den Stringdaten für dieses Element. Der Offset sollte auf eine Position im Abschnitt data verweisen und die Daten sollten das unten unter „string_data_item“ angegebene Format haben. Für den Offset gibt es keine Ausrichtungsanforderungen.

string_data_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Name	Format	Beschreibung
utf16_size	uleb128	Größe dieses Strings in UTF-16-Codeeinheiten (entspricht in vielen Systemen der „Stringlänge“). Das ist die decodierte Länge des Strings. Die codierte Länge ergibt sich aus der Position des 0-Byte.
Daten	ubyte[]	eine Reihe von MUTF-8-Codeeinheiten (auch Oktette oder Byte genannt), gefolgt von einem Byte mit dem Wert 0. Weitere Informationen zum Datenformat finden Sie oben im Abschnitt „MUTF-8-Codierung (Modified UTF-8)“. Hinweis:Ein String, der (die codierte Form von) UTF-16-Ersatzcodeeinheiten (d. h. U+d800 … U+dfff) enthält, ist zulässig, entweder isoliert oder in falscher Reihenfolge in Bezug auf die übliche Codierung von Unicode in UTF-16. Es liegt an der Verwendung von Strings auf höherer Ebene, solche ungültigen Codierungen gegebenenfalls abzulehnen.

type_id_item

Wird im Abschnitt „type_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
descriptor_idx	uint	Index in der Liste string_ids für den Deskriptorstring dieses Typs. Der String muss der oben definierten Syntax für TypeDescriptor entsprechen.

proto_id_item

Wird im Abschnitt „proto_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
shorty_idx	uint	Index in der Liste string_ids für den Kurzform-Deskriptorstring dieses Prototyps. Der String 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 der Liste type_ids für den Rückgabetyp dieses Prototyps
parameters_off	uint	Der Offset vom Anfang der Datei zur Liste der Parametertypen für diesen Prototyp oder 0, wenn dieser Prototyp keine Parameter hat. Dieser Offset sollte, sofern er nicht null ist, im Abschnitt data angegeben werden. Die Daten dort sollten dem Format entsprechen, das unten durch "type_list" festgelegt wird. Außerdem sollte in der Liste kein Verweis auf den Typ void enthalten sein.

field_id_item

Wird im Abschnitt „field_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
class_idx	ushort	Index in der Liste type_ids für den Definierer dieses Felds. Dies muss ein Klassentyp und kein Array- oder primitiver Typ sein.
type_idx	ushort	Index in der Liste type_ids für den Typ dieses Felds
name_idx	uint	Index in die Liste string_ids für den Namen dieses Felds. Der String muss der oben definierten Syntax für MemberName entsprechen.

method_id_item

Wird im Abschnitt „method_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
class_idx	ushort	Index in der Liste type_ids für den Definierer dieser Methode. Dies muss ein Klassen- oder Arraytyp und kein primitiver Typ sein.
proto_idx	ushort	Index in der Liste proto_ids für den Prototyp dieser Methode
name_idx	uint	Index in der Liste string_ids für den Namen dieser Methode. Der String muss der oben definierten Syntax für MemberName entsprechen.

class_def_item

Wird im Abschnitt „class_defs“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
class_idx	uint	Index in der Liste type_ids für diese Klasse. Dies muss ein Klassentyp und kein Array- oder primitiver Typ sein.
access_flags	uint	Zugriffsflags für die Klasse (public, final usw.). Weitere Informationen finden Sie unter „access_flags-Definitionen“.
superclass_idx	uint	Index in der Liste type_ids für die Oberklasse oder der konstante Wert NO_INDEX, wenn diese Klasse keine Oberklasse hat (d.h., sie ist eine Stammklasse wie Object). Wenn vorhanden, muss dies ein Klassentyp und kein Array- oder primitiver Typ sein.
interfaces_off	uint	Offset vom Anfang der Datei zur Liste der Schnittstellen oder 0, wenn keine vorhanden sind. Dieser Offset sollte im Abschnitt data angegeben werden. Die Daten dort sollten dem Format entsprechen, das unten unter „type_list“ beschrieben wird. Jedes Element der Liste muss ein Klassentyp (kein Array oder primitiver Typ) sein und es darf keine Duplikate geben.
source_file_idx	uint	Index in der Liste string_ids für den Namen der Datei, die den ursprünglichen Quellcode für (mindestens den Großteil) dieser Klasse enthält, oder der spezielle Wert NO_INDEX, wenn diese Informationen nicht vorhanden sind. Die debug_info_item einer Methode kann diese Quelldatei überschreiben. Es wird jedoch davon ausgegangen, dass die meisten Klassen nur aus einer Quelldatei stammen.
annotations_off	uint	Offset vom Beginn der Datei zur Annotationsstruktur für diese Klasse oder 0, wenn es keine Annotationen für diese Klasse gibt. Dieser Offset sollte, sofern er nicht null ist, im Abschnitt data angegeben werden. Die Daten dort sollten im Format sein, das unten unter „annotations_directory_item“ angegeben ist. Alle Elemente, die sich auf diese Klasse beziehen, sollten sie als Definierer verwenden.
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. Das kann beispielsweise der Fall sein, wenn diese Klasse eine Markierungsschnittstelle ist. Der Offset sollte, sofern er nicht null ist, im Abschnitt data angegeben werden. Die Daten dort sollten dem Format entsprechen, das unten unter „class_data_item“ angegeben ist. Alle Elemente, die sich auf diese Klasse beziehen, sollten als Definierer angegeben werden.
static_values_off	uint	Offset vom Beginn 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 sollen. Dieser Offset sollte sich im Abschnitt data befinden und die Daten dort sollten das unten angegebene Format encoded_array_item haben. Die Größe des Arrays darf nicht größer als die Anzahl der static-Felder sein, die von dieser Klasse deklariert werden. Die Elemente entsprechen den static-Feldern in derselben Reihenfolge wie in der entsprechenden field_list deklariert. Der Typ jedes Arrayelements muss mit dem deklarierten Typ des entsprechenden Felds übereinstimmen. Wenn das Array weniger Elemente als static-Felder enthält, werden die verbleibenden Felder mit einem typgerechten 0 oder null initialisiert.

call_site_id_item

Wird im Abschnitt „call_site_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
call_site_off	uint	Offset vom Anfang der Datei zur Definition der Aufrufstelle. Der Offset sollte sich im Datenabschnitt befinden und die Daten dort sollten das unten unter „call_site_item“ angegebene Format haben.

call_site_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: Keine (byte-aligned)

Das call_site_item ist ein encoded_array_item, dessen Elemente den Argumenten entsprechen, die für eine Bootstrap-Linker-Methode angegeben wurden. Die ersten drei Argumente sind:

1. Ein Methodenhandle, das die Bootstrap-Linker-Methode darstellt (VALUE_METHOD_HANDLE).
2. Ein Methodenname, der vom Bootstrap-Linker aufgelöst werden soll (VALUE_STRING).
3. 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 in der Reihenfolge 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:

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

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

method_handle_item

Wird im Abschnitt „method_handles“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
method_handle_type	ushort	Typ des Methoden-Handles (siehe Tabelle unten)
unused	ushort	(nicht verwendet)
field_or_method_id	ushort	Feld- oder Methoden-ID, je nachdem, ob der MethodHandle-Typ ein Accessor oder ein Methodenaufrufer ist
unused	ushort	(nicht verwendet)

Methoden-Handle-Typcodes

Konstante	Wert	Beschreibung
METHOD_HANDLE_TYPE_STATIC_PUT	0x00	Methoden-Handle ist ein statischer Feld-Setter (Accessor)
METHOD_HANDLE_TYPE_STATIC_GET	0x01	Methoden-Handle ist ein statischer Feld-Getter (Accessor)
METHOD_HANDLE_TYPE_INSTANCE_PUT	0x02	Methodenhandle ist ein Setter für ein Instanzfeld (Accessor)
METHOD_HANDLE_TYPE_INSTANCE_GET	0x03	Methodenhandle ist ein Instanzfeld-Getter (Accessor)
METHOD_HANDLE_TYPE_INVOKE_STATIC	0x04	Methodenhandle ist ein statischer Methodenaufrufer
METHOD_HANDLE_TYPE_INVOKE_INSTANCE	0x05	Methodenhandle ist ein Aufrufer für Instanzmethoden
METHOD_HANDLE_TYPE_INVOKE_CONSTRUCTOR	0x06	Methodenhandle ist ein Konstruktormethodenaufrufer
METHOD_HANDLE_TYPE_INVOKE_DIRECT	0x07	Methodenhandle ist ein direkter Methodenaufrufer
METHOD_HANDLE_TYPE_INVOKE_INTERFACE	0x08	Methodenhandle ist ein Aufrufer für Schnittstellenmethoden

class_data_item

Referenziert von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Name	Format	Beschreibung
static_fields_size	uleb128	Anzahl der in diesem Element definierten statischen Felder
instance_fields_size	uleb128	Anzahl der in diesem Element definierten Instanzfelder
direct_methods_size	uleb128	Anzahl der in diesem Element definierten direkten Methoden
virtual_methods_size	uleb128	Anzahl der in diesem Element definierten virtuellen Methoden
static_fields	encoded_field[static_fields_size]	die definierten statischen Felder, dargestellt als Folge codierter Elemente. Die Felder müssen nach field_idx in aufsteigender Reihenfolge sortiert werden.
instance_fields	encoded_field[instance_fields_size]	die definierten Instanzfelder, dargestellt als Folge codierter Elemente. Die Felder müssen nach field_idx in aufsteigender Reihenfolge sortiert werden.
direct_methods	encoded_method[direct_methods_size]	die definierten direkten Methoden (static, private oder Konstruktor), dargestellt als Sequenz codierter Elemente. Die Methoden müssen nach method_idx in aufsteigender Reihenfolge sortiert werden.
virtual_methods	encoded_method[virtual_methods_size]	die definierten virtuellen Methoden (keine static-, private- oder Konstruktormethoden), die als Sequenz codierter Elemente dargestellt werden. Diese Liste sollte keine geerbten Methoden enthalten, sofern sie nicht von der Klasse überschrieben werden, die dieses Element repräsentiert. Die Methoden müssen nach method_idx in aufsteigender Reihenfolge sortiert werden. Die method_idx einer virtuellen Methode darf nicht mit der einer direkten Methode übereinstimmen.

Hinweis:Alle field_id- und method_id-Instanzen von Elementen müssen auf dieselbe definierende Klasse verweisen.

Format von „encoded_field“

Name	Format	Beschreibung
field_idx_diff	uleb128	Index in der Liste field_ids für die Identität dieses Felds (einschließlich Name und Deskriptor), dargestellt als Differenz zum Index des vorherigen Elements in der Liste. Der Index des ersten Elements in einer Liste wird direkt dargestellt.
access_flags	uleb128	Zugriffsflags für das Feld (public, final usw.). Weitere Informationen finden Sie unter „access_flags-Definitionen“.

Format von „encoded_method“

Name	Format	Beschreibung
method_idx_diff	uleb128	Index in der Liste method_ids für die Identität dieser Methode (einschließlich Name und Deskriptor), dargestellt als Differenz zum Index des vorherigen Elements in der Liste. Der Index des ersten Elements in einer Liste wird direkt dargestellt.
access_flags	uleb128	Zugriffsflags für die Methode (public, final usw.). Weitere Informationen finden Sie unter „access_flags-Definitionen“.
code_off	uleb128	Offset vom Anfang der Datei zur Codestruktur für diese Methode oder 0, wenn diese Methode entweder abstract oder native ist. Der Offset sollte auf einen Ort im Abschnitt data verweisen. Das Format der Daten wird unten durch „code_item“ angegeben.

type_list

Referenziert von class_def_item und proto_id_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
Größe	uint	Größe der Liste in Einträgen
Liste	type_item[size]	Elemente der Liste

type_item-Format

Name	Format	Beschreibung
type_idx	ushort	Index in der Liste type_ids

code_item

Referenziert von „encoded_method“

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
registers_size	ushort	Die Anzahl der von diesem Code verwendeten Register
ins_size	ushort	die Anzahl der Wörter der eingehenden Argumente für die Methode, für die dieser Code gilt
outs_size	ushort	Die Anzahl der Wörter des ausgehenden Argumentbereichs, die für den Methodenaufruf durch diesen Code erforderlich sind.
tries_size	ushort	Die Anzahl der try_item für diese Instanz. Wenn der Wert ungleich null ist, werden diese als tries-Array direkt nach insns angezeigt.
debug_info_off	uint	Offset vom Anfang der Datei zur Sequenz mit Debugging-Informationen (Zeilennummern + Informationen zu lokalen Variablen) für diesen Code oder 0, wenn keine Informationen vorhanden sind. Der Offset sollte, sofern er nicht null ist, auf eine Position im Abschnitt data verweisen. Das Format der Daten wird unten durch „debug_info_item“ angegeben.
insns_size	uint	Größe der Anweisungsliste in 16‑Bit-Codeeinheiten
insns	ushort[insns_size]	tatsächliches Bytecode-Array. Das Format des Codes in einem insns-Array wird im Begleitdokument Dalvik-Bytecode beschrieben. Obwohl dies als Array von ushort definiert ist, bevorzugen einige interne Strukturen die Ausrichtung auf vier Byte. Wenn dies in einer endian-getauschten Datei geschieht, wird der Tausch nur für einzelne ushort-Instanzen und nicht für die größeren internen Strukturen durchgeführt.
padding	ushort (optional) = 0	zwei Byte Padding, um tries an der Vier-Byte-Grenze auszurichten. 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 im Code Ausnahmen abgefangen werden und wie sie behandelt werden. Die Elemente des Arrays dürfen sich nicht überschneiden und müssen nach aufsteigender Adresse sortiert sein. Dieses Element ist nur vorhanden, wenn tries_size ungleich null ist.
Handler	encoded_catch_handler_list (optional)	Bytes, die eine Liste von Listen mit Catch-Typen und zugehörigen Handler-Adressen darstellen. Jeder try_item hat einen bytebasierten Offset 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 Codeblocks, der von diesem Eintrag abgedeckt wird. Die Adresse ist die Anzahl der 16-Bit-Codeeinheiten bis zum Beginn der ersten abgedeckten Anweisung.
insn_count	ushort	Anzahl der 16‑Bit-Codeeinheiten, die von diesem Eintrag abgedeckt werden. Die letzte abgedeckte Codeeinheit (einschließlich) ist start_addr + insn_count - 1.
handler_off	ushort	Der Offset in Bytes vom Beginn des zugehörigen encoded_catch_hander_list bis zum encoded_catch_handler für diesen Eintrag. Dies muss ein Offset zum Beginn eines encoded_catch_handler sein.

Format für „encoded_catch_handler_list“

Name	Format	Beschreibung
Größe	uleb128	Größe dieser Liste in Einträgen
Liste	encoded_catch_handler[handlers_size]	tatsächliche Liste der Handlerlisten, direkt dargestellt (nicht als Offsets) und sequenziell verkettet

Format von „encoded_catch_handler“

Name	Format	Beschreibung
Größe	sleb128	Anzahl der Fangtypen in dieser Liste. Wenn der Wert nicht positiv ist, entspricht er dem Negativ der Anzahl der Catch-Typen. Auf die Catches folgt ein Catch-All-Handler. Beispiel: Ein size von 0 bedeutet, dass es einen Catch-all, aber keine explizit typisierten Catches gibt. Ein size von 2 bedeutet, dass es zwei explizit typisierte Catches und keinen Catch-all gibt. Ein size von -1 bedeutet, dass es einen typisierten Catch-Block und einen Catch-All-Block gibt.
Handler	encoded_type_addr_pair[abs(size)]	Stream von abs(size)-codierten Elementen, eines für jeden abgefangenen Typ, in der Reihenfolge, in der die Typen getestet werden sollen.
catch_all_addr	uleb128 (optional)	Bytecode-Adresse des Catchall-Handlers. Dieses Element ist nur vorhanden, wenn size nicht positiv ist.

Format von encoded_type_addr_pair

Name	Format	Beschreibung
type_idx	uleb128	Index in der Liste type_ids für den Typ der abzufangenden Ausnahme
addr	uleb128	Bytecode-Adresse des zugehörigen Ausnahmehandlers

debug_info_item

Referenziert von code_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Jede debug_info_item definiert eine DWARF3-inspirierte bytecodierte Statusmaschine, die bei der Interpretation die Positionstabelle und (potenziell) die Informationen zu lokalen Variablen für eine code_item ausgibt. Die Sequenz beginnt mit einem Header variabler Länge (dessen Länge von der Anzahl der Methodenparameter abhängt), gefolgt von den Bytecodes der Zustandsmaschine und endet mit einem DBG_END_SEQUENCE-Byte.

Die Zustandsmaschine besteht aus fünf Registern. Das address-Register stellt den Befehls-Offset im zugehörigen insns_item in 16‑Bit-Codeeinheiten dar. Das address-Register beginnt am Anfang jeder debug_info-Sequenz bei 0 und darf nur monoton ansteigen. Das line-Register gibt an, welche Quellzeilennummer dem nächsten Positionsstabelleneintrag zugeordnet werden soll, der von der Statusmaschine ausgegeben wird. Sie wird im Sequenzheader initialisiert und kann sich in positiver oder negativer Richtung ändern, darf aber nie kleiner als 1 sein. Das source_file-Register stellt die Quelldatei dar, auf die sich die Zeilennummereinträge beziehen. Sie wird mit dem Wert von source_file_idx in class_def_item initialisiert. Die beiden anderen Variablen, prologue_end und epilogue_begin, sind boolesche Flags (mit false initialisiert), die angeben, ob die nächste ausgegebene Position als Methodenprolog oder -epilog betrachtet werden soll. Die Statusmaschine muss auch den Namen und Typ der letzten lokalen Variablen verfolgen, die in jedem Register für den DBG_RESTART_LOCAL-Code aktiv ist.

Der Header sieht so aus:

Name	Format	Beschreibung
line_start	uleb128	Der Anfangswert für das line-Register der Zustandsmaschine. Stellt keinen tatsächlichen Positionsdatensatz dar.
parameters_size	uleb128	Die Anzahl der codierten Parameternamen. Es sollte einen pro Methodenparameter geben, mit Ausnahme des this einer Instanzmethode, falls vorhanden.
parameter_names	uleb128p1[parameters_size]	Stringindex des Namens des Methodenparameters. Ein codierter Wert von NO_INDEX gibt an, dass für den zugehörigen Parameter kein Name verfügbar ist. Der Typdeskriptor und die Signatur werden aus dem Methodendeskriptor und der Signatur abgeleitet.

Die Bytecode-Werte sind:

Name	Wert	Formatieren	Argumente	Beschreibung
DBG_END_SEQUENCE	0x00		(keine)	Beendet eine Sequenz mit Informationen zur Fehlerbehebung für ein code_item.
DBG_ADVANCE_PC	0x01	uleb128 addr_diff	addr_diff: Betrag, der dem Adressregister hinzugefügt werden soll	Das Adressregister wird erweitert, ohne dass ein Positionseintrag ausgegeben wird.
DBG_ADVANCE_LINE	0x02	sleb128 line_diff	line_diff: Betrag, um den das Zeilenregister geändert werden soll	wird das Zeilenregister vorangestellt, ohne einen Positionsdatensatz auszugeben.
DBG_START_LOCAL	0x03	uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx	register_num: Register, das local enthält name_idx: Stringindex des Namens type_idx: Typindex des Typs	führt eine lokale Variable an der aktuellen Adresse ein. name_idx oder type_idx kann NO_INDEX sein, um anzugeben, dass der Wert unbekannt ist.
DBG_START_LOCAL_EXTENDED	0x04	uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx uleb128p1 sig_idx	register_num: Register, das lokale enthält name_idx: String-Index des Namens type_idx: Typindex des Typs sig_idx: String-Index der Typsignatur	Führt eine lokale Variable mit einer Typsignatur an der aktuellen Adresse ein. name_idx, type_idx oder sig_idx können NO_INDEX sein, um anzugeben, dass der Wert unbekannt ist. Wenn sig_idx jedoch -1 ist, könnten dieselben Daten effizienter mit dem Opcode DBG_START_LOCAL dargestellt werden. Hinweis:Weitere Informationen zum Umgang mit Signaturen finden Sie unten im Abschnitt „dalvik.annotation.Signature“.
DBG_END_LOCAL	0x05	uleb128 register_num	register_num: Register, das lokal enthalten war	kennzeichnet eine aktuell aktive lokale Variable als außerhalb des Gültigkeitsbereichs an der aktuellen Adresse.
DBG_RESTART_LOCAL	0x06	uleb128 register_num	register_num: Registrieren, um neu zu starten	führt eine lokale Variable an der aktuellen Adresse wieder ein. Der Name und der Typ sind dieselben wie beim letzten lokalen Element, das im angegebenen Register aktiv war.
DBG_SET_PROLOGUE_END	0x07		(keine)	Legt das prologue_end-Zustandsmaschinenregister fest. Der nächste hinzugefügte Positionseintrag wird als Ende eines Methodenprologs betrachtet (ein geeigneter Ort für einen Methoden-Haltepunkt). Das prologue_end-Register wird durch jeden speziellen (>= 0x0a) Opcode gelöscht.
DBG_SET_EPILOGUE_BEGIN	0x08		(keine)	legt das epilogue_begin-Zustandsmaschinenregister fest. Damit wird angegeben, dass der nächste hinzugefügte Positionseintrag als Beginn eines Methodenepilogs betrachtet werden soll. Dies ist ein geeigneter Ort, um die Ausführung vor dem Beenden der Methode anzuhalten. Das epilogue_begin-Register wird durch jeden speziellen (>= 0x0a) Opcode gelöscht.
DBG_SET_FILE	0x09	uleb128p1 name_idx	name_idx: Stringindex des Quelldateinamens; NO_INDEX, falls unbekannt	Gibt an, dass sich alle nachfolgenden Zeilennummer-Einträge auf diesen Quelldateinamen beziehen und nicht auf den Standardnamen, der in code_item angegeben ist.
Spezielle Opcodes	0x0a…0xff		(keine)	erhöht die Register line und address, gibt einen Positionseintrag aus und löscht prologue_end und epilogue_begin. Eine Beschreibung finden Sie unten.

Spezielle Opcodes

Opcodes mit Werten zwischen 0x0a und 0xff (einschließlich) verschieben sowohl die Register line als auch address um einen kleinen Betrag und geben dann einen neuen Positionstabelleneintrag aus. Die Formel für die Steigerungen lautet so:

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

Referenziert von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
class_annotations_off	uint	Offset vom Anfang der Datei zu den Anmerkungen, die direkt in der Klasse vorgenommen wurden, oder 0, wenn die Klasse keine direkten Anmerkungen enthält. Der Offset sollte, sofern er nicht null ist, auf eine Position im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.
fields_size	uint	Anzahl der Felder, die mit diesem Element annotiert sind
annotated_methods_size	uint	Anzahl der Methoden, die mit diesem Element annotiert sind
annotated_parameters_size	uint	Anzahl der Methodenparameterlisten, die mit diesem Element annotiert sind
field_annotations	field_annotation[fields_size] (optional)	Liste der zugehörigen Feldanmerkungen. Die Elemente der Liste müssen nach field_idx in aufsteigender Reihenfolge sortiert sein.
method_annotations	method_annotation[methods_size] (optional)	Liste der zugehörigen Methodenanmerkungen. Die Elemente der Liste müssen nach method_idx in aufsteigender Reihenfolge sortiert sein.
parameter_annotations	parameter_annotation[parameters_size] (optional)	Liste der zugehörigen Methodenparameter-Annotationen. Die Elemente der Liste müssen nach method_idx in aufsteigender Reihenfolge sortiert werden.

Hinweis:Alle field_id- und method_id-Instanzen von Elementen müssen auf dieselbe definierende Klasse verweisen.

Format der Feldanmerkung

Name	Format	Beschreibung
field_idx	uint	Index in der Liste field_ids für die Identität des zu annotierenden Felds
annotations_off	uint	Offset vom Beginn der Datei zur Liste der Anmerkungen für das Feld. Der Offset sollte auf einen Ort im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.

Format für method_annotation

Name	Format	Beschreibung
method_idx	uint	Index in der Liste method_ids für die Identität der Methode, die mit Anmerkungen versehen wird
annotations_off	uint	Offset vom Anfang der Datei zur Liste der Anmerkungen für die Methode. Der Offset sollte auf einen Ort im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.

Format für Parameteranmerkungen

Name	Format	Beschreibung
method_idx	uint	Index in der Liste method_ids für die Identität der Methode, deren Parameter mit Anmerkungen versehen werden
annotations_off	uint	Der Offset vom Anfang der Datei zur Liste der Anmerkungen für die Methodenparameter. Der Offset sollte auf einen Ort im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_ref_list“ angegeben.

annotation_set_ref_list

Referenziert von parameter_annotations_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
Größe	uint	Größe der Liste in Einträgen
Liste	annotation_set_ref_item[size]	Elemente der Liste

annotation_set_ref_item-Format

Name	Format	Beschreibung
annotations_off	uint	Offset vom Anfang der Datei zum referenzierten Annotationssatz oder 0, wenn für dieses Element keine Annotationen vorhanden sind. Der Offset sollte, sofern er nicht null ist, auf eine Position im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.

annotation_set_item

Referenziert von annotations_directory_item, field_annotations_item, method_annotations_item und annotation_set_ref_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
Größe	uint	Größe des Sets in Einträgen
Beiträge	annotation_off_item[size]	Elemente des Sets. Die Elemente müssen nach type_idx in aufsteigender Reihenfolge sortiert werden.

annotation_off_item-Format

Name	Format	Beschreibung
annotation_off	uint	Offset vom Anfang der Datei zu einer Annotation. Der Offset sollte auf einen Speicherort im Abschnitt data verweisen. Das Format der Daten an diesem Speicherort wird unten durch „annotation_item“ angegeben.

annotation_item

Referenziert von „annotation_set_item“

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Name	Format	Beschreibung
Sichtbarkeit	ubyte	Die beabsichtigte Sichtbarkeit dieser Anmerkung (siehe unten)
Hinweis	encoded_annotation	codierte Anmerkungsinhalte im Format, das oben unter „encoded_value-Codierung“ im Abschnitt „encoded_annotation-Format“ beschrieben wird.

Sichtbarkeitswerte

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

Name	Wert	Beschreibung
VISIBILITY_BUILD	0x00	nur zur Build-Zeit sichtbar sein sollen (z.B. während der Kompilierung von anderem Code)
VISIBILITY_RUNTIME	0x01	zur Laufzeit sichtbar
VISIBILITY_SYSTEM	0x02	zur Laufzeit sichtbar, aber nur für das zugrunde liegende System (und nicht für regulären Nutzercode)

encoded_array_item

Referenziert von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Name	Format	Beschreibung
value	encoded_array	Bytes, die den codierten Array-Wert im Format darstellen, das oben unter „encoded_array-Format“ bei „encoded_value-Codierung“ angegeben ist.

hiddenapi_class_data_item

Dieser Abschnitt enthält Daten zu eingeschränkten Schnittstellen, die von den einzelnen Klassen verwendet werden.

Hinweis:Die Funktion für verborgene APIs wurde in Android 10.0 eingeführt und gilt nur für die DEX-Dateien von Klassen im Boot-Klassenpfad. Die unten beschriebene Liste der Flags kann in zukünftigen Android-Releases erweitert werden. Weitere Informationen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.

Name	Format	Beschreibung
Größe	uint	Gesamtgröße des Abschnitts
Verschiebungen	uint[]	Array von Offsets, das nach class_idx indexiert wird. Ein Array-Eintrag mit dem Wert 0 am Index class_idx bedeutet, dass entweder keine Daten für diesen class_idx vorhanden sind oder alle verborgenen API-Flags null sind. Andernfalls ist der Arrayeintrag ungleich null und enthält einen Offset vom Anfang des Abschnitts zu einem Array mit verborgenen API-Flags für diesen class_idx.
Flags	uleb128[]	Verkettete Arrays mit verborgenen API-Flags für jede Klasse. Mögliche Flag-Werte sind in der Tabelle unten beschrieben. Flags werden in derselben Reihenfolge codiert wie Felder und Methoden in Klassendaten.

Arten von Einschränkungsflags:

Name	Wert	Beschreibung
auf die Zulassungsliste setzen	0	Schnittstellen, die frei verwendet werden können und als Teil des offiziell dokumentierten Android-Frameworks Package Index unterstützt werden.
Greylist	1	Nicht-SDK-Schnittstellen, die unabhängig vom Ziel-API-Level der Anwendung verwendet werden können.
Auf die Sperrliste setzen	2	Nicht-SDK-Schnittstellen, die unabhängig vom Ziel-API-Level 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 niedriger verwendet werden können, sofern sie nicht eingeschränkt sind.
greylist‑max‑p	4	Nicht-SDK-Schnittstellen, die für Android 9.x verwendet werden können, sofern sie nicht eingeschränkt sind.
greylist‑max‑q	5	Nicht-SDK-Schnittstellen, die für Android 10.x verwendet werden können, sofern sie nicht eingeschränkt sind.
greylist‑max‑r	6	Nicht-SDK-Schnittstellen, die für Android 11.x verwendet werden können, sofern sie nicht eingeschränkt sind.

Systemanmerkungen

Systemanmerkungen werden verwendet, um verschiedene reflektierende Informationen zu Klassen (und Methoden und Feldern) darzustellen. Auf diese Informationen wird in der Regel nur indirekt über Clientcode (nicht Systemcode) zugegriffen.

Systemanmerkungen werden in .dex-Dateien als Anmerkungen mit der Sichtbarkeit VISIBILITY_SYSTEM dargestellt.

dalvik.annotation.AnnotationDefault

Wird in Methoden in Anmerkungsoberflächen angezeigt

Jeder Annotationsschnittstelle, die Standardbindungen angeben möchte, ist eine AnnotationDefault-Annotation angehängt.

Name	Format	Beschreibung
value	Anmerkung	Die Standardbindungen für diese Anmerkung, dargestellt als Anmerkung dieses Typs. Die Annotation muss nicht alle Namen enthalten, die durch die Annotation definiert werden. Für fehlende Namen gibt es einfach keine Standardwerte.

dalvik.annotation.EnclosingClass

Wird in Kursen angezeigt

Jeder Klasse, die entweder als Mitglied einer anderen Klasse definiert ist oder anonym ist, aber nicht in einem Methodenkörper definiert ist (z.B. eine synthetische innere Klasse), ist eine EnclosingClass-Annotation angehängt. Jede Klasse, die diese Annotation hat, muss auch eine InnerClass-Annotation haben. Außerdem darf eine Klasse nicht sowohl eine EnclosingClass- als auch eine EnclosingMethod-Annotation haben.

Name	Format	Beschreibung
value	Klasse	die Klasse, die diese Klasse lexikalisch am engsten eingrenzt

dalvik.annotation.EnclosingMethod

Wird in Kursen angezeigt

Jeder Klasse, die in einem Methodenkörper definiert ist, wird eine EnclosingMethod-Annotation angehängt. Jede Klasse mit dieser Annotation muss auch eine InnerClass-Annotation haben. Außerdem darf eine Klasse nicht sowohl eine EnclosingClass- als auch eine EnclosingMethod-Annotation haben.

Name	Format	Beschreibung
value	Methode	Die Methode, die diese Klasse lexikalisch am besten eingrenzt.

dalvik.annotation.InnerClass

Wird in Kursen angezeigt

Jeder Klasse, die im lexikalischen Bereich der Definition einer anderen Klasse definiert ist, wird eine InnerClass-Annotation angehängt. Jede Klasse, die diese Annotation hat, muss entweder eine EnclosingClass-Annotation oder eine EnclosingMethod-Annotation haben.

Name	Format	Beschreibung
Name	String	Der ursprünglich deklarierte einfache Name dieser Klasse (ohne Paketpräfix). Wenn diese Klasse anonym ist, lautet der Name null.
accessFlags	int	die ursprünglich deklarierten Zugriffsflags der Klasse, die sich aufgrund einer Diskrepanz zwischen den Ausführungsmodellen der Quellsprache und der Ziel-VM von den effektiven Flags unterscheiden können

dalvik.annotation.MemberClasses

Wird in Kursen angezeigt

Jeder Klasse, in der Member-Klassen deklariert werden, ist eine MemberClasses-Annotation angehängt. Eine Member-Klasse ist eine direkte innere Klasse mit einem Namen.

Name	Format	Beschreibung
value	Klasse[]	Array der Mitgliedsklassen

dalvik.annotation.MethodParameters

Erscheint in Methoden

Hinweis:Diese Anmerkung wurde nach Android 7.1 hinzugefügt. Die Anwesenheit in früheren Android-Versionen wird ignoriert.

Eine MethodParameters-Anmerkung ist optional und kann verwendet werden, um Parametermetadaten wie Parameternamen und Modifizierer anzugeben.

Die Annotation kann für eine Methode oder einen Konstruktor weggelassen werden, wenn die Parametermetadaten zur Laufzeit nicht erforderlich sind. Mit java.lang.reflect.Parameter.isNamePresent() können Sie prüfen, ob Metadaten für einen Parameter vorhanden sind. Die zugehörigen Reflection-Methoden wie java.lang.reflect.Parameter.getName() greifen zur Laufzeit auf das Standardverhalten zurück, wenn die Informationen nicht vorhanden sind.

Wenn Parametermetadaten enthalten sind, müssen Compiler Informationen für generierte Klassen wie Enums einfügen, da die Parametermetadaten angeben, ob ein Parameter synthetisch oder obligatorisch ist.

Eine MethodParameters-Annotation beschreibt nur einzelne Methodenparameter. Daher können Compiler die Annotation bei Konstruktoren und Methoden ohne Parameter aus Gründen der Codegröße und Laufzeiteffizienz vollständig weglassen.

Die unten dokumentierten Arrays müssen dieselbe Größe wie die method_id_item-DEX-Struktur haben, die der Methode zugeordnet ist. Andernfalls wird zur Laufzeit eine java.lang.reflect.MalformedParametersException ausgelöst.

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

Da MethodParameters alle formalen Methodenparameter beschreibt, auch solche, die nicht explizit oder implizit im Quellcode deklariert sind, kann sich die Größe der Arrays von der Signatur oder anderen Metadateninformationen unterscheiden, die nur auf expliziten Parametern basieren, die im Quellcode deklariert sind. MethodParameters enthält auch keine Informationen zu Typanmerkungs-Empfängerparametern, die in der tatsächlichen Methodensignatur nicht vorhanden sind.

Name	Format	Beschreibung
namen	String[]	Die Namen der formalen Parameter für die zugehörige Methode. Das Array darf nicht null sein, muss aber leer sein, wenn keine formalen Parameter vorhanden sind. Ein Wert im Array muss „null“ sein, wenn der formale Parameter mit diesem Index keinen Namen hat. Wenn Parametername-Strings leer sind oder „.“, „;“, „[“ oder „/“ enthalten, wird zur Laufzeit eine java.lang.reflect.MalformedParametersException ausgelöst.
accessFlags	int[]	Die Zugriffsflags der formalen Parameter für die zugehörige Methode. Das Array darf nicht null sein, muss aber leer sein, wenn keine formalen Parameter vorhanden sind. Der Wert ist eine Bitmaske mit den folgenden Werten: 0x0010 : final, der Parameter wurde als „final“ deklariert. 0x1000 : synthetisch, der Parameter wurde vom Compiler eingeführt 0x8000 : vorgeschrieben, der Parameter ist synthetisch, wird aber auch durch die Sprachspezifikation impliziert Wenn Bits außerhalb dieser Menge festgelegt sind, wird zur Laufzeit eine java.lang.reflect.MalformedParametersException ausgelöst.

dalvik.annotation.Signature

Wird für Klassen, Felder und Methoden angezeigt

Jeder Klasse, jedem Feld und jeder Methode, die in Bezug auf einen komplizierteren Typ als einen type_id_item definiert ist, ist eine Signature-Annotation angehängt. Im .dex-Format wird das Format für Signaturen nicht definiert. Es soll lediglich in der Lage sein, alle Signaturen darzustellen, die für eine erfolgreiche Implementierung der Semantik einer Quellsprache erforderlich sind. Daher werden Signaturen in der Regel nicht von Implementierungen virtueller Maschinen geparst (oder überprüft). Die Signaturen werden einfach an APIs und Tools der höheren Ebene (z. B. Debugger) übergeben. Jede Verwendung einer Signatur sollte daher so geschrieben werden, dass keine Annahmen darüber getroffen werden, dass nur gültige Signaturen empfangen werden. Es sollte explizit gegen die Möglichkeit einer syntaktisch ungültigen Signatur abgesichert werden.

Da Signatur-Strings in der Regel viele doppelte Inhalte enthalten, wird eine Signature-Annotation als Array von Strings definiert. Doppelte Elemente verweisen dabei natürlich auf dieselben zugrunde liegenden Daten. Die Signatur ist die Verkettung aller Strings im Array. Es gibt keine Regeln dafür, wie eine Signatur in separate Strings aufgeteilt werden soll. Das liegt ganz an den Tools, mit denen .dex-Dateien generiert werden.

Name	Format	Beschreibung
value	String[]	Die Signatur dieser Klasse oder dieses Mitglieds als Array von Strings, die verkettet werden sollen.

dalvik.annotation.Throws

Erscheint in Methoden

Jeder Methode, die deklariert ist, um einen oder mehrere Ausnahmetypen auszulösen, ist eine Throws-Annotation angefügt.

Name	Format	Beschreibung
value	Klasse[]	das Array der ausgelösten Ausnahmetypen