دالفيك تنسيق قابل للتنفيذ

يصف هذا المستند تخطيط ومحتويات ملفات .dex ، والتي يتم استخدامها للاحتفاظ بمجموعة من تعريفات الفئات والبيانات المساعدة المرتبطة بها.

دليل الأنواع

جنيه 128

LEB128 (" L ittle- E ndian B ase 128 ") هو ترميز متغير الطول للكميات الصحيحة الموقعة أو غير الموقعة. تم استعارة التنسيق من مواصفات DWARF3 . في ملف .dex ، يتم استخدام LEB128 فقط لتشفير كميات 32 بت.

تتكون كل قيمة مشفرة LEB128 من واحد إلى خمسة بايت، والتي تمثل معًا قيمة واحدة مكونة من 32 بت. تحتوي كل بايت على مجموعة البت الأكثر أهمية، باستثناء البايت الأخير في التسلسل، الذي يحتوي على البت الأكثر أهمية بوضوح. البتات السبع المتبقية من كل بايت هي حمولة، مع وجود البتات السبعة الأقل أهمية من الكمية في البايت الأول، والسبع التالية في البايت الثاني، وهكذا. في حالة LEB128 ( sleb128 ) الموقعة، يتم تمديد بت الحمولة الأكثر أهمية من البايت النهائي في التسلسل لإنتاج القيمة النهائية. في الحالة غير الموقعة ( uleb128 )، يتم تفسير أي بتات غير ممثلة بشكل صريح على أنها 0 .

يتم استخدام المتغير uleb128p1 لتمثيل قيمة موقعة، حيث يكون التمثيل للقيمة بالإضافة إلى واحدة مشفرة كـ uleb128 . وهذا يجعل ترميز -1 (بدلاً من ذلك يُنظر إليه على أنه القيمة غير الموقعة 0xffffffff ) - ولكن لا يوجد رقم سالب آخر - بايت واحد، ويكون مفيدًا في تلك الحالات التي يجب أن يكون فيها الرقم المُمثل إما غير سالب أو -1 (أو 0xffffffff )، وحيث لا يُسمح بقيم سالبة أخرى (أو حيث من غير المرجح أن تكون هناك حاجة إلى قيم كبيرة غير موقعة).

فيما يلي بعض الأمثلة على التنسيقات:

تخطيط الملف

تعريفات Bitfield والسلسلة والثابتة

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، والذي قدم اثنين من الرموز الثانوية الجديدة، const-method-handle و const-method-type . (يتم وصف كل منها في جدول ملخص مجموعة الرموز الثانوية .) في Android 10، يقوم الإصدار 039 بتوسيع تنسيق ملف DEX ليشمل معلومات واجهة برمجة التطبيقات المخفية التي تنطبق فقط على ملفات DEX الموجودة على مسار فئة التمهيد.

ملحوظة: تمت إضافة دعم الإصدار 038 من التنسيق في إصدار Android 8.0. أضاف الإصدار 038 أكواد ثانوية جديدة ( invoke-polymorphic invoke-custom ) وبيانات لمقابض الطريقة.

ملحوظة: تمت إضافة دعم الإصدار 037 من التنسيق في إصدار Android 7.0. قبل الإصدار 037 استخدمت معظم إصدارات Android الإصدار 035 من التنسيق. والفرق الوحيد بين الإصدارين 035 و 037 هو إضافة الطرق الافتراضية وتعديل invoke .

ملاحظة: تم استخدام إصدارين سابقين على الأقل من التنسيق في إصدارات البرامج العامة المتاحة على نطاق واسع. على سبيل المثال، تم استخدام الإصدار 009 لإصدارات M3 لمنصة أندرويد (نوفمبر-ديسمبر 2007)، وتم استخدام الإصدار 013 لإصدارات M5 لمنصة أندرويد (فبراير-مارس 2008). في عدة جوانب، تختلف هذه الإصدارات السابقة من التنسيق بشكل كبير عن الإصدار الموضح في هذا المستند.

ENDIAN_CONSTANT وREVERSE_ENDIAN_CONSTANT

مضمن في header_item

يتم استخدام الثابت ENDIAN_CONSTANT للإشارة إلى نهاية الملف الذي تم العثور عليه فيه. على الرغم من أن تنسيق .dex القياسي قليل النهاية، إلا أن التطبيقات قد تختار إجراء تبديل البايت. إذا صادف التنفيذ رأسًا تكون 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 في شكل ثنائي البايت.
• يشير البايت الخالي العادي (القيمة 0 ) إلى نهاية السلسلة، كما هو الحال في تفسير لغة C القياسية.

يمكن تلخيص العنصرين الأولين أعلاه على النحو التالي: MUTF-8 هو تنسيق ترميز لـ UTF-16، بدلاً من كونه تنسيق ترميز مباشر أكثر لأحرف Unicode.

يتيح العنصران الأخيران أعلاه إمكانية تضمين نقطة الرمز U+0000 في سلسلة في وقت واحد مع الاستمرار في التعامل معها كسلسلة منتهية بنمط C.

ومع ذلك، فإن التشفير الخاص لـ U+0000 يعني أنه، على عكس UTF-8 العادي، فإن نتيجة استدعاء الدالة C القياسية strcmp() على زوج من سلاسل MUTF-8 لا تشير دائمًا إلى النتيجة الموقعة بشكل صحيح لمقارنة السلاسل غير المتساوية . عندما يكون الترتيب (وليس فقط المساواة) أمرًا مثيرًا للقلق، فإن الطريقة الأكثر مباشرة لمقارنة سلاسل MUTF-8 هي فك تشفيرها حرفًا بحرف، ومقارنة القيم التي تم فك تشفيرها. (ومع ذلك، من الممكن أيضًا تنفيذ تطبيقات أكثر ذكاءً.)

الرجاء الرجوع إلى معيار Unicode للحصول على مزيد من المعلومات حول ترميز الأحرف. إن MUTF-8 هو في الواقع أقرب إلى تشفير CESU-8 (الأقل شهرة نسبيًا) منه إلى UTF-8 في حد ذاته.

ترميز_القيمة_المشفرة

مضمن في annotation_element وencoded_array_item

encoded_value هي جزء مشفر من البيانات المنظمة هرميًا (تقريبًا). من المفترض أن يكون الترميز مضغوطًا وسهل التحليل.

تنسيقات القيمة

تنسيق encoded_array

تنسيق encoded_annotation

تنسيق عنصر التعليق التوضيحي

بناء جملة السلسلة

هناك عدة أنواع من العناصر في ملف .dex والتي تشير في النهاية إلى سلسلة. تشير تعريفات نمط BNF التالية إلى الصيغة المقبولة لهذه السلاسل.

اسم بسيط

SimpleName هو الأساس لبناء جملة أسماء الأشياء الأخرى. يتيح تنسيق .dex قدرًا لا بأس به من خطوط العرض هنا (أكثر بكثير من معظم لغات المصدر الشائعة). باختصار، يتكون الاسم البسيط من أي حرف أو رقم أبجدي منخفض ASCII، وعدد قليل من رموز ASCII المحددة، ومعظم نقاط التعليمات البرمجية غير ASCII التي ليست عبارة عن تحكم أو مسافة أو أحرف خاصة. بدءًا من الإصدار 040 ، يسمح التنسيق بالإضافة إلى ذلك بأحرف المسافات (فئة Unicode Zs ). لاحظ أن نقاط الكود البديلة (في النطاق U+d800 … U+dfff ) لا تعتبر أحرف اسم صالحة، في حد ذاتها، ولكن أحرف Unicode التكميلية صالحة (والتي يتم تمثيلها بالبديل النهائي لقاعدة SimpleNameChar )، وهي يجب أن يتم تمثيله في ملف كأزواج من نقاط الكود البديلة في تشفير MUTF-8.

اسم عضو

يستخدم بواسطة field_id_item وmethod_id_item

اسم العضو هو اسم عضو في الفصل الدراسي، والأعضاء عبارة عن حقول وأساليب وفئات داخلية.

اسم الفئة الكاملة

FullClassName هو اسم فئة مؤهل بالكامل، بما في ذلك محدد الحزمة الاختياري متبوعًا بالاسم المطلوب.

نوع واصف

يستخدم بواسطة type_id_item

TypeDescriptor هو تمثيل لأي نوع، بما في ذلك الأوليات، والفئات، والمصفوفات، void . انظر أدناه لمعرفة معنى الإصدارات المختلفة.

وصف قصير

يستخدم بواسطة proto_id_item

ShortyDescriptor هو تمثيل قصير للنموذج الأولي للطريقة، بما في ذلك أنواع الإرجاع والمعلمات، باستثناء أنه لا يوجد تمييز بين أنواع المراجع المختلفة (الفئة أو المصفوفة). وبدلاً من ذلك، يتم تمثيل جميع أنواع المراجع بحرف 'L' واحد.

دلالات واصف النوع

هذا هو معنى كل متغير من متغيرات 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).

أي وسيطات إضافية هي قيم ثابتة تم تمريرها إلى طريقة رابط bootstrap. يتم تمرير هذه الوسائط بالترتيب وبدون أي تحويلات للنوع.

يجب أن يكون لمقبض الأسلوب الذي يمثل أسلوب رابط bootstrap نوع الإرجاع java.lang.invoke.CallSite . أنواع المعلمات الثلاثة الأولى هي:

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

يتم تحديد أنواع المعلمات لأي وسيطات إضافية من قيمها الثابتة.

method_handle_item

يظهر في قسمmethod_handles

المحاذاة: 4 بايت

طريقة مقبض رموز نوع الرموز

class_data_item

المشار إليها من class_def_item

يظهر في قسم البيانات

المحاذاة: لا شيء (محاذاة بايت)

ملاحظة: يجب أن تشير جميع العناصر ' field_id S و method_id s إلى نفس الفئة المحددة.

تنسيق encoded_field

تنسيق encoded_method

type_list

يشار إليه من class_def_item و proto_id_item

يظهر في قسم البيانات

المحاذاة: 4 بايت

تنسيق type_item

Code_Item

المشار إليها من encoded_method

يظهر في قسم البيانات

المحاذاة: 4 بايت

Try_Item تنسيق

encoded_catch_handler_list تنسيق

تنسيق encoded_catch_handler

encoded_type_addr_pair تنسيق

debug_info_item

المشار إليها من Code_Item

يظهر في قسم البيانات

المحاذاة: لا شيء (محاذاة بايت)

يحدد كل debug_info_item آلة حالة بايت مستوحاة من قزم 3 والتي ، عند تفسيرها ، تنبعث من جدول المواضع و (يحتمل) المعلومات المتغيرة المحلية لـ code_item . يبدأ التسلسل برأس طول متغير (يعتمد طوله على عدد معلمات الأسلوب) ، ويتبعه بايت آلية الحالة ، وينتهي ببايت DBG_END_SEQUENCE .

تتكون آلة الدولة من خمسة سجلات. يمثل سجل address تعليمات التعليمات في وحدة insns_item المرتبطة بوحدات رمز 16 بت. يبدأ سجل address في 0 في بداية كل تسلسل debug_info ويجب أن يزداد رتابة فقط. يمثل سجل line ما هو رقم سطر المصدر الذي يجب أن يرتبط بإدخال جدول المواضع التالية المنبعثة من جهاز الحالة. تتم تهيئته في رأس التسلسل ، وقد يتغير في الاتجاهات الإيجابية أو السلبية ولكن يجب ألا يكون أقل من 1 . يمثل سجل source_file الملف المصدر الذي تشير إليه إدخالات رقم السطر. تتم تهيئتها إلى قيمة source_file_idx في class_def_item . المتغيران الآخران ، prologue_end و epilogue_begin ، هما أعلام منطقية (تهيئتها إلى false ) تشير إلى ما إذا كان الموضع التالي المنبعث يجب اعتباره طريقة مقدمة أو خاتمة. يجب أن يتتبع جهاز الحالة أيضًا اسم ونوع آخر متغير محلي يعيش في كل سجل لرمز DBG_RESTART_LOCAL .

الرأس كما يلي:

قيم رمز البايت هي كما يلي:

الرموز الخاصة الخاصة

تحرك الرموز المفرطة ذات القيم بين 0x0a و 0xff (شاملة) كل من سجلات line address بمقدار صغير ثم تنبعث منها إدخال جدول الموضع الجديد. الصيغة للزيادات هي كما يلي:

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)

التعليقات التوضيحية_Directory_Item

المشار إليها من class_def_item

يظهر في قسم البيانات

المحاذاة: 4 بايت

ملاحظة: يجب أن تشير جميع العناصر ' field_id S و method_id s إلى نفس الفئة المحددة.

field_annotation تنسيق

تنسيق method_annotation

Parameter_annotation تنسيق

antation_set_ref_list

المشار إليها من المعلمة _annotations_item

يظهر في قسم البيانات

المحاذاة: 4 بايت

Entation_Set_Ref_Item Format

antation_set_item

المشار إليها من التعليقات التوضيحية_directory_item ، field_annotations_item ، method_annotations_item ، و enrotation_set_ref_item

يظهر في قسم البيانات

المحاذاة: 4 بايت

Estation_off_Item Format

التعليق التوضيحي

المشار إليها من التعليق التوضيحي_set_item

يظهر في قسم البيانات

المحاذاة: لا شيء (محاذاة بايت)

قيم الرؤية

هذه هي الخيارات لحقل visibility في annotation_item :

encoded_array_item

المشار إليها من class_def_item

يظهر في قسم البيانات

المحاذاة: لا شيء (محاذاة بايت)

hiddenapi_class_data_item

يحتوي هذا القسم على بيانات عن واجهات مقيدة تستخدمها كل فئة.

ملاحظة: تم تقديم ميزة API المخفية في Android 10.0 وتنطبق فقط على ملفات DEX للفئات في مسار فئة التمهيد. يمكن تمديد قائمة الأعلام الموضحة أدناه في الإصدارات المستقبلية لنظام Android. لمزيد من المعلومات ، راجع القيود المفروضة على واجهات غير SDK .

أنواع علم التقييد:

تعليقات النظام

تُستخدم تعليقات النظام لتمثيل أجزاء مختلفة من المعلومات العاكسة حول الفصول (والأساليب والحقول). يتم الوصول إلى هذه المعلومات بشكل عام فقط بشكل غير مباشر بواسطة رمز العميل (غير نظام).

يتم تمثيل تعليقات النظام في ملفات .dex كشروط مع تعيين الرؤية على VISIBILITY_SYSTEM .

dalvik.annotation.annotationDefault

يظهر على الطرق في واجهات التعليق التوضيحي

يتم إرفاق شرح التعليق AnnotationDefault بكل واجهة شرحية ترغب في الإشارة إلى الارتباطات الافتراضية.

dalvik.annotation.enclosingClass

يظهر في الفصول

يتم إرفاق تعليق توضيحي EnclosingClass بكل فئة يتم تعريفه إما كعضو في فئة أخرى ، في حد ذاته ، أو هو مجهول ولكن لم يتم تعريفه في هيئة طريقة (على سبيل المثال ، فئة داخلية اصطناعية). يجب أن يكون لكل فصل لديه هذا التعليق التوضيحي أيضًا شرحًا InnerClass . بالإضافة إلى ذلك ، لا يجب أن يكون لدى الفصل كل من EnclosingClass EnclosingMethod .

dalvik.annotation.enclosingMethod

يظهر في الفصول

يتم إرفاق تعليق توضيحي EnclosingMethod بكل فئة محددة داخل هيئة طريقة. يجب أن يكون لكل فصل لديه هذا التعليق التوضيحي أيضًا شرحًا InnerClass . بالإضافة إلى ذلك ، لا يجب أن يكون لدى الفصل كل من EnclosingClass EnclosingMethod .

dalvik.annotation.innerclass

يظهر في الفصول

يتم إرفاق التعليق InnerClass لكل فئة محددة في النطاق المعجمي لتعريف فئة أخرى. يجب أن يكون لدى أي فصل يحتوي على هذا التعليق التوضيحي أيضًا توضيحيًا EnclosingClass أو تعليقًا على توضيح EnclosingMethod .

dalvik.annotation.memberClasses

يظهر في الفصول

يتم إرفاق شرح MemberClasses لكل فصل يعلن فصول الأعضاء. (فئة الأعضاء هي فئة داخلية مباشرة لها اسم.)

dalvik.annotation.methodparameters

يظهر على الأساليب

ملاحظة: تمت إضافة هذا التعليق بعد Android 7.1. سيتم تجاهل وجودها في إصدارات Android السابقة.

يكون توضيح MethodParameters اختياريًا ويمكن استخدامه لتوفير بيانات التعريف المعلمة مثل أسماء المعلمات والمعدلات.

يمكن حذف التعليق التوضيحي من طريقة أو مُنشئ بأمان عندما لا تكون بيانات تعريف المعلمة مطلوبة في وقت التشغيل. يمكن استخدام java.lang.reflect.Parameter.isNamePresent() للتحقق مما إذا كانت البيانات الوصفية موجودة للمعلمة ، وسوف تعود طرق الانعكاس المرتبطة مثل java.lang.reflect.Parameter.getName() إلى السلوك الافتراضي في وقت التشغيل في وقت التشغيل إذا كانت المعلومات غير موجودة.

عند تضمين بيانات التعريف المعلمة ، يجب أن يتضمن المجمعون معلومات لفئات تم إنشاؤها مثل التعدادات ، نظرًا لأن بيانات التعريف المعلمة تتضمن ما إذا كانت المعلمة عبارة عن معلمة اصطناعية أم لا.

يصف شرح MethodParameters معلمات الطريقة الفردية فقط. لذلك ، قد يحذف المترجمون التعليق التوضيحي بالكامل للمقدمين والأساليب التي ليس لها معلمات ، من أجل حجم الكود وكفاءة وقت التشغيل.

يجب أن تكون المصفوفات الموثقة أدناه بنفس الحجم بالنسبة لهيكل method_id_item dex المرتبط بالطريقة ، وإلا فإن java.lang.reflect.MalformedParametersException سيتم إلقاؤها في وقت التشغيل.

هذا هو: method_id_item.proto_idx -> proto_id_item.parameters_off -> type_list.size يجب أن يكون هو نفسه names().length accessFlags().length .

نظرًا لأن MethodParameters تصف جميع معلمات الطريقة الرسمية ، حتى تلك التي لم يتم الإعلان عنها بشكل صريح أو ضمني في رمز المصدر ، قد يختلف حجم المصفوفات عن التوقيع أو معلومات التعريف الأخرى التي تعتمد فقط على المعلمات الصريحة المعلنة في رمز المصدر. لن تتضمن MethodParameters أيضًا أي معلومات حول معلمات مستقبل التعليقات التوضيحية نوعًا غير موجودة في توقيع الطريقة الفعلية.

dalvik.annotation.Signature

يظهر على الفصول والحقول والأساليب

يتم إرفاق التعليق Signature بكل فئة أو حقل أو طريقة يتم تعريفها من حيث النوع الأكثر تعقيدًا من تمثيلها بواسطة type_id_item . لا يحدد تنسيق .dex تنسيق التوقيعات ؛ من المفترض فقط أن تكون قادرًا على تمثيل أي توقيعات تتطلب لغة المصدر للتنفيذ الناجح لدلالات تلك اللغة. على هذا النحو ، لا يتم تحليل التوقيعات عمومًا (أو التحقق منها) بواسطة تطبيقات الجهاز الظاهري. يتم تسليم التوقيعات ببساطة إلى واجهات برمجة التطبيقات والأدوات ذات المستوى الأعلى (مثل التصحيحات). لذلك ، يجب كتابة أي استخدام للتوقيع حتى لا يضع أي افتراضات حول تلقي توقيعات صالحة فقط ، ويحرسان نفسه بشكل صريح من إمكانية التواصل مع توقيع غير صالح بشكل نحلي.

نظرًا لأن سلاسل Signature تميل إلى الحصول على الكثير من المحتوى المكررة ، يتم تعريف شرح توقيع على أنه مجموعة من الأوتار ، حيث تشير العناصر المكررة بشكل طبيعي إلى نفس البيانات الأساسية ، ويتم اعتبار التوقيع هو تسلسل جميع الأوتار في المصفوفة . لا توجد قواعد حول كيفية تفكيك التوقيع في سلاسل منفصلة ؛ هذا متروك بالكامل للأدوات التي تنشئ ملفات .dex .

dalvik.annotation.throws

يظهر على الأساليب

يتم إرفاق تعليق توضيحي Throws بكل طريقة يُعلن أنها ترمي نوعًا أو أكثر من أنواع الاستثناءات.