محدودیت ها

یک فایل .dex فرمت انتقال بایت کد Dalvik است. برای اینکه یک فایل یک فایل .dex معتبر باشد، محدودیت‌های نحوی و معنایی خاصی وجود دارد و برای پشتیبانی از فایل‌های .dex معتبر، زمان اجرا لازم است.

محدودیت های یکپارچگی عمومی .dex

محدودیت‌های یکپارچگی کلی مربوط به ساختار بزرگ‌تر یک فایل .dex است، همانطور که در قالب .dex به تفصیل توضیح داده شده است.

شناسه توضیحات
G1 شماره magic فایل .dex باید برای نسخه 35 dex\n035\0 یا برای نسخه‌های بعدی مشابه باشد.
G2 چک‌سوم باید یک جمع‌سنجی Adler-32 از کل محتویات فایل به جز magic و فیلد checksum باشد.
G3 امضا باید یک هش SHA-1 از کل محتویات فایل به جز magic ، checksum و signature باشد.
G4

file_size باید با اندازه واقعی فایل بر حسب بایت مطابقت داشته باشد. (نسخه 40 یا قبل از آن)

file_size باید به هدر بعدی در کانتینر یا در انتهای فایل pysical (کانتینر) اشاره کند. اگر به هدر بعدی اشاره کرد، اندازه فایل باید 4 بایت تراز شود. مجموع تمام فیلدهای file_size باید با container_size برابر باشد. (نسخه 41 یا بالاتر)

G5

header_size باید مقدار 0x70 (v40 یا قبل از آن) را داشته باشد.

header_size باید دارای مقدار: 0x78 (v41 یا بالاتر) باشد.

G6 endian_tag باید دارای یک مقدار باشد: ENDIAN_CONSTANT یا REVERSE_ENDIAN_CONSTANT
G7

برای هر یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data ، فیلدهای offset و size باید هر دو صفر یا غیرصفر باشند. در مورد دوم، افست باید چهار بایت تراز شود.

فیلدهای offset و size باید در داخل کانتینر باشند و به داده‌هایی اشاره کنند که بعد از هدری که آنها را تعریف می‌کند قرار دارند. (نسخه 41 یا بالاتر)

G8 تمام فیلدهای offset در هدر به جز map_off باید چهار بایت تراز شوند.
G9 فیلد map_off باید یا صفر باشد یا به بخش داده اشاره کند. در مورد دوم، بخش data باید وجود داشته باشد.
G10 هیچ یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data نباید با یکدیگر یا سربرگ همپوشانی داشته باشند.
G11 اگر نقشه وجود داشته باشد، هر ورودی نقشه باید یک نوع معتبر داشته باشد. هر نوع ممکن است حداکثر یک بار ظاهر شود.
G12 اگر نقشه ای وجود داشته باشد، هر ورودی نقشه باید یک افست و اندازه غیر صفر داشته باشد. افست باید به بخش مربوط به فایل اشاره کند (یعنی یک string_id_item باید به بخش string_ids اشاره کند) و اندازه صریح یا ضمنی آیتم باید با محتویات و اندازه واقعی بخش مطابقت داشته باشد.
G13 اگر نقشه ای وجود داشته باشد، آنگاه افست ورودی نقشه n+1 باید بزرگتر یا مساوی با افست ورودی نقشه n plus than size of map entry n باشد. این به معنای ورودی های غیر همپوشانی و سفارش کم به بالا است.
G14 انواع ورودی‌های زیر باید دارای یک افست چهار بایتی باشند: string_id_item ، type_id_item ، proto_id_item ، field_id_item ، method_id_item ، class_def_item ، type_list ، code_item ، annotations_directory_item .
G15

برای هر string_id_item ، فیلد string_data_off باید دارای یک مرجع معتبر در بخش data باشد. (نسخه 40 یا قبل از آن)

برای هر string_id_item ، فیلد string_data_off باید در داخل کانتینر و بعد از هر هدری که به‌طور سنتی از آن استفاده می‌کند، یک افست باشد. (نسخه 41 یا بالاتر)

برای string_data_item ارجاع شده، فیلد data باید دارای یک رشته معتبر MUTF-8 باشد و utf16_size باید با طول رمزگشایی شده رشته مطابقت داشته باشد.

G16 برای هر type_id_item ، فیلد descriptor_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیفگر نوع معتبر باشد.
G17 برای هر proto_id_item ، فیلد shorty_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیف کننده کوتاه معتبر باشد. همچنین، فیلد return_type_idx باید یک شاخص معتبر در بخش type_ids باشد و فیلد parameters_off باید صفر باشد یا یک افست معتبر که به بخش data اشاره می‌کند. اگر غیر صفر باشد، لیست پارامترها نباید حاوی هیچ ورودی خالی باشد.
G18 برای هر field_id_item ، هر دو فیلد class_idx و type_idx باید شاخص‌های معتبری در لیست type_ids باشند. ورودی ارجاع شده توسط class_idx باید یک نوع مرجع غیر آرایه باشد. علاوه بر این، فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G19 برای هر method_id_item ، فیلد class_idx باید یک شاخص معتبر در بخش type_ids باشد و ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد. فیلد proto_id باید یک مرجع معتبر در لیست proto_ids باشد. فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G20 برای هر field_id_item ، فیلد class_idx باید یک فهرست معتبر در لیست type_ids باشد. ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد.

محدودیت های بایت کد استاتیک

محدودیت‌های استاتیک، محدودیت‌هایی بر روی عناصر جداگانه بایت کد هستند. آنها معمولاً می توانند بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده بررسی شوند.

شناسه توضیحات
A1 آرایه insns نباید خالی باشد.
A2 اولین اپکد در آرایه insns باید دارای اندیس صفر باشد.
A3 آرایه insns باید فقط دارای کدهای آپشن معتبر Dalvik باشد.
A4 شاخص دستور n+1 باید با شاخص دستورالعمل n به اضافه طول دستورالعمل n برابر باشد، با در نظر گرفتن عملوندهای ممکن.
A5 آخرین دستور در آرایه insns باید به شاخص insns_size-1 ختم شود.
A6 همه اهداف goto و if-<kind> باید کدهای عملیاتی در یک روش باشند.
A7 تمام اهداف یک دستورالعمل packed-switch باید کدهای عملیاتی در همان روش باشند. اندازه و فهرست اهداف باید هماهنگ باشد.
A8 تمام اهداف یک دستورالعمل sparse-switch باید کدهای عملیاتی در همان روش باشند. جدول مربوطه باید سازگار و مرتب شده از کم به بالا باشد.
A9 عملوند B دستورات const-string و const-string/jumbo باید یک شاخص معتبر در مجموعه ثابت رشته باشد.
A10 عملوند C دستورات iget<kind> و iput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد نمونه باشد.
A11 عملوند C دستورات sget<kind> و sput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد ثابت باشد.
A12 عملوند C دستورات invoke-virtual ، invoke-super ، invoke-direct و invoke-static باید یک شاخص معتبر در مخزن ثابت متد باشد.
A13 عملوند B دستورات invoke-virtual/range ، invoke-super/range ، invoke-direct/range و invoke-static/range باید یک شاخص معتبر در مخزن ثابت متد باشد.
A14 روشی که نام آن با «<» شروع می‌شود فقط باید به طور ضمنی توسط VM فراخوانی شود، نه با کدی که از یک فایل .dex منشا می‌گیرد. تنها استثناء اولیه ساز نمونه است که ممکن است توسط invoke-direct فراخوانی شود.
A15 عملوند C دستور واسط invoke-interface باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A16 عملوند B دستور invoke-interface/range باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A17 عملوند B دستورات const-class ، check-cast ، new-instance و filled-new-array/range باید یک شاخص معتبر در مخزن ثابت نوع باشد.
A18 عملوند C دستورات instance-of ، new-array و filled-new-array باید یک شاخص معتبر برای نوع ثابت Pool باشد.
A19 ابعاد یک آرایه ایجاد شده توسط یک دستور new-array باید کمتر از 256 باشد.
A20 دستورالعمل new نباید به کلاس های آرایه، رابط ها یا کلاس های انتزاعی اشاره کند.
A21 نوع ارجاع شده توسط یک دستورالعمل new-array باید یک نوع معتبر و غیر مرجع باشد.
A22 همه رجیسترهایی که توسط یک دستورالعمل به صورت تک عرض (غیر جفتی) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size باشد.
A23 همه رجیسترهایی که توسط یک دستورالعمل به صورت دو عرض (جفت) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size-1 باشد.
A24 عملوند method_id دستورات invoke-virtual و invoke-direct باید متعلق به یک کلاس (نه یک رابط) باشد. در فایل‌های Dex قبل از نسخه 037 همین امر باید در مورد دستورالعمل‌های invoke-super و invoke-static صادق باشد.
A25 عملوند method_id دستورات invoke-virtual/range و invoke-direct/range باید به یک کلاس تعلق داشته باشد (نه یک رابط). در فایل‌های Dex قبل از نسخه 037 همین امر باید در مورد دستورالعمل‌های invoke-super/range و invoke-static/range صادق باشد.

محدودیت های بایت کد ساختاری

محدودیت های ساختاری محدودیت هایی در روابط بین چندین عنصر بایت کد هستند. آنها معمولاً بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده قابل بررسی نیستند.

شناسه توضیحات
B1 تعداد و انواع آرگومان ها (رجیسترها و مقادیر فوری) باید همیشه با دستورالعمل مطابقت داشته باشد.
B2 جفت های ثبت نام هرگز نباید از هم جدا شوند.
B3 یک ثبات (یا جفت) ابتدا باید قبل از خواندن آن اختصاص داده شود.
B4 یک دستور invoke-direct باید یک نمونه اولیه یا یک متد را فقط در کلاس فعلی یا یکی از ابر کلاس های آن فراخوانی کند.
B5 یک نمونه اولیه باید فقط در یک نمونه غیر اولیه فراخوانی شود.
B6 روش‌های نمونه را می‌توان فقط در فراخوانی کرد و فیلدهای نمونه را فقط در نمونه‌هایی که از قبل مقداردهی شده‌اند قابل دسترسی هستند.
B7 اگر همان دستورالعمل new-instance قبل از مقداردهی اولیه مجدداً اجرا شود، ثباتی که نتیجه یک دستورالعمل new-instance را در خود نگه می دارد، نباید استفاده شود.
B8 قبل از اینکه بتوان به اعضای نمونه دسترسی داشت، یک مقداردهی اولیه باید یک نمونه اولیه دیگر (همان کلاس یا سوپرکلاس) را فراخوانی کند. استثنائات، فیلدهای نمونه غیر ارثی هستند که می توانند قبل از فراخوانی اولیه کننده دیگر و کلاس Object به طور کلی اختصاص داده شوند.
B9 همه آرگومان های متد واقعی باید با آرگومان های رسمی مربوطه خود سازگار با انتساب باشند.
B10 برای هر فراخوانی روش نمونه، نمونه واقعی باید با کلاس یا رابط مشخص شده در دستورالعمل سازگار باشد.
B11 یک دستور return<kind> باید با نوع برگشتی متد خود مطابقت داشته باشد.
B12 هنگام دسترسی به اعضای محافظت شده یک سوپرکلاس، نوع واقعی نمونه مورد دسترسی باید کلاس فعلی یا یکی از زیر کلاس های آن باشد.
B13 نوع مقدار ذخیره شده در یک فیلد ثابت باید با نوع فیلد سازگار باشد یا به آن تبدیل شود.
B14 نوع مقدار ذخیره شده در یک فیلد باید با نوع فیلد سازگار باشد یا به آن تبدیل شود.
B15 نوع هر مقدار ذخیره شده در یک آرایه باید با نوع مولفه آرایه سازگار باشد.
B16 عملوند A دستور throw باید با java.lang.Throwable سازگار باشد.
B17 آخرین دستورالعمل قابل دسترسی یک متد باید یا یک goto به عقب یا شاخه، یک return یا یک دستورالعمل throw باشد. نباید امکان رها کردن آرایه insns در پایین وجود داشته باشد.
B18 نصف تخصیص‌نخورده یک جفت رجیستر سابق نمی‌تواند خوانده شود (نامعتبر در نظر گرفته می‌شود) تا زمانی که توسط دستورالعمل دیگری تخصیص داده نشده باشد.
B19 یک دستور move-result<kind> باید بلافاصله قبل از (در آرایه insns ) یک دستور invoke-<kind> باشد. تنها استثنا دستور move-result-object است که ممکن است قبل از یک دستور filled-new-array نیز باشد.
B20 یک دستور move-result<kind> باید بلافاصله قبل از آن (در جریان کنترل واقعی) با یک دستورالعمل return-<kind> منطبق باشد (نباید به آن پرش کرد). تنها استثنا دستور move-result-object است که ممکن است قبل از یک دستور filled-new-array نیز باشد.
B21 یک دستور move-exception باید فقط به عنوان اولین دستورالعمل در یک کنترل کننده استثنا ظاهر شود.
B22 دستورات packed-switch-data ، sparse-switch-data ، و fill-array-data نباید توسط جریان کنترل قابل دسترسی باشند.
،

یک فایل .dex فرمت انتقال بایت کد Dalvik است. برای اینکه یک فایل یک فایل .dex معتبر باشد، محدودیت‌های نحوی و معنایی خاصی وجود دارد و برای پشتیبانی از فایل‌های .dex معتبر، زمان اجرا لازم است.

محدودیت های یکپارچگی عمومی .dex

محدودیت‌های یکپارچگی کلی مربوط به ساختار بزرگ‌تر یک فایل .dex است، همانطور که در قالب .dex به تفصیل توضیح داده شده است.

شناسه توضیحات
G1 شماره magic فایل .dex باید برای نسخه 35 dex\n035\0 یا برای نسخه‌های بعدی مشابه باشد.
G2 چک‌سوم باید یک جمع‌سنجی Adler-32 از کل محتویات فایل به جز magic و فیلد checksum باشد.
G3 امضا باید یک هش SHA-1 از کل محتویات فایل به جز magic ، checksum و signature باشد.
G4

file_size باید با اندازه واقعی فایل بر حسب بایت مطابقت داشته باشد. (نسخه 40 یا قبل از آن)

file_size باید به هدر بعدی در کانتینر یا در انتهای فایل pysical (کانتینر) اشاره کند. اگر به هدر بعدی اشاره کرد، اندازه فایل باید 4 بایت تراز شود. مجموع تمام فیلدهای file_size باید با container_size برابر باشد. (نسخه 41 یا بالاتر)

G5

header_size باید مقدار 0x70 (v40 یا قبل از آن) را داشته باشد.

header_size باید دارای مقدار: 0x78 (v41 یا بالاتر) باشد.

G6 endian_tag باید دارای یک مقدار باشد: ENDIAN_CONSTANT یا REVERSE_ENDIAN_CONSTANT
G7

برای هر یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data ، فیلدهای offset و size باید هر دو صفر یا غیرصفر باشند. در مورد دوم، افست باید چهار بایت تراز شود.

فیلدهای offset و size باید در داخل کانتینر باشند و به داده‌هایی اشاره کنند که بعد از هدری که آنها را تعریف می‌کند قرار دارند. (نسخه 41 یا بالاتر)

G8 تمام فیلدهای offset در هدر به جز map_off باید چهار بایت تراز شوند.
G9 فیلد map_off باید یا صفر باشد یا به بخش داده اشاره کند. در مورد دوم، بخش data باید وجود داشته باشد.
G10 هیچ یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data نباید با یکدیگر یا سربرگ همپوشانی داشته باشند.
G11 اگر نقشه وجود داشته باشد، هر ورودی نقشه باید یک نوع معتبر داشته باشد. هر نوع ممکن است حداکثر یک بار ظاهر شود.
G12 اگر نقشه ای وجود داشته باشد، هر ورودی نقشه باید یک افست و اندازه غیر صفر داشته باشد. افست باید به بخش مربوط به فایل اشاره کند (یعنی یک string_id_item باید به بخش string_ids اشاره کند) و اندازه صریح یا ضمنی آیتم باید با محتویات و اندازه واقعی بخش مطابقت داشته باشد.
G13 اگر نقشه ای وجود داشته باشد، آنگاه افست ورودی نقشه n+1 باید بزرگتر یا مساوی با افست ورودی نقشه n plus than size of map entry n باشد. این به معنای ورودی های غیر همپوشانی و سفارش کم به بالا است.
G14 انواع ورودی‌های زیر باید دارای یک افست چهار بایتی باشند: string_id_item ، type_id_item ، proto_id_item ، field_id_item ، method_id_item ، class_def_item ، type_list ، code_item ، annotations_directory_item .
G15

برای هر string_id_item ، فیلد string_data_off باید دارای یک مرجع معتبر در بخش data باشد. (نسخه 40 یا قبل از آن)

برای هر string_id_item ، فیلد string_data_off باید در داخل کانتینر و بعد از هر هدری که به‌طور سنتی از آن استفاده می‌کند، یک افست باشد. (نسخه 41 یا بالاتر)

برای string_data_item ارجاع شده، فیلد data باید دارای یک رشته معتبر MUTF-8 باشد و utf16_size باید با طول رمزگشایی شده رشته مطابقت داشته باشد.

G16 برای هر type_id_item ، فیلد descriptor_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیفگر نوع معتبر باشد.
G17 برای هر proto_id_item ، فیلد shorty_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیف کننده کوتاه معتبر باشد. همچنین، فیلد return_type_idx باید یک شاخص معتبر در بخش type_ids باشد و فیلد parameters_off باید صفر باشد یا یک افست معتبر که به بخش data اشاره می‌کند. اگر غیر صفر باشد، لیست پارامترها نباید حاوی هیچ ورودی خالی باشد.
G18 برای هر field_id_item ، هر دو فیلد class_idx و type_idx باید شاخص‌های معتبری در لیست type_ids باشند. ورودی ارجاع شده توسط class_idx باید یک نوع مرجع غیر آرایه باشد. علاوه بر این، فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G19 برای هر method_id_item ، فیلد class_idx باید یک شاخص معتبر در بخش type_ids باشد و ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد. فیلد proto_id باید یک مرجع معتبر در لیست proto_ids باشد. فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G20 برای هر field_id_item ، فیلد class_idx باید یک فهرست معتبر در لیست type_ids باشد. ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد.

محدودیت های بایت کد استاتیک

محدودیت‌های استاتیک، محدودیت‌هایی بر روی عناصر جداگانه بایت کد هستند. آنها معمولاً می توانند بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده بررسی شوند.

شناسه توضیحات
A1 آرایه insns نباید خالی باشد.
A2 اولین اپکد در آرایه insns باید دارای اندیس صفر باشد.
A3 آرایه insns باید فقط دارای کدهای آپشن معتبر Dalvik باشد.
A4 شاخص دستور n+1 باید با شاخص دستورالعمل n به اضافه طول دستورالعمل n برابر باشد، با در نظر گرفتن عملوندهای ممکن.
A5 آخرین دستور در آرایه insns باید به شاخص insns_size-1 ختم شود.
A6 همه اهداف goto و if-<kind> باید کدهای عملیاتی در یک روش باشند.
A7 تمام اهداف یک دستورالعمل packed-switch باید کدهای عملیاتی در همان روش باشند. اندازه و فهرست اهداف باید هماهنگ باشد.
A8 تمام اهداف یک دستورالعمل sparse-switch باید کدهای عملیاتی در همان روش باشند. جدول مربوطه باید سازگار و مرتب شده از کم به بالا باشد.
A9 عملوند B دستورات const-string و const-string/jumbo باید یک شاخص معتبر در مجموعه ثابت رشته باشد.
A10 عملوند C دستورات iget<kind> و iput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد نمونه باشد.
A11 عملوند C دستورات sget<kind> و sput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد ثابت باشد.
A12 عملوند C دستورات invoke-virtual ، invoke-super ، invoke-direct و invoke-static باید یک شاخص معتبر در مخزن ثابت متد باشد.
A13 عملوند B دستورات invoke-virtual/range ، invoke-super/range ، invoke-direct/range و invoke-static/range باید یک شاخص معتبر در مخزن ثابت متد باشد.
A14 روشی که نام آن با «<» شروع می‌شود فقط باید به طور ضمنی توسط VM فراخوانی شود، نه با کدی که از یک فایل .dex منشا می‌گیرد. تنها استثناء اولیه ساز نمونه است که ممکن است توسط invoke-direct فراخوانی شود.
A15 عملوند C دستور واسط invoke-interface باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A16 عملوند B دستور invoke-interface/range باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A17 عملوند B دستورات const-class ، check-cast ، new-instance و filled-new-array/range باید یک شاخص معتبر در مخزن ثابت نوع باشد.
A18 عملوند C دستورات instance-of ، new-array و filled-new-array باید یک شاخص معتبر برای نوع ثابت Pool باشد.
A19 ابعاد یک آرایه ایجاد شده توسط یک دستور new-array باید کمتر از 256 باشد.
A20 دستورالعمل new نباید به کلاس های آرایه، رابط ها یا کلاس های انتزاعی اشاره کند.
A21 نوع ارجاع شده توسط یک دستورالعمل new-array باید یک نوع معتبر و غیر مرجع باشد.
A22 همه رجیسترهایی که توسط یک دستورالعمل به صورت تک عرض (غیر جفتی) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size باشد.
A23 همه رجیسترهایی که توسط یک دستورالعمل به صورت دو عرض (جفت) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size-1 باشد.
A24 عملوند method_id دستورات invoke-virtual و invoke-direct باید متعلق به یک کلاس (نه یک رابط) باشد. در فایل‌های Dex قبل از نسخه 037 همین امر باید در مورد دستورالعمل‌های invoke-super و invoke-static صادق باشد.
A25 عملوند method_id دستورات invoke-virtual/range و invoke-direct/range باید به یک کلاس تعلق داشته باشد (نه یک رابط). در فایل‌های Dex قبل از نسخه 037 همین امر باید در مورد دستورالعمل‌های invoke-super/range و invoke-static/range صادق باشد.

محدودیت های بایت کد ساختاری

محدودیت های ساختاری محدودیت هایی در روابط بین چندین عنصر بایت کد هستند. آنها معمولاً بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده قابل بررسی نیستند.

شناسه توضیحات
B1 تعداد و انواع آرگومان ها (رجیسترها و مقادیر فوری) باید همیشه با دستورالعمل مطابقت داشته باشد.
B2 جفت های ثبت نام هرگز نباید از هم جدا شوند.
B3 یک ثبات (یا جفت) ابتدا باید قبل از خواندن آن اختصاص داده شود.
B4 یک دستور invoke-direct باید یک نمونه اولیه یا یک متد را فقط در کلاس فعلی یا یکی از ابر کلاس های آن فراخوانی کند.
B5 یک نمونه اولیه باید فقط در یک نمونه غیر اولیه فراخوانی شود.
B6 روش‌های نمونه را می‌توان فقط در فراخوانی کرد و فیلدهای نمونه را فقط در نمونه‌هایی که از قبل مقداردهی شده‌اند قابل دسترسی هستند.
B7 اگر همان دستورالعمل new-instance قبل از مقداردهی اولیه مجدداً اجرا شود، ثباتی که نتیجه یک دستورالعمل new-instance را در خود نگه می دارد، نباید استفاده شود.
B8 قبل از اینکه بتوان به اعضای نمونه دسترسی داشت، یک مقداردهی اولیه باید یک نمونه اولیه دیگر (همان کلاس یا سوپرکلاس) را فراخوانی کند. استثنائات، فیلدهای نمونه غیر ارثی هستند که می توانند قبل از فراخوانی اولیه کننده دیگر و کلاس Object به طور کلی اختصاص داده شوند.
B9 همه آرگومان های متد واقعی باید با آرگومان های رسمی مربوطه خود سازگار با انتساب باشند.
B10 برای هر فراخوانی روش نمونه، نمونه واقعی باید با کلاس یا رابط مشخص شده در دستورالعمل سازگار باشد.
B11 یک دستور return<kind> باید با نوع برگشتی متد خود مطابقت داشته باشد.
B12 هنگام دسترسی به اعضای محافظت شده یک سوپرکلاس، نوع واقعی نمونه مورد دسترسی باید کلاس فعلی یا یکی از زیر کلاس های آن باشد.
B13 نوع مقدار ذخیره شده در یک فیلد ثابت باید با نوع فیلد سازگار باشد یا به آن تبدیل شود.
B14 نوع مقدار ذخیره شده در یک فیلد باید با نوع فیلد سازگار باشد یا به آن تبدیل شود.
B15 نوع هر مقدار ذخیره شده در یک آرایه باید با نوع مولفه آرایه سازگار باشد.
B16 عملوند A دستور throw باید با java.lang.Throwable سازگار باشد.
B17 آخرین دستورالعمل قابل دسترسی یک متد باید یا یک goto به عقب یا شاخه، یک return یا یک دستورالعمل throw باشد. نباید امکان رها کردن آرایه insns در پایین وجود داشته باشد.
B18 نصف تخصیص‌نخورده یک جفت رجیستر سابق نمی‌تواند خوانده شود (نامعتبر در نظر گرفته می‌شود) تا زمانی که توسط دستورالعمل دیگری تخصیص داده نشده باشد.
B19 یک دستور move-result<kind> باید بلافاصله قبل از (در آرایه insns ) یک دستور invoke-<kind> باشد. تنها استثنا دستور move-result-object است که ممکن است قبل از یک دستور filled-new-array نیز باشد.
B20 یک دستور move-result<kind> باید بلافاصله قبل از آن (در جریان کنترل واقعی) با یک دستورالعمل return-<kind> منطبق باشد (نباید به آن پرش کرد). تنها استثنا دستور move-result-object است که ممکن است قبل از یک دستور filled-new-array نیز باشد.
B21 یک دستور move-exception باید فقط به عنوان اولین دستورالعمل در یک کنترل کننده استثنا ظاهر شود.
B22 دستورات packed-switch-data ، sparse-switch-data ، و fill-array-data نباید توسط جریان کنترل قابل دسترسی باشند.
،

یک فایل .dex فرمت انتقال بایت کد Dalvik است. برای اینکه یک فایل یک فایل .dex معتبر باشد، محدودیت‌های نحوی و معنایی خاصی وجود دارد و برای پشتیبانی از فایل‌های .dex معتبر، زمان اجرا لازم است.

محدودیت های یکپارچگی عمومی .dex

محدودیت‌های یکپارچگی کلی مربوط به ساختار بزرگ‌تر یک فایل .dex است، همانطور که در قالب .dex به تفصیل توضیح داده شده است.

شناسه توضیحات
G1 شماره magic فایل .dex باید برای نسخه 35 dex\n035\0 یا برای نسخه‌های بعدی مشابه باشد.
G2 چک‌سوم باید یک جمع‌سنجی Adler-32 از کل محتویات فایل به جز magic و فیلد checksum باشد.
G3 امضا باید یک هش SHA-1 از کل محتویات فایل به جز magic ، checksum و signature باشد.
G4

file_size باید با اندازه واقعی فایل بر حسب بایت مطابقت داشته باشد. (نسخه 40 یا قبل از آن)

file_size باید به هدر بعدی در کانتینر یا در انتهای فایل pysical (کانتینر) اشاره کند. اگر به هدر بعدی اشاره کرد، اندازه فایل باید 4 بایت تراز شود. مجموع تمام فیلدهای file_size باید با container_size برابر باشد. (نسخه 41 یا بالاتر)

G5

header_size باید مقدار 0x70 (v40 یا قبل از آن) را داشته باشد.

header_size باید دارای مقدار: 0x78 (v41 یا بالاتر) باشد.

G6 endian_tag باید دارای یک مقدار باشد: ENDIAN_CONSTANT یا REVERSE_ENDIAN_CONSTANT
G7

برای هر یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data ، فیلدهای offset و size باید هر دو صفر یا غیرصفر باشند. در مورد دوم، افست باید چهار بایت تراز شود.

فیلدهای offset و size باید در داخل کانتینر باشند و به داده‌هایی اشاره کنند که بعد از هدری که آنها را تعریف می‌کند قرار دارند. (نسخه 41 یا بالاتر)

G8 تمام فیلدهای offset در هدر به جز map_off باید چهار بایت تراز شوند.
G9 فیلد map_off باید یا صفر باشد یا به بخش داده اشاره کند. در مورد دوم، بخش data باید وجود داشته باشد.
G10 هیچ یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش‌های data نباید با یکدیگر یا سربرگ همپوشانی داشته باشند.
G11 اگر نقشه وجود داشته باشد، هر ورودی نقشه باید یک نوع معتبر داشته باشد. هر نوع ممکن است حداکثر یک بار ظاهر شود.
G12 اگر نقشه ای وجود داشته باشد، هر ورودی نقشه باید یک افست و اندازه غیر صفر داشته باشد. افست باید به بخش مربوط به فایل اشاره کند (یعنی یک string_id_item باید به بخش string_ids اشاره کند) و اندازه صریح یا ضمنی آیتم باید با محتویات و اندازه واقعی بخش مطابقت داشته باشد.
G13 اگر نقشه ای وجود داشته باشد، آنگاه افست ورودی نقشه n+1 باید بزرگتر یا مساوی با افست ورودی نقشه n plus than size of map entry n باشد. این به معنای ورودی های غیر همپوشانی و سفارش کم به بالا است.
G14 انواع ورودی‌های زیر باید دارای یک افست چهار بایتی باشند: string_id_item ، type_id_item ، proto_id_item ، field_id_item ، method_id_item ، class_def_item ، type_list ، code_item ، annotations_directory_item .
G15

برای هر string_id_item ، فیلد string_data_off باید دارای یک مرجع معتبر در بخش data باشد. (نسخه 40 یا قبل از آن)

برای هر string_id_item ، فیلد string_data_off باید در داخل کانتینر و بعد از هر هدری که به‌طور سنتی از آن استفاده می‌کند، یک افست باشد. (نسخه 41 یا بالاتر)

برای string_data_item ارجاع شده، فیلد data باید دارای یک رشته معتبر MUTF-8 باشد و utf16_size باید با طول رمزگشایی شده رشته مطابقت داشته باشد.

G16 برای هر type_id_item ، فیلد descriptor_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیفگر نوع معتبر باشد.
G17 برای هر proto_id_item ، فیلد shorty_idx باید حاوی یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیف کننده کوتاه معتبر باشد. همچنین، فیلد return_type_idx باید یک شاخص معتبر در بخش type_ids باشد و فیلد parameters_off باید صفر باشد یا یک افست معتبر که به بخش data اشاره می‌کند. اگر غیر صفر باشد، لیست پارامترها نباید حاوی هیچ ورودی خالی باشد.
G18 برای هر field_id_item ، هر دو فیلد class_idx و type_idx باید شاخص‌های معتبری در لیست type_ids باشند. ورودی ارجاع شده توسط class_idx باید یک نوع مرجع غیر آرایه باشد. علاوه بر این، فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G19 برای هر method_id_item ، فیلد class_idx باید یک شاخص معتبر در بخش type_ids باشد و ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد. فیلد proto_id باید یک مرجع معتبر در لیست proto_ids باشد. فیلد name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید با مشخصات MemberName مطابقت داشته باشد.
G20 برای هر field_id_item ، فیلد class_idx باید یک فهرست معتبر در لیست type_ids باشد. ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد.

محدودیت های بایت کد استاتیک

محدودیت‌های استاتیک، محدودیت‌هایی بر روی عناصر جداگانه بایت کد هستند. آنها معمولاً می توانند بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده بررسی شوند.

شناسه توضیحات
A1 آرایه insns نباید خالی باشد.
A2 اولین اپکد در آرایه insns باید دارای اندیس صفر باشد.
A3 آرایه insns باید فقط دارای کدهای آپشن معتبر Dalvik باشد.
A4 شاخص دستور n+1 باید با شاخص دستورالعمل n به اضافه طول دستورالعمل n برابر باشد، با در نظر گرفتن عملوندهای ممکن.
A5 آخرین دستور در آرایه insns باید به شاخص insns_size-1 ختم شود.
A6 همه اهداف goto و if-<kind> باید کدهای عملیاتی در یک روش باشند.
A7 تمام اهداف یک دستورالعمل packed-switch باید کدهای عملیاتی در همان روش باشند. اندازه و فهرست اهداف باید هماهنگ باشد.
A8 تمام اهداف یک دستورالعمل sparse-switch باید کدهای عملیاتی در همان روش باشند. جدول مربوطه باید سازگار و مرتب شده از کم به بالا باشد.
A9 عملوند B دستورات const-string و const-string/jumbo باید یک شاخص معتبر در مجموعه ثابت رشته باشد.
A10 عملوند C دستورات iget<kind> و iput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد نمونه باشد.
A11 عملوند C دستورات sget<kind> و sput<kind> باید یک شاخص معتبر در مخزن ثابت فیلد باشد. ورودی ارجاع شده باید نمایانگر یک فیلد ثابت باشد.
A12 عملوند C دستورات invoke-virtual ، invoke-super ، invoke-direct و invoke-static باید یک شاخص معتبر در مخزن ثابت متد باشد.
A13 عملوند B دستورات invoke-virtual/range ، invoke-super/range ، invoke-direct/range و invoke-static/range باید یک شاخص معتبر در مخزن ثابت متد باشد.
A14 روشی که نام آن با «<» شروع می‌شود فقط باید به طور ضمنی توسط VM فراخوانی شود، نه با کدی که از یک فایل .dex منشا می‌گیرد. تنها استثناء اولیه ساز نمونه است که ممکن است توسط invoke-direct فراخوانی شود.
A15 عملوند C دستور واسط invoke-interface باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A16 عملوند B دستور invoke-interface/range باید یک شاخص معتبر در مخزن ثابت متد باشد. method_id ارجاع شده باید به یک رابط (نه کلاس) تعلق داشته باشد.
A17 عملوند B دستورات const-class ، check-cast ، new-instance و filled-new-array/range باید یک شاخص معتبر در مخزن ثابت نوع باشد.
A18 عملوند C دستورات instance-of ، new-array و filled-new-array باید یک شاخص معتبر برای نوع ثابت Pool باشد.
A19 ابعاد یک آرایه ایجاد شده توسط یک دستور new-array باید کمتر از 256 باشد.
A20 دستورالعمل new نباید به کلاس های آرایه، رابط ها یا کلاس های انتزاعی اشاره کند.
A21 نوع ارجاع شده توسط یک دستورالعمل new-array باید یک نوع معتبر و غیر مرجع باشد.
A22 همه رجیسترهایی که توسط یک دستورالعمل به صورت تک عرض (غیر جفتی) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size باشد.
A23 همه رجیسترهایی که توسط یک دستورالعمل به صورت دو عرض (جفت) ارجاع می شوند باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size-1 باشد.
A24 عملوند method_id دستورات invoke-virtual و invoke-direct باید متعلق به یک کلاس (نه یک رابط) باشد. در فایل‌های Dex قبل از نسخه 037 همین امر باید در مورد دستورالعمل‌های invoke-super و invoke-static صادق باشد.
A25 روش method_id از دستورالعمل های invoke-virtual/range و invoke-direct/range باید متعلق به یک کلاس باشد (نه یک رابط). در پرونده های DEX قبل از نسخه 037 ، باید در مورد دستورالعمل های invoke-super/range و invoke-static/range یکسان باشد.

محدودیت های ساختاری Bytecode

محدودیت های ساختاری محدودیت در روابط بین چندین عنصر بایت کد است. آنها معمولاً بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده ها قابل بررسی نیستند.

شناسه توضیحات
B1 تعداد و انواع آرگومان ها (ثبت ها و مقادیر فوری) همیشه باید با دستورالعمل مطابقت داشته باشند.
B2 جفت های ثبت هرگز نباید شکسته شوند.
B3 قبل از خواندن ، یک رجیستر (یا جفت) باید ابتدا اختصاص داده شود.
B4 یک دستورالعمل invoke-direct باید یک نمونه اولیه یا یک روش را فقط در کلاس فعلی یا یکی از ابرقهرمانان آن فراخوانی کند.
B5 یک نمونه اولیه نمونه فقط باید در یک نمونه غیرقانونی استفاده شود.
B6 روشهای نمونه فقط در مواردی مورد استفاده قرار می گیرند و قسمتهای نمونه فقط در نمونه های اولیه از قبل قابل دسترسی هستند.
B7 در صورتی که همان دستورالعمل new-instance جدید قبل از شروع نمونه اجرا شود ، رجیستری که نتیجه یک دستورالعمل new-instance را در اختیار دارد ، نباید استفاده شود.
B8 قبل از دسترسی به اعضای نمونه ، یک نمونه اولیه نمونه باید با یک نمونه اولیه دیگر (همان کلاس یا ابر کلاس) تماس بگیرد. استثنائات زمینه های نمونه غیر متعهد هستند که می توانند قبل از فراخوانی یک ابتکار عمل دیگری و به طور کلی کلاس Object اختصاص دهند.
B9 تمام آرگومان های روش واقعی باید با استدلال رسمی مربوطه سازگار باشند.
B10 برای هر فراخوانی روش نمونه ، نمونه واقعی باید با کلاس یا رابط مشخص شده در دستورالعمل سازگار باشد.
B11 یک دستورالعمل return<kind> باید با نوع بازگشت روش آن مطابقت داشته باشد.
B12 هنگام دسترسی به اعضای حفاظت شده یک ابرقهرمان ، نوع واقعی نمونه ای که در آن قابل دسترسی است باید یا کلاس فعلی یا یکی از زیر کلاس های آن باشد.
B13 نوع مقداری که در یک قسمت استاتیک ذخیره شده است باید سازگار با یا قابل تبدیل به نوع قسمت باشد.
B14 نوع مقدار ذخیره شده در یک قسمت باید سازگار با واگذاری یا قابل تبدیل به نوع قسمت باشد.
B15 نوع هر مقدار ذخیره شده در یک آرایه باید با نوع مؤلفه آرایه سازگار باشد.
B16 A عمل یک دستورالعمل throw باید با java.lang.Throwable سازگار باشد.
B17 آخرین دستورالعمل قابل دسترسی یک روش باید یا به goto یا شاخه ، return یا دستورالعمل throw باشد. نمی توان آرایه insns در پایین گذاشت.
B18 تا زمانی که توسط برخی دستورالعمل های دیگر مجدداً تعیین نشده باشد ، نیمی از یک جفت ثبت نام قبلی ممکن است خوانده نشود (نامعتبر تلقی می شود).
B19 یک دستورالعمل move-result<kind> باید بلافاصله (در آرایه insns ) توسط یک دستورالعمل invoke-<kind> انجام شود. تنها استثناء دستورالعمل move-result-object است که ممکن است قبل از یک دستورالعمل filled-new-array نیز انجام شود.
B20 یک دستورالعمل move-result<kind> باید بلافاصله (در جریان کنترل واقعی) با یک دستورالعمل return-<kind> (نباید به آن پرید). تنها استثناء دستورالعمل move-result-object است که ممکن است قبل از یک دستورالعمل filled-new-array نیز انجام شود.
B21 یک دستورالعمل move-exception فقط باید به عنوان اولین دستورالعمل در یک کنترل کننده استثنا ظاهر شود.
B22 packed-switch-data ، sparse-switch-data ، و fill-array-data را با جریان کنترل قابل دسترسی نیستند.
،

پرونده .dex قالب حمل و نقل برای کد Dalvik است. محدودیت های نحوی و معنایی خاصی وجود دارد که یک پرونده یک پرونده معتبر .dex باشد و یک زمان اجرا برای پشتیبانی از فایلهای معتبر .DEX لازم است.

محدودیت های یکپارچگی عمومی .DEX

محدودیت های یکپارچگی عمومی مربوط به ساختار بزرگتر یک پرونده .dex است ، همانطور که در قالب .dex به تفصیل شرح داده شده است.

شناسه توضیحات
G1 تعداد magic پرونده .dex برای نسخه 35 باید dex\n035\0 باشد ، یا برای نسخه های بعدی مشابه باشد.
G2 Checksum باید یک چک Adler-32 از کل محتویات پرونده به جز زمینه magic و checksum باشد.
G3 امضای باید یک هش SHA-1 از کل مطالب پرونده به جز magic ، checksum و signature باشد.
G4

file_size باید با اندازه واقعی پرونده در بایت مطابقت داشته باشد. (v40 یا زودتر)

file_size باید به عنوان بعدی در ظرف یا در انتهای پرونده Pysical (ظرف) اشاره کند. اگر به عنوان بعدی اشاره کند ، اندازه پرونده باید 4 بایت باشد. مجموع تمام زمینه های file_size باید با container_size برابر باشد. (v41 یا بعد)

G5

header_size باید مقدار آن را داشته باشد: 0x70 (v40 یا قبل از آن)

header_size باید مقدار آن را داشته باشد: 0x78 (v41 یا بعد)

G6 endian_tag باید یا مقدار آن را داشته باشد: ENDIAN_CONSTANT یا REVERSE_ENDIAN_CONSTANT
G7

برای هر یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و data ها ، قسمت های offset و size باید هم صفر یا هر دو غیر صفر باشند. در حالت دوم ، جبران باید چهار با هماهنگ باشد.

قسمتهای offset و size باید در داخل ظرف قرار داشته باشند و به داده هایی که بعد از هدر قرار دارد که آنها را تعریف می کند ، مراجعه کنید. (v41 یا بعد)

G8 تمام زمینه های افست در هدر به جز map_off ​​باید چهار با همبستگی باشد.
G9 قسمت map_off ​​باید صفر باشد یا به بخش داده اشاره کند. در حالت دوم ، بخش data باید وجود داشته باشد.
G10 هیچ یک از link ، string_ids ، type_ids ، proto_ids ، field_ids ، method_ids ، class_defs و بخش های data باید با یکدیگر یا هدر همپوشانی داشته باشند.
G11 اگر یک نقشه وجود داشته باشد ، پس از آن هر ورودی نقشه باید یک نوع معتبر داشته باشد. هر نوع ممکن است حداکثر یک بار ظاهر شود.
G12 اگر یک نقشه وجود داشته باشد ، پس از آن هر ورودی نقشه باید یک جبران و اندازه غیر صفر داشته باشد. افست باید به بخش مربوط به پرونده اشاره کند (یعنی یک string_id_item باید به بخش string_ids اشاره کند) و اندازه صریح یا ضمنی مورد باید با محتویات و اندازه واقعی بخش مطابقت داشته باشد.
G13 اگر نقشه وجود داشته باشد ، جبران ورودی نقشه n+1 باید بیشتر یا برابر با جبران ورودی نقشه n plus than size of map entry n باشد. این به معنای ورودی های غیر همپوشانی و سفارش کم به بالا است.
G14 انواع ورودی های زیر باید دارای یک افست باشد که چهار بایت هماهنگ باشد: string_id_item ، type_id_item ، proto_id_item ، field_id_item ، method_id_item ، class_def_item ، type_list ، code_item ، annotations_directory_item .
G15

برای هر string_id_item ، قسمت string_data_off باید حاوی یک مرجع معتبر به بخش data باشد. (v40 یا زودتر)

برای هر string_id_item ، قسمت string_data_off باید یک جبران در ظرف و بعد از هر هدر باشد که به طور واقعی از آن استفاده می کند. (v41 یا بعد)

برای ارجاع شده string_data_item ، قسمت data باید دارای یک رشته معتبر mutf-8 باشد ، و utf16_size باید با طول رمزگشایی شده رشته مطابقت داشته باشد.

G16 برای هر type_id_item ، قسمت descriptor_idx باید دارای یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیف کننده نوع معتبر باشد.
G17 برای هر proto_id_item ، قسمت shorty_idx باید دارای یک مرجع معتبر در لیست string_ids باشد. رشته ارجاع شده باید یک توصیف کننده معتبر کوتاه باشد. همچنین ، قسمت return_type_idx باید یک شاخص معتبر در بخش type_ids باشد ، و قسمت parameters_off باید صفر باشد یا یک جبران معتبر که به بخش data اشاره دارد. در صورت عدم صفر ، لیست پارامتر نباید حاوی ورودی های خالی باشد.
G18 برای هر field_id_item ، هر دو قسمت class_idx و type_idx باید شاخص های معتبر در لیست type_ids باشند. ورودی ارجاع شده توسط class_idx باید یک نوع مرجع غیر آرایه باشد. علاوه بر این ، قسمت name_idx باید یک مرجع معتبر به بخش string_ids باشد ، و محتوای ورودی ارجاع شده باید مطابق با مشخصات MemberName باشد.
G19 برای هر method_id_item ، قسمت class_idx باید یک شاخص معتبر در بخش type_ids باشد ، و ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد. قسمت proto_id باید یک مرجع معتبر در لیست proto_ids باشد. قسمت name_idx باید یک مرجع معتبر در بخش string_ids باشد و محتوای ورودی ارجاع شده باید مطابق با مشخصات MemberName باشد.
G20 برای هر field_id_item ، قسمت class_idx باید یک شاخص معتبر در لیست type_ids باشد. ورودی ارجاع شده باید یک نوع مرجع غیر آرایه باشد.

محدودیت های استاتیک Bytecode

محدودیت های استاتیک محدودیت هایی در عناصر فردی بایت کد است. آنها معمولاً بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده ها قابل بررسی هستند.

شناسه توضیحات
A1 آرایه insns نباید خالی باشد.
A2 اولین نسخه در آرایه insns باید دارای صفر باشد.
A3 آرایه insns فقط باید حاوی Opcodes معتبر Dalvik باشد.
A4 شاخص دستورالعمل n+1 باید با در نظر گرفتن عملیات های احتمالی با شاخص دستورالعمل n به علاوه طول دستورالعمل n برابر شود.
A5 آخرین دستورالعمل در آرایه insns باید به Index insns_size-1 پایان یابد.
A6 همه اهداف goto و if-<kind> باید با همان روش Opcode باشند.
A7 تمام اهداف یک دستورالعمل packed-switch باید با همان روش Opcode باشند. اندازه و لیست اهداف باید سازگار باشد.
A8 تمام اهداف یک دستورالعمل sparse-switch باید با همان روش Opcodes باشند. جدول مربوطه باید سازگار و طبقه پایین تا بالا باشد.
A9 عملیات B از دستورالعمل های const-string و const-string/jumbo باید یک شاخص معتبر در استخر ثابت رشته باشد.
A10 دستورالعمل های C از iget<kind> و iput<kind> باید یک شاخص معتبر در استخر ثابت میدان باشد. ورودی ارجاع شده باید یک قسمت نمونه را نشان دهد.
A11 دستورالعمل های C از sget<kind> و sput<kind> باید یک شاخص معتبر در استخر ثابت میدان باشد. ورودی ارجاع شده باید یک زمینه استاتیک را نشان دهد.
A12 عمل C از invoke-virtual ، invoke-super ، invoke-direct و invoke-static باید یک شاخص معتبر در استخر ثابت روش باشد.
A13 Operand B از invoke-virtual/range ، invoke-super/range ، invoke-direct/range و دستورالعمل های invoke-static/range باید یک شاخص معتبر در استخر ثابت روش باشد.
A14 روشی که نام آن با "<" شروع می شود ، فقط باید توسط VM به طور ضمنی فراخوانی شود ، نه با کد منشأ یک پرونده .dex . تنها استثناء اولیه سازی نمونه است که ممکن است توسط invoke-direct فراخوانی شود.
A15 عمل C دستورالعمل invoke-interface باید یک شاخص معتبر در استخر ثابت باشد. method_id ارجاع شده باید متعلق به یک رابط باشد (نه یک کلاس).
A16 عملیات B از دستورالعمل invoke-interface/range باید یک شاخص معتبر در استخر ثابت باشد. method_id ارجاع شده باید متعلق به یک رابط باشد (نه یک کلاس).
A17 دستورالعمل های B از const-class ، check-cast ، new-instance و filled-new-array/range باید یک شاخص معتبر در استخر ثابت باشد.
A18 عملیات C از دستورالعمل های instance-of ، new-array و filled-new-array باید یک شاخص معتبر در استخر ثابت باشد.
A19 ابعاد آرایه ای که توسط یک دستورالعمل new-array ایجاد شده است باید کمتر از 256 باشد.
A20 دستورالعمل new نباید به کلاسهای آرایه ، رابط ها یا کلاسهای انتزاعی اشاره کند.
A21 نوع ذکر شده توسط یک دستورالعمل new-array باید یک نوع معتبر و غیر مرجع باشد.
A22 کلیه رجیسترهای ذکر شده توسط یک دستورالعمل به صورت یک عرض (غیر جفت) باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size باشند.
A23 کلیه رجیسترهای ذکر شده توسط یک دستورالعمل به صورت دو عرض (جفت) باید برای روش فعلی معتبر باشند. یعنی شاخص های آنها باید غیر منفی و کوچکتر از registers_size-1 باشند.
A24 روش method_id دستورالعمل های invoke-virtual و invoke-direct باید متعلق به یک کلاس باشد (نه یک رابط). در پرونده های DEX قبل از نسخه 037 ، باید در مورد دستورالعمل های invoke-super و invoke-static صادق باشد.
A25 روش method_id از دستورالعمل های invoke-virtual/range و invoke-direct/range باید متعلق به یک کلاس باشد (نه یک رابط). در پرونده های DEX قبل از نسخه 037 ، باید در مورد دستورالعمل های invoke-super/range و invoke-static/range یکسان باشد.

محدودیت های ساختاری Bytecode

محدودیت های ساختاری محدودیت در روابط بین چندین عنصر بایت کد است. آنها معمولاً بدون استفاده از تکنیک های کنترل یا تجزیه و تحلیل جریان داده ها قابل بررسی نیستند.

شناسه توضیحات
B1 تعداد و انواع آرگومان ها (ثبت ها و مقادیر فوری) همیشه باید با دستورالعمل مطابقت داشته باشند.
B2 جفت های ثبت هرگز نباید شکسته شوند.
B3 قبل از خواندن ، یک رجیستر (یا جفت) باید ابتدا اختصاص داده شود.
B4 یک دستورالعمل invoke-direct باید یک نمونه اولیه یا یک روش را فقط در کلاس فعلی یا یکی از ابرقهرمانان آن فراخوانی کند.
B5 یک نمونه اولیه نمونه فقط باید در یک نمونه غیرقانونی استفاده شود.
B6 روشهای نمونه فقط در مواردی مورد استفاده قرار می گیرند و قسمتهای نمونه فقط در نمونه های اولیه از قبل قابل دسترسی هستند.
B7 در صورتی که همان دستورالعمل new-instance جدید قبل از شروع نمونه اجرا شود ، رجیستری که نتیجه یک دستورالعمل new-instance را در اختیار دارد ، نباید استفاده شود.
B8 قبل از دسترسی به اعضای نمونه ، یک نمونه اولیه نمونه باید با یک نمونه اولیه دیگر (همان کلاس یا ابر کلاس) تماس بگیرد. استثنائات زمینه های نمونه غیر متعهد هستند که می توانند قبل از فراخوانی یک ابتکار عمل دیگری و به طور کلی کلاس Object اختصاص دهند.
B9 تمام آرگومان های روش واقعی باید با استدلال رسمی مربوطه سازگار باشند.
B10 برای هر فراخوانی روش نمونه ، نمونه واقعی باید با کلاس یا رابط مشخص شده در دستورالعمل سازگار باشد.
B11 یک دستورالعمل return<kind> باید با نوع بازگشت روش آن مطابقت داشته باشد.
B12 هنگام دسترسی به اعضای حفاظت شده یک ابرقهرمان ، نوع واقعی نمونه ای که در آن قابل دسترسی است باید یا کلاس فعلی یا یکی از زیر کلاس های آن باشد.
B13 نوع مقداری که در یک قسمت استاتیک ذخیره شده است باید سازگار با یا قابل تبدیل به نوع قسمت باشد.
B14 نوع مقدار ذخیره شده در یک قسمت باید سازگار با واگذاری یا قابل تبدیل به نوع قسمت باشد.
B15 نوع هر مقدار ذخیره شده در یک آرایه باید با نوع مؤلفه آرایه سازگار باشد.
B16 A عمل یک دستورالعمل throw باید با java.lang.Throwable سازگار باشد.
B17 آخرین دستورالعمل قابل دسترسی یک روش باید یا به goto یا شاخه ، return یا دستورالعمل throw باشد. نمی توان آرایه insns در پایین گذاشت.
B18 تا زمانی که توسط برخی دستورالعمل های دیگر مجدداً تعیین نشده باشد ، نیمی از یک جفت ثبت نام قبلی ممکن است خوانده نشود (نامعتبر تلقی می شود).
B19 یک دستورالعمل move-result<kind> باید بلافاصله (در آرایه insns ) توسط یک دستورالعمل invoke-<kind> انجام شود. تنها استثناء دستورالعمل move-result-object است که ممکن است قبل از یک دستورالعمل filled-new-array نیز انجام شود.
B20 یک دستورالعمل move-result<kind> باید بلافاصله (در جریان کنترل واقعی) با یک دستورالعمل return-<kind> (نباید به آن پرید). تنها استثناء دستورالعمل move-result-object است که ممکن است قبل از یک دستورالعمل filled-new-array نیز انجام شود.
B21 یک دستورالعمل move-exception فقط باید به عنوان اولین دستورالعمل در یک کنترل کننده استثنا ظاهر شود.
B22 packed-switch-data ، sparse-switch-data ، و fill-array-data را با جریان کنترل قابل دسترسی نیستند.