Ausführbares Dalvik-Format

Dieses Dokument beschreibt das Layout und den Inhalt von .dex Dateien, die zum Speichern einer Reihe von Klassendefinitionen und der zugehörigen Zusatzdaten verwendet werden.

Leitfaden zu Typen

LEB128

LEB128 („ Little - Endian Base 128 “) ist eine Codierung variabler Länge für beliebige vorzeichenbehaftete oder vorzeichenlose ganzzahlige Größen. Das Format wurde der DWARF3 -Spezifikation entlehnt. In einer .dex Datei wird LEB128 immer nur zum Codieren von 32-Bit-Größen verwendet.

Jeder LEB128-codierte Wert besteht aus einem bis fünf Bytes, die zusammen einen einzelnen 32-Bit-Wert darstellen. Für jedes Byte ist das höchstwertige Bit gesetzt, mit Ausnahme des letzten Bytes in der Sequenz, dessen höchstwertiges Bit gelöscht ist. Die verbleibenden sieben Bits jedes Bytes sind Nutzdaten, wobei die niedrigstwertigen sieben Bits der Menge im ersten Byte, die nächsten sieben im zweiten Byte usw. liegen. Im Fall eines vorzeichenbehafteten LEB128 ( sleb128 ) wird das höchstwertige Nutzlastbit des letzten Bytes in der Sequenz vorzeichenerweitert, um den endgültigen Wert zu erzeugen. Im vorzeichenlosen Fall ( uleb128 ) werden alle nicht explizit dargestellten Bits als 0 interpretiert.

Die Variante uleb128p1 wird zur Darstellung eines vorzeichenbehafteten Werts verwendet, wobei die Darstellung aus dem Wert plus eins besteht, der als uleb128 codiert ist. Dies macht die Codierung von -1 (alternativ als vorzeichenloser Wert 0xffffffff gedacht) – aber keiner anderen negativen Zahl – zu einem einzelnen Byte und ist genau in den Fällen nützlich, in denen die dargestellte Zahl entweder nicht negativ oder -1 sein muss (oder 0xffffffff ) und wo keine anderen negativen Werte zulässig sind (oder wo große vorzeichenlose Werte wahrscheinlich nicht erforderlich sind).

Hier einige Beispiele für die Formate:

Dateilayout

Bitfeld-, String- und Konstantendefinitionen

DEX_FILE_MAGIC

eingebettet in header_item

Das konstante Array/String DEX_FILE_MAGIC ist die Liste der Bytes, die am Anfang einer .dex Datei stehen müssen, damit sie als solche erkannt wird. Der Wert enthält absichtlich eine neue Zeile ( "\n" oder 0x0a ) und ein Nullbyte ( "\0" oder 0x00 ), um die Erkennung bestimmter Formen der Korruption zu erleichtern. Der Wert kodiert auch eine Formatversionsnummer als drei Dezimalstellen, die voraussichtlich mit der Zeit monoton ansteigen, wenn sich das Format weiterentwickelt.

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

Hinweis: Unterstützung für Version 039 des Formats wurde in der Version Android 9.0 hinzugefügt, die zwei neue Bytecodes einführte: const-method-handle und const-method-type . (Diese werden jeweils in der Tabelle „Zusammenfassung der Bytecode-Sets“ beschrieben.) In Android 10 erweitert Version 039 das DEX-Dateiformat um versteckte API-Informationen, die nur für DEX-Dateien im Boot-Klassenpfad gelten.

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

Hinweis: Unterstützung für Version 037 des Formats wurde in der Android 7.0-Version hinzugefügt. Vor Version 037 verwendeten die meisten Android-Versionen Version 035 des Formats. Der einzige Unterschied zwischen den Versionen 035 und 037 besteht in der Hinzufügung von Standardmethoden und der Anpassung des invoke .

Hinweis: Mindestens einige frühere Versionen des Formats wurden in allgemein verfügbaren öffentlichen Softwareversionen verwendet. Beispielsweise wurde Version 009 für die M3-Versionen der Android-Plattform (November–Dezember 2007) und Version 013 für die M5-Versionen der Android-Plattform (Februar–März 2008) verwendet. In mehrfacher Hinsicht unterscheiden sich diese früheren Versionen des Formats erheblich von der in diesem Dokument beschriebenen Version.

ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT

eingebettet in header_item

Die Konstante ENDIAN_CONSTANT wird verwendet, um die Endianness der Datei anzugeben, in der sie gefunden wird. Obwohl das standardmäßige .dex Format Little-Endian ist, können sich Implementierungen dafür entscheiden, einen Byte-Austausch durchzuführen. Sollte eine Implementierung auf einen Header stoßen, dessen endian_tag REVERSE_ENDIAN_CONSTANT anstelle von ENDIAN_CONSTANT lautet, weiß sie, dass die Datei in der erwarteten Form byteweise ausgetauscht wurde.

uint ENDIAN_CONSTANT = 0x12345678;
uint REVERSE_ENDIAN_CONSTANT = 0x78563412;

NO_INDEX

eingebettet in class_def_item und debug_info_item

Die Konstante NO_INDEX wird verwendet, um anzuzeigen, dass ein Indexwert fehlt.

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

Der gewählte Wert für NO_INDEX kann als einzelnes Byte in der uleb128p1 Kodierung dargestellt werden.

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

access_flags-Definitionen

eingebettet in class_def_item, encoded_field, encoded_method und InnerClass

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

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

MUTF-8-Kodierung (modifiziertes UTF-8).

Als Zugeständnis an eine einfachere Legacy-Unterstützung kodiert das .dex Format seine Zeichenfolgendaten in einer de-facto-standardisierten, modifizierten UTF-8-Form, im Folgenden als MUTF-8 bezeichnet. Dieses Formular ist mit dem Standard-UTF-8 identisch, außer:

• Es werden nur die Ein-, Zwei- und Drei-Byte-Kodierungen verwendet.
• Codepunkte im Bereich U+10000 … U+10ffff werden als Ersatzpaar codiert, von denen jeder als drei Byte codierter Wert dargestellt wird.
• Der Codepunkt U+0000 wird in Zwei-Byte-Form codiert.
• Ein einfaches Nullbyte (Wert 0 ) gibt das Ende einer Zeichenfolge an, wie es bei der Standardinterpretation der C-Sprache der Fall ist.

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

Die letzten beiden oben genannten Elemente ermöglichen es gleichzeitig, den Codepunkt U+0000 in eine Zeichenfolge einzuschließen und ihn dennoch als nullterminierte Zeichenfolge im C-Stil zu bearbeiten.

Allerdings bedeutet die spezielle Codierung von U+0000 , dass im Gegensatz zu normalem UTF-8 das Ergebnis des Aufrufs der Standard-C-Funktion strcmp() für ein Paar von MUTF-8-Strings nicht immer das ordnungsgemäß vorzeichenbehaftete Ergebnis des Vergleichs ungleicher Strings anzeigt . Wenn die Reihenfolge (nicht nur die Gleichheit) von Bedeutung ist, besteht der einfachste Weg, MUTF-8-Zeichenfolgen zu vergleichen, darin, sie Zeichen für Zeichen zu dekodieren und die dekodierten Werte zu vergleichen. (Es sind jedoch auch cleverere Implementierungen möglich.)

Weitere Informationen zur Zeichenkodierung finden Sie im Unicode-Standard . MUTF-8 ähnelt tatsächlich eher der (relativ weniger bekannten) Kodierung CESU-8 als UTF-8 an sich.

encoded_value-Kodierung

eingebettet in annotation_element und encoded_array_item

Ein encoded_value ist ein kodierter Teil (fast) beliebiger hierarchisch strukturierter Daten. Die Kodierung soll sowohl kompakt als auch einfach zu analysieren sein.

Wertformate

encoded_array-Format

encoded_annotation-Format

annotation_element-Format

String-Syntax

Es gibt verschiedene Arten von Elementen in einer .dex Datei, die letztendlich auf eine Zeichenfolge verweisen. Die folgenden Definitionen im BNF-Stil geben die akzeptable Syntax für diese Zeichenfolgen an.

SimpleName

Ein SimpleName ist die Grundlage für die Syntax der Namen anderer Dinge. Das .dex Format bietet hier einen erheblichen Spielraum (viel mehr als die meisten gängigen Quellsprachen). Kurz gesagt besteht ein einfacher Name aus einem beliebigen Low-ASCII-alphabetischen Zeichen oder einer beliebigen Ziffer, einigen spezifischen Low-ASCII-Symbolen und den meisten Nicht-ASCII-Codepunkten, bei denen es sich nicht um Steuerzeichen, Leerzeichen oder Sonderzeichen handelt. Ab Version 040 erlaubt das Format zusätzlich Leerzeichen (Kategorie Unicode Zs ). Beachten Sie, dass Ersatzcodepunkte (im Bereich U+d800 … U+dfff ) per se nicht als gültige Namenszeichen gelten, Unicode-Ergänzungszeichen jedoch gültig sind (die durch die letzte Alternative der Regel für SimpleNameChar dargestellt werden) und sie sollten in einer Datei als Paare von Ersatzcodepunkten in der MUTF-8-Codierung dargestellt werden.

Mitgliedsname

Wird von field_id_item und method_id_item verwendet

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

Vollständiger Klassenname

Ein FullClassName ist ein vollständig qualifizierter Klassenname, einschließlich eines optionalen Paketspezifizierers, gefolgt von einem erforderlichen Namen.

TypeDescriptor

Wird von type_id_item verwendet

Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich Grundelementen, Klassen, Arrays und void . Die Bedeutung der verschiedenen Versionen finden Sie weiter unten.

ShortyDescriptor

Wird von proto_id_item verwendet

Ein ShortyDescriptor ist die Kurzformdarstellung eines Methodenprototyps, einschließlich Rückgabe- und Parametertypen, mit der Ausnahme, dass zwischen verschiedenen Referenztypen (Klasse oder Array) nicht unterschieden wird. Stattdessen werden alle Referenztypen durch ein einzelnes 'L' -Zeichen dargestellt.

TypeDescriptor -Semantik

Dies ist die Bedeutung jeder Variante von TypeDescriptor .

Elemente und zugehörige Strukturen

Dieser Abschnitt enthält Definitionen für jedes Element der obersten Ebene, das in einer .dex Datei erscheinen kann.

header_item

erscheint im Kopfbereich

Ausrichtung: 4 Bytes

Kartenliste

erscheint im Datenbereich

referenziert von header_item

Ausrichtung: 4 Bytes

Dies ist eine Liste des gesamten Inhalts einer Datei in der Reihenfolge. Es enthält eine gewisse Redundanz in Bezug auf header_item , soll aber eine einfache Form sein, die zum Durchlaufen einer gesamten Datei verwendet werden kann. Ein bestimmter Typ darf höchstens einmal in einer Karte vorkommen, es gibt jedoch keine Einschränkung hinsichtlich der Reihenfolge, in der Typen erscheinen dürfen, abgesehen von den Einschränkungen, die durch den Rest des Formats impliziert werden (z. B. muss zuerst ein header Abschnitt erscheinen, gefolgt von string_ids . Abschnitt usw.). Darüber hinaus müssen die Karteneinträge nach anfänglichem Offset sortiert sein und dürfen sich nicht überschneiden.

map_item-Format

Typencodes

string_id_item

erscheint im Abschnitt string_ids

Ausrichtung: 4 Bytes

string_data_item

erscheint im Datenbereich

Ausrichtung: keine (Byte-ausgerichtet)

type_id_item

erscheint im Abschnitt type_ids

Ausrichtung: 4 Bytes

proto_id_item

erscheint im Abschnitt proto_ids

Ausrichtung: 4 Bytes

field_id_item

erscheint im Abschnitt field_ids

Ausrichtung: 4 Bytes

method_id_item

erscheint im Abschnitt method_ids

Ausrichtung: 4 Bytes

class_def_item

erscheint im Abschnitt class_defs

Ausrichtung: 4 Bytes

call_site_id_item

erscheint im Abschnitt call_site_ids

Ausrichtung: 4 Bytes

call_site_item

erscheint im Datenbereich

Ausrichtung: keine (Byte-ausgerichtet)

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

1. Ein Methodenhandle, das die Bootstrap-Linker-Methode darstellt (VALUE_METHOD_HANDLE).
2. Ein Methodenname, den der Bootstrap-Linker auflösen 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 der Reihe nach und ohne Typkonvertierungen übergeben.

Das Methodenhandle, das die Bootstrap-Linker-Methode darstellt, muss den Rückgabetyp java.lang.invoke.CallSite haben. Die ersten drei Parametertypen sind:

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

Die Parametertypen aller zusätzlichen Argumente werden aus ihren konstanten Werten bestimmt.

method_handle_item

erscheint im Abschnitt „method_handles“.

Ausrichtung: 4 Bytes

Methodenhandel -Typ -Codes

class_data_item

Referenziert aus class_def_item

erscheint im Datenabschnitt

Ausrichtung: Keine (Byte-ausgerichtet)

Hinweis: Alle Elemente ' field_id S und method_id S müssen sich auf dieselbe definierende Klasse beziehen.

Coded_field -Format

coded_method Format

Typ_List

Bezogen von class_def_item und proto_id_item

erscheint im Datenabschnitt

Ausrichtung: 4 Bytes

Typ_item -Format

code_item

Referenziert aus coded_method

erscheint im Datenabschnitt

Ausrichtung: 4 Bytes

Try_item -Format

coded_catch_handler_list Format

coded_catch_handler Format

Coded_type_addr_pair Format

DEBUG_INFO_ITEM

Referenziert aus Code_Item

erscheint im Datenabschnitt

Ausrichtung: Keine (Byte-ausgerichtet)

Jedes debug_info_item definiert eine von DWARF3-inspirierte Byt-codierte Statusmaschine, die bei der Interpretation die Tabelle der Positionen ausgibt und (möglicherweise) die lokalen Variableninformationen für ein code_item . Die Sequenz beginnt mit einem Header mit variabler Länge (deren Länge von der Anzahl der Methodenparameter abhängt), folgt von den Statusmaschinen-Bytecodes und endet mit einem Byte DBG_END_SEQUENCE .

Die Staatsmaschine besteht aus fünf Registern. Das address repräsentiert den Anweisungsversatz in der zugehörigen insns_item in 16-Bit-Codeeinheiten. Das address beginnt bei 0 zu Beginn jeder debug_info -Sequenz und darf nur monoton erhöhen. Das line stellt dar, welche Quellliniennummer mit dem von der Statusmaschine emittierten Tabelleneintrag für die nächsten Positionen zugeordnet werden soll. Es wird im Sequenzheader initialisiert und kann sich in positiven oder negativen Richtungen ändern, dürfen jedoch niemals weniger als 1 sein. Das Register source_file repräsentiert die Quelldatei, auf die sich die Zeilennummer -Einträge beziehen. Es wird auf den Wert von source_file_idx in class_def_item initialisiert. Die beiden anderen Variablen, prologue_end und epilogue_begin , sind boolesche Flaggen (infitiert zu false ), die angeben, ob die nächste emittierte Position als Methode -Prolog oder Epilog betrachtet werden sollte. Die Statusmaschine muss auch den Namen und die Art der letzten lokalen Variablen live in jedem Register für den Code DBG_RESTART_LOCAL verfolgen.

Der Header ist wie folgt:

Die Byte -Code -Werte sind wie folgt:

Spezielle Opcodes

Opcodes mit Werten zwischen 0x0a und 0xff (inklusive) verschieben sowohl die line als auch address um einen geringen Betrag und geben dann einen neuen Eintragstabelle aus. Die Formel für die Schritte lautet wie folgt:

DBG_FIRST_SPECIAL = 0x0a  // the smallest special opcode
DBG_LINE_BASE   = -4      // the smallest line number increment
DBG_LINE_RANGE  = 15      // the number of line increments represented

adjusted_opcode = opcode - DBG_FIRST_SPECIAL

line += DBG_LINE_BASE + (adjusted_opcode % DBG_LINE_RANGE)
address += (adjusted_opcode / DBG_LINE_RANGE)

Annotationen_Directory_Item

Referenziert aus class_def_item

erscheint im Datenabschnitt

Ausrichtung: 4 Bytes

Hinweis: Alle Elemente ' field_id S und method_id S müssen sich auf dieselbe definierende Klasse beziehen.

Field_annotation Format

Method_annotation Format

Parameter_annotation Format

Annotation_Set_ref_List

Bezogen aus Parameter_annotations_Item

erscheint im Datenabschnitt

Ausrichtung: 4 Bytes

Annotation_Set_ref_item Format

Annotation_set_item

Verweis auf Annotations_Directory_Item, field_annotations_item, method_annotations_item und Annotation_set_ref_item

erscheint im Datenabschnitt

Ausrichtung: 4 Bytes

Annotation_off_item Format

Annotation_Item

Bezogen von Annotation_set_item

erscheint im Datenabschnitt

Ausrichtung: Keine (Byte-ausgerichtet)

Sichtbarkeitswerte

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

coded_array_item

Referenziert aus class_def_item

erscheint im Datenabschnitt

Ausrichtung: Keine (Byte-ausgerichtet)

hiddenapi_class_data_item

Dieser Abschnitt enthält Daten zu eingeschränkten Schnittstellen, die von jeder Klasse verwendet werden.

Hinweis: Die versteckte API -Funktion wurde in Android 10.0 eingeführt und ist nur für die DEX -Klassendateien im Startklassenpfad anwendbar. Die unten beschriebene Liste der nachstehend beschriebenen Flaggen kann in den zukünftigen Veröffentlichungen von Android erweitert werden. Weitere Informationen finden Sie unter Beschränkungen der Non-SDK-Schnittstellen .

Restriktionsflaggentypen:

Systemanmerkungen

Systemanmerkungen werden verwendet, um verschiedene reflektierende Informationen über Klassen (und Methoden und Felder) darzustellen. Diese Informationen werden im Allgemeinen nur nach dem Client-Code (Nicht-System) indirekt zugegriffen.

Systemanmerkungen werden in .dex -Dateien als Annotationen mit Sichtbarkeit auf VISIBILITY_SYSTEM dargestellt.

Dalvik.annotation.AnnotationDefault

erscheint auf Methoden in Annotationsschnittstellen

Eine AnnotationDefault -Annotation ist an jede Annotationsschnittstelle beigefügt, die Standardbindungen angeben möchte.

Dalvik.annotation.enclosingClass

erscheint auf Klassen

Eine Annotation der EnclosingClass -Annotation ist an jede Klasse beigefügt, die entweder als Mitglied einer anderen Klasse an sich definiert ist oder anonym, aber in einem Methodenkörper nicht definiert ist (z. B. eine synthetische innere Klasse). Jede Klasse, die diese Annotation hat, muss auch eine Annotation InnerClass haben. Zusätzlich darf eine Klasse nicht sowohl eine EnclosingClass als auch eine Annotation EnclosingMethod haben.

Dalvik.annotation.enclosingMethod

erscheint auf Klassen

An jeder Klasse, die in einem Methodenkörper definiert ist, ist eine EnclosingMethod -Annotation beigefügt. Jede Klasse, die diese Annotation hat, muss auch eine Annotation InnerClass haben. Zusätzlich darf eine Klasse nicht sowohl eine EnclosingClass als auch eine Annotation EnclosingMethod haben.

Dalvik.annotation.innnerClass

erscheint auf Klassen

Eine Annotation InnerClass ist an jede Klasse beigefügt, die im lexikalischen Bereich der Definition einer anderen Klasse definiert ist. Jede Klasse, die diese Annotation hat, muss entweder entweder eine Annotation für die Annotation EnclosingClass oder eine Annotation EnclosingMethod haben.

dalvik.annotation.memberclasses

erscheint auf Klassen

Eine Annotation MemberClasses ist an jede Klasse beigefügt, die Mitgliedsklassen deklariert. (Eine Mitgliedsklasse ist eine direkte innere Klasse, die einen Namen hat.)

Dalvik.annotation.methodParameters

erscheint auf Methoden

Hinweis: Diese Annotation wurde nach Android 7.1 hinzugefügt. Die Anwesenheit früherer Android -Veröffentlichungen wird ignoriert.

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

Die Annotation kann sicher aus einer Methode oder einem Konstruktor weggelassen werden, wenn die Parametermetadaten zur Laufzeit nicht erforderlich sind. java.lang.reflect.Parameter.getName() java.lang.reflect.Parameter.isNamePresent() kann verwendet werden, um zu überprüfen Wenn die Informationen nicht vorhanden sind.

Bei der Einbeziehung von Parametermetadaten müssen Compiler Informationen für generierte Klassen wie Enums enthalten, da die Parametermetadaten enthält, ob ein Parameter synthetisch oder vorgeschrieben ist oder nicht.

Eine MethodParameters -Annotation beschreibt nur einzelne Methodenparameter. Daher können Compiler die Annotation ausschließlich für Konstruktoren und Methoden mit keinen Parametern auslassen, um die Effizienz von Codegröße und Laufzeit zu willen.

Die unten dokumentierten Arrays müssen die gleiche Größe haben wie für die mit der Methode zugeordnete method_id_item Dex -Struktur, ansonsten wird eine java.lang.reflect.MalformedParametersException zur Laufzeit geworfen.

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

Da MethodParameters alle formalen Methodenparameter beschreibt, können selbst diejenigen, die nicht explizit oder implizit in Quellcode deklariert sind, die Größe der Arrays von der Signatur oder anderen Metadateninformationen unterscheidet, die nur auf expliziten Parametern basieren, die in Quellcode deklariert sind. MethodParameters enthält auch keine Informationen zu den Parametern des Typs Annotationsempfänger, die in der tatsächlichen Methodensignatur nicht vorhanden sind.

dalvik.annotation.signature

erscheint auf Klassen, Feldern und Methoden

Eine Signature ist an jede Klasse, jedes Feld oder die Methode beigefügt, die in Bezug auf einen komplizierteren Typ definiert ist als durch ein type_id_item dargestellt werden. Das .dex -Format definiert das Format für Unterschriften nicht; Es soll lediglich in der Lage sein, die Signaturen darzustellen, die eine Quellsprache für eine erfolgreiche Implementierung der Semantik dieser Sprache erfordert. Daher werden Unterschriften durch virtuelle Maschinenimplementierungen im Allgemeinen nicht analysiert (oder verifiziert). Die Unterschriften werden einfach auf höhere APIs und Tools (wie Debugger) übergeben. Jede Verwendung einer Signatur sollte daher geschrieben werden, um keine Annahmen über die Erhalt gültiger Unterschriften zu treffen, was sich ausdrücklich vor der Möglichkeit schützt, auf eine syntaktisch ungültige Signatur zu stoßen.

Da die Signature tendenziell viele doppelte Inhalte aufweisen . Es gibt keine Regeln, wie man eine Signatur in getrennte Saiten auseinanderzieht. Dies entspricht ganz den Tools, die .dex -Dateien generieren.

dalvik.annotation.throws

erscheint auf Methoden

An jeder Methode wird eine Annotation Throws , die erklärt wird, dass sie einen oder mehrere Ausnahmetypen werfen.