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

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.

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:

Dateilayout

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.

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

Werteformat

Format „encoded_array“

Format für codierte Anmerkungen

annotation_element-Format

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.

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, der einen optionalen Paketbezeichner gefolgt von einem erforderlichen Namen enthält.

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.

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.

TypeDescriptor-Semantik

Das ist die Bedeutung der einzelnen Varianten von TypeDescriptor.

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

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.

map_item-Format

Typcodes

string_id_item

Wird im Abschnitt „string_ids“ angezeigt

Ausrichtung: 4 Byte

string_data_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

type_id_item

Wird im Abschnitt „type_ids“ angezeigt

Ausrichtung: 4 Byte

proto_id_item

Wird im Abschnitt „proto_ids“ angezeigt

Ausrichtung: 4 Byte

field_id_item

Wird im Abschnitt „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 Abschnitt „call_site_ids“ angezeigt

Ausrichtung: 4 Byte

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

Methoden-Handle-Typcodes

class_data_item

Referenziert von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

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

Format von „encoded_field“

Format von „encoded_method“

type_list

Referenziert von class_def_item und proto_id_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

type_item-Format

code_item

Referenziert von „encoded_method“

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

try_item-Format

Format für „encoded_catch_handler_list“

Format von „encoded_catch_handler“

Format von encoded_type_addr_pair

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:

Die Bytecode-Werte sind:

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

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

Format der Feldanmerkung

Format für method_annotation

Format für Parameteranmerkungen

annotation_set_ref_list

Referenziert von parameter_annotations_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: 4 Byte

annotation_set_ref_item-Format

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

annotation_off_item-Format

annotation_item

Referenziert von „annotation_set_item“

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

Sichtbarkeitswerte

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

encoded_array_item

Referenziert von class_def_item

Wird im Bereich „Daten“ angezeigt

Ausrichtung: keine (byte-aligned)

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.

Arten von Einschränkungsflags:

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.

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.

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.

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.

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.

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.

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.

dalvik.annotation.Throws

Erscheint in Methoden

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