Format pliku wykonywalnego Dalvik

W tym dokumencie opisano układ i zawartość plików .dex , które służą do przechowywania zestawu definicji klas i powiązanych z nimi danych dodatkowych.

Przewodnik po typach

LEB128

LEB128 („ Little - Endian Base 128 ”) to kodowanie o zmiennej długości dla dowolnych liczb całkowitych ze znakiem lub bez znaku. Format został zapożyczony ze specyfikacji DWARF3 . W pliku .dex LEB128 jest zawsze używany tylko do kodowania ilości 32-bitowych.

Każda wartość zakodowana w LEB128 składa się z jednego do pięciu bajtów, które razem reprezentują pojedynczą wartość 32-bitową. Każdy bajt ma ustawiony najbardziej znaczący bit, z wyjątkiem ostatniego bajtu w sekwencji, dla którego najbardziej znaczący bit jest wolny. Pozostałe siedem bitów każdego bajtu to ładunek, przy czym najmniej znaczące siedem bitów ilości znajduje się w pierwszym bajcie, kolejnych siedem w drugim bajcie i tak dalej. W przypadku znaku LEB128 ( sleb128 ) najbardziej znaczący bit ładunku ostatniego bajtu w sekwencji jest rozszerzany znakiem w celu uzyskania wartości końcowej. W przypadku bez znaku ( uleb128 ) wszelkie bity, które nie są jawnie reprezentowane, są interpretowane jako 0 .

Wariant uleb128p1 służy do reprezentowania wartości ze znakiem, gdzie reprezentacja jest wartością plus jeden zakodowaną jako uleb128 . To sprawia, że ​​kodowanie -1 (alternatywnie uważanej za wartość bez znaku 0xffffffff ) — ale żadnej innej liczby ujemnej — jest pojedynczym bajtem i jest przydatne dokładnie w tych przypadkach, gdy reprezentowana liczba musi być albo nieujemna, albo -1 (lub 0xffffffff ) i gdzie nie są dozwolone żadne inne wartości ujemne (lub gdzie jest mało prawdopodobne, aby potrzebne były duże wartości bez znaku).

Oto kilka przykładów formatów:

Układ pliku

Definicje pól bitowych, łańcuchów i stałych

DEX_FILE_MAGIC

osadzony w header_item

Stała tablica/łańcuch DEX_FILE_MAGIC to lista bajtów, które muszą pojawić się na początku pliku .dex , aby został on rozpoznany jako taki. Wartość celowo zawiera znak nowej linii ( "\n" lub 0x0a ) i bajt zerowy ( "\0" lub 0x00 ), aby pomóc w wykryciu określonych form korupcji. Wartość koduje również numer wersji formatu w postaci trzech cyfr dziesiętnych, a liczba ta powinna z czasem rosnąć monotonicznie w miarę ewolucji formatu.

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

Uwaga: w wersji Androida 9.0 dodano obsługę wersji 039 formatu, która wprowadziła dwa nowe kody bajtowe: const-method-handle i const-method-type . (Każdy z nich opisano w tabeli Podsumowanie zestawów kodów bajtowych ). W systemie Android 10 wersja 039 rozszerza format pliku DEX, aby uwzględnić ukryte informacje API, które mają zastosowanie tylko do plików DEX w ścieżce klasy rozruchowej.

Uwaga: w wersji Androida 8.0 dodano obsługę wersji 038 formatu. Wersja 038 dodała nowe kody bajtowe ( invoke-polymorphic i invoke-custom ) oraz dane dla uchwytów metod.

Uwaga: w wersji Androida 7.0 dodano obsługę wersji 037 formatu. Przed wersją 037 większość wersji Androida korzystała z wersji 035 formatu. Jedyną różnicą pomiędzy wersjami 035 i 037 jest dodanie metod domyślnych i dostosowanie invoke .

Uwaga: co najmniej kilka wcześniejszych wersji tego formatu było używanych w powszechnie dostępnych publicznych wydaniach oprogramowania. Na przykład wersja 009 była używana w wydaniach M3 platformy Android (listopad – grudzień 2007), a wersja 013 była używana w wydaniach M5 platformy Android (luty – marzec 2008). Pod kilkoma względami te wcześniejsze wersje formatu różnią się znacznie od wersji opisanej w tym dokumencie.

ENDIAN_CONSTANT i REVERSE_ENDIAN_CONSTANT

osadzony w header_item

Stała ENDIAN_CONSTANT służy do wskazania endianowości pliku, w którym się znajduje. Chociaż standardowym formatem .dex jest Little-Endian, implementacje mogą zdecydować się na wykonanie zamiany bajtów. Jeśli implementacja napotka nagłówek, którego endian_tag ma REVERSE_ENDIAN_CONSTANT zamiast ENDIAN_CONSTANT , będzie wiedzieć, że plik został zamieniony bajtami z oczekiwanej formy.

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

NO_INDEX

osadzone w class_def_item i debug_info_item

Stała NO_INDEX służy do wskazania braku wartości indeksu.

Uwaga: ta wartość nie jest zdefiniowana jako 0 , ponieważ w rzeczywistości jest to zazwyczaj prawidłowy indeks.

Wybrana wartość NO_INDEX jest reprezentowana jako pojedynczy bajt w kodowaniu uleb128p1 .

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

definicje flag_dostępu

osadzone w class_def_item, encoded_field, encoded_method i InnerClass

Pola bitowe tych flag służą do wskazania dostępności i ogólnych właściwości klas i członków klas.

* Dozwolona tylko w przypadku adnotacji InnerClass i nigdy nie może być włączona w class_def_item .

Kodowanie MUTF-8 (zmodyfikowany UTF-8).

W ramach ustępstwa na rzecz łatwiejszej obsługi starszych wersji, format .dex koduje dane w postaci ciągów znaków w de facto standardowej zmodyfikowanej formie UTF-8, zwanej dalej MUTF-8. Formularz ten jest identyczny ze standardowym UTF-8, z wyjątkiem:

• Stosowane jest tylko kodowanie jedno-, dwu- i trzybajtowe.
• Punkty kodowe z zakresu U+10000 … U+10ffff są kodowane jako para zastępcza, z których każda jest reprezentowana jako zakodowana wartość trzybajtowa.
• Punkt kodowy U+0000 jest kodowany w postaci dwubajtowej.
• Zwykły bajt zerowy (wartość 0 ) wskazuje koniec łańcucha, zgodnie ze standardową interpretacją języka C.

Pierwsze dwa powyższe elementy można podsumować w następujący sposób: MUTF-8 to format kodowania dla UTF-16, zamiast być bardziej bezpośrednim formatem kodowania znaków Unicode.

Ostatnie dwa elementy powyżej umożliwiają jednoczesne włączenie punktu kodowego U+0000 do ciągu i nadal manipulowanie nim jako ciągiem zakończonym zerem w stylu C.

Jednak specjalne kodowanie U+0000 oznacza, że ​​w przeciwieństwie do zwykłego UTF-8, wynik wywołania standardowej funkcji C strcmp() na parze ciągów MUTF-8 nie zawsze wskazuje poprawnie podpisany wynik porównania nierównych ciągów . Gdy problemem jest kolejność (nie tylko równość), najprostszym sposobem porównania ciągów MUTF-8 jest dekodowanie ich znak po znaku i porównanie zdekodowanych wartości. (Jednak możliwe są również bardziej sprytne implementacje.)

Więcej informacji na temat kodowania znaków można znaleźć w dokumencie Standard Unicode . MUTF-8 jest w rzeczywistości bliższy (stosunkowo mniej znanemu) kodowaniu CESU-8 niż UTF-8 jako takiemu.

kodowanie wartości_kodowanej

osadzone w annotation_element i encoded_array_item

encoded_value to zakodowany fragment (prawie) dowolnych danych o strukturze hierarchicznej. Kodowanie ma być zarówno zwarte, jak i łatwe do analizy.

Formaty wartości

format zakodowanej_tablicy

format zakodowanej_adnotacji

format elementu adnotacji

Składnia ciągu

W pliku .dex istnieje kilka rodzajów elementów, które ostatecznie odnoszą się do ciągu znaków. Poniższe definicje w stylu BNF wskazują akceptowalną składnię tych ciągów.

Prosta nazwa

SimpleName jest podstawą składni nazw innych rzeczy. Format .dex zapewnia tutaj dużą swobodę (znacznie większą niż w przypadku większości popularnych języków źródłowych). W skrócie, prosta nazwa składa się z dowolnego znaku lub cyfry z niskiego ASCII, kilku określonych symboli z niskiego ASCII i większości punktów kodowych spoza ASCII, które nie są znakami kontrolnymi, spacjami ani znakami specjalnymi. Począwszy od wersji 040 format dodatkowo dopuszcza znaki spacji (kategoria Unicode Zs ). Należy zauważyć, że zastępcze punkty kodowe (w zakresie U+d800 … U+dfff ) nie są same w sobie uważane za prawidłowe znaki nazwy, ale prawidłowe są dodatkowe znaki Unicode (które są reprezentowane przez ostateczną alternatywę reguły dla SimpleNameChar ) i powinny być reprezentowane w pliku jako pary zastępczych punktów kodowych w kodowaniu MUTF-8.

Nazwa członka

używane przez Field_id_item i method_id_item

MemberName to nazwa członka klasy, której członkami są pola, metody i klasy wewnętrzne.

Pełna nazwa klasy

FullClassName to w pełni kwalifikowana nazwa klasy, zawierająca opcjonalny specyfikator pakietu, po którym następuje wymagana nazwa.

Deskryptor typu

używany przez type_id_item

TypeDescriptor to reprezentacja dowolnego typu, w tym elementów pierwotnych, klas, tablic i void . Poniżej znajdziesz znaczenie różnych wersji.

Krótki opis

używany przez proto_id_item

ShortyDescriptor to krótka reprezentacja prototypu metody, obejmująca typy zwracane i parametry, z tą różnicą, że nie ma rozróżnienia między różnymi typami referencyjnymi (klasami lub tablicami). Zamiast tego wszystkie typy referencyjne są reprezentowane przez pojedynczy znak 'L' .

Semantyka deskryptora typu

Takie jest znaczenie każdego z wariantów TypeDescriptor .

Przedmioty i powiązane struktury

Ta sekcja zawiera definicje każdego elementu najwyższego poziomu, który może pojawić się w pliku .dex .

element nagłówka

pojawia się w sekcji nagłówka

wyrównanie: 4 bajty

lista_map

pojawia się w sekcji danych

odniesienie do header_item

wyrównanie: 4 bajty

To jest lista całej zawartości pliku, w kolejności. Zawiera pewną nadmiarowość w odniesieniu do header_item , ale ma być łatwą w użyciu formą iteracji po całym pliku. Dany typ musi pojawić się na mapie najwyżej raz, ale nie ma żadnych ograniczeń co do kolejności, w jakiej typy mogą się pojawiać, poza ograniczeniami wynikającymi z pozostałej części formatu (np. sekcja header musi pojawić się jako pierwsza, po której następuje string_ids sekcja itp.). Dodatkowo wpisy na mapie muszą być uporządkowane według przesunięcia początkowego i nie mogą na siebie zachodzić.

format elementu mapy

Wpisz kody

string_id_item

pojawia się w sekcji string_ids

wyrównanie: 4 bajty

element_danych_stringu

pojawia się w sekcji danych

wyrównanie: brak (wyrównane do bajtów)

typ_id_item

pojawia się w sekcji type_ids

wyrównanie: 4 bajty

proto_id_item

pojawia się w sekcji proto_ids

wyrównanie: 4 bajty

element_id_pola

pojawia się w sekcji Field_ids

wyrównanie: 4 bajty

metoda_id_item

pojawia się w sekcji method_ids

wyrównanie: 4 bajty

class_def_item

pojawia się w sekcji class_defs

wyrównanie: 4 bajty

call_site_id_item

pojawia się w sekcji call_site_ids

wyrównanie: 4 bajty

call_site_item

pojawia się w sekcji danych

wyrównanie: brak (wyrównane bajty)

Call_site_item to encoded_array_item, którego elementy odpowiadają argumentom dostarczonym do metody linkera ładującego. Pierwsze trzy argumenty to:

1. Uchwyt metody reprezentujący metodę linkera ładowania początkowego (VALUE_METHOD_HANDLE).
2. Nazwa metody, którą powinien rozwiązać linker ładowania początkowego (VALUE_STRING).
3. Typ metody odpowiadający typowi nazwy metody, która ma zostać rozpoznana (VALUE_METHOD_TYPE).

Wszelkie dodatkowe argumenty są wartościami stałymi przekazywanymi do metody linkera ładującego. Argumenty te są przekazywane w kolejności i bez konwersji typów.

Uchwyt metody reprezentujący metodę linkera ładowania początkowego musi mieć typ zwracany java.lang.invoke.CallSite . Pierwsze trzy typy parametrów to:

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

Typy parametrów dodatkowych argumentów są określane na podstawie ich stałych wartości.

metoda_uchwytu_item

pojawia się w sekcji method_handles

wyrównanie: 4 bajty

Kody typu uchwytu metody

class_data_item

Odwołane z klasy_def_item

pojawia się w sekcji danych

Wyrównanie: Brak (bajtowy)

UWAGA: Wszystkie elementy „ field_id s i method_id S muszą odnosić się do tej samej klasy definiującej.

Format kodeded_field

Format Encoded_Method

Type_List

Odwołane z klasy_def_item i proto_id_item

pojawia się w sekcji danych

Wyrównanie: 4 bajty

Format typu_item

Code_item

Odwołany od Encoded_Method

pojawia się w sekcji danych

Wyrównanie: 4 bajty

Format try_item

Encoded_catch_handler_list Format

Format Encoded_Catch_Handler

Format Encoded_Type_Addr_Pair

debug_info_item

Odwołane z Code_Item

pojawia się w sekcji danych

Wyrównanie: Brak (bajtowy)

Każdy debug_info_item definiuje inspirowaną przez Dwarf3 maszynę stanową kodowaną przez bajtę, która po interpretacji emituje tabelę pozycji i (potencjalnie) informacje o zmiennej lokalnej dla code_item . Sekwencja rozpoczyna się od nagłówka o zmiennej długości (której długość zależy od liczby parametrów metody), następuje bajt maszyny stanu, a kończy bajtem DBG_END_SEQUENCE .

Maszyna stanowa składa się z pięciu rejestrów. Rejestr address reprezentuje przesunięcie instrukcji w powiązanym insns_item w 16-bitowych jednostkach kodowych. Rejestr address rozpoczyna się od 0 na początku każdej sekwencji debug_info i musi jedynie monotonicznie rosnąć. Rejestr line reprezentuje, jaki numer linii źródłowej powinien być powiązany z następnymi pozycjami wpisu tabeli emitowanej przez maszynę stanową. Jest inicjowany w nagłówku sekwencji i może zmieniać pozytywne lub negatywne kierunki, ale nigdy nie może być mniejsze niż 1 . Rejestr source_file reprezentuje plik źródłowy, do którego odnoszą się wpisy numeru linii. Jest inicjowany do wartości source_file_idx w class_def_item . Pozostałe dwie zmienne, prologue_end i epilogue_begin , to flagi boolowskie (zainicjowane do false ), które wskazują, czy kolejne emitowane pozycja należy uznać za metodę prolog lub epilog. Maszyna stanu musi również śledzić nazwę i rodzaj ostatniej zmiennej lokalnej na żywo w każdym rejestrze dla kodu DBG_RESTART_LOCAL .

Nagłówek jest następujący:

Wartości kodu bajtów są następujące:

Specjalne opcody

Kody o wartości między 0x0a a 0xff (włączające) przesuwają zarówno rejestry line , jak i address o niewielką ilość, a następnie emitować nowy wpis tabeli pozycji. Wzór przyrostów jest następujący:

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

Odwołane z klasy_def_item

pojawia się w sekcji danych

Wyrównanie: 4 bajty

UWAGA: Wszystkie elementy „ field_id s i method_id S muszą odnosić się do tej samej klasy definiującej.

Format field_annotation

Method_annotation Format

Parameter_annotation Format

annotation_set_ref_list

Odwołany z parametru_annotations_item

pojawia się w sekcji danych

Wyrównanie: 4 bajty

Format adnotation_set_ref_item

Annotation_Set_item

Odwołany od adnotations_directory_item, field_annotations_item, metod_annotations_item i adnotation_set_ref_item

pojawia się w sekcji danych

Wyrównanie: 4 bajty

Format annotation_off_item

Annotation_item

Odwołany od adnotation_set_item

pojawia się w sekcji danych

Wyrównanie: Brak (bajtowy)

Wartości widoczności

Są to opcje pola visibility w annotation_item :

encoded_array_item

Odwołane z klasy_def_item

pojawia się w sekcji danych

Wyrównanie: Brak (bajtowy)

hiddenapi_class_data_item

W tej sekcji zawiera dane dotyczące ograniczonych interfejsów używanych przez każdą klasę.

Uwaga: Funkcja ukrytego API została wprowadzona w Android 10.0 i ma zastosowanie tylko do plików DEX klas na ścieżce klasy rozruchowej. Lista flag opisanych poniżej można rozszerzyć w przyszłych wydaniach Androida. Aby uzyskać więcej informacji, zobacz ograniczenia dotyczące interfejsów innych niż SDK .

Rodzaje flag ograniczeń:

Adnotacje systemowe

Adnotacje systemowe są wykorzystywane do przedstawienia różnych elementów refleksyjnych informacji o klasach (i metodach i polach). Informacje te są na ogół dostępne tylko pośrednio przez kod klienta (inne niż system).

Adnotacje systemowe są reprezentowane w plikach .dex jako adnotacje z widocznością ustawionymi na VISIBILITY_SYSTEM .

dalvik.annotation.annotationdefault

pojawia się na metodach w interfejsach adnotacyjnych

Do każdego interfejsu adnotacji jest dołączona adnotacja AnnotationDefault , która chce wskazać domyślne powiązania.

dalvik.annotation.enclosingClass

pojawia się na zajęciach

Do każdej klasy dołączona jest adnotacja EnclosingClass , która jest zdefiniowana jako członek innej klasy, per se, albo jest anonimowy, ale nie zdefiniowany w ciele metody (np. Syntetyczna klasa wewnętrzna). Każda klasa, która ma tę adnotację, musi również mieć adnotację InnerClass . Dodatkowo klasa nie może mieć zarówno EnclosingClass , jak i EnclosingMethod adnotacji.

dalvik.annotation.enclosingMethod

pojawia się na zajęciach

Do każdej klasy, która jest zdefiniowana w ciele metody, jest dołączona EnclosingMethod . Każda klasa, która ma tę adnotację, musi również mieć adnotację InnerClass . Dodatkowo klasa nie może mieć zarówno EnclosingClass , jak i EnclosingMethod adnotacji.

dalvik.annotation.innerclass

pojawia się na zajęciach

Do każdej klasy dołączono adnotację InnerClass , która jest zdefiniowana w zakresie leksykalnej definicji innej klasy. Każda klasa, która ma tę adnotację, musi również zawierać adnotację EnclosingClass lub EnclosingMethod adnotację.

dalvik.annotation.memberclasses

pojawia się na zajęciach

Do każdej klasy są dołączane do MemberClasses . (Klasa członkowska to bezpośrednia klasa wewnętrzna, która ma nazwę.)

dalvik.annotation.methodparameters

pojawia się na metodach

Uwaga: Ta adnotacja została dodana po Androida 7.1. Jego obecność na wcześniejszych wydaniach z Androidem zostanie zignorowana.

Adnotacja MethodParameters jest opcjonalna i może być używana do dostarczania metadanych parametrów, takich jak nazwy parametrów i modyfikatory.

Adnotację można bezpiecznie pominąć w metodzie lub konstruktora, gdy metadane parametrów nie są wymagane w czasie wykonywania. java.lang.reflect.Parameter.isNamePresent() można użyć do sprawdzenia, czy metadane są obecne dla parametru, a powiązane metody odbicia, takie jak java.lang.reflect.Parameter.getName() , powrócą do domyślnego zachowania w czasie wykonywania. Jeśli informacje nie są obecne.

Przy uwzględnieniu metadanych parametrów kompilatory muszą zawierać informacje dla wygenerowanych klas, takich jak wyliczenia, ponieważ metadane parametrów zawiera to, czy parametr jest syntetyczny, czy nakazany.

Adnotacja MethodParameters opisuje tylko indywidualne parametry metody. Dlatego kompilatory mogą całkowicie pominąć adnotację dla konstruktorów i metod, które nie mają parametrów, ze względu na wydajność wielkości kodu i wykonania środowiska wykonawczego.

Tablice udokumentowane poniżej muszą mieć ten sam rozmiar, co w przypadku struktury DEX method_id_item powiązanej z metodą, w przeciwnym razie java.lang.reflect.MalformedParametersException zostanie wyrzucony w czasie wykonywania.

To znaczy: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size musi być taki sam jak names().length i accessFlags().length .

Ponieważ MethodParameters opisuje wszystkie parametry metody formalnej, nawet te, które nie są jawne lub domyślnie zadeklarowane w kodzie źródłowym, rozmiar tablic może różnić się od podpisu lub innych informacji o metadanych opartych wyłącznie na wyraźnych parametrach ogłoszonych w kodzie źródłowym. MethodParameters nie będą również zawierać żadnych informacji o parametrach odbiornika adnotacji typu, które nie istnieją w faktycznej metodzie.

dalvik.annotation.signature

pojawia się na zajęciach, polach i metodach

Do każdej klasy, pola lub metody jest dołączona do opisu Signature , która jest zdefiniowana w kategoriach bardziej skomplikowanego typu niż jest reprezentowana przez type_id_item . Format .dex nie definiuje formatu podpisów; Ma to jedynie na celu reprezentowanie wszelkich podpisów, jakie wymaga języka źródłowego, aby pomyślnie wdrożyć semantykę tego języka. W związku z tym podpisy nie są na ogół analizowane (lub weryfikowane) przez implementacje maszyn wirtualnych. Podpisy są po prostu przekazywane interfejsom API i narzędzi wyższego poziomu (takich jak debuggery). Dlatego wszelkie użycie podpisu powinno być napisane, aby nie przyjmować żadnych założeń dotyczących tylko otrzymywania ważnych podpisów, wyraźnie strzegącym się przed możliwością spotkania się z syntaktycznie nieważnym podpisem.

Ponieważ sznurki podpisowe mają tendencję do wielu zduplikowanych treści, Signature adnotacja jest zdefiniowana jako tablica ciągów, w których powielone elementy naturalnie odnoszą się do tych samych danych podstawowych, a podpis jest podejmowany jako połączenie wszystkich ciągów w tablicy . Nie ma żadnych zasad dotyczących rozdzielenia podpisu w oddzielne struny; To zależy całkowicie do narzędzi generujących pliki .dex .

dalvik.annotation.throws

pojawia się na metodach

Do każdej Throws , która jest zadeklarowana do rzucania jednego lub więcej typów wyjątków.