Ausführbares Dalvik-Format

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

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.

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:

Dateilayout

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.

* 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.

Werteformate

Format „encoded_array“

Format „encoded_annotation“

annotation_element format

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.

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.

FullClassName

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

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.

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.

TypeDescriptor-Semantik

Das ist die Bedeutung der einzelnen Varianten von TypeDescriptor.

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

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.

map_item format

TypeCodes

string_id_item

Wird im Abschnitt „string_ids“ angezeigt.

Ausrichtung: 4 Byte

string_data_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

type_id_item

Wird im Bereich „type_ids“ angezeigt.

Ausrichtung: 4 Byte

proto_id_item

Wird im Abschnitt „proto_ids“ angezeigt

Ausrichtung: 4 Byte

field_id_item

Wird im Bereich „field_ids“ angezeigt

Ausrichtung: 4 Byte

method_id_item

Wird im Abschnitt „method_ids“ angezeigt

Ausrichtung: 4 Byte

class_def_item

Wird im Abschnitt „class_defs“ angezeigt

Ausrichtung: 4 Byte

call_site_id_item

Wird im Bereich „call_site_ids“ angezeigt

Ausrichtung: 4 Byte

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

Codes für den Typ des Methoden-Handles

class_data_item

Verweis von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

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

Format von „encoded_field“

Format „encoded_method“

type_list

Wird von „class_def_item“ und „proto_id_item“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

type_item-Format

code_item

Wird von „encoded_method“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

try_item-Format

encoded_catch_handler_list format

Format „encoded_catch_handler“

encoded_type_addr_pair-Format

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:

Die Bytecode-Werte sind:

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

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

Format von „field_annotation“

format „method_annotation“

Format „parameter_annotation“

annotation_set_ref_list

Verweis von parameter_annotations_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

annotation_set_ref_item format

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

annotation_off_item format

annotation_item

Wird von „annotation_set_item“ referenziert

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

Sichtbarkeitswerte

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

encoded_array_item

Verweis von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-ausgerichtet)

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.

Arten von Einschränkungsflaggen:

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.

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.

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.

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.

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.

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.

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.

dalvik.annotation.Throws

Erscheint bei Methoden

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