In diesem Dokument werden das Layout und der Inhalt von .dex
beschrieben.
-Dateien, die eine Reihe von Klassendefinitionen und die zugehörigen
Zusatzdaten.
Anleitung zu Typen
Name | Beschreibung |
---|---|
Byte | 8-Bit-Int |
Ubyte | 8-Bit-Int ohne Vorzeichen |
kurz | 16-Bit-Signiert int, Little-Endian |
Ushort | 16-Bit, unsignierte Anmeldung, Little-Endian |
int | 32-Bit-Signiert int, Little-Endian |
Uint | 32-Bit ohne Vorzeichen, Little-Endian |
long | 64-Bit-Signiert int, Little-Endian |
Ulong | 64-Bit, unsignierte Anmeldung, Little-Endian |
sleb128 | signiert LEB128, variable Länge (siehe unten) |
Uleb128 | LEB128 ohne Vorzeichen, variable Länge (siehe unten) |
Uleb128p1 | LEB128 ohne Vorzeichen plus 1 , variable Länge (siehe unten) |
LEB128
LEB128 ("Little-Endian Base 128") ist ein
Codierung mit variabler Länge für
beliebige vorzeichenbehaftete oder vorzeichenlose Ganzzahlen Das Format war
von DWARF3 übernommen
Spezifikation zu ändern. In einer .dex
-Datei wird LEB128 ausschließlich für Folgendes verwendet:
32-Bit-Mengen zu codieren.
Jeder LEB128-codierte Wert besteht aus einem bis fünf
Byte, die zusammen einen einzelnen 32-Bit-Wert darstellen. Jedes
Bei Byte ist das höchstwertige Bit gesetzt, mit Ausnahme des letzten Byte im
-Sequenz, deren wichtigstes Bit klar ist. Die verbleibenden
7 Bits von jedem Byte sind Nutzlasten, wobei die niedrigstwertige sieben
der Anzahl im ersten Byte, in den nächsten sieben im zweiten Byte
Byte usw. Im Fall eines unterzeichneten LEB128 (sleb128
)
ist das höchstwertige Nutzlast-Bit
des letzten Bytes in der Sequenz,
um den Endwert zu erzeugen. Im nicht signierten Fall
(uleb128
), sind alle nicht explizit dargestellten Bits
als 0
interpretiert.
Bitweises Diagramm eines Zwei-Byte-LEB128-Werts | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Erstes Byte | Zweites Byte | ||||||||||||||
1 |
Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0 | 0 |
Bit13 | Bit12 | Bit11 | Bit10 | Bit9 | Bit8 | Bit7 |
Die Variante uleb128p1
wird für ein signiertes
Wert, wobei der codierte Wert plus eins dargestellt wird
als uleb128
. Dadurch wird die Codierung von -1
(alternativ als vorzeichenloser Wert 0xffffffff
angesehen)
- aber keine andere negative Zahl - ein einzelnes Byte und ist
in denen die dargestellte Zahl entweder
nicht negativ oder -1
(oder 0xffffffff
) sein,
und keine anderen negativen Werte zulässig sind (oder große, vorzeichenlose
-Werte wahrscheinlich nicht erforderlich sind).
Hier einige Beispiele für Formate:
Codierte Sequenz | Als sleb128 |
Als uleb128 |
Als uleb128p1 |
---|---|---|---|
00 | 0 | 0 | -1 |
01 | 1 | 1 | 0 |
7f | -1 | 127 | 126 |
80 7f | -128 | 16256 | 16255 |
Dateilayout
Name | Format | Beschreibung |
---|---|---|
Überschrift | Header-Element | der Header |
String-IDs | string_id_item[] | Liste der Zeichenfolgenkennungen. Dies sind Kennungen für alle Strings, von dieser Datei verwendet, entweder für die interne Benennung (z.B. Typdeskriptoren) oder als konstante Objekte bezeichnet, auf die durch Code verwiesen wird. Diese Liste muss sortiert werden durch Zeichenfolgeninhalte unter Verwendung von UTF-16-Codepunktwerten (nicht in je nach Sprache) und darf keine doppelten Einträge enthalten. |
Typ-IDs | type_id_item[] | Liste der Typenkennungen. Dies sind Kennungen für alle Typen (Klassen,
Arrays oder primitive Typen), auf die in dieser Datei verwiesen wird, unabhängig davon, ob diese definiert wurden
in der Datei ist oder nicht. Diese Liste muss nach string_id sortiert werden
und darf keine doppelten Einträge enthalten.
|
proto_ids | proto_id_item[] | Liste der Prototyp-Identifikatoren. Dies sind Kennungen für alle
auf die in dieser Datei verwiesen wird. Diese Liste muss sortiert werden in
Rückgabetyp (nach type_id -Index) und dann
Nach Argumentliste (lexikografische Sortierung, einzelne Argumente
sortiert nach type_id -Index). Die Liste darf nicht
doppelte Einträge enthalten.
|
Feld-IDs | Feld_ID_Element[] | Feldkennungen. Dies sind Kennungen für alle Felder
auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert ist oder nicht. Dieses
Liste muss sortiert werden, wobei der definierende Typ (nach type_id )
Index) ist die Hauptreihenfolge, Feldname (nach string_id -Index)
ist die Zwischenreihenfolge und der Typ (nach type_id -Index)
ist die Nebenreihenfolge. Die Liste darf keine doppelten Einträge enthalten.
|
method_ids | method_id_item[] | Liste der Methodenkennungen. Dies sind Kennungen für alle Methoden
auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert ist oder nicht. Dieses
Liste muss sortiert werden, wobei der definierende Typ (nach type_id )
Index) ist die Hauptreihenfolge, Methodenname (nach string_id )
ist die Zwischenreihenfolge und
die Methode „Prototype“ (nach
proto_id -Index) die Nebenanordnung ist. Die Liste darf nicht
doppelte Einträge enthalten.
|
Klassendefinitionen | class_def_item[] | Liste der Klassendefinitionen. Die Klassen müssen so geordnet sein, dass eine bestimmte Die Basisklasse und implementierten Schnittstellen der Klasse werden in der vor der verweisenden Klasse stehen. Außerdem ist es ungültig für eine Definition für dieselbe Klasse mit demselben Namen, die mehrmals in auf der Liste. |
Anruf-Website-IDs | call_site_id_item[] | Liste der Website-IDs für Anrufe enthält. Dies sind Kennungen für alle Anrufwebsites.
auf die in dieser Datei verwiesen wird, unabhängig davon, ob sie in der Datei definiert ist oder nicht. Diese Liste
muss in aufsteigender Reihenfolge nach call_site_off sortiert werden.
|
Methoden-Handles | method_handle_item[] | Handles list. Eine Liste aller Methoden-Handles, auf die diese Datei verweist, unabhängig davon, ob die Datei in der Datei definiert ist oder nicht. Diese Liste ist nicht sortiert und enthält möglicherweise Duplikate, die logisch verschiedenen Methoden-Handle-Instanzen entsprechen. |
Daten | ubyte[] | Datenbereich mit allen Supportdaten für die oben aufgeführten Tabellen. Verschiedene Elemente haben unterschiedliche Ausrichtungsanforderungen und Padding-Byte werden gegebenenfalls vor jedem Element eingefügt, falls erforderlich, um korrekt ausgerichtet sind. |
link_data (Link-Daten) | ubyte[] | Daten, die in statisch verknüpften Dateien verwendet werden. Das Format der Daten Dieser Abschnitt wird in diesem Dokument nicht angegeben. Dieser Abschnitt ist in nicht verknüpften Dateien und Laufzeitimplementierungen leer kann es nach eigenem Ermessen verwenden. |
Bitfeld-, String- und Konstantendefinitionen
DEX_DATEI_MAGIC
Eingebettet in „header_item“
Das konstante Array/String DEX_FILE_MAGIC
ist die Liste der
Byte, die am Anfang einer .dex
-Datei stehen müssen
damit sie als solche erkannt werden. Der Wert ist bewusst
enthält einen Zeilenumbruch ("\n"
oder 0x0a
) und einen
Nullbyte ("\0"
oder 0x00
) enthält,
bei der Erkennung bestimmter Arten von Korruption. Der Wert
codiert eine Versionsnummer des Formats mit drei Dezimalstellen, was
mit der Zeit kontinuierlich zunehmen,
während 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
-Format wurde in der Android-Version 9.0 hinzugefügt, in der zwei
neue Bytecodes, const-method-handle
und
const-method-type
(Diese werden im
Zusammenfassung des Bytecode-Satzes
. In Android 10 wird das DEX-Dateiformat durch Version 039
um versteckte Dateien erweitert
API-Informationen, die nur für DEX-Dateien im Bootklassenpfad gelten.
Hinweis: Versionsunterstützung
038
des Formats wurden in Android 8.0 hinzugefügt.
Veröffentlichung. Version 038
hat neue Bytecodes hinzugefügt
(invoke-polymorphic
und invoke-custom
) und
Daten für Methoden-Handles.
Hinweis: Unterstützung für Version 037
von
Das Format wurde in der Android-Version 7.0 hinzugefügt. Vor Version 037
am häufigsten
-Versionen von Android haben Version 035
des Formats verwendet. Die einzige
Unterschied zwischen den Versionen 035
und 037
ist der
Hinzufügung von Standardmethoden und Anpassung der invoke
.
Hinweis:Einige frühere Versionen dieses Formats wurden
in allgemein verfügbaren
öffentlichen Software-Releases verwendet werden. Beispiel:
Version 009
wurde für die M3-Releases der
Android-Plattform (November bis Dezember 2007),
und Version 013
wurde für die M5-Releases von Android
Plattform (Februar bis März 2008). In mehrfacher Hinsicht haben diese früheren
Versionen des Formats erheblich von der hier beschriebenen Version unterscheiden.
Dokument.
ENDIAN_CONSTANT und REVERSE_ENDIAN_CONSTANT
Eingebettet in „header_item“
Mit der Konstante ENDIAN_CONSTANT
wird angegeben,
Endianität der Datei, in der sie gefunden wurde. Obwohl der Standard
Das Format von .dex
ist Little-Endian, Implementierungen können gewählt werden
um Byte-Swapping durchzuführen. Sollte bei einer Implementierung eine
Header, dessen endian_tag
REVERSE_ENDIAN_CONSTANT
ist
statt ENDIAN_CONSTANT
würde die Datei wissen,
für das erwartete Format
mit Byte-Swapping durchgeführt wurde.
uint ENDIAN_CONSTANT = 0x12345678; uint REVERSE_ENDIAN_CONSTANT = 0x78563412;
NO_INDEX
Eingebettet in class_def_item und debug_info_item
Mit der Konstante NO_INDEX
wird angegeben,
ein Indexwert fehlt.
Hinweis:Dieser Wert ist nicht als
0
, da dies normalerweise ein gültiger Index ist.
Der ausgewählte Wert für NO_INDEX
ist
als einzelnes Byte in der uleb128p1
-Codierung darstellbar.
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 Innenklasse
Bitfelder dieser Flags werden verwendet, um die Barrierefreiheit und Gesamteigenschaften von Klassen und Klassenmitgliedern.
Name | Wert | Für Klassen (und InnerClass -Annotationen) |
Für Felder | Für Methoden |
---|---|---|---|---|
ACC_PUBLIC | 0x1 | public : überall sichtbar |
public : überall sichtbar |
public : überall sichtbar |
ACC_PRIVATE | 0x2 | private : nur für die definierende Klasse sichtbar
|
private : nur für die definierende Klasse sichtbar |
private : nur für die definierende Klasse sichtbar |
GESCHÜTZT_GESCHÜTZT | 0x4 | protected : sichtbar für Pakete und abgeleitete Klassen
|
protected : sichtbar für Pakete und abgeleitete Klassen |
protected : sichtbar für Pakete und abgeleitete Klassen |
ACC_STATIC | 0x8 | static : ist nicht mit einer äußeren
Referenz zu this |
static : global zur definierenden Klasse |
static : verwendet kein this -Argument |
ACC_ENDGÜLTIGE | 0x10 | final : keine abgeleitete Klasse |
final : nach der Konstruktion unveränderlich |
final : nicht überschreibbar |
ACC_SYNCHRONIZED (ACC_SYNCHRONIZED) | 0x20 | synchronized : zugehörige Sperre automatisch hergestellt
für den Aufruf dieser Methode. Hinweis:Dieses Feld kann nur festgelegt werden, wenn
|
||
AKK-VOLATILE | 0x40 | volatile : spezielle Zugriffsregeln zur Unterstützung beim Thread
Sicherheit |
||
ACC_BRIDGE | 0x40 | Brückenmethode, die vom Compiler automatisch als typsicher hinzugefügt wird Brücke | ||
AKZE_TRANSIENT | 0x80 | transient : wird nicht als Standard-Serialisierung gespeichert |
||
ACC_VARARGS | 0x80 | Das letzte Argument sollte als „Ruhe“ behandelt werden. Argument nach Compiler | ||
ACC_NATIVE | 0x100 | native : in nativem Code implementiert |
||
ACC_BENUTZEROBERFLÄCHE | 0x200 | interface : multiplizierbare abstrakte Klasse |
||
ACC_ABSTRACT (ACC_ABSTRACT) | 0x400 | abstract : nicht direkt instanziierbar |
abstract : von dieser Klasse nicht implementiert |
|
ACC_STRICT (ACC_STRICT) | 0x800 | strictfp : strenge Regeln für die Gleitkommaarithmetik |
||
ACC_SYNTHETISCH | 0x1000 | nicht direkt im Quellcode definiert | nicht direkt im Quellcode definiert | nicht direkt im Quellcode definiert |
AKZEKHINWEIS | 0x2000 | als Anmerkungsklasse deklariert | ||
ACC_ENUM | 0x4000 | als Aufzählungstyp deklariert | als Aufzählungswert deklariert | |
(nicht verwendet) | 0 x 8.000 | |||
ACC_CONSTRUCTOR | 0 x 10.000 | Konstruktor-Methode (Klassen- oder Instanzinitialisierer) | ||
ACC_DECLARED_ SYNCHRONIZED (SYNCHRONISIERT) |
0 x 20.000 | erklärte synchronized . Hinweis:Dies hat keine Auswirkungen auf (außer in Anbetracht dieser Kennzeichnung an sich). |
InnerClass
-Annotationen,
und darf in einem class_def_item
nicht aktiv sein.
Geänderte UTF-8-Codierung
Als Nachlass zur Vereinfachung des Legacy-Supports wurde das .dex
-Format
codiert seine Zeichenfolgendaten in einer De-facto-Standard-Modifizierte UTF-8-Form.
auch als MUTF-8 bezeichnet. Dieses Formular entspricht dem Standard-UTF-8-Code, mit folgenden Ausnahmen:
- Es werden nur die Ein-, Zwei- und Drei-Byte-Codierung verwendet.
- Codepunkte im Bereich
U+10000
...U+10ffff
sind als Ersatzwertpaar codiert, das jeweils die als codierter 3-Byte-Wert dargestellt wird. - Der Codepunkt
U+0000
ist in Zwei-Byte-Form codiert. - Ein einfaches Nullbyte (Wert
0
) zeigt das Ende von Einen String, ebenso wie die Interpretation der Standard-C-Sprache.
Die ersten beiden Elemente oben können wie folgt zusammengefasst werden: MUTF-8 ist ein Codierungsformat für UTF-16. Es ist kein direkter Codierungsformat für Unicode-Zeichen verwenden.
Mit den letzten beiden Punkten oben können Sie
den Codepunkt U+0000
in einem String und bearbeiten weiterhin
als C-ähnlicher String mit Nullabschluss.
Die spezielle Codierung von U+0000
bedeutet jedoch, dass im Gegensatz zu
Normal UTF-8, das Ergebnis des Aufrufs der C-Standardfunktion
strcmp()
für ein Paar von MUTF-8-Strings bedeutet nicht immer,
das richtig signierte Ergebnis des Vergleichs von ungleich-Strings anzeigen.
Wenn die Reihenfolge (und nicht nur die Gleichheit) ein Problem ist,
MUTF-8-Strings lassen sich
Zeichen für Zeichen decodieren.
und die decodierten Werte vergleichen. (Klügere Implementierungen sind jedoch
ebenfalls möglich.)
Weitere Informationen finden Sie im Artikel Das Unicode- Standard. MUTF-8 ist näher an der (weniger bekannten) Codierung. CESU-8 als in UTF-8 nicht als Ganzes betrachtet.
codierte_Wert-Codierung
Eingebettet in „annotation_element“ und „encoded_array_item“
Ein encoded_value
ist ein codiertes Teil eines (fast)
beliebige hierarchisch strukturierte Daten. Die Codierung soll
sowohl kompakt als auch einfach zu parsen sein.
Name | Format | Beschreibung |
---|---|---|
(value_arg << 5) | Werttyp | Ubyte | Byte, das den Typ der unmittelbar nachfolgenden
value entlang
mit einem optionalen klärenden Argument in den drei Bits höherer Ordnung.
Unten findest du die verschiedenen Definitionen für value .
In den meisten Fällen codiert value_arg die Länge
die unmittelbar nachfolgenden value in Byte, wie
(size - 1) z.B. 0 bedeutet Folgendes:
Der Wert erfordert ein Byte und 7 bedeutet, dass
acht Byte; Es gibt jedoch Ausnahmen.
|
value | ubyte[] | Bytes stehen für den Wert, mit variabler Länge und interpretierter Interpretation
für verschiedene value_type -Byte unterschiedlich
immer Little-Endian. Unten finden Sie die verschiedenen Wertdefinitionen für
Details.
|
Wertformate
Typname | value_type |
value_arg -Format |
value -Format |
Beschreibung |
---|---|---|---|---|
WERT_BYTE | 0x00 | (Keine; muss 0 sein) |
ubyte[1] | Vorzeichenbehafteter 1-Byte-Ganzzahlwert |
WERT_SHORT | 0x02 | Größe – 1 (0...1) | Ubyte[Größe] | 2-Byte-Ganzzahlwert mit Vorzeichen, vorzeichenerweitert |
WERT_CHAR | 0x03 | Größe – 1 (0...1) | Ubyte[Größe] | 2-Byte-Ganzzahlwert ohne Vorzeichen, nullerweitert |
WERT_INT | 0x04 | Größe – 1 (0...3) | Ubyte[Größe] | 4-Byte-Ganzzahlwert mit Vorzeichen, vorzeichenerweitert |
WERT_LANG | 0x06 | Größe – 1 (0...7) | Ubyte[Größe] | 8-Byte-Ganzzahlwert mit Vorzeichen, vorzeichenerweitert |
WERT_FLOAT | 0x10 | Größe – 1 (0...3) | Ubyte[Größe] | 4-Byte-Bitmuster, nullerweitert nach rechts und Wird als 32-Bit-Gleitkommawert nach IEEE 754 interpretiert |
WERT_DOPPEL | 0x11 | size – 1 (0...7) | Ubyte[Größe] | Acht-Byte-Bitmuster, nullerweitert nach rechts und Wird als 64-Bit-Gleitkommawert nach IEEE754 interpretiert |
WERT_METHODE_TYPE | 0x15 | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
den Abschnitt proto_ids und stellen einen Methodentypwert dar
|
WERT_METHODE_HANDLE | 0x16 | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
den Abschnitt method_handles und stellt einen Methoden-Handle-Wert dar
|
WERT_STRING | 0x17 | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
den Abschnitt string_ids und stellt einen Stringwert dar
|
WERT_TYP | 0x18 | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
Abschnitt type_ids und stellt ein reflektierendes Element dar
Typ/Klassenwert
|
WERT_FELD | 0x19 | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
field_ids -Abschnitt und stellt ein reflektierendes Element dar
Feldwert
|
WERT_METHODE | 0x1a | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
method_ids -Abschnitt und stellt ein reflektierendes Element dar
Methodenwert
|
WERT_ENUM | 0x1b | Größe – 1 (0...3) | Ubyte[Größe] | vorzeichenloser (nullerweiter) 4-Byte-Ganzzahlwert,
als Index interpretiert werden,
den Abschnitt field_ids und stellt den Wert von
eine Konstante des Enum-Typs
|
WERT_ARRAY | 0x1c | (Keine; muss 0 sein) |
codiertes_Array | ein Array von Werten im durch
„encoded_array -Format“ unten. Die Größe
der value ist in der Codierung implizit enthalten.
|
WERT_ANMERKUNG | 0 x 1 Tag | (Keine; muss 0 sein) |
codierte_Anmerkung | eine Unteranmerkung im durch die
„encoded_annotation -Format“ unten. Die Größe
der value ist in der Codierung implizit enthalten.
|
WERT_NULL | 0x1e | (Keine; muss 0 sein) |
(Keine) | null -Referenzwert |
WERT_BOOLESCH | 0x1f | Boolesch (0...1) | (Keine) | 1-Bit-Wert; 0 für false und
1 für true . Das Bit wird im
value_arg
|
codiertes_Array-Format
Name | Format | Beschreibung |
---|---|---|
Größe | Uleb128 | Anzahl der Elemente im Array |
Werte | codierter_Wert[Größe] | eine Reihe von size encoded_value -Byte
in dem in diesem Abschnitt angegebenen Format, verkettet
sequenziell.
|
encoded_annotation-Format
Name | Format | Beschreibung |
---|---|---|
Typ_IDX | Uleb128 | Typ der Anmerkung. Dies muss eine Klasse sein (kein Array oder Primitiv). Typ. |
Größe | Uleb128 | Anzahl der Name/Wert-Zuordnungen in dieser Annotation |
Elemente | annotation_element[Größe] | -Elemente der Anmerkung, die direkt inline dargestellt werden (nicht als
Offsets). Die Elemente müssen in aufsteigender Reihenfolge sortiert werden nach
string_id -Index.
|
Format des Anmerkungselements
Name | Format | Beschreibung |
---|---|---|
name_idx | Uleb128 | -Elements, dargestellt als Index im
string_ids Abschnitt. Der String muss den
für MemberName wie oben definiert.
|
value | codierter_Wert | Elementwert |
String syntax
Eine .dex
-Datei enthält verschiedene Arten von Elementen,
auf eine Zeichenfolge verweisen. Die folgenden Definitionen im BNF-Stil
die akzeptable Syntax für diese Zeichenfolgen an.
Einfacher Name
Ein SimpleName ist die Grundlage für die Syntax der Namen anderer
Dinge. Das Format .dex
ermöglicht eine hohe Breite
(deutlich mehr als die meisten Ausgangssprachen). Kurz gesagt:
aus ASCII-Schriftzeichen oder Ziffern,
und die meisten Nicht-ASCII-Codepunkte, die nicht
Steuer-, Leer- oder Sonderzeichen. Ab Version 040
Das Format lässt zusätzlich Leerzeichen (Unicode Zs
Kategorie). Beachten Sie, dass Ersatzcodepunkte
(im Bereich U+d800
... U+dfff
) sind nicht
als gültige Namenszeichen betrachtet, aber Unicode-Zeichen
Zeichen gültig sind (gekennzeichnet durch das
der Regel für SimpleNameChar). Außerdem sollten sie
in einer Datei als Paare von Ersatzcodepunkten im MUTF-8-Format dargestellt.
Codierung.
SimpleName → | ||
SimpleNameChar (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 |
Mitgliedsname
verwendet von „field_id_item“ und „method_id_item“
Ein MemberName ist der Name eines Gruppenmitglieds. -Feldern, Methoden und inneren Klassen.
MemberName → | |
Einfacher Name | |
| | '<' Einfacher Name '>' |
Vollständiger Klassenname
Ein FullClassName ist ein vollständig qualifizierter Klassenname, einschließlich eines optionaler Paketspezifizierer gefolgt von einem erforderlichen Namen.
FullClassName → | |
OptionalPackagePrefix SimpleName | |
OptionalPackagePrefix → | |
(SimpleName '/' )* |
Typdeskriptor
Wird von type_id_item verwendet
Ein TypeDescriptor ist die Darstellung eines beliebigen Typs, einschließlich
Primitiven, Klassen, Arrays und void
. Siehe unten für
die Bedeutung der verschiedenen Versionen.
TypeDescriptor → | |
'V' |
|
| | FieldTypeDescriptor |
FieldTypeDescriptor → | |
NonArrayFieldTypeDescriptor | |
| | ('[' * 1...255)
NonArrayFieldTypeDescriptor |
NonArrayFieldTypeDescriptor→ | |
'Z' |
|
| | 'B' |
| | 'S' |
| | 'C' |
| | 'I' |
| | 'J' |
| | 'F' |
| | 'D' |
| | 'L' FullClassName ';' |
Kurzbeschreibung
Wird von proto_id_item verwendet
Ein ShortyDescriptor ist die Kurzform einer Methode.
Prototyp einschließlich Rückgabe- und Parametertypen, außer dass es
keine Unterscheidung zwischen verschiedenen Referenztypen (Klasse oder Array). Stattdessen
Alle Referenztypen werden durch ein einzelnes 'L'
-Zeichen dargestellt.
ShortyDescriptor → | |
ShortyReturnType (ShortyFieldType)* | |
ShortyReturnType → | |
'V' |
|
| | ShortyFieldType |
ShortyFieldType → | |
'Z' |
|
| | 'B' |
| | 'S' |
| | 'C' |
| | 'I' |
| | 'J' |
| | 'F' |
| | 'D' |
| | 'L' |
TypeDescriptor-Semantik
Dies entspricht der Bedeutung der einzelnen Varianten von TypeDescriptor.
Syntax | Bedeutung |
---|---|
V | void ; nur für Rückgabetypen gültig |
Z | boolean |
B | byte |
S | short |
C | char |
I | int |
J | long |
F | float |
D | double |
Vollständig/qualifiziert/Name: | die Klasse fully.qualified.Name |
[Beschreibung | Array von descriptor , rekursiv für
Arrays-of-Arrays, auch wenn mehr als 255 Arrays nicht zulässig sind
Dimensionen.
|
Elemente und verwandte Strukturen
Dieser Abschnitt enthält Definitionen für alle Elemente der obersten Ebene, die
kann in einer .dex
-Datei enthalten sein.
Header-Element
Erscheint im Kopfzeilenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Magie | ubyte[8] = DEX_FILE_MAGIC | magischen Wert. Siehe Diskussion oben unter "DEX_FILE_MAGIC "
.
|
Prüfsumme | Uint | adler32-Prüfsumme der Datei (alles außer
magic und dieses Feld); zum Erkennen von Dateibeschädigungen
|
Signatur | Ubyte[20] | SHA-1-Signatur (Hash) der Datei (alles außer
magic , checksum und dieses Feld); belegt
zur eindeutigen Identifizierung von Dateien
|
Dateigröße | Uint | Größe der gesamten Datei (einschließlich Header) in Byte |
Header-Größe | uint = 0x70 | Größe des Headers (dieses gesamten Abschnitts) in Byte. Dadurch können bei die Abwärts-/Vorwärtskompatibilität ohne damit das Format ungültig wird. |
Endian-Tag | uint = ENDIAN_CONSTANT | endianness-Tag enthält. Siehe Diskussion oben unter "ENDIAN_CONSTANT "
und REVERSE_ENDIAN_CONSTANT " .
|
Link-Größe | Uint | die Größe des Linkbereichs oder 0 , wenn dies nicht
statisch verknüpft |
Link_off [Link_off] | Uint | der Abstand vom Anfang der Datei zum Linkbereich oder
0 wenn link_size == 0 . Der Offset, falls ungleich null,
sollte ein Versatz im Abschnitt link_data sein. Die
Das Format der Daten, auf die verwiesen wird, wird in diesem Dokument nicht angegeben.
werden dieses Header-Feld (und das vorherige) als Hooks für die Verwendung durch
Laufzeitimplementierungen.
|
Map-off | Uint | Abstand vom Anfang der Datei zum Kartenelement. Das Offset, das
nicht null sein, muss ein Versatz im Abschnitt data sein,
Die Daten müssen in dem mit „map_list “ angegebenen Format vorliegen.
unten.
|
string_ids_size | Uint | Anzahl der Strings in der Liste der Stringkennungen |
String_IDs_off | Uint | vom Anfang der Datei zur Liste der String-IDs verschoben werden oder
0 wenn string_ids_size == 0 (zugegebenermaßen ein
merkwürdigen Grenzfall). Der Offset, falls ungleich null,
sollte am Anfang des Abschnitts string_ids stehen.
|
type_ids_size | Uint | Anzahl der Elemente in der Liste der Typkennungen, höchstens 65.535 |
typ_ids_off | Uint | der Abstand vom Anfang der Datei zur Liste der Typkennungen oder
0 wenn type_ids_size == 0 (zugegebenermaßen ein
merkwürdigen Grenzfall). Der Offset, falls ungleich null,
sollte am Anfang von type_ids sein
.
|
proto_ids_size | Uint | Anzahl der Elemente in der Liste der Prototypkennungen, höchstens 65.535 |
proto_ids_off (Proto-IDs deaktiviert) | Uint | der Abstand vom Anfang der Datei zur Liste der Prototyp-IDs oder
0 wenn proto_ids_size == 0 (zugegebenermaßen ein
merkwürdigen Grenzfall). Der Offset, falls ungleich null,
sollte am Anfang von proto_ids sein
.
|
Feld_ID_Größe | Uint | Anzahl der Elemente in der Liste der Feldkennungen |
Feld_IDs_Aus | Uint | der Abstand vom Anfang der Datei zur Liste der Feldkennungen oder
0 wenn field_ids_size == 0 . Der Offset, wenn
nicht Null, muss am Anfang von field_ids stehen
. |
method_ids_size | Uint | Anzahl der Elemente in der Liste der Methodenkennungen |
method_ids_off [method_ids_off] | Uint | der Abstand vom Anfang der Datei zur Liste der Methodenkennungen oder
0 wenn method_ids_size == 0 . Der Offset, wenn
nicht Null, muss am Anfang von method_ids stehen
. |
class_defs_size | Uint | Anzahl der Elemente in der Liste der Klassendefinitionen |
klassen_defs_aus | Uint | der Abstand vom Anfang der Datei zur Liste der Klassendefinitionen oder
0 wenn class_defs_size == 0 (zugegebenermaßen ein
merkwürdigen Grenzfall). Der Offset, falls ungleich null,
sollte am Anfang des Abschnitts class_defs stehen.
|
data_size | Uint | Größe des Abschnitts data in Byte. Muss ein gerader Wert sein
Vielfaches von sizeof(uint). |
Daten deaktiviert | Uint | vom Anfang der Datei bis zum Anfang der
data Abschnitt.
|
Kartenliste
Erscheint im Datenbereich
Verweist von „header_item“
Ausrichtung: 4 Byte
Dies ist eine geordnete Liste des gesamten Inhalts einer Datei. Es
enthält eine gewisse Redundanz in Bezug auf header_item
ist aber für die Iteration über das gesamte
-Datei. Ein bestimmter Typ darf höchstens einmal in einer Karte vorkommen,
ist die Einschränkung, in welchen Auftragstypen
Einschränkungen, die durch das restliche Format (z.B. eine
Der Abschnitt header
muss zuerst stehen, gefolgt von einem
string_ids
usw.). Außerdem müssen die Zuordnungseinträge
nach anfänglichem Offset sortiert werden und dürfen sich nicht überschneiden.
Name | Format | Beschreibung |
---|---|---|
Größe | Uint | Größe der Liste in Einträgen |
Liste | Kartenelement[Größe] | Elemente der Liste |
Format von „map_item“
Name | Format | Beschreibung |
---|---|---|
type | Ushort | Art der Elemente; siehe Tabelle unten |
unused | Ushort | (nicht verwendet) |
Größe | Uint | Anzahl der Elemente, die am angegebenen Offset gefunden werden sollen |
kompensiert | Uint | Abstand vom Anfang der Datei zu den betreffenden Elementen |
Typcodes
Artikeltyp | Konstante | Wert | Artikelgröße in Byte |
---|---|---|---|
Header-Element | TYPE_HEADER_ITEM | 0x0000 | 0x70 |
String_ID_Element | TYPE_STRING_ID_ITEM | 0x0001 | 0x04 |
type_id_item [Typ_ID_Artikel] | TYPE_ID-ARTIKEL | 0x0002 | 0x04 |
proto_id_item | TYPE_PROTO_ID_ITEM | 0x0003 | 0x0c |
Feld_ID_Element | TYPE_FIELD_ID_ITEM | 0x0004 | 0x08 |
method_id_item [method_id_item] | METHODEN-ID_TYP | 0x0005 | 0x08 |
class_def_item | TYPE_CLASS_DEF_ITEM | 0x0006 | 0x20 |
Anruf-ID-Element | TYPE_CALL_SITE_ID_ITEM | 0x0007 | 0x04 |
method_handle_item [Methode_Handle_item] | METHODEN_HANDLE_TYPE | 0x0008 | 0x08 |
Kartenliste | TYPE_MAP_LISTE | 0x1000 | 4 + (item.size * 12) |
Typliste | TYPE_LISTE | 0x1001 | 4 + (item.size * 2) |
Annotationssatz_Referenzliste | TYP_NOTE_SET_REF_LIST | 0x1002 | 4 + (item.size * 4) |
Annotationssatzelement | TYPE_NOTE_SET_ITEM | 0x1003 | 4 + (item.size * 4) |
class_data_item [Klasse_Datenelement] | TYPE_CLASS_DATA_ITEM | 0x2000 | implizit; muss geparst werden |
Codeelement | TYPE_CODE_ITEM | 0x2001 | implizit; muss geparst werden |
string_data_item | TYPE_STRING_DATENELEMENT | 0x2002 | implizit; muss geparst werden |
Debug-Infoelement | TYPE_DEBUG_INFO_ITEM_FEHLERBEHEBUNG | 0x2003 | implizit; muss geparst werden |
Anmerkungselement | TYPE_NOTE_ITEM | 0x2004 | implizit; muss geparst werden |
codiertes_Array-Element | TYPE_ENCODED_ARRAY_ITEM | 0x2005 | implizit; muss geparst werden |
Anmerkungen_Verzeichniselement | TYP_VERWEIS_ARTIKEL | 0x2006 | implizit; muss geparst werden |
verborgenes Datenelement der API-Klasse | TYPE_HIDDENAPI_CLASS_DATA_ITEM | 0xF000 | implizit; muss geparst werden |
String_ID_Element
Erscheint im Abschnitt string_ids
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
string_data_off (Zeichenfolgendaten_aus) | Uint | vom Anfang der Datei zu den Zeichenfolgendaten
ein. Der Offset sollte zu einem Standort
im Abschnitt data und die Daten sollten sich im
Format angegeben durch "string_data_item " unten.
Für den Offset ist keine Ausrichtung erforderlich.
|
string_data_item
Erscheint im Datenbereich
Ausrichtung: keine (byte-orientiert)
Name | Format | Beschreibung |
---|---|---|
utf16_size | Uleb128 | die Größe dieser Zeichenfolge in UTF-16-Codeeinheiten, also der
Länge" in vielen Systemen). Das heißt, dies ist die decodierte Länge
die Zeichenfolge. (Die codierte Länge wird durch die Position der
das 0 -Byte.) |
Daten | ubyte[] | eine Reihe von MUTF-8-Codeeinheiten (auch Oktette genannt)
gefolgt von einem Byte mit dem Wert 0 . Weitere Informationen finden Sie unter
MUTF-8-Codierung (geänderte UTF-8-Codierung) weiter oben.
Diskussion über das Datenformat.
Hinweis: Zulässig sind Strings, die Folgendes enthalten:
(die codierte Form von) UTF-16-Ersatzcodeeinheiten, d. h.
|
type_id_item [Typ_ID_Artikel]
Erscheint im Abschnitt „type_ids“
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
deskriptor_idx | Uint | in die string_ids -Liste für den Deskriptor aufnehmen
String dieses Typs. Die Zeichenfolge muss der Syntax für
TypeDescriptor, wie oben definiert.
|
proto_id_item
Erscheint im Abschnitt „proto_ids“
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Shorty_IDX | Uint | in die string_ids -Liste für die Kurzform
Deskriptor-String dieses Prototyps. Der String muss den
Syntax für ShortyDescriptor, wie oben definiert. Sie muss den
gibt den Rückgabetyp und die Parameter dieses Elements an.
|
return_type_idx [Rückgabetyp_IDx] | Uint | Index in die type_ids -Liste für den Rückgabetyp einfügen
dieses Prototyps
|
Parameter_off | Uint | Abstand vom Anfang der Datei zur Liste der Parametertypen
für diesen Prototyp oder 0 , wenn dieser Prototyp keine
Parameter. Dieser Offset, wenn dieser nicht null ist, sollte im
data und die Daten sollten im
Format, das unten durch "type_list" angegeben wird. Außerdem gibt es
sollte kein Verweis auf den Typ void in der Liste sein.
|
Feld_ID_Element
Wird im „field_ids“-Abschnitt angezeigt
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
class_idx (Klasse IDX) | Ushort | Index in die type_ids -Liste für die Definition dieses
ein. Dies muss ein Klassentyp sein, kein Array oder ein primitiver Typ.
|
Typ_IDX | Ushort | in die type_ids -Liste für den Typ
dieses Feld
|
name_idx | Uint | Index in die string_ids -Liste einfügen, um den Namen dieses
ein. Der String muss der Syntax für MemberName entsprechen,
wie oben beschrieben.
|
method_id_item [method_id_item]
Erscheint im Abschnitt method_ids
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
class_idx (Klasse IDX) | Ushort | Index in die type_ids -Liste für die Definition dieses
. Dies muss ein Klassen- oder Arraytyp sein, kein primitiver Typ.
|
proto_idx | Ushort | in die proto_ids -Liste für den Prototyp von
diese Methode
|
name_idx | Uint | Index in die string_ids -Liste einfügen, um den Namen dieses
. Der String muss der Syntax für MemberName entsprechen,
wie oben beschrieben.
|
class_def_item
Wird im Abschnitt class_defs angezeigt
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
class_idx (Klasse IDX) | Uint | Index in die type_ids -Liste für diese Klasse ein.
Dies muss ein Klassentyp sein, kein Array oder ein primitiver Typ.
|
Zugriffsflags | Uint | Zugriffs-Flags für die Klasse (public , final ,
usw.). Siehe „access_flags -Definitionen“ .
|
superclass_idx | Uint | in die type_ids -Liste für die Basisklasse indexieren oder
den konstanten Wert NO_INDEX , wenn diese Klasse keine
übergeordnete Klasse (d.h. eine Stammklasse wie Object ).
Falls vorhanden, muss dies ein Klassentyp und kein Array- oder primitiver Typ sein.
|
Interfaces_off | Uint | der Abstand vom Anfang der Datei zur Liste der Schnittstellen oder
0 , wenn keine vorhanden sind. Dieser Offset
sollte sich im Abschnitt data befinden und die Daten
Sie muss in dem Format vorliegen,
„type_list “ unten. Jedes der Elemente der Liste
muss ein Klassentyp sein (kein Array oder primitiver Typ).
darf keine Duplikate sein.
|
ID der Quelldatei | Uint | in die string_ids -Liste für den Namen des
Datei mit der ursprünglichen Quelle für (zumindest den größten Teil) dieser Klasse,
oder der spezielle Wert NO_INDEX , um das Fehlen
diese Informationen. Die debug_info_item einer beliebigen Methode
diese Quelldatei überschreiben, aber es wird erwartet,
aus einer Quelldatei stammen.
|
Anmerkungen_aus | Uint | Versatz vom Anfang der Datei zur Anmerkungsstruktur
für diese Klasse oder 0 , wenn es keine Anmerkungen
diesem Kurs. Dieser Offset, wenn dieser nicht null ist, sollte im
data und die Daten sollten in
das durch „annotations_directory_item “ angegebene Format unten
wobei sich alle Elemente auf diese Klasse als Definierende beziehen.
|
class_data_off (Kursdaten deaktiviert) | Uint | vom Anfang der Datei bis zu dem
Klassendaten für dieses Element oder 0 , wenn keine Klasse vorhanden ist
Daten für diesen Kurs. (Dies kann z. B. der Fall sein, wenn diese Klasse
ist eine Markierungsoberfläche. Der Offset, wenn dieser nicht null ist, sollte in der
data und die Daten sollten im Bereich
Format angegeben durch "class_data_item " unten, mit allen
Elemente, die sich auf diese Klasse als Definierende beziehen.
|
statische_werte_aus | Uint | der Versatz vom Anfang der Datei zur Liste der Anfangsbuchstaben
Werte für static -Felder oder 0 , wenn es
sind keine (und alle static -Felder sollen mit
0 oder null ). Dieser Offset sollte im
data und die Daten sollten im Bereich
Format angegeben durch "encoded_array_item " unten. Die Größe
des Arrays darf nicht größer sein als die Anzahl von static .
-Felder, die von dieser Klasse deklariert werden, und die Elemente entsprechen den
static -Felder in der gleichen Reihenfolge wie in den
entsprechenden field_list . Der Typ jedes Arrays
-Element muss mit dem deklarierten Typ des entsprechenden Felds übereinstimmen.
Wenn das Array weniger Elemente enthält als vorhanden sind,
static Feldern, dann werden die verbleibenden Felder initialisiert.
mit einem typgerechten 0 - oder null -Element.
|
Anruf-ID-Element
Erscheint im Abschnitt „call_site_ids“
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Anrufseite deaktiviert | Uint | vom Anfang der Datei aus, um die Website-Definition aufzurufen. Der Offset sollte befinden sich im Datenabschnitt und die Daten sollten in dem Format vorliegen, das durch die „call_site_item“ unten. |
Element_der_Anrufwebsite
Erscheint im Datenbereich
Ausrichtung: keine (byte ausgerichtet)
"call_site_item" ist ein codiertes Arrayelement, dessen Elemente den Argumenten entsprechen. einer Bootstrap-Verknüpfungsmethode übergeben. Die ersten drei Argumente sind:
- Methoden-Handle, das die Bootstrap-Verknüpfungsmethode (VALUE_METHOD_HANDLE) darstellt.
- Ein Methodenname, den die Bootstrap-Verknüpfung auflösen soll (VALUE_STRING).
- Methodentyp, der dem Typ des aufzulösenden Methodennamens entspricht (VALUE_METHOD_TYPE)
Alle zusätzlichen Argumente sind konstante Werte, die an die Bootstrap-Verknüpfungsmethode übergeben werden. Diese Argumente sind werden in der richtigen Reihenfolge ohne Typ-Conversions weitergegeben.
Das Methoden-Handle, das die Bootstrap-Verknüpfungsmethode darstellt, muss den Rückgabetyp java.lang.invoke.CallSite
haben. Die ersten drei Parametertypen sind:
java.lang.invoke.Lookup
java.lang.String
java.lang.invoke.MethodType
Die Parametertypen zusätzlicher Argumente werden anhand ihrer konstanten Werte bestimmt.
method_handle_item [Methode_Handle_item]
Erscheint im Abschnitt method_handles
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Handle_type_Methode | Ushort | Typ des Methoden-Handles: siehe Tabelle unten |
unused | Ushort | (nicht verwendet) |
Feld_oder_Methoden-ID | Ushort | Feld- oder Methoden-ID, je nachdem, ob der Methoden-Handle-Typ eine Zugriffsfunktion oder ein Methodenaufrufer ist |
unused | Ushort | (nicht verwendet) |
Codes der Methoden-Handle-Typen
Konstante | Wert | Beschreibung |
---|---|---|
METHOD_HANDLE_TYPE_STATIC_PUT | 0x00 | Methoden-Handle ist ein statischer Feld-Setter (Accessor) |
METHOD_HANDLE_TYPE_STATIC_GET | 0x01 | Methoden-Handle ist ein statischer Feld-Getter (Zugriffsfunktion) |
METHOD_HANDLE_TYPE_INSTANCE_PUT | 0x02 | Methoden-Handle ist ein Instanzfeld-Setter (Zugriffsfunktion) |
METHOD_HANDLE_TYPE_INSTANCE_GET | 0x03 | Methoden-Handle ist ein Instanzfeld-Getter (Zugriffsfunktion) |
METHODENHANDLE_TYPE_INVOKE_STATIC | 0x04 | Der Methoden-Handle ist ein statischer Methodenaufrufer |
METHODENHANDLE_TYPE_INVOKE_INSTANCE | 0x05 | Die Methoden-Handle ist ein Instanzmethoden-Aufrufer. |
METHODENHANDLE_TYPE_INVOKE_CONSTRUCTOR | 0x06 | Methoden-Handle ist ein Konstruktor-Methodenaufrufer |
METHODENHANDLE_TYPE_INVOKE_DIRECT | 0x07 | Der Methoden-Handle ist ein direkter Methodenaufrufer |
METHODENHANDLE_TYPE_INVOKE_INTERFACE | 0x08 | Der Methoden-Handle ist ein Interface-Methoden-Aufrufer |
class_data_item [Klasse_Datenelement]
Von class_def_item referenziert
Erscheint im Datenbereich
Ausrichtung: keine (byte-orientiert)
Name | Format | Beschreibung |
---|---|---|
static_fields_size | Uleb128 | Anzahl der in diesem Element definierten statischen Felder |
Größe der Instanzfelder | Uleb128 | die Anzahl der in diesem Element definierten Instanzfelder |
direkte_methoden_größe | Uleb128 | Anzahl der in diesem Element definierten direkten Methoden |
virtuelle_methoden_größe | Uleb128 | Anzahl der in diesem Element definierten virtuellen Methoden |
Statische Felder | codiertes_Feld[static_fields_size] | definierten statischen Feldern, dargestellt als Folge von
codierten Elementen. Die Felder müssen nach
field_idx in aufsteigender Reihenfolge.
|
Instanzfelder | codiertes_Feld[instance_fields_size] | die definierten Instanzfelder, dargestellt als Folge von
codierten Elementen. Die Felder müssen nach
field_idx in aufsteigender Reihenfolge.
|
direkte_methoden | codierte_Methode[direct_methods_size] | die definierte Direktverbindung (static , private ,
oder Konstruktor), dargestellt als Folge von
codierten Elementen. Die Methoden müssen nach
method_idx in aufsteigender Reihenfolge.
|
virtuelle_methoden | codierte_Methode[virtual_methods_size] | die definierte virtuelle (nicht static , private ,
oder Konstruktor), dargestellt als Folge von
codierten Elementen. Diese Liste sollte nicht übernommene
, es sei denn, sie werden von der Klasse überschrieben, die dieses Element repräsentiert. Die
Methoden müssen in aufsteigender Reihenfolge nach method_idx sortiert werden.
Die method_idx einer virtuellen Methode darf nicht gleich sein
wie jede direkte Methode.
|
Hinweis:Das Attribut „Alle Elemente“ field_id
und
method_id
-Instanzen müssen auf dieselbe definierende Klasse verweisen.
codiertes_Feldformat
Name | Format | Beschreibung |
---|---|---|
Feld_IDX_Differenz | Uleb128 | Index in die field_ids -Liste für die Identität dieses
-Feld (enthält den Namen und die Beschreibung), das als Differenz dargestellt wird
aus dem Index des vorherigen Elements in der Liste. Der Index der
in einer Liste direkt repräsentiert wird.
|
Zugriffsflags | Uleb128 | Zugriffs-Flags für das Feld (public , final ,
usw.). Siehe „access_flags -Definitionen“ .
|
encoded_method-Format
Name | Format | Beschreibung |
---|---|---|
method_idx_diff | Uleb128 | Index in die method_ids -Liste für die Identität dieses
(einschließlich Name und Beschreibung), die als Differenz dargestellt wird
aus dem Index des vorherigen Elements in der Liste. Der Index der
in einer Liste direkt repräsentiert wird.
|
Zugriffsflags | Uleb128 | Zugriffs-Flags für die Methode (public , final ,
usw.). Siehe „access_flags -Definitionen“ .
|
Codeoff | Uleb128 | vom Anfang der Datei zur Codestruktur für dieses
oder 0 , wenn diese Methode entweder abstract ist
oder native . Der Versatz sollte auf eine Position im
data Abschnitt. Das Format der Daten wird durch
„code_item “ unten.
|
Typliste
Verweist von class_def_item und proto_id_item
Erscheint im Datenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Größe | Uint | Größe der Liste in Einträgen |
Liste | type_item[Größe] | Elemente der Liste |
type_item-Format
Name | Format | Beschreibung |
---|---|---|
Typ_IDX | Ushort | Index in die type_ids -Liste einfügen |
Codeelement
Verweist von encoded_method
Erscheint im Datenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Registers_Größe | Ushort | Anzahl der von diesem Code verwendeten Register |
ins_size | Ushort | die Anzahl der Wörter von eingehenden Argumenten für die Methode, Code ist für |
Übergröße | Ushort | die Anzahl der Wörter des von diesem Code für Methodenaufruf |
Versuche_Größe | Ushort | Die Anzahl der try_item s für diese Instanz. Wenn nicht null,
werden diese als tries -Array direkt nach dem
insns in dieser Instanz.
|
Debug-Informationen_aus | Uint | Abstand vom Anfang der Datei zu den Debug-Informationen (Zeilennummern +
Informationen zu lokalen Variablen) für diesen Code oder 0 , wenn
einfach keine Informationen. Wenn der Offset ungleich null ist, sollte
an einen Speicherort im Abschnitt data . Das Format von
Die Daten werden durch „debug_info_item “ angegeben unten.
|
insns_größe | Uint | Größe der Anleitungsliste in 16-Bit-Codeeinheiten |
Insns | ushort[insns_größe] | Array von Bytecode. Das Codeformat in einem insns
Das Array wird vom Begleitdokument angegeben.
Dalvik-Bytecode. Hinweis
Obwohl dies als Array von ushort definiert ist, gibt es
sind einige interne Strukturen, die eine 4-Byte-Ausrichtung bevorzugen. Außerdem
wenn dies in einer Datei mit
endiantgewechselter Datei auftritt, ist der Austausch
nur für einzelne ushort -Instanzen und nicht für die
größere interne Strukturen.
|
padding | ushort (optional) = 0 | zwei Byte Padding, damit tries auf vier Byte ausgerichtet ist.
Dieses Element ist nur vorhanden, wenn tries_size ungleich null ist
und insns_size ist ungerade.
|
Versuche | Try_item[tries_size] (optional) | Array, das angibt, wo im Code Ausnahmen abgefangen werden
wie Sie damit umgehen. Elemente des Arrays dürfen sich in
und in der Reihenfolge von niedrig nach hoher Adresse. Dieses Element ist nur
vorhanden, wenn tries_size ungleich null ist.
|
Handler | encoded_catch_handler_list (optional) | Byte, die eine Liste von Listen mit Fangtypen und zugehörigen
Handler-Adressen. Jeder try_item hat einen byteweisen Offset
in diese Struktur verschieben. Dieses Element ist nur vorhanden, wenn
tries_size ist ungleich null.
|
„try_item“-Format
Name | Format | Beschreibung |
---|---|---|
Ausgangsadresse | Uint | Startadresse des Codeblocks, der von diesem Eintrag abgedeckt wird. Adresse entspricht der Anzahl der 16-Bit-Codeeinheiten bis zum Beginn der ersten Anleitung. |
Insn-Anzahl | Ushort | Anzahl der 16-Bit-Codeeinheiten, die von diesem Eintrag abgedeckt werden. Der letzte Code
abgedeckte Einheit (einschließlich) start_addr + insn_count - 1 .
|
Handler_off | Ushort | Offset in Byte vom Beginn des zugehörigen
encoded_catch_hander_list in den
encoded_catch_handler für diesen Eintrag. Dies muss ein
Versatz zum Anfang eines encoded_catch_handler .
|
Format „codierter_catch_handler_list“
Name | Format | Beschreibung |
---|---|---|
Größe | Uleb128 | Größe dieser Liste in Einträgen |
Liste | codierter_catch_handler[handlers_size] | tatsächliche Liste der Handler-Listen, direkt dargestellt (nicht als Offsets), und sequenziell verkettet. |
codiertes_Handler-Format
Name | Format | Beschreibung |
---|---|---|
Größe | sleb128 | Anzahl der Catch-Typen in dieser Liste. Ist dies nicht positiv, ist dies
der negative Wert der Anzahl der Catch-Typen, und die Catch-Typen werden befolgt
durch einen Catchall-Handler. Beispiel: Ein size von 0
bedeutet, dass es zwar einen Catch-all gibt, aber keine explizit typisierten Catcher.
Ein size von 2 bedeutet, dass zwei explizit
Fake-Eingaben und kein Auffangen. Und size von -1
bedeutet, dass es einen typisierten Fang zusammen mit einem Catchall gibt.
|
Handler | encoded_type_addr_pair[Abs(Größe)] | Stream von abs(size) codierten Elementen, eines für jedes gefangene Objekt
und zwar in der Reihenfolge, in der die Typen getestet werden sollen.
|
Catchall-Adresse | uleb128 (optional) | Bytecode-Adresse des Catchall-Handlers. Dieses Element ist nur
vorhanden, wenn size nicht positiv ist.
|
codiertes_type_addr_pair-Format
Name | Format | Beschreibung |
---|---|---|
Typ_IDX | Uleb128 | in die type_ids -Liste für den Typ des
Zu erfassende Ausnahme
|
Addr | Uleb128 | Bytecode-Adresse des zugehörigen Ausnahme-Handlers |
Debug-Infoelement
Von „code_item“ referenziert
Erscheint im Datenbereich
Ausrichtung: keine (byte-orientiert)
Jeder debug_info_item
definiert einen DWARF3-inspirierten byte-codierten
Zustandsautomat, der bei Interpretation die Positionen
und ggf. auch die Informationen zu den lokalen Variablen
code_item
. Die Sequenz beginnt mit einer variablen Länge
Header (ihre Länge hängt von der Anzahl der Methoden
Parameter) gefolgt von den Bytecodes der Zustandsmaschine und endet
mit einem DBG_END_SEQUENCE
-Byte.
Der Zustandsautomat besteht aus fünf Registern. Die
Das Register address
steht für den Anweisungs-Offset im
verknüpfte insns_item
in 16-Bit-Codeeinheiten. Die
address
-Registrierungen beginnen jeweils um 0
debug_info
-Sequenz und darf nur monoton ansteigen.
Das line
-Register gibt an, welche Quellzeilennummer
sollte mit dem Tabelleneintrag für nächste Positionen verknüpft werden, der von
Zustandsautomaten. Sie wird im Sequenzheader initialisiert und kann
Änderung in positive oder negative Richtungen, darf aber nie kleiner sein als
1
Das source_file
-Register steht für die
Quelldatei, auf die sich die Einträge mit der Zeilennummer beziehen. Sie ist initialisiert mit
Wert von source_file_idx
in class_def_item
Die anderen beiden Variablen prologue_end
und
epilogue_begin
sind boolesche Flags (mit
false
), die angeben, ob die nächste Position
sollte als Methodenprolog oder Epilog betrachtet werden. Der Zustandsautomat
müssen auch den Namen und den Typ der letzten lokalen Variablen
jedes Registers für den DBG_RESTART_LOCAL
-Code.
Der Header lautet wie folgt:
Name | Format | Beschreibung |
---|---|---|
line_start | Uleb128 | Anfangswert für das line -Register der Zustandsmaschine
Stellt keinen tatsächlichen Positionseintrag dar.
|
parameter_size [Parameter_Größe] | Uleb128 | die Anzahl der codierten Parameternamen. Es sollte
einen pro Methodenparameter, mit Ausnahme von this einer Instanzmethode,
falls zutreffend.
|
parameter_names (Parameternamen) | uleb128p1[Parametergröße] | Stringindex des Methodenparameternamens. Ein codierter Wert von
NO_INDEX gibt an, dass kein Name vorhanden ist.
für den zugehörigen Parameter verfügbar ist. Die Typbeschreibung
und Signatur aus dem Methodendeskriptor und der Signatur impliziert.
|
Die Bytecodewerte sind:
Name | Wert | Formatieren | Argumente | Beschreibung |
---|---|---|---|---|
DBG_END_SEQUENCE | 0x00 | (Keine) | beendet eine Sequenz von Debug-Informationen für ein code_item |
|
DBG_ADVANCE_PC | 0x01 | uleb128 addr_diff | addr_diff : Betrag, der in das Adressregister aufgenommen wird |
führt das Adressregister fort, ohne einen Positionseintrag auszugeben. |
DBG_ADVANCE_LINE | 0x02 | sleb128 line_diff | line_diff : Betrag, um den das Linienregister geändert werden soll |
fährt im Linienregister fort, ohne einen Positionseintrag auszugeben |
DBG_START_LOCAL | 0x03 | uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx |
register_num : Registrieren, das die lokale enthält name_idx : Stringindex des Namenstype_idx : Typindex des Typs
|
eine lokale Variable bei der aktuellen Adresse ein. Beides
name_idx oder type_idx ist möglicherweise
NO_INDEX fest, wenn dieser Wert unbekannt ist.
|
DBG_START_LOCAL_EXTENDED | 0x04 | uleb128 register_num uleb128p1 name_idx uleb128p1 type_idx uleb128p1 sig_idx |
register_num : Registrieren, das die lokale enthält name_idx : Stringindex des Namenstype_idx : Typindex des Typs sig_idx : Stringindex des Typssignatur
|
führt einen lokalen mit einer Typsignatur unter der aktuellen Adresse ein.
name_idx , type_idx oder
sig_idx ist möglicherweise NO_INDEX
um anzuzeigen, dass dieser Wert unbekannt ist. (Wenn sig_idx gleich
-1 . Dieselben Daten könnten jedoch stärker repräsentiert werden.
mit dem Opcode DBG_START_LOCAL .)
Hinweis: Die Diskussion finden Sie unter
„ |
DBG_END_LOCAL | 0x05 | uleb128 register_num | register_num : Registrieren, das lokale Elemente enthält |
eine derzeit aktive lokale Variable als ausgeschlossen markiert, Adresse |
DBG_RESTART_LOCAL | 0x06 | uleb128 register_num | register_num : zum Neustart registrieren |
wird erneut eine lokale Variable unter der aktuellen Adresse eingefügt. Name und Typ sind mit den letzten lokalen Einträgen in der angegebenen |
DBG_SET_PROLOGUE_END | 0x07 | (Keine) | legt das prologue_end -Zustandsmaschinenregister fest,
Dies gibt an, dass der nächste hinzugefügte Positionseintrag
als Ende eines Methodenvorfalls betrachtet (ein geeigneter Platz für
einen Methodenhaltepunkt). Das prologue_end -Register ist
wird durch einen speziellen Opcode (>= 0x0a ) gelöscht.
|
|
DBG_SET_EPILOGUE_BEGIN | 0x08 | (Keine) | legt das epilogue_begin -Zustandsmaschinenregister fest,
Dies gibt an, dass der nächste hinzugefügte Positionseintrag
als der Anfang eines Methodenepilogues betrachtet (ein geeigneter Ort,
die Ausführung vor dem Beenden der Methode auszusetzen).
Das epilogue_begin -Register wird von einem besonderen
(>= 0x0a )-Opcode.
|
|
DBG_SET_FILE | 0x09 | uleb128p1 Name_IDx | name_idx : Stringindex des Namens der Quelldatei;
NO_INDEX , falls unbekannt
|
gibt an, dass sich alle nachfolgenden Zeilennummerneinträge auf diese
Namen der Quelldatei anstelle des Standardnamens, der in
code_item
|
Spezielle Opcodes | 0x0a...0xff | (Keine) | erhöht die line - und address -Register,
gibt einen Positionseintrag aus und löscht prologue_end und
epilogue_begin . Eine Beschreibung finden Sie unten.
|
Spezielle Opcodes
Opcodes mit Werten zwischen 0x0a
und 0xff
(einschließlich) verschieben sowohl line
als auch address
registriert und gibt dann einen neuen Positionstabelleneintrag aus.
Die Formel für die Inkremente 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)
Anmerkungen_Verzeichniselement
Von class_def_item referenziert
Erscheint im Datenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Klassenannotationen_aus | Uint | der Versatz vom Anfang der Datei zu den direkt eingefügten Anmerkungen
für die Klasse oder 0 , wenn die Klasse keine direkten Anmerkungen hat.
Wenn der Versatz nicht null ist, sollte er sich an einer Position in der
data Abschnitt. Das Format der Daten wird angegeben.
von "annotation_set_item " unten.
|
Felder_Größe | Uint | Anzahl der von diesem Element annotierten Felder |
Methoden_für_Annotierungen | Uint | Anzahl der von diesem Element annotierten Methoden |
annotierte_parameter_größe | Uint | Anzahl der von diesem Element annotierten Methodenparameterlisten |
Feldannotationen | Feldannotation [fields_size] (optional) | Liste der zugehörigen Feldanmerkungen. Die Elemente der Liste müssen
in aufsteigender Reihenfolge nach field_idx sortiert werden.
|
Methodenannotationen | method_annotation[methods_size] (optional) | Liste der zugehörigen Methodenanmerkungen. Die Elemente der Liste müssen
in aufsteigender Reihenfolge nach method_idx sortiert werden.
|
Parameterannotationen | parameter_annotation[parameters_size] (optional) | Liste der zugehörigen Annotationen von Methodenparametern. Die Elemente der
Liste muss in aufsteigender Reihenfolge nach method_idx sortiert werden.
|
Hinweis:Das Attribut „Alle Elemente“ field_id
und
method_id
-Instanzen müssen auf dieselbe definierende Klasse verweisen.
Format von „field_annotation“
Name | Format | Beschreibung |
---|---|---|
Feld_ID | Uint | in die field_ids -Liste für die Identität des
Feld, das annotiert wird
|
Anmerkungen_aus | Uint | der Abstand vom Anfang der Datei zur Liste der Anmerkungen für
auf dem Feld. Der Offset sollte auf eine Position im data sein.
. Das Format der Daten wird durch
„annotation_set_item “ unten.
|
Format der method_annotation
Name | Format | Beschreibung |
---|---|---|
method_idx (method_idx) | Uint | in die method_ids -Liste für die Identität des
annotierte Methode
|
Anmerkungen_aus | Uint | der Abstand vom Anfang der Datei zur Liste der Anmerkungen für
die Methode verwenden. Der Versatz sollte auf eine Position im
data Abschnitt. Das Format der Daten wird durch
„annotation_set_item “ unten.
|
Format „parameter_annotation“
Name | Format | Beschreibung |
---|---|---|
method_idx (method_idx) | Uint | in die method_ids -Liste für die Identität des
-Methode, deren Parameter annotiert werden
|
Anmerkungen_aus | Uint | der Abstand vom Anfang der Datei zur Liste der Anmerkungen für
Methodenparameter an. Der Versatz sollte auf eine Position im
data Abschnitt. Das Format der Daten wird durch
„annotation_set_ref_list “ unten.
|
Annotationssatz_Referenzliste
Verweist von parameter_annotations_item
Erscheint im Datenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Größe | Uint | Größe der Liste in Einträgen |
Liste | Annotationssatz_ref_item[Größe] | Elemente der Liste |
Format „annotation_set_ref_item“
Name | Format | Beschreibung |
---|---|---|
Anmerkungen_aus | Uint | Versatz vom Anfang der Datei zum referenzierten Annotationssatz
oder 0 , wenn für dieses Element keine Anmerkungen vorhanden sind.
Der Offset, wenn er ungleich null ist, sollte bei einer Position im data sein.
. Das Format der Daten wird durch
„annotation_set_item “ unten.
|
Annotationssatzelement
Verweist von „annotations_directory_item“, „field_annotations_item“ method_annotations_item undannotation_set_ref_item
Erscheint im Datenbereich
Ausrichtung: 4 Byte
Name | Format | Beschreibung |
---|---|---|
Größe | Uint | Größe des Datasets in Einträgen |
Einträge | Anmerkung_aus_Artikel[Größe] | Elemente des Datasets. Die Elemente müssen
in aufsteigender Reihenfolge sortiert werden,
von type_idx .
|
Format „annotation_off_item“
Name | Format | Beschreibung |
---|---|---|
Anmerkung_aus | Uint | vom Anfang der Datei zu einer Annotation.
Der Versatz sollte einer Position im Abschnitt data entsprechen.
und das Format der Daten an diesem Speicherort wird durch
„annotation_item “ unten.
|
Anmerkungselement
Verweist von „annotation_set_item“
Erscheint im Datenbereich
Ausrichtung: keine (byte-orientiert)
Name | Format | Beschreibung |
---|---|---|
Sichtbarkeit | Ubyte | beabsichtigte Sichtbarkeit dieser Anmerkung (siehe unten) |
Hinweis | codierte_Anmerkung | codierten Anmerkungsinhalten in dem von
„encoded_annotation -Format“ unter
„encoded_value -Codierung“ oben.
|
Sichtbarkeitswerte
Dies sind die Optionen für das Feld visibility
in einer
annotation_item
:
Name | Wert | Beschreibung |
---|---|---|
SICHTBARKEIT_AUFBAUEN | 0x00 | die nur während der Build-Erstellung sichtbar sein sollen (z.B. während der Kompilierung) des anderen Codes) |
VISIBILITY_RUNTIME | 0x01 | die während der Laufzeit sichtbar sein sollen, |
VISIBILITÄT_SYSTEM | 0x02 | zur Laufzeit sichtbar sein sollen, aber nur für das zugrunde liegende System (und nicht mit dem normalen Nutzercode) |
codiertes_Array-Element
Von class_def_item referenziert
Erscheint im Datenbereich
Ausrichtung: keine (byte-orientiert)
Name | Format | Beschreibung |
---|---|---|
value | codiertes_Array | Bytes, die den codierten Arraywert im angegebenen Format darstellen
von "encoded_array Format" unter „encoded_value “
Codierung“ oben.
|
verborgenes Datenelement der API-Klasse
Dieser Abschnitt enthält Daten zu eingeschränkten Schnittstellen, die von jeder Klasse verwendet werden.
Hinweis: Die verborgene API-Funktion wurde mit Android 10.0 eingeführt. und gilt nur für die DEX-Dateien von Klassen im Bootklassenpfad. Die Liste der unten beschriebenen Flags wird in zukünftigen Releases möglicherweise erweitert. von Android. Weitere Informationen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.
Name | Format | Beschreibung |
---|---|---|
Größe | Uint | Gesamtgröße des Bereichs |
Offsets | uint[] | Array von Offsets, die von class_idx indexiert wurden.
Ein Array-Eintrag mit Null bei Index class_idx bedeutet, dass entweder
Für diese class_idx oder alle ausgeblendeten APIs sind keine Daten vorhanden
sind null.
Andernfalls ist der Arrayeintrag ungleich null und enthält einen Versatz von
dem Anfang des Abschnitts zu einem Array ausgeblendeter API-Flags
für dieses class_idx .
|
Flags | uleb128[] | Verkettete Arrays von verborgenen API-Flags für jede Klasse. Mögliche Flag-Werte sind in der folgenden Tabelle beschrieben. Flags werden in der gleichen Reihenfolge codiert wie Felder und Methoden. in Klassendaten codiert. |
Arten von Einschränkungs-Flags:
Name | Wert | Beschreibung |
---|---|---|
auf die Zulassungsliste setzen | 0 | Schnittstellen, die frei verwendet werden können und als Teil von das offiziell dokumentierte Android-Framework, Paketindex: |
Greylist | 1 | Nicht-SDK-Schnittstellen, die unabhängig vom Ziel-API-Level an. |
Auf die Sperrliste setzen | 2 | Nicht-SDK-Schnittstellen, die unabhängig vom Typ der Anwendung nicht verwendet werden können Ziel-API-Level an. Wenn Sie auf eine dieser Schnittstellen zugreifen, Laufzeitfehler |
Greylist-max-o | 3 | Nicht-SDK-Schnittstellen, die für Android 8.x und niedriger verwendet werden können es sei denn, sie sind eingeschränkt. |
Greylist‐max‐p | 4 | Nicht-SDK-Schnittstellen, die für Android 9.x verwendet werden können es sei denn, sie sind eingeschränkt. |
Greylist‐max‐q | 5 | Nicht-SDK-Schnittstellen, die für Android 10.x verwendet werden können es sei denn, sie sind eingeschränkt. |
Greylist-max-r | 6 | Nicht-SDK-Schnittstellen, die für Android 11.x verwendet werden können es sei denn, sie sind eingeschränkt. |
Systemhinweise
Systemanmerkungen stellen verschiedene reflektierende Elemente dar. Informationen zu Klassen (sowie Methoden und Feldern). Diese Informationen sind Der Zugriff erfolgt in der Regel nur indirekt über Client-Code (kein Systemcode).
Systemanmerkungen werden in .dex
-Dateien als
Anmerkungen, deren Sichtbarkeit auf VISIBILITY_SYSTEM
festgelegt ist.
dalvik.annotation.AnnotationDefault
Erscheint bei Methoden in Anmerkungsoberflächen
Jedem Element wird eine Anmerkung AnnotationDefault
beigefügt.
Anmerkungsoberfläche, in der Standardbindungen angegeben werden sollen.
Name | Format | Beschreibung |
---|---|---|
value | Anmerkung | Die Standardbindungen für diese Annotation, dargestellt als Annotation dieses Typs. Die Annotation muss nicht alle von der Anmerkung; fehlende Namen haben einfach keine Standardnamen. |
dalvik.annotation.EnclosureClass
Erscheint in Kursen
Jede Klasse wird mit einer EnclosingClass
-Anmerkung versehen.
das entweder als Mitglied einer anderen Klasse definiert ist, per se oder
anonym, aber nicht innerhalb eines Methodentexts definiert (z.B. eine synthetische
innere Klasse). Jeder Kurs mit dieser Anmerkung muss auch einen
InnerClass
-Anmerkung. Außerdem darf eine Klasse keine
sowohl ein EnclosingClass
als auch ein
EnclosingMethod
-Anmerkung.
Name | Format | Beschreibung |
---|---|---|
value | Klasse | Die Klasse, die diese Klasse lexikalisch am ehesten beschreibt |
dalvik.annotation.EnclosureMethod
Erscheint in Kursen
Jede Klasse wird mit einer EnclosingMethod
-Anmerkung versehen.
der in einem Methodentext definiert ist. In allen Kursen mit dieser
-Annotation auch eine InnerClass
-Annotation haben.
Außerdem darf eine Klasse nicht sowohl einen EnclosingClass
-Wert haben als auch
und einer EnclosingMethod
-Anmerkung.
Name | Format | Beschreibung |
---|---|---|
value | Method | die Methode, die diese Klasse lexikalisch am genauesten umfasst |
dalvik.annotation.InnerClass
Erscheint in Kursen
Jede Klasse wird mit einer InnerClass
-Anmerkung versehen.
der im lexikalischen Bereich der Definition einer anderen Klasse definiert ist.
Jede Klasse mit dieser Annotation muss außerdem entweder ein
Anmerkung EnclosingClass
oder eine
EnclosingMethod
-Anmerkung.
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 Zugriffs-Flags der Klasse (die sich unterscheiden können) von den geltenden Flags entfernt, weil es eine Diskrepanz zwischen der Ausführung der Quellsprache und der virtuellen Zielmaschine) |
dalvik.annotation.MemberClass
Erscheint in Kursen
Jedem Kurs wird eine MemberClasses
-Anmerkung angehängt.
mit der Member-Klassen deklariert werden. (Eine Mitgliederklasse ist eine direkte innere Klasse,
das einen Namen hat.)
Name | Format | Beschreibung |
---|---|---|
value | Klasse[] | Array der Mitgliederklassen |
dalvik.annotation.MethodParameters
Erscheint bei Methoden
Hinweis:Diese Anmerkung wurde nach Android hinzugefügt. 7.1 In früheren Android-Versionen wird die Funktion ignoriert.
Eine MethodParameters
-Anmerkung ist optional und kann für Folgendes verwendet werden:
Parametermetadaten wie Parameternamen und Modifikatoren bereitstellen.
Die Annotation kann bei einer Methode oder einem Konstruktor sicher weggelassen werden, wenn der
Parametermetadaten sind zur Laufzeit nicht erforderlich.
Mit java.lang.reflect.Parameter.isNamePresent()
kann Folgendes überprüft werden:
Ob Metadaten für einen Parameter vorhanden sind, und die zugehörige Reflexion
wie java.lang.reflect.Parameter.getName()
während der Laufzeit auf das Standardverhalten zurückgesetzt werden, wenn keine Informationen vorhanden sind.
Beim Einbeziehen von Parametermetadaten müssen Compiler Informationen angeben für generierte Klassen wie enums, da die Parameter-Metadaten gibt an, ob ein Parameter synthetisch ist oder erforderlich ist.
Eine MethodParameters
-Anmerkung beschreibt nur eine einzelne Methode.
Parameter. Daher können Compiler die Annotation unter Umständen ganz
für Konstruktoren und Methoden, die keine Parameter haben, aus Gründen der Codegröße
und Laufzeiteffizienz.
Die unten dokumentierten Arrays müssen dieselbe Größe wie für den
method_id_item
dex-Struktur, die der Methode zugeordnet ist, andernfalls
wird ein java.lang.reflect.MalformedParametersException
Laufzeit.
Das heißt: method_id_item.proto_idx
->
proto_id_item.parameters_off
->
type_list.size
muss mit names().length
übereinstimmen und
accessFlags().length
Weil MethodParameters
alle formalen Methoden beschreibt
auch solche, die nicht explizit oder implizit im Quellcode deklariert sind,
Die Größe der Arrays kann sich von der Signatur oder anderen Metadaten unterscheiden.
Informationen, die nur auf expliziten Parametern basieren, die in der Quelle deklariert wurden
Code. MethodParameters
gibt auch keine Informationen über
-Typanmerkungsempfängerparameter, die in der eigentlichen Methode nicht vorhanden sind.
Signatur.
Name | Format | Beschreibung |
---|---|---|
namen | String[] | Die Namen der formalen Parameter für die zugehörige Methode. Das Array
darf nicht null sein, muss aber leer sein, wenn keine formalen Parameter vorhanden sind. Ein Wert in
Das Array muss null sein, wenn der formale Parameter mit diesem Index keinen Namen hat. Strings für Parameternamen sind leer oder enthalten „.“, „;“, „[“ oder "/" dann ein java.lang.reflect.MalformedParametersException wird um
Laufzeit.
|
accessFlags | int[] | Die Zugriffs-Flags der formalen Parameter für die zugehörige Methode. Die
Das Array darf nicht null sein, muss aber leer sein, wenn keine formalen Parameter vorhanden sind. Der Wert ist eine Bitmaske mit den folgenden Werten: <ph type="x-smartling-placeholder">
java.lang.reflect.MalformedParametersException wird zur Laufzeit ausgelöst.
|
dalvik.annotation.Signatur
Erscheint für Klassen, Felder und Methoden
Jede Klasse wird mit einer Signature
-Anmerkung versehen.
Feld oder Methode, die im Hinblick auf einen komplizierteren Typ definiert ist,
als durch type_id_item
dargestellt werden kann. Die
Das .dex
-Format definiert nicht das Format für Signaturen. sie
soll lediglich die Signaturen einer Quelle darstellen.
Sprache ist für die erfolgreiche Implementierung des
Semantik. Daher werden Signaturen im Allgemeinen nicht geparst (oder verifiziert)
durch virtuelle Maschinenimplementierungen. Die Unterschriften werden einfach zugestellt.
auf übergeordnete APIs und Tools (wie Debugger) übertragen. Jegliche Verwendung eines
Signatur ist daher so zu verfassen,
Annahmen darüber, nur gültige Signaturen zu erhalten, expliziter Schutz
der Möglichkeit eines syntaktischen
ungültige Signatur.
Da Signaturstrings in der Regel viele duplizierte Inhalte enthalten,
Eine Signature
-Annotation ist definiert als Array aus
, bei denen sich duplizierte Elemente naturgemäß auf dasselbe
zugrunde liegende Daten und die Signatur ist die Verkettung von
alle Zeichenfolgen im Array. Es gibt keine Regeln dazu, wie
Signatur in separate Strings aufteilen; die vollständig von der
Tools zum Generieren von .dex
-Dateien.
Name | Format | Beschreibung |
---|---|---|
value | String[] | die Signatur dieser Klasse oder dieses Mitglieds als Array von Zeichenfolgen, die miteinander verkettet werden, |
dalvik.annotation.wirft
Erscheint bei Methoden
Jeder Methode wird eine Throws
-Anmerkung zugeordnet,
deklariert, um einen oder mehrere Ausnahmetypen auszulösen.
Name | Format | Beschreibung |
---|---|---|
value | Klasse[] | Das Array der ausgelösten Ausnahmetypen |