Ausführbares Dalvik-Format

In diesem Dokument wird 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	8-Bit-Vorzeichenlose Ganzzahl
kurz	16-Bit-Ganzzahl mit Vorzeichen, Little Endian
ushort	16-Bit-Vorzeichenlose Ganzzahl, Little Endian
int	32-Bit-Ganzzahl mit Vorzeichen, Little Endian
uint	32-Bit-Vorzeichenlose Ganzzahl, Little Endian
long	Vorzeichenbehaftete 64-Bit-Ganzzahl, Little Endian
ulong	64-Bit-Vorzeichenlose Ganzzahl, Little Endian
sleb128	signierte LEB128, variable Länge (siehe unten)
uleb128	unsignierte LEB128, variable Länge (siehe unten)
uleb128p1	unsigniertes LEB128 + 1, variable Länge (siehe unten)

LEB128

LEB128 („Little-Endian Base 128“) ist eine Codierung mit variabler Länge für beliebige vor- oder vorzeichenlose Ganzzahlmengen. Das Format wurde aus der DWARF3-Spezifikation übernommen. In einer .dex-Datei wird LEB128 nur zum Codieren von 32‑Bit-Mengen 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 Bytes in der Sequenz, bei dem das höchstwertige Bit gelöscht ist. Die verbleibenden sieben Bits jedes Bytes sind Nutzlast, wobei die sieben niedrigstwertigen Bits der Menge im ersten Byte, die nächsten sieben im zweiten Byte usw. enthalten sind. Bei einer signierten LEB128 (sleb128) wird das höchstwertige Nutzlastbit des letzten Bytes in der Sequenz signaturerweitert, um den endgültigen Wert zu erhalten. Im Fall ohne Vorzeichen (uleb128) werden alle nicht explizit dargestellten Bits als 0 interpretiert.

Bitweises Diagramm eines zwei Byte großen 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, bei dem der Wert plus eins als uleb128 codiert ist. Dadurch wird die Codierung von -1 (alternativ als der unsignierte Wert 0xffffffff betrachtet) – aber keinesfalls anderer negativer Zahlen – auf ein einzelnes Byte reduziert. 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 unsignierte Werte wahrscheinlich nicht erforderlich sind).

Hier einige Beispiele für die Formate:

Codierte Sequenz	Stand: sleb128	Stand: uleb128	Stand: 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 der String-IDs. Dies sind IDs für alle Strings, die in dieser Datei verwendet werden, entweder für die interne Benennung (z.B. Typdeskriptoren) oder als Konstantenobjekte, auf die im Code verwiesen wird. Diese Liste muss nach Stringinhalt sortiert werden, wobei UTF-16-Codepunktwerte verwendet werden (nicht länderspezifisch). Sie darf keine doppelten Einträge enthalten.
type_ids	type_id_item[]	-Liste der Typ-IDs. Dies sind die IDs 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 IDs für den Methodenprototyp. Dies sind die IDs aller Prototypen, auf die in dieser Datei verwiesen wird. Diese Liste muss 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 Feld-IDs. Dies sind IDs 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 sein, 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 untergeordnete Reihenfolge ist. Die Liste darf keine doppelten Einträge enthalten.
method_ids	method_id_item[]	Liste der Methoden-IDs. Dies sind die IDs aller Methoden, auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert sind oder nicht. Diese Liste muss sortiert sein, 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 untergeordnete Reihenfolge 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 die implementierten Schnittstellen einer bestimmten Klasse in der Liste vor der referenzierten Klasse erscheinen. Außerdem darf eine Definition für eine Klasse mit demselben Namen nicht mehrmals in der Liste vorkommen.
call_site_ids	call_site_id_item[]	Liste der Website-IDs aufrufen. Dies sind IDs 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 nach call_site_off sortiert sein.
method_handles	method_handle_item[]	Liste der Methoden-Handles. Eine Liste aller Methoden-Handle, 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 logisch verschiedenen Method-Handle-Instanzen entsprechen.
Daten	ubyte[]	Datenbereich mit allen Supportdaten für die oben aufgeführten Tabellen. Für verschiedene Elemente gelten unterschiedliche Ausrichtungsanforderungen. Falls erforderlich, werden vor jedem Element Padding-Byte eingefügt, um eine korrekte 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. In nicht verknüpften Dateien ist dieser Abschnitt leer und kann von Laufzeitimplementierungen nach Belieben verwendet werden.

Container format

Version 41 führt ein neues Containerformat für DEX-Daten ein, um Speicherplatz zu sparen. Mit diesem Containerformat können mehrere logische DEX-Dateien in einer einzigen physischen Datei kombiniert werden. Das neue Format besteht größtenteils nur aus einer naiven Konkatenierung von Dateien im vorherigen Format, mit einigen Unterschieden:

• file_size ist die Größe der logischen Datei, nicht der physischen Datei. Damit können alle logischen Dateien im Container durchgegangen werden.
• Logische dex-Dateien können auf spätere Daten im Container verweisen, aber nicht auf frühere. So können dex-Dateien Daten wie Strings miteinander teilen.
• Alle Abweichungen beziehen sich auf die physische Datei. Kein Offset ist relativ zur Überschrift. So können Abschnitte mit Abweichungen zwischen logischen Dateien freigegeben werden.
• Der Header fügt zwei neue Felder hinzu, um die Grenzen des Containers zu beschreiben. Dies ist eine zusätzliche Konsistenzprüfung und erleichtert das Portieren von Code in das neue Format.
• data_size und data_off werden jetzt nicht mehr verwendet. Die Daten können auf mehrere logische Dateien verteilt sein und müssen nicht zusammenhängen.

Bitfeld-, String- und Konstantendefinitionen

DEX_FILE_MAGIC

In „header_item“ eingebettet

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 einen neuen Zeilenvorschlag ("\n" oder 0x0a) und ein Null-Byte ("\0" oder 0x00), um bestimmte Beschädigungsformen zu erkennen. Der Wert enthält auch eine Formatversionsnummer als drei Dezimalstellen, die sich im Laufe der Zeit mit der Weiterentwicklung des Formats kontinuierlich erhöhen soll.

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

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

Hinweis: Die Unterstützung für Version 039 des Formats wurde mit der Android 9.0-Version hinzugefügt. Dabei wurden zwei neue Bytecodes eingeführt: const-method-handle und const-method-type. Diese werden in der Tabelle Zusammenfassung des Bytecode-Sets beschrieben. In Android 10, Version 039, wird das DEX-Dateiformat um versteckte API-Informationen erweitert, die nur für DEX-Dateien auf dem Boot-Klassenpfad gelten.

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

Hinweis:Die Unterstützung für Version 037 des Formats wurde mit der Android 7.0-Version hinzugefügt. Vor Version 037 wurde in den meisten Android-Versionen Version 035 des Formats verwendet. Der einzige Unterschied zwischen den Versionen 035 und 037 besteht in der Hinzufügung von Standardmethoden und der Anpassung der 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–Dezember 2007) und Version 013 für die M5-Releases der Android-Plattform (Februar–März 2008) verwendet. Diese früheren Versionen des Formats unterscheiden sich in mehreren Punkten erheblich von der in diesem Dokument beschriebenen Version.

ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT

In „header_item“ eingebettet

Die Konstante ENDIAN_CONSTANT gibt das Endianness-Format der Datei an, in der sie sich befindet. Obwohl das Standardformat .dex Little-Endian ist, kann bei Implementierungen ein Byte-Swap verwendet werden. Wenn eine Implementierung auf einen Header stößt, dessen endian_tag REVERSE_ENDIAN_CONSTANT anstelle von ENDIAN_CONSTANT ist, weiß sie, dass die Datei vom erwarteten Format in einen Byte-Swap umgewandelt 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 gibt an, dass kein Indexwert vorhanden ist.

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 in der uleb128p1-Codierung als einzelnes Byte dargestellt werden.

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

Definitionen für „access_flags“

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

Bitfelder dieser Flags geben die Barrierefreiheit und die allgemeinen Eigenschaften von Klassen und Klassenmitgliedern an.

Name	Wert	Für Kurse (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: für Paket und Unterklassen sichtbar	protected: für Pakete und Unterklassen sichtbar	protected: für Pakete und Unterklassen sichtbar
ACC_STATIC	0x8	* static: wird nicht mit einer äußeren this-Referenz erstellt	static: global für die definierende Klasse	static: nimmt kein this-Argument entgegen
ACC_FINAL	0x10	final: nicht unterteilbar	final: nach der Erstellung unveränderlich	final: nicht überschreibbar
ACC_SYNCHRONIZED	0x20			synchronized: zugehörige Sperre, die automatisch um den Aufruf dieser Methode herum erworben wird. Hinweis:Diese Einstellung ist nur gültig, wenn auch ACC_NATIVE festgelegt ist.
ACC_VOLATILE	0x40		volatile: spezielle Zugriffsregeln zur Verbesserung der Sicherheit von Threads
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 instantiierbar		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 Anmerkungsklasse 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 dass dieses Flag berücksichtigt wird.

* Nur für InnerClass-Hinweise zulässig und darf in class_def_item-Elementen nicht aktiviert sein.

Modifizierte UTF-8-Codierung

Zur besseren Unterstützung älterer Versionen werden die Stringdaten im .dex-Format in einer de-facto standardmäßigen modifizierten UTF-8-Form codiert, die im Folgenden als MUTF-8 bezeichnet wird. Diese Form ist mit der Standard-UTF-8-Codierung identisch, mit folgenden Ausnahmen:

• Es werden nur die Codierungen mit einem, zwei und drei Byte verwendet.
• Codepunkte im Bereich U+10000…U+10ffff werden als Surrogate-Paar codiert, wobei jedes als drei Byte codierter Wert dargestellt wird.
• Der Codepunkt U+0000 ist in zwei Byte codiert.
• Ein einfaches Null-Byte (Wert 0) gibt das Ende eines Strings an, wie es auch in der C-Programmiersprache üblich ist.

Die ersten beiden Punkte oben können so zusammengefasst werden: MUTF-8 ist ein Codierungsformat für UTF-16 und kein direkteres Codierungsformat für Unicode-Zeichen.

Mit den letzten beiden Punkten oben können Sie den Codepunkt U+0000 gleichzeitig in einen String einfügen und ihn trotzdem als nullterminierten String im C-Format bearbeiten.

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

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

Codierung von „encoded_value“

Eingebettet in „annotation_element“ und „encoded_array_item“

Ein encoded_value ist ein codiertes Stück (fast) beliebiger hierarchisch strukturierter 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 der unmittelbar nachfolgenden value angibt, sowie ein optionales Erläuterungsargument in den drei höherwertigen Bits. Unten finden Sie die verschiedenen Definitionen für value. In den meisten Fällen codiert value_arg die Länge der unmittelbar nachfolgenden value in Byte, z.B. (size - 1): 0 bedeutet, dass für den Wert ein Byte erforderlich ist, und 7, dass acht Byte erforderlich sind. Es gibt jedoch Ausnahmen, wie unten angegeben.
value	ubyte[]	Bytes, die den Wert darstellen, variieren in der Länge und werden für verschiedene value_type-Bytes unterschiedlich interpretiert, aber immer im Little-Endian-Format. Weitere Informationen finden Sie in den verschiedenen Wertdefinitionen unten.

Werteformate

Typname	value_type	value_arg-Format	value-Format	Beschreibung
VALUE_BYTE	0x00	(kein; muss 0 sein)	ubyte[1]	Ganzzahlwert mit Vorzeichen und einem Byte
VALUE_SHORT	0x02	size – 1 (0…1)	ubyte[size]	Vorzeichenbehafteter Ganzzahlwert mit zwei Byte, mit Vorzeichenerweiterung
VALUE_CHAR	0x03	size – 1 (0…1)	ubyte[size]	Vorzeichenloser Ganzzahlwert mit zwei Byte, mit Null erweitert
VALUE_INT	0x04	size – 1 (0…3)	ubyte[size]	Vorzeichenbehafteter Ganzzahlwert mit vier Byte, mit Vorzeichenerweiterung
VALUE_LONG	0x06	size – 1 (0…7)	ubyte[size]	Vorzeichenbehafteter Ganzzahlwert mit acht Byte, mit Vorzeichenerweiterung
VALUE_FLOAT	0x10	size – 1 (0…3)	ubyte[size]	Vier-Byte-Bitmuster, nach rechts mit Nullen erweitert und als IEEE 754-32-Bit-Gleitkommawert interpretiert
VALUE_DOUBLE	0x11	size – 1 (0…7)	ubyte[size]	Acht-Byte-Bitmuster, nach rechts mit Nullen erweitert und als IEEE 754-64-Bit-Gleitkommawert interpretiert
VALUE_METHOD_TYPE	0x15	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (auf Null erweiterter) ganzzahliger Wert mit vier Byte, der als Index in den Abschnitt proto_ids interpretiert wird und einen Methodentyp darstellt
VALUE_METHOD_HANDLE	0x16	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (auf Null erweiterter) ganzzahliger Wert mit vier Byte, der als Index in den Abschnitt method_handles interpretiert wird und einen Method-Handle-Wert darstellt
VALUE_STRING	0x17	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (nullerweiterter) ganzzahliger Wert mit vier Byte, der als Index in den Abschnitt string_ids interpretiert wird und einen Stringwert darstellt
VALUE_TYPE	0x18	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (auf Null erweiterter) Ganzzahlwert mit vier Byte, der als Index in den Abschnitt type_ids interpretiert wird und einen reflektiven Typ-/Klassenwert darstellt
VALUE_FIELD	0x19	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (nullerweiterter) ganzzahliger Wert mit vier Byte, der als Index in den Abschnitt field_ids interpretiert wird und einen reflektiven Feldwert darstellt
VALUE_METHOD	0x1a	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (auf Null erweiterter) ganzzahliger Wert mit vier Byte, der als Index in den Abschnitt method_ids interpretiert wird und einen Wert für eine reflektive Methode darstellt
VALUE_ENUM	0x1b	size – 1 (0…3)	ubyte[size]	Vorzeichenloser (auf Null erweiterter) Ganzzahlwert mit vier Byte, der als Index in den Abschnitt field_ids interpretiert wird und den Wert einer Konstante des Aufzählungstyps darstellt
VALUE_ARRAY	0x1c	(kein; muss 0 sein)	encoded_array	ein Array von Werten im Format, das unten unter „encoded_array-Format“ angegeben ist. Die Größe des value ist in der Codierung implizit.
VALUE_ANNOTATION	0x1d	(kein; muss 0 sein)	encoded_annotation	eine untergeordnete Anmerkung im Format, das unten unter „encoded_annotation-Format“ angegeben ist. Die Größe des value ist in der Codierung implizit.
VALUE_NULL	0x1e	(kein; muss 0 sein)	(none)	null-Referenzwert
VALUE_BOOLEAN	0x1f	boolean (0…1)	(none)	Ein-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-Bytefolgen im in diesem Abschnitt angegebenen Format, die nacheinander zusammengefügt werden.

Format „encoded_annotation“

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

annotation_element format

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

String syntax

In einer .dex-Datei gibt es mehrere Arten von Elementen, die letztendlich auf einen String verweisen. Die folgenden BNF-Definitionen 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 eine relativ große Flexibilität (viel mehr als die meisten gängigen Quellsprachen). Kurz gesagt: Ein einfacher Name besteht aus beliebigen Low-ASCII-Buchstaben oder -Ziffern, einigen bestimmten Low-ASCII-Symbolen und den meisten Nicht-ASCII-Codepunkten, die keine Steuerzeichen, Leerzeichen oder Sonderzeichen sind. Ab Version 040 sind im Format zusätzlich Leerzeichen (Unicode-Kategorie Zs) zulässig. Surrogate-Codepunkte (im Bereich U+d800 bis U+dfff) gelten nicht als gültige Namenszeichen. Unicode-Ergänzungszeichen sind jedoch gültig (sie werden durch die letzte Alternative der Regel für SimpleNameChar dargestellt) und sollten in einer Datei als Paare von Surrogate-Codepunkten 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.

Mitgliedername →
	SimpleName
|	'<' SimpleName '>'

FullClassName

Ein FullClassName ist ein voll qualifizierter Klassenname, einschließlich einer optionalen Paketspezifikation, gefolgt von einem erforderlichen Namen.

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

TypeDescriptor

Wird von „type_id_item“ verwendet

Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich primitiver Typen, Klassen, Arrays und void. Unten finden Sie die Bedeutung der verschiedenen Versionen.

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 Kurzdarstellung eines Methodenprototyps, einschließlich Rückgabe- und Parametertypen, mit der Ausnahme, dass keine Unterscheidung zwischen verschiedenen Referenztypen (Klasse oder Array) erfolgt. 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 gültig für Rückgabetypen
Z	boolean
B	byte
S	short
C	char
I	int
J	long
F	float
D	double
Lfully/qualified/Name;	den Kurs fully.qualified.Name
[descriptor	Array von descriptor, rekursiv verwendbar für Arrays von Arrays, wobei jedoch nicht mehr als 255 Dimensionen zulässig sind.

Elemente und zugehörige Strukturen

Dieser Abschnitt enthält Definitionen für alle übergeordneten Elemente, die in einer .dex-Datei vorkommen 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 unter „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 restlichen Teils der Datei (alles außer magic, checksum und dieses Felds); dient zur eindeutigen Identifizierung von Dateien
file_size	uint	Größe der gesamten Datei (einschließlich Header) in Byte (Version 40 oder älter) Abstand in Byte vom Anfang dieser Kopfzeile bis zur nächsten Kopfzeile oder bis zum Ende der gesamten Datei (des Containers). (Version 41 oder höher)
header_size	uint	Größe der Kopfzeile (dieser gesamte Abschnitt) in Byte. Dadurch ist zumindest eine begrenzte Abwärts-/Vorwärtskompatibilität möglich, ohne das Format ungültig zu machen. muss 0x70 (112) Byte groß sein (Version 40 oder niedriger) muss 0x78 (120) Byte groß sein (Version 41 oder höher)
endian_tag	uint = ENDIAN_CONSTANT	Endianness-Tag. Weitere Informationen finden Sie oben unter „ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT“.
link_size	uint	Größe des Linkabschnitts oder 0, wenn diese Datei nicht statisch verknüpft ist
link_off	uint	Offset vom Anfang der Datei bis zum Linkabschnitt oder 0, wenn link_size == 0. Der Offset, falls nicht null, sollte auf einen Offset im Abschnitt link_data verweisen. Das Format der Daten, auf die verwiesen wird, wird in diesem Dokument nicht angegeben. Dieses Header-Feld (und das vorherige) dienen als Hooks für die Verwendung durch Laufzeitimplementierungen.
map_off	uint	Offset vom Anfang der Datei bis zum Kartenelement. Der Offset, der nicht null sein darf, sollte auf einen Offset im Abschnitt data verweisen und die Daten müssen im Format angegeben sein, das unten unter „map_list“ angegeben ist.
string_ids_size	uint	Anzahl der Strings in der Liste der String-IDs
string_ids_off	uint	Offset vom Anfang der Datei bis zur Liste der String-IDs oder 0, wenn string_ids_size == 0 (zugegeben ein merkwürdiger Sonderfall). Der Offset, falls nicht null, sollte sich auf den Anfang des Abschnitts string_ids beziehen.
type_ids_size	uint	Anzahl der Elemente in der Liste der Typen-IDs, maximal 65.535
type_ids_off	uint	Offset vom Anfang der Datei bis zur Liste der Typen-IDs oder 0, wenn type_ids_size == 0 (zugegeben ein merkwürdiger Sonderfall). Der Offset, falls nicht null, sollte sich auf den Anfang des type_ids-Abschnitts beziehen.
proto_ids_size	uint	Anzahl der Elemente in der Liste der Prototypen-IDs, maximal 65.535
proto_ids_off	uint	Offset vom Anfang der Datei bis zur Liste der Prototyp-IDs oder 0, wenn proto_ids_size == 0 (zugegeben ein merkwürdiger Grenzfall). Der Offset, falls nicht null, sollte sich auf den Anfang des proto_ids-Abschnitts beziehen.
field_ids_size	uint	Anzahl der Elemente in der Liste der Feld-IDs
field_ids_off	uint	Offset vom Anfang der Datei bis zur Liste der Feld-IDs oder 0, wenn field_ids_size == 0. Der Offset, falls nicht null, sollte sich auf den Anfang des field_ids-Abschnitts beziehen.
method_ids_size	uint	Anzahl der Elemente in der Liste der Methoden-IDs
method_ids_off	uint	Offset vom Anfang der Datei bis zur Liste der Methoden-IDs oder 0, wenn method_ids_size == 0. Der Offset, falls nicht null, sollte sich auf den Anfang des method_ids-Abschnitts beziehen.
class_defs_size	uint	Anzahl der Elemente in der Liste der Klassendefinitionen
class_defs_off	uint	Offset vom Anfang der Datei bis zur Liste der Klassendefinitionen oder 0, wenn class_defs_size == 0 (zugegeben ein merkwürdiger Sonderfall). Der Offset, falls nicht null, sollte sich auf den Anfang des Abschnitts class_defs beziehen.
data_size	uint	Größe des data-Abschnitts in Byte. Muss ein gerades Vielfaches von sizeof(uint) sein. (Version 40 oder älter) Nicht verwendet (Version 41 oder höher)
data_off	uint	Offset vom Anfang der Datei bis zum Anfang des Abschnitts data (Version 40 oder älter) Nicht verwendet (Version 41 oder höher)
container_size	uint	Dieses Feld ist nicht vorhanden. Es kann davon ausgegangen werden, dass es file_size entspricht. (Version 40 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. Es kann davon ausgegangen werden, dass es 0 entspricht. (Version 40 oder älter) vom Anfang der Datei bis zum Beginn dieser Kopfzeile. (Version 41 oder höher)

map_list

Wird im Bereich „Daten“ angezeigt

Verweis von header_item

Ausrichtung: 4 Byte

Dies ist eine Liste des gesamten Inhalts einer Datei in der richtigen Reihenfolge. Sie enthält einige Redundanzen im Vergleich zu header_item, soll aber eine einfache Möglichkeit bieten, eine ganze Datei zu durchlaufen. Ein bestimmter Typ darf in einer Karte höchstens einmal vorkommen. Es gibt jedoch keine Einschränkungen hinsichtlich der Reihenfolge, in der die Typen erscheinen dürfen, mit Ausnahme der Einschränkungen, die sich aus dem Rest des Formats ergeben (z. B. muss ein header-Abschnitt zuerst erscheinen, gefolgt von einem string_ids-Abschnitt usw.). Außerdem müssen die Karteneinträge nach dem Anfangsoffset 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	Art der Artikel (siehe Tabelle unten)
unused	ushort	(nicht verwendet)
Größe	uint	Anzahl der Elemente, die am angegebenen Offset gefunden werden
kompensiert	uint	Offset vom Anfang der Datei zu den betreffenden Elementen

TypeCodes

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	implicit; must parse
code_item	TYPE_CODE_ITEM	0x2001	implicit; must parse
string_data_item	TYPE_STRING_DATA_ITEM	0x2002	implicit; must parse
debug_info_item	TYPE_DEBUG_INFO_ITEM	0x2003	implicit; must parse
annotation_item	TYPE_ANNOTATION_ITEM	0x2004	implicit; must parse
encoded_array_item	TYPE_ENCODED_ARRAY_ITEM	0x2005	implicit; must parse
annotations_directory_item	TYPE_ANNOTATIONS_DIRECTORY_ITEM	0x2006	implicit; must parse
hiddenapi_class_data_item	TYPE_HIDDENAPI_CLASS_DATA_ITEM	0xF000	implicit; must parse

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 einen Speicherort im Abschnitt data verweisen und die Daten müssen im Format vorliegen, das unten unter „string_data_item“ angegeben ist. Für den Versatz gibt es keine Ausrichtungsanforderungen.

string_data_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

Name	Format	Beschreibung
utf16_size	uleb128	Größe dieses Strings in UTF-16-Codeeinheiten (in vielen Systemen als „Stringlänge“ bezeichnet). 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 UTF-8-Codeeinheiten (auch Oktette oder Byte genannt), gefolgt von einem Byte mit dem Wert 0. Weitere Informationen zum Datenformat finden Sie oben unter „MUTF-8-Codierung (Modified UTF-8)“. Hinweis:Ein String, der UTF-16-Surrogate-Code-Einheiten (d. h. U+d800…U+dfff) enthält, ist zulässig. Diese können entweder einzeln oder in einer anderen Reihenfolge als bei der üblichen Unicode-Codierung in UTF-16 verwendet werden. Es liegt in der Verantwortung der Nutzer auf höherer Ebene, solche ungültigen Codierungen gegebenenfalls abzulehnen.

type_id_item

Wird im Bereich „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 Kurzstring des Beschreibungsstrings 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	Offset vom Anfang der Datei bis zur Liste der Parametertypen für diesen Prototyp oder 0, wenn dieser Prototyp keine Parameter hat. Wenn dieser Offset nicht null ist, sollte er im Abschnitt data angegeben sein und die Daten dort sollten das Format haben, das unten unter "type_list" angegeben ist. Außerdem darf in der Liste kein Verweis auf den Typ void enthalten sein.

field_id_item

Wird im Bereich „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 der 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 sein, kein primitiver Typ.
proto_idx	ushort	Index in der Liste proto_ids für den Prototyp dieser Methode
name_idx	uint	den 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 type_ids-Liste für die Superklasse oder der Konstantenwert NO_INDEX, wenn diese Klasse keine Superklasse hat (d.h., es handelt sich um eine Stammklasse wie Object). Ist dieser Wert vorhanden, muss es sich um einen Klassentyp handeln und nicht um ein Array oder einen primitiven Typ.
interfaces_off	uint	Offset vom Anfang der Datei bis zur Liste der Schnittstellen oder 0, wenn keine vorhanden sind. Dieser Offset sollte sich im Abschnitt data befinden und die Daten dort sollten das unten unter „type_list“ angegebene Format haben. Jedes Element der Liste muss ein Klassentyp (kein Array oder primitiver Typ) sein und es dürfen keine Duplikate vorhanden sein.
source_file_idx	uint	Index in der Liste string_ids für den Namen der Datei, die die Originalquelle für (mindestens den Großteil) dieser Klasse enthält, oder den Sonderwert NO_INDEX, um anzugeben, dass diese Informationen nicht verfügbar sind. Die debug_info_item einer bestimmten Methode kann diese Quelldatei überschreiben. Es wird jedoch davon ausgegangen, dass die meisten Klassen nur aus einer Quelldatei stammen.
annotations_off	uint	Offset vom Anfang der Datei bis zum Anmerkungsstruktur für diese Klasse oder 0, wenn es für diese Klasse keine Anmerkungen gibt. Dieser Offset, falls nicht null, sollte sich im Abschnitt data befinden und die Daten dort sollten im Format sein, das unten unter „annotations_directory_item“ angegeben ist. Alle Elemente müssen sich auf diese Klasse als Definitor beziehen.
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, falls nicht null, sollte sich im Abschnitt data befinden und die Daten dort sollten im Format sein, das unten unter „class_data_item“ angegeben ist. Alle Elemente müssen sich auf diese Klasse als Definitor beziehen.
static_values_off	uint	Offset vom Anfang der Datei bis zur Liste der Anfangswerte für static-Felder oder 0, wenn es keine gibt (und alle static-Felder mit 0 oder null initialisiert werden sollen). Dieser Offset sollte sich im Abschnitt data befinden und die Daten dort sollten im Format sein, das unten unter „encoded_array_item“ angegeben ist. Die Größe des Arrays darf nicht größer sein als die Anzahl der von dieser Klasse deklarierten static-Felder. Die Elemente müssen den static-Feldern in der Reihenfolge entsprechen, die in der entsprechenden field_list deklariert wurde. 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 Bereich „call_site_ids“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
call_site_off	uint	Offset vom Anfang der Datei, um die Websitedefinition aufzurufen. Der Offset sollte sich im Datenabschnitt befinden und die Daten dort sollten im Format „call_site_item“ unten angegeben sein.

call_site_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

Das „call_site_item“ ist ein „encoded_array_item“, dessen Elemente den Argumenten entsprechen, die einer Bootstrap-Linker-Methode übergeben werden. Die ersten drei Argumente sind:

1. Ein Methoden-Handle, das die Bootstrap-Linker-Methode (VALUE_METHOD_HANDLE) darstellt.
2. Ein Methodenname, der vom Bootstrap-Linker aufgelöst werden soll (VALUE_STRING).
3. Ein Methodentyp, der dem Typ des zu bearbeitenden Methodennamens entspricht (VALUE_METHOD_TYPE).

Alle zusätzlichen Argumente sind Konstantenwerte, die an die Bootstrap-Linker-Methode übergeben werden. Diese Argumente werden in der Reihenfolge und ohne Typkonvertierung übergeben.

Der Methoden-Handle, der 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 zusätzlicher 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 Typ des Methoden-Handles ein Zugriffs- oder ein Methodenaufruf ist
unused	ushort	(nicht verwendet)

Codes für den Typ des Methoden-Handles

Konstante	Wert	Beschreibung
METHOD_HANDLE_TYPE_STATIC_PUT	0x00	Der Methoden-Handle ist ein statischer Feld-Setter (Zugriffsmethode).
METHOD_HANDLE_TYPE_STATIC_GET	0x01	Method Handle ist ein statischer Feldgetter (Accessor)
METHOD_HANDLE_TYPE_INSTANCE_PUT	0x02	Method Handle ist ein Instanzfeld-Setter (Zugriffsmethode)
METHOD_HANDLE_TYPE_INSTANCE_GET	0x03	Der Methoden-Handle ist ein Instanzfeld-Getter (Zugriffsmethode).
METHOD_HANDLE_TYPE_INVOKE_STATIC	0x04	Method Handle ist ein Aufrufer einer statischen Methode
METHOD_HANDLE_TYPE_INVOKE_INSTANCE	0x05	Der Methoden-Handle ist ein Instanzmethodenaufruf
METHOD_HANDLE_TYPE_INVOKE_CONSTRUCTOR	0x06	Der Methoden-Handle ist ein Aufrufer der Konstruktormethode.
METHOD_HANDLE_TYPE_INVOKE_DIRECT	0x07	Method Handle ist ein direkter Methodenaufruf
METHOD_HANDLE_TYPE_INVOKE_INTERFACE	0x08	Der Methoden-Handle ist ein Aufrufer der Schnittstellenmethode.

class_data_item

Verweis von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

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

Hinweis:Die field_id- und method_id-Instanzen aller Elemente müssen sich auf dieselbe definierende Klasse beziehen.

Format von „encoded_field“

Name	Format	Beschreibung
field_idx_diff	uleb128	Index in der Liste field_ids für die Identität dieses Felds (enthält den Namen und den Descriptor), 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 „encoded_method“

Name	Format	Beschreibung
method_idx_diff	uleb128	Index in der Liste method_ids für die Identität dieser Methode (enthält den Namen und den Descriptor), 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 bis zur Codestruktur für diese Methode oder 0, wenn diese Methode 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

Wird von „class_def_item“ und „proto_id_item“ referenziert

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

Wird von „encoded_method“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

Name	Format	Beschreibung
registers_size	ushort	die Anzahl der Register, die von diesem Code verwendet werden
ins_size	ushort	die Anzahl der Wörter der eingehenden Argumente für die Methode, für die dieser Code bestimmt ist
outs_size	ushort	die Anzahl der Wörter des ausgehenden Argumentspeicherplatzes, die für diesen Code für die Methodenaufruf erforderlich sind
tries_size	ushort	die Anzahl der try_items für diese Instanz. Wenn der Wert ungleich 0 ist, werden sie in diesem Fall als tries-Array direkt nach dem insns angezeigt.
debug_info_off	uint	Offset vom Anfang der Datei bis zur Debug-Informationssequenz (Zeilennummern + Informationen zu lokalen Variablen) für diesen Code oder 0, wenn es einfach keine Informationen gibt. Der Offset, falls nicht null, sollte 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ächlichen Bytecode-Array. Das Format des Codes in einem insns-Array wird im Begleitdokument Dalvik-Bytecode angegeben. Beachten Sie, dass dies zwar als Array von ushort definiert ist, es aber einige interne Strukturen gibt, bei denen eine Ausrichtung auf vier Byte bevorzugt wird. Wenn sich die Datei in einer Datei mit Endian-Swap befindet, wird der Swap nur auf einzelne ushort-Instanzen und nicht auf die größeren internen Strukturen angewendet.
padding	ushort (optional) = 0	zwei Padding-Byte, damit tries auf vier Byte ausgerichtet ist. Dieses Element ist nur vorhanden, wenn tries_size ungleich 0 und insns_size ungerade ist.
Versuche	try_item[tries_size] (optional)	Array, das angibt, wo im Code Ausnahmen abgefangen und wie sie behandelt werden sollen. Die Elemente des Arrays dürfen sich nicht überschneiden und müssen in aufsteigender Adressreihenfolge angeordnet 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. Jedes try_item hat einen Byte-Offset in dieser 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 durch diesen Eintrag abgedeckt wird. Die Adresse ist eine Zählung von 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	Offset in Bytes vom Anfang der zugehörigen encoded_catch_hander_list bis zur encoded_catch_handler für diesen Eintrag. Dies muss ein Offset zum Beginn einer encoded_catch_handler sein.

encoded_catch_handler_list format

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

Format „encoded_catch_handler“

Name	Format	Beschreibung
Größe	sleb128	Anzahl der Fangarten in dieser Liste. Wenn der Wert nicht positiv ist, entspricht er der negativen Anzahl der Catch-Typen. Auf die Catches folgt dann ein Catch-all-Handler. Beispiel: Ein size von 0 bedeutet, dass es einen Catch-all-Filter, 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 eine typisierte und eine allgemeine Erfassung gibt.
Handler	encoded_type_addr_pair[abs(size)]	Stream von abs(size) codierten Elementen, jeweils eines für jeden erfassten 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.

encoded_type_addr_pair-Format

Name	Format	Beschreibung
type_idx	uleb128	Index in der Liste type_ids für den Typ der zu erfassenden Ausnahme
addr	uleb128	Bytecodeadresse des zugehörigen Ausnahmebehandlungsprogramms

debug_info_item

Verweis von „code_item“

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

Jede debug_info_item definiert einen bytecodierten Zustandsautomaten nach dem Vorbild von DWARF3, der bei der Interpretation die Positionstabelle und (potenziell) die Informationen zur lokalen Variablen für eine code_item ausgibt. Die Sequenz beginnt mit einem Header mit variabler Länge, dessen Länge von der Anzahl der Methodenparameter abhängt. Darauf folgen die Bytecodes des Zustandsautomaten und die Sequenz endet mit einem DBG_END_SEQUENCE-Byte.

Die Zustandsmaschine besteht aus fünf Registern. Das address-Register stellt den Anweisungsoffset im zugehörigen insns_item in 16‑Bit-Codeeinheiten dar. Das address-Register beginnt am Anfang jeder debug_info-Sequenz bei 0 und darf sich nur monoton erhöhen. Das line-Register gibt an, welche Quellzeilennummer dem nächsten Tabelleneintrag für Positionen zugeordnet werden soll, der vom Zustandsautomaten ausgegeben wird. Sie wird im Sequence-Header initialisiert und kann sich positiv oder negativ ändern, darf aber niemals kleiner als 1 sein. Das Register source_file steht für die Quelldatei, auf die sich die Zeilennummerneinträ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 (initialisiert auf false), die angeben, ob die nächste ausgegebene Position als Prolog oder Epilog einer Methode betrachtet werden soll. Der Zustandsautomat muss außerdem den Namen und Typ der letzten lokalen Variablen in jedem Register für den DBG_RESTART_LOCAL-Code verfolgen.

Der Header sieht so aus:

Name	Format	Beschreibung
line_start	uleb128	den Anfangswert für das line-Register des Zustandsautomaten. Stellt keinen tatsächlichen Eintrag für eine Position dar.
parameters_size	uleb128	die Anzahl der codierten Parameternamen. Es sollte einen pro Methodenparameter geben, ausgenommen den 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 Methodensignatur abgeleitet.

Die Bytecode-Werte sind:

Name	Wert	Formatieren	Argumente	Beschreibung
DBG_END_SEQUENCE	0x00		(none)	beendet eine Debug-Informationssequenz für eine code_item
DBG_ADVANCE_PC	0x01	uleb128 addr_diff	addr_diff: Betrag, der dem Adressregister hinzugefügt werden soll	das Adressregister weiter, ohne einen Positionseintrag auszugeben
DBG_ADVANCE_LINE	0x02	sleb128 line_diff	line_diff: Betrag, um den das Zeilenregister geändert werden soll	das Zeilenregister vorrückt, ohne einen Positions-Eintrag auszugeben
DBG_START_LOCAL	0x03	uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx	register_num: Register, das lokale name_idx: Stringindex des Namens type_idx: Typindex des Typs	führt an der aktuellen Adresse eine lokale Variable ein. Sowohl name_idx als auch type_idx können 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: Stringindex des Namens type_idx: Typindex des Typs sig_idx: Stringindex der Typsignatur	führt eine lokale Variable mit einer Typsignatur an der aktuellen Adresse ein. Anstelle von name_idx, type_idx oder sig_idx kann auch NO_INDEX angegeben werden, um anzugeben, dass der Wert unbekannt ist. Wenn sig_idx jedoch -1 ist, können dieselben Daten mit dem Opcode DBG_START_LOCAL effizienter dargestellt werden. Hinweis:Weitere Informationen zum Umgang mit Signaturen finden Sie unten unter „dalvik.annotation.Signature“.
DBG_END_LOCAL	0x05	uleb128 register_num	register_num: Register, das lokale	kennzeichnet eine aktuell gültige lokale Variable an der aktuellen Adresse als nicht gültig
DBG_RESTART_LOCAL	0x06	uleb128 register_num	register_num: register to restart	führt eine lokale Variable an der aktuellen Adresse wieder ein. Name und Typ entsprechen dem letzten lokalen Eintrag, der im angegebenen Register aktiv war.
DBG_SET_PROLOGUE_END	0x07		(none)	legt das prologue_end-Statusmaschinenregister fest und gibt an, dass der nächste hinzugefügte Positionseintrag als Ende eines Methodenprologs betrachtet werden soll (ein geeigneter Ort für einen Methoden-Bruchpunkt). Das prologue_end-Register wird durch einen beliebigen speziellen (>= 0x0a) Opcode gelöscht.
DBG_SET_EPILOGUE_BEGIN	0x08		(none)	legt das epilogue_begin-Statusmaschinenregister fest und gibt an, dass der nächste hinzugefügte Positionseintrag als Beginn eines Methodenepilogs betrachtet werden soll (ein geeigneter Ort, um die Ausführung vor dem Methodenende anzuhalten). Das epilogue_begin-Register wird durch einen beliebigen Spezial-Opcode (>= 0x0a) gelöscht.
DBG_SET_FILE	0x09	uleb128p1 name_idx	name_idx: Stringindex des Namens der Quelldatei; NO_INDEX, wenn unbekannt	gibt an, dass alle nachfolgenden Einträge für die Zeilennummer auf diesen Quelldateinamen verweisen, anstelle des in code_item angegebenen Standardnamens.
Spezielle Opcodes	0x0a…0xff		(none)	line und address werden weitergezählt, ein Positionseintrag wird ausgegeben und prologue_end und epilogue_begin werden gelöscht. Beschreibung siehe unten.

Spezielle Opcodes

Bei Opcodes mit Werten zwischen 0x0a und 0xff (einschließlich) werden sowohl die line- als auch die address-Register um einen kleinen Betrag verschoben und dann ein neuer Eintrag in die Positionierungstabelle ausgegeben. Die Formel für die Intervalle lautet:

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

Verweis 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 gemacht wurden, oder 0, wenn die Klasse keine direkten Anmerkungen enthält. Der Offset, falls nicht null, sollte 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 kommentiert wurden
annotated_parameters_size	uint	Anzahl der Methodenparameterlisten, die mit diesem Element kommentiert wurden
field_annotations	field_annotation[fields_size] (optional)	Liste der zugehörigen Feldanmerkungen. Die Elemente der Liste müssen in aufsteigender Reihenfolge nach field_idx sortiert sein.
method_annotations	method_annotation[methods_size] (optional)	Liste der zugehörigen Methodenanmerkungen. Die Elemente der Liste müssen in aufsteigender Reihenfolge nach method_idx sortiert sein.
parameter_annotations	parameter_annotation[parameters_size] (optional)	Liste der zugehörigen Anmerkungen zu Methodenparametern. Die Elemente der Liste müssen in aufsteigender Reihenfolge nach method_idx sortiert sein.

Hinweis:Die field_id- und method_id-Instanzen aller Elemente müssen sich auf dieselbe definierende Klasse beziehen.

Format von „field_annotation“

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 Anfang der Datei bis zur Liste der Anmerkungen für das Feld. Der Offset sollte auf einen Speicherort im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.

format „method_annotation“

Name	Format	Beschreibung
method_idx	uint	Index in der Liste method_ids für die Identität der Methode, die kommentiert wird
annotations_off	uint	Offset vom Anfang der Datei bis 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 „parameter_annotation“

Name	Format	Beschreibung
method_idx	uint	Index in der Liste method_ids für die Identität der Methode, deren Parameter kommentiert werden
annotations_off	uint	Offset vom Anfang der Datei bis 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

Verweis 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 bis zum referenzierten Anmerkungssatz oder 0, wenn es für dieses Element keine Anmerkungen gibt. Der Offset, falls nicht null, sollte auf eine Position im Abschnitt data verweisen. Das Format der Daten wird unten durch „annotation_set_item“ angegeben.

annotation_set_item

Wird von „annotations_directory_item“, „field_annotations_item“, „method_annotations_item“ und „annotation_set_ref_item“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

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

annotation_off_item format

Name	Format	Beschreibung
annotation_off	uint	Offset vom Anfang der Datei zu einer Anmerkung. 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

Wird von „annotation_set_item“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

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“ als „encoded_annotation-Format“ beschrieben wird.

Sichtbarkeitswerte

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

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

encoded_array_item

Verweis von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

Name	Format	Beschreibung
value	encoded_array	Bytes, die den codierten Arraywert im Format darstellen, das oben unter „encoded_value-Codierung“ mit „encoded_array-Format“ 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 „Ausgeblendete API“ wurde in Android 10.0 eingeführt und gilt nur für die DEX-Dateien von Klassen im Boot-Klassenpfad. Die Liste der unten beschriebenen Flags wird in zukünftigen Android-Releases möglicherweise erweitert. 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, die mit class_idx indexiert sind. Ein Arrayeintrag mit dem Wert „0“ an Index class_idx bedeutet, dass entweder keine Daten für diese class_idx vorhanden sind oder alle ausgeblendeten API-Flags den Wert „0“ haben. Andernfalls ist der Arrayeintrag ungleich null und enthält einen Offset vom Anfang des Abschnitts zu einem Array mit ausgeblendeten API-Flags für diese class_idx.
flags	uleb128[]	Konkatenierte Arrays von ausgeblendeten API-Flags für jede Klasse. Mögliche Flag-Werte sind in der folgenden Tabelle beschrieben. Flags werden in derselben Reihenfolge codiert wie Felder und Methoden in Klassendaten.

Arten von Einschränkungsflaggen:

Name	Wert	Beschreibung
Zulassungsliste	0	Schnittstellen, die frei verwendet werden können und im Rahmen 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.

Systemhinweise

Systemanmerkungen werden verwendet, um verschiedene reflektive Informationen zu Klassen (und Methoden und Feldern) darzustellen. Normalerweise wird auf diese Informationen 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 Anmerkungsoberflächen bei Methoden angezeigt

Jede Anmerkungsoberfläche, für die Standardbindungen angegeben werden sollen, ist mit der Anmerkung AnnotationDefault verknüpft.

Name	Format	Beschreibung
value	Anmerkung	die Standardbindungen für diese Anmerkung, dargestellt als Anmerkung dieses Typs. Die Anmerkung muss nicht alle Namen enthalten, die durch die Anmerkung definiert sind. Fehlende Namen haben einfach keine Standardwerte.

dalvik.annotation.EnclosingClass

Erscheint in Kursen

Jede Klasse, die entweder als Mitglied einer anderen Klasse definiert ist oder anonym, aber nicht im Methodenkörper definiert ist (z.B. eine synthetische innere Klasse), ist mit einer EnclosingClass-Anmerkung versehen. Jede Klasse mit dieser Annotation muss auch eine InnerClass-Annotation haben. Außerdem darf eine Klasse nicht sowohl eine EnclosingClass- als auch eine EnclosingMethod-Anmerkung haben.

Name	Format	Beschreibung
value	Klasse	die Klasse, die dieser Klasse lexikalisch am nächsten kommt

dalvik.annotation.EnclosingMethod

Erscheint in Kursen

Jede Klasse, die im Methodenkörper definiert ist, ist mit einer EnclosingMethod-Anmerkung versehen. Jede Klasse mit dieser Annotation muss auch eine InnerClass-Annotation haben. Außerdem darf eine Klasse nicht sowohl eine EnclosingClass- als auch eine EnclosingMethod-Anmerkung haben.

Name	Format	Beschreibung
value	Method	die Methode, die diese Klasse lexikalisch am besten umschließt

dalvik.annotation.InnerClass

Erscheint in Kursen

Jede Klasse ist mit einer InnerClass-Anmerkung verknüpft, die im lexikalischen Gültigkeitsbereich der Definition einer anderen Klasse definiert ist. Jede Klasse mit dieser Anmerkung muss entweder eine EnclosingClass-Anmerkung oder eine EnclosingMethod-Anmerkung 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 Abweichung zwischen den Ausführungsmodellen der Quellsprache und der Ziel-VM von den effektiven Flags unterscheiden können)

dalvik.annotation.MemberClasses

Erscheint in Kursen

Jede Klasse ist mit einer MemberClasses-Anmerkung versehen, in der Mitgliedsklassen deklariert werden. Eine Mitgliedsklasse ist eine direkte innere Klasse mit einem Namen.

Name	Format	Beschreibung
value	Class[]	Array der Mitgliedsklassen

dalvik.annotation.MethodParameters

Erscheint bei Methoden

Hinweis:Diese Anmerkung wurde nach Android 7.1 hinzugefügt. Die Präsenz in früheren Android-Releases wird ignoriert.

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

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

Wenn Compiler Parametermetadaten einschließen, müssen sie auch Informationen zu generierten Klassen wie Enumerationen angeben, da die Parametermetadaten angeben, ob ein Parameter synthetisch oder obligatorisch ist.

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

Die unten beschriebenen Arrays müssen dieselbe Größe wie die der mit der Methode verknüpften method_id_item-Dex-Struktur haben. Andernfalls wird bei der Laufzeit eine java.lang.reflect.MalformedParametersException geworfen.

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 diejenigen, 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 Parametern für den Empfänger der Typannotation, die nicht in der tatsächlichen Methodensignatur vorhanden sind.

Name	Format	Beschreibung
namen	String[]	Die Namen der formalen Parameter für die zugehörige Methode. Das Array darf nicht null sein, aber leer, wenn keine formellen Parameter vorhanden sind. Ein Wert im Array muss null sein, wenn der formale Parameter mit diesem Index keinen Namen hat. Wenn Parameternamen leer sind oder „.“ oder „;“ oder „[“ oder „/“ enthalten, wird während der Laufzeit eine java.lang.reflect.MalformedParametersException geworfen.
accessFlags	int[]	Die Zugriffsflags der formellen Parameter für die zugehörige Methode. Das Array darf nicht null sein, aber leer, wenn es keine formellen Parameter gibt. 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 : Erforderlich. Der Parameter ist synthetisch, aber auch in der Sprachspezifikation impliziert. Wenn außerhalb dieses Bereichs Bits gesetzt sind, wird bei der Laufzeit eine java.lang.reflect.MalformedParametersException geworfen.

dalvik.annotation.Signature

Wird für Klassen, Felder und Methoden angezeigt

Jede Klasse, jedes Feld oder jede Methode, die in Bezug auf einen komplexeren Typ definiert ist, als mit einem type_id_item darstellbar ist, ist mit einer Signature-Anmerkung versehen. Das .dex-Format definiert nicht das Format für Signaturen. Es soll lediglich alle Signaturen darstellen können, die eine Quellsprache für die erfolgreiche Implementierung der Semantik dieser Sprache benötigt. Daher werden Signaturen von virtuellen Maschinen im Allgemeinen nicht geparst (oder verifiziert). Die Signaturen werden einfach an APIs und Tools höherer Ebene (z. B. Debugger) übergeben. Die Verwendung einer Signatur sollte daher so formuliert sein, dass keine Annahmen darüber getroffen werden, dass nur gültige Signaturen empfangen werden. Es muss ausdrücklich darauf hingewiesen werden, dass eine syntaktisch ungültige Signatur auftreten kann.

Da Signaturstrings in der Regel viele duplizierte Inhalte enthalten, wird eine Signature-Anmerkung als Array von Strings definiert, wobei sich duplizierte Elemente natürlich auf dieselben zugrunde liegenden Daten beziehen. Die Signatur wird als Konkatenierung aller Strings im Array betrachtet. Es gibt keine Regeln dafür, wie eine Signatur in separate Strings zerlegt wird. Das hängt ganz von den Tools ab, mit denen .dex-Dateien generiert werden.

Name	Format	Beschreibung
value	String[]	die Signatur dieser Klasse oder dieses Mitglieds als Array von Strings, die miteinander verknüpft werden sollen

dalvik.annotation.Throws

Erscheint bei Methoden

Jede Methode, die einen oder mehrere Ausnahmetypen auswerfen soll, ist mit einer Throws-Anmerkung versehen.

Name	Format	Beschreibung
value	Class[]	das Array der geworfenen Ausnahmetypen