รูปแบบไฟล์ปฏิบัติการ Dalvik

เอกสารนี้อธิบายโครงร่างและเนื้อหาของไฟล์ .dex ซึ่งใช้เพื่อเก็บชุดของคำจำกัดความของคลาสและข้อมูลเสริมที่เกี่ยวข้อง

คู่มือประเภท

LEB128

LEB128 (" L ittle- E ndian B ase 128 ") คือการเข้ารหัสที่มีความยาวผันแปรได้สำหรับปริมาณจำนวนเต็มที่มีการลงชื่อหรือไม่ได้ลงนามโดยอำเภอใจ รูปแบบนี้ยืมมาจากข้อกำหนด DWARF3 ในไฟล์ .dex .dex ถูกใช้เพื่อเข้ารหัสปริมาณแบบ 32 บิตเท่านั้น

ค่าที่เข้ารหัส LEB128 แต่ละค่าประกอบด้วยหนึ่งถึงห้าไบต์ ซึ่งรวมกันแทนค่า 32 บิตเดียว แต่ละไบต์มีชุดบิตที่สำคัญที่สุด ยกเว้นไบต์สุดท้ายในลำดับ ซึ่งมีบิตที่ชัดเจนที่สุด เจ็ดบิตที่เหลือของแต่ละไบต์คือเพย์โหลด โดยมีปริมาณเจ็ดบิตที่มีนัยสำคัญน้อยที่สุดในไบต์แรก เจ็ดบิตถัดไปในไบต์ที่สอง และอื่นๆ ในกรณีของ LEB128 ที่ลงนาม ( sleb128 ) บิตเพย์โหลดที่สำคัญที่สุดของไบต์สุดท้ายในลำดับจะถูกขยายสัญญาณเพื่อสร้างค่าสุดท้าย ในกรณีที่ไม่ได้ลงนาม ( uleb128 ) บิตใดๆ ที่ไม่ได้แสดงไว้อย่างชัดเจนจะถูกตีความว่าเป็น 0

ตัวแปร uleb128p1 ใช้เพื่อแสดงค่าที่ลงนาม โดยการแสดงเป็นค่า บวกหนึ่ง เข้ารหัสเป็น uleb128 สิ่งนี้ทำให้การเข้ารหัสของ -1 (หรือคิดอีกทางหนึ่งว่าเป็นค่าที่ไม่ได้ลงนาม 0xffffffff ) — แต่ไม่มีตัวเลขติดลบอื่น — ไบต์เดียว และมีประโยชน์ในกรณีที่ตัวเลขที่แสดงต้องไม่เป็นค่าลบหรือ -1 (หรือ 0xffffffff ) และในกรณีที่ไม่อนุญาตให้มีค่าลบอื่น ๆ (หรือในกรณีที่ไม่ต้องการค่าขนาดใหญ่ที่ไม่ได้ลงนาม)

นี่คือตัวอย่างบางส่วนของรูปแบบ:

รูปแบบไฟล์

คำจำกัดความของ Bitfield, string และค่าคงที่

DEX_FILE_MAGIC

ฝังอยู่ใน header_item

อาร์เรย์/สตริงคงที่ DEX_FILE_MAGIC คือรายการของไบต์ที่ต้องปรากฏที่จุดเริ่มต้นของไฟล์ .dex เพื่อให้ระบบรู้จักไฟล์ดังกล่าว ค่ามีเจตนาประกอบด้วยการขึ้นบรรทัดใหม่ ( "\n" หรือ 0x0a ) และไบต์ว่าง ( "\0" หรือ 0x00 ) เพื่อช่วยในการตรวจหาความเสียหายบางรูปแบบ ค่านี้ยังเข้ารหัสหมายเลขเวอร์ชันของรูปแบบเป็นทศนิยมสามหลัก ซึ่งคาดว่าจะเพิ่มขึ้นอย่างซ้ำซากจำเจเมื่อเวลาผ่านไปในขณะที่รูปแบบพัฒนาขึ้น

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

หมายเหตุ: เพิ่มการรองรับเวอร์ชัน 039 ของรูปแบบใน Android 9.0 ซึ่งเปิดตัว bytecodes ใหม่สองตัว const-method-handle และ const-method-type (มีอธิบายไว้ในตาราง สรุปชุดไบต์โค้ด ) ใน Android 10 เวอร์ชัน 039 ขยายรูปแบบไฟล์ DEX เพื่อรวมข้อมูล API ที่ซ่อนอยู่ซึ่งใช้ได้กับไฟล์ DEX บนเส้นทางคลาสบูตเท่านั้น

หมายเหตุ: เพิ่มการรองรับเวอร์ชัน 038 ของรูปแบบใน Android 8.0 รีลีส เวอร์ชัน 038 เพิ่ม bytecodes ใหม่ ( invoke-polymorphic และ invoke-custom ) และข้อมูลสำหรับการจัดการเมธอด

หมายเหตุ: เพิ่มการรองรับเวอร์ชัน 037 ของรูปแบบใน Android 7.0 รีลีส ก่อนหน้าเวอร์ชัน 037 Android เวอร์ชันส่วนใหญ่ใช้เวอร์ชัน 035 ของรูปแบบ ความแตกต่างเพียงอย่างเดียวระหว่างเวอร์ชัน 035 และ 037 คือการเพิ่มวิธีการเริ่มต้นและการปรับการ invoke

หมายเหตุ: มีการใช้รูปแบบเวอร์ชันก่อนหน้าอย่างน้อยสองสามเวอร์ชันในซอฟต์แวร์สาธารณะที่เผยแพร่อย่างกว้างขวาง ตัวอย่างเช่น เวอร์ชัน 009 ใช้สำหรับเวอร์ชัน M3 ของแพลตฟอร์ม Android (พฤศจิกายน–ธันวาคม 2550) และเวอร์ชัน 013 ใช้สำหรับเวอร์ชัน M5 ของแพลตฟอร์ม Android (กุมภาพันธ์–มีนาคม 2551) รูปแบบเวอร์ชันก่อนหน้าเหล่านี้แตกต่างอย่างมากจากเวอร์ชันที่อธิบายไว้ในเอกสารนี้ในหลายประการ

ENDIAN_CONSTANT และ REVERSE_ENDIAN_CONSTANT

ฝังอยู่ใน header_item

ค่าคงที่ ENDIAN_CONSTANT ใช้เพื่อระบุจุดสิ้นสุดของไฟล์ที่พบ แม้ว่ารูปแบบ .dex มาตรฐานจะเป็นแบบ little-endian แต่การใช้งานอาจเลือกที่จะทำการสลับไบต์ได้ หากการใช้งานพบส่วนหัวที่มี endian_tag เป็น REVERSE_ENDIAN_CONSTANT แทนที่จะเป็น ENDIAN_CONSTANT ก็จะรู้ว่าไฟล์ถูกสลับไบต์จากแบบฟอร์มที่คาดไว้

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

NO_INDEX

ฝังอยู่ใน class_def_item และ debug_info_item

ค่าคงที่ NO_INDEX ใช้เพื่อระบุว่าไม่มีค่าดัชนี

หมายเหตุ: ค่านี้ไม่ได้กำหนดเป็น 0 เนื่องจากโดยทั่วไปแล้วจะเป็นดัชนีที่ถูกต้อง

ค่าที่เลือกสำหรับ NO_INDEX สามารถแสดงเป็นไบต์เดียวในการเข้ารหัส uleb128p1

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

คำจำกัดความ access_flags

ฝังอยู่ใน class_def_item, encoded_field, encoded_method และ InnerClass

บิตฟิลด์ของแฟล็กเหล่านี้ใช้เพื่อระบุการเข้าถึงและคุณสมบัติโดยรวมของคลาสและสมาชิกคลาส

* อนุญาตเฉพาะสำหรับคำอธิบายประกอบ InnerClass และต้องไม่เปิดใน class_def_item

การเข้ารหัส MUTF-8 (ดัดแปลง UTF-8)

เพื่อเป็นการยินยอมในการสนับสนุนแบบเดิมที่ง่ายขึ้น รูปแบบ .dex จะเข้ารหัสข้อมูลสตริงในรูปแบบ UTF-8 ที่แก้ไขโดยพฤตินัยมาตรฐาน ซึ่งต่อจากนี้จะเรียกว่า MUTF-8 แบบฟอร์มนี้เหมือนกับ UTF-8 มาตรฐาน ยกเว้น:

• ใช้การเข้ารหัสแบบหนึ่ง สอง และสามไบต์เท่านั้น
• รหัสชี้อยู่ในช่วง U+10000 … U+10ffff ถูกเข้ารหัสเป็นคู่ตัวแทน ซึ่งแต่ละค่าจะแสดงเป็นค่าที่เข้ารหัสแบบสามไบต์
• จุดรหัส U+0000 ถูกเข้ารหัสในรูปแบบสองไบต์
• null null ธรรมดา (value 0 ) ระบุจุดสิ้นสุดของสตริง เช่นเดียวกับการตีความภาษา C มาตรฐาน

สองรายการแรกข้างต้นสามารถสรุปได้ดังนี้: MUTF-8 เป็นรูปแบบการเข้ารหัสสำหรับ UTF-16 แทนที่จะเป็นรูปแบบการเข้ารหัสโดยตรงสำหรับอักขระ Unicode

สองรายการสุดท้ายด้านบนทำให้สามารถรวมจุดโค้ด U+0000 ลงในสตริงได้พร้อมๆ กัน และ ยังคงจัดการเป็นสตริงที่สิ้นสุดด้วยค่า null สไตล์ C

อย่างไรก็ตาม การเข้ารหัสแบบพิเศษของ U+0000 หมายความว่าไม่เหมือนกับ UTF-8 ปกติ ผลลัพธ์ของการเรียกใช้ฟังก์ชัน C มาตรฐาน strcmp() บนคู่ของสตริง MUTF-8 ไม่ได้ระบุผลลัพธ์ที่ลงนามอย่างถูกต้องของการเปรียบเทียบสตริงที่ ไม่เท่ากัน เสมอไป . เมื่อต้องสั่งซื้อ (ไม่ใช่แค่ความเท่าเทียมกัน) เป็นเรื่องที่ต้องกังวล วิธีที่ตรงไปตรงมาที่สุดในการเปรียบเทียบสตริง MUTF-8 คือการถอดรหัสอักขระทีละอักขระ และเปรียบเทียบค่าที่ถอดรหัส (อย่างไรก็ตาม การใช้งานที่ชาญฉลาดยิ่งขึ้นก็เป็นไปได้เช่นกัน)

โปรดดูที่ The Unicode Standard สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเข้ารหัสอักขระ จริง ๆ แล้ว MUTF-8 นั้นใกล้เคียงกับการเข้ารหัส CESU-8 (ค่อนข้างเป็นที่รู้จักน้อย) มากกว่า UTF-8 ต่อตัว

encoded_value การเข้ารหัส

ฝังอยู่ใน annotation_element และ encoded_array_item

encoded_value คือส่วนที่เข้ารหัสของข้อมูลที่มีโครงสร้างแบบลำดับชั้น (เกือบ) โดยพลการ การเข้ารหัสมีจุดมุ่งหมายเพื่อให้มีขนาดกะทัดรัดและง่ายต่อการแยกวิเคราะห์

รูปแบบค่า

encoded_array รูปแบบ

encoded_annotation รูปแบบ

รูปแบบคำอธิบายประกอบ_องค์ประกอบ

ไวยากรณ์สตริง

มีรายการหลายประเภทในไฟล์ .dex ซึ่งท้ายที่สุดจะอ้างถึงสตริง คำจำกัดความรูปแบบ BNF ต่อไปนี้ระบุไวยากรณ์ที่ยอมรับได้สำหรับสตริงเหล่านี้

SimpleName

SimpleName เป็นพื้นฐานสำหรับไวยากรณ์ของชื่อของสิ่งอื่น รูปแบบ .dex อนุญาตให้ใช้ละติจูดที่นี่ (มากกว่าภาษาต้นฉบับทั่วไปส่วนใหญ่) โดยสังเขป ชื่ออย่างง่ายประกอบด้วยอักขระหรือตัวเลขที่เป็นตัวอักษร ASCII ต่ำ สัญลักษณ์ ASCII ต่ำบางตัว และจุดรหัสที่ไม่ใช่ ASCII ส่วนใหญ่ซึ่งไม่ได้ควบคุม เว้นวรรค หรืออักขระพิเศษ เริ่มตั้งแต่เวอร์ชัน 040 รูปแบบนี้อนุญาตให้ใช้อักขระเว้นวรรคเพิ่มเติมได้ (หมวด Unicode Zs ) โปรดทราบว่าจุดรหัสตัวแทน (ในช่วง U+d800 d800 … U+dfff ) ไม่ถือว่าเป็นอักขระชื่อที่ถูกต้อง ต่อ se แต่อักขระเสริม Unicode นั้น ถูกต้อง (ซึ่งแสดงโดยทางเลือกสุดท้ายของกฎสำหรับ SimpleNameChar ) และพวกมัน ควรแสดงในไฟล์เป็นคู่ของรหัสตัวแทนในการเข้ารหัส MUTF-8

ชื่อสมาชิก

ใช้โดย field_id_item และ method_id_item

MemberName คือชื่อของสมาชิกของคลาส สมาชิกเป็นฟิลด์ เมธอด และคลาสภายใน

ชื่อเต็มคลาส

FullClassName คือชื่อคลาสที่มีคุณสมบัติครบถ้วน รวมถึงตัวระบุแพ็คเกจที่เป็นตัวเลือกตามด้วยชื่อที่ต้องการ

ประเภทคำอธิบาย

ใช้โดย type_id_item

TypeDescriptor เป็นตัวแทนประเภทใดก็ได้ รวมถึง primitives, คลาส, อาร์เรย์ และ void ดูความหมายของเวอร์ชันต่างๆ ด้านล่าง

ShortyDescriptor

ใช้โดย proto_id_item

ShortyDescriptor คือการแสดงรูปแบบสั้น ๆ ของต้นแบบวิธีการ ซึ่งรวมถึงประเภทการส่งคืนและพารามิเตอร์ ยกเว้นว่าไม่มีความแตกต่างระหว่างประเภทการอ้างอิง (คลาสหรืออาร์เรย์) ต่างๆ ประเภทการอ้างอิงทั้งหมดจะแสดงด้วยอักขระ 'L' ตัวเดียวแทน

TypeDescriptor Semantics

นี่คือความหมายของแต่ละตัวแปรของ TypeDescriptor

รายการและโครงสร้างที่เกี่ยวข้อง

ส่วนนี้มีคำจำกัดความสำหรับแต่ละรายการระดับบนสุดที่อาจปรากฏในไฟล์ .dex

header_item

ปรากฏในส่วนหัว

การจัดตำแหน่ง: 4 ไบต์

map_list

ปรากฏในส่วนข้อมูล

อ้างอิงจาก header_item

การจัดตำแหน่ง: 4 ไบต์

นี่คือรายการเนื้อหาทั้งหมดของไฟล์ตามลำดับ มีความซ้ำซ้อนบางอย่างเกี่ยวกับ header_item แต่มีวัตถุประสงค์เพื่อให้เป็นรูปแบบที่ใช้งานง่ายเพื่อทำซ้ำในไฟล์ทั้งหมด ประเภทที่กำหนดจะต้องปรากฏอย่างมากที่สุดครั้งเดียวในแผนที่ แต่ไม่มีข้อจำกัดว่าประเภทคำสั่งใดที่อาจปรากฏในนั้น นอกเหนือจากข้อจำกัดที่บอกเป็นนัยโดยรูปแบบที่เหลือ (เช่น header ต้องปรากฏก่อน ตามด้วย string_ids ส่วน เป็นต้น) นอกจากนี้ รายการแผนที่ต้องเรียงลำดับตามออฟเซ็ตเริ่มต้นและต้องไม่ทับซ้อนกัน

map_item รูปแบบ

พิมพ์รหัส

string_id_item

ปรากฏในส่วน string_ids

การจัดตำแหน่ง: 4 ไบต์

string_data_item

ปรากฏในส่วนข้อมูล

การจัดตำแหน่ง: ไม่มี (จัดตำแหน่งแบบไบต์)

type_id_item

ปรากฏในส่วน type_ids

การจัดตำแหน่ง: 4 ไบต์

proto_id_item

ปรากฏในส่วน proto_ids

การจัดตำแหน่ง: 4 ไบต์

field_id_item

ปรากฏในส่วน field_ids

การจัดตำแหน่ง: 4 ไบต์

method_id_item

ปรากฏในส่วน method_ids

การจัดตำแหน่ง: 4 ไบต์

class_def_item

ปรากฏในหมวด class_defs

การจัดตำแหน่ง: 4 ไบต์

call_site_id_item

ปรากฏในส่วน call_site_ids

การจัดตำแหน่ง: 4 ไบต์

call_site_item

ปรากฏในส่วนข้อมูล

การจัดตำแหน่ง: ไม่มี (จัดตำแหน่งไบต์)

call_site_item เป็น encoded_array_item ซึ่งมีองค์ประกอบที่สอดคล้องกับอาร์กิวเมนต์ที่ให้ไว้กับเมธอดตัวเชื่อมโยงบูตสแตรป อาร์กิวเมนต์สามข้อแรกคือ:

1. ตัวจัดการเมธอดที่แสดงเมธอดตัวเชื่อมโยงบูตสแตรป (VALUE_METHOD_HANDLE)
2. ชื่อเมธอดที่ตัวเชื่อมโยงบูตสแตรปควรแก้ไข (VALUE_STRING)
3. ประเภทเมธอดที่สอดคล้องกับประเภทของชื่อเมธอดที่จะแก้ไข (VALUE_METHOD_TYPE)

Any additional arguments are constant values passed to the bootstrap linker method. These arguments are passed in order and without any type conversions.

The method handle representing the bootstrap linker method must have return type java.lang.invoke.CallSite . The first three parameter types are:

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

The parameter types of any additional arguments are determined from their constant values.

method_handle_item

appears in the method_handles section

alignment: 4 bytes

Method Handle Type Codes

class_data_item

referenced from class_def_item

appears in the data section

alignment: none (byte-aligned)

Note: All elements' field_id s and method_id s must refer to the same defining class.

encoded_field format

encoded_method format

type_list

referenced from class_def_item and proto_id_item

appears in the data section

alignment: 4 bytes

type_item format

code_item

referenced from encoded_method

appears in the data section

alignment: 4 bytes

try_item format

encoded_catch_handler_list format

encoded_catch_handler format

encoded_type_addr_pair format

debug_info_item

referenced from code_item

appears in the data section

alignment: none (byte-aligned)

Each debug_info_item defines a DWARF3-inspired byte-coded state machine that, when interpreted, emits the positions table and (potentially) the local variable information for a code_item . The sequence begins with a variable-length header (the length of which depends on the number of method parameters), is followed by the state machine bytecodes, and ends with an DBG_END_SEQUENCE byte.

The state machine consists of five registers. The address register represents the instruction offset in the associated insns_item in 16-bit code units. The address register starts at 0 at the beginning of each debug_info sequence and must only monotonically increase. The line register represents what source line number should be associated with the next positions table entry emitted by the state machine. It is initialized in the sequence header, and may change in positive or negative directions but must never be less than 1 . The source_file register represents the source file that the line number entries refer to. It is initialized to the value of source_file_idx in class_def_item . The other two variables, prologue_end and epilogue_begin , are boolean flags (initialized to false ) that indicate whether the next position emitted should be considered a method prologue or epilogue. The state machine must also track the name and type of the last local variable live in each register for the DBG_RESTART_LOCAL code.

The header is as follows:

The byte code values are as follows:

Special opcodes

Opcodes with values between 0x0a and 0xff (inclusive) move both the line and address registers by a small amount and then emit a new position table entry. The formula for the increments are as follows:

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

referenced from class_def_item

appears in the data section

alignment: 4 bytes

Note: All elements' field_id s and method_id s must refer to the same defining class.

field_annotation format

method_annotation format

parameter_annotation format

annotation_set_ref_list

referenced from parameter_annotations_item

appears in the data section

alignment: 4 bytes

annotation_set_ref_item format

annotation_set_item

referenced from annotations_directory_item, field_annotations_item, method_annotations_item, and annotation_set_ref_item

appears in the data section

alignment: 4 bytes

annotation_off_item format

annotation_item

referenced from annotation_set_item

appears in the data section

alignment: none (byte-aligned)

Visibility values

These are the options for the visibility field in an annotation_item :

encoded_array_item

referenced from class_def_item

appears in the data section

alignment: none (byte-aligned)

hiddenapi_class_data_item

This section contains data on restricted interfaces used by each class.

Note: The hidden API feature was introduced in Android 10.0 and is only applicable to the DEX files of classes in the boot class path. The list of flags described below may be extended in the future releases of Android. For more information, see restrictions on non-SDK interfaces .

Restriction flag types:

System annotations

System annotations are used to represent various pieces of reflective information about classes (and methods and fields). This information is generally only accessed indirectly by client (non-system) code.

System annotations are represented in .dex files as annotations with visibility set to VISIBILITY_SYSTEM .

dalvik.annotation.AnnotationDefault

appears on methods in annotation interfaces

An AnnotationDefault annotation is attached to each annotation interface which wishes to indicate default bindings.

dalvik.annotation.EnclosingClass

appears on classes

An EnclosingClass annotation is attached to each class which is either defined as a member of another class, per se, or is anonymous but not defined within a method body (eg, a synthetic inner class). Every class that has this annotation must also have an InnerClass annotation. Additionally, a class must not have both an EnclosingClass and an EnclosingMethod annotation.

dalvik.annotation.EnclosingMethod

appears on classes

An EnclosingMethod annotation is attached to each class which is defined inside a method body. Every class that has this annotation must also have an InnerClass annotation. Additionally, a class must not have both an EnclosingClass and an EnclosingMethod annotation.

dalvik.annotation.InnerClass

appears on classes

An InnerClass annotation is attached to each class which is defined in the lexical scope of another class's definition. Any class which has this annotation must also have either an EnclosingClass annotation or an EnclosingMethod annotation.

dalvik.annotation.MemberClasses

appears on classes

A MemberClasses annotation is attached to each class which declares member classes. (A member class is a direct inner class that has a name.)

dalvik.annotation.MethodParameters

appears on methods

Note: This annotation was added after Android 7.1. Its presence on earlier Android releases will be ignored.

A MethodParameters annotation is optional and can be used to provide parameter metadata such as parameter names and modifiers.

The annotation can be omitted from a method or constructor safely when the parameter metadata is not required at runtime. java.lang.reflect.Parameter.isNamePresent() can be used to check whether metadata is present for a parameter, and the associated reflection methods such as java.lang.reflect.Parameter.getName() will fall back to default behavior at runtime if the information is not present.

When including parameter metadata, compilers must include information for generated classes such as enums, since the parameter metadata includes whether or not a parameter is synthetic or mandated.

A MethodParameters annotation describes only individual method parameters. Therefore, compilers may omit the annotation entirely for constructors and methods that have no parameters, for the sake of code-size and runtime efficiency.

The arrays documented below must be the same size as for the method_id_item dex structure associated with the method, otherwise a java.lang.reflect.MalformedParametersException will be thrown at runtime.

That is: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size must be the same as names().length and accessFlags().length .

Because MethodParameters describes all formal method parameters, even those not explicitly or implicitly declared in source code, the size of the arrays may differ from the Signature or other metadata information that is based only on explicit parameters declared in source code. MethodParameters will also not include any information about type annotation receiver parameters that do not exist in the actual method signature.

dalvik.annotation.Signature

appears on classes, fields, and methods

A Signature annotation is attached to each class, field, or method which is defined in terms of a more complicated type than is representable by a type_id_item . The .dex format does not define the format for signatures; it is merely meant to be able to represent whatever signatures a source language requires for successful implementation of that language's semantics. As such, signatures are not generally parsed (or verified) by virtual machine implementations. The signatures simply get handed off to higher-level APIs and tools (such as debuggers). Any use of a signature, therefore, should be written so as not to make any assumptions about only receiving valid signatures, explicitly guarding itself against the possibility of coming across a syntactically invalid signature.

Because signature strings tend to have a lot of duplicated content, a Signature annotation is defined as an array of strings, where duplicated elements naturally refer to the same underlying data, and the signature is taken to be the concatenation of all the strings in the array. There are no rules about how to pull apart a signature into separate strings; that is entirely up to the tools that generate .dex files.

dalvik.annotation.Throws

appears on methods

A Throws annotation is attached to each method which is declared to throw one or more exception types.