সীমাবদ্ধতা

.dex ফাইল হল Dalvik বাইটকোডের ট্রান্সপোর্ট ফর্ম্যাট। কোনও ফাইলকে সঠিক .dex ফাইল হতে হলে, সেটির জন্য নির্দিষ্ট সিনট্যাক্স ও সিম্যান্টিক সংক্রান্ত সীমাবদ্ধতা থাকতে হবে এবং শুধুমাত্র সঠিক .dex ফাইল সাপোর্ট করার জন্য রানটাইম প্রয়োজন।

সাধারণ .dex ইন্টিগ্রিটি সংক্রান্ত বাধ্যবাধকতা

সাধারণ ইন্টিগ্রিটি সংক্রান্ত সীমাবদ্ধতা .dex ফাইলের বৃহত্তর কাঠামোর সাথে সম্পর্কিত, যেমন .dex ফর্ম্যাটে বিস্তারিতভাবে বর্ণনা করা হয়েছে।

শনাক্তকারী বর্ণনা
G1 .dex ফাইলের magic নম্বরটি অবশ্যই dex\n035\0 ভার্সন ৩৫ বা পরবর্তী ভার্সনের ক্ষেত্রে একই রকম হতে হবে।
G2 magic ও checksum ফিল্ড ছাড়া সম্পূর্ণ ফাইল কন্টেন্টের Adler-32 চেকসাম হতে হবে।
G3 স্বাক্ষরটি অবশ্যই magic, checksum এবং signature বাদে সম্পূর্ণ ফাইল কন্টেন্টের SHA-1 হ্যাশ হতে হবে।
G4

file_size অবশ্যই বাইটে প্রকৃত ফাইলের সাইজের সাথে মিলতে হবে। (v40 বা তার আগের ভার্সন)

file_size-কে অবশ্যই কন্টেনারের পরবর্তী হেডিংয়ের দিকে নির্দেশ করতে হবে, অথবা ফিজিক্যাল ফাইলের (কন্টেনার) শেষে। এটি পরবর্তী হেডারের দিকে নির্দেশ করলে, ফাইলের সাইজ অবশ্যই ৪-বাইট অ্যালাইন করা হতে হবে। সব 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 কোনও ম্যাপ থাকলে, প্রতিটি ম্যাপ এন্ট্রিতে শূন্য নয় এমন অফসেট ও সাইজ থাকতে হবে। অফসেটকে অবশ্যই ফাইলের সংশ্লিষ্ট বিভাগে পয়েন্ট করতে হবে (যেমন, a 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 তালিকার একটি সঠিক ইন্ডেক্স হতে হবে। রেফারেন্স করা এন্ট্রিকে অবশ্যই নন-অ্যারে রেফারেন্স টাইপ হতে হবে।

স্ট্যাটিক বাইটকোড সংক্রান্ত বিধিনিষেধ

স্ট্যাটিক সীমাবদ্ধতা হল বাইটকোডের স্বতন্ত্র এলিমেন্টের উপর আরোপ করা সীমাবদ্ধতা। এগুলি সাধারণত কন্ট্রোল বা ডেটা-ফ্লো বিশ্লেষণ টেকনিক ব্যবহার না করেই চেক করা যায়।

শনাক্তকারী বর্ণনা
A1 insns অ্যারে খালি রাখা যাবে না।
A2 insns অ্যারের প্রথম অপকোডের ইন্ডেক্স শূন্য হতে হবে।
A3 insns অ্যারেতে শুধুমাত্র সঠিক Dalvik opcode থাকতে হবে।
A4 সম্ভাব্য অপারেন্ড বিবেচনা করে, নির্দেশ n+1-এর ইন্ডেক্স অবশ্যই নির্দেশ n-এর ইন্ডেক্স ও নির্দেশ n-এর দৈর্ঘ্যের যোগফলের সমান হতে হবে।
A5 insns অ্যারের শেষ নির্দেশিকা অবশ্যই ইন্ডেক্স -এ শেষ হতে হবে insns_size-1।
A6 সব goto ও if-<kind> টার্গেটকে অবশ্যই একই পদ্ধতির মধ্যে অপকোড হতে হবে।
A7 packed-switch নির্দেশাবলীর সব টার্গেটকে একই পদ্ধতির মধ্যে অপকোড হতে হবে। টার্গেটের সাইজ ও তালিকা অবশ্যই সামঞ্জস্যপূর্ণ হতে হবে।
A8 sparse-switch নির্দেশাবলীর সব টার্গেটকে একই পদ্ধতির মধ্যে অপকোড হতে হবে। সংশ্লিষ্ট টেবিলটি অবশ্যই সামঞ্জস্যপূর্ণ হতে হবে এবং ছোট থেকে বড় ক্রমে সাজানো থাকতে হবে।
A9 const-string ও const-string/jumbo নির্দেশাবলীর B অপার‍্যান্ডকে স্ট্রিং কনস্ট্যান্ট পুলে একটি সঠিক ইন্ডেক্স হতে হবে।
A10 iget<kind> ও iput<kind> নির্দেশাবলীর C অপার‍্যান্ডকে ফিল্ড কনস্ট্যান্ট পুলে একটি সঠিক ইন্ডেক্স হতে হবে। রেফার করা এন্ট্রিকে অবশ্যই একটি ইনস্ট্যান্স ফিল্ড হতে হবে।
A11 sget<kind> এবং sput<kind> নির্দেশের C অপারেন্ডটি অবশ্যই ফিল্ড কনস্ট্যান্ট পুলে একটি সঠিক ইনডেক্স হতে হবে। রেফার করা এন্ট্রিকে অবশ্যই একটি স্ট্যাটিক ফিল্ড হতে হবে।
A12 invoke-virtual, invoke-super, invoke-direct এবং invoke-static নির্দেশাবলীর C অপার‍্যান্ডকে অবশ্যই পদ্ধতি কনস্ট্যান্ট পুলে একটি বৈধ ইন্ডেক্স হতে হবে।
A13 invoke-virtual/range, invoke-super/range, invoke-direct/range এবং invoke-static/range নির্দেশাবলীর B অপার‍্যান্ডকে অবশ্যই মেথড কনস্ট্যান্ট পুলে একটি বৈধ ইন্ডেক্স হতে হবে।
A14 '<' দিয়ে শুরু হওয়া নামের কোনও মেথডকে অবশ্যই VM-এর মাধ্যমে পরোক্ষভাবে ইনভোক করতে হবে, .dex ফাইল থেকে তৈরি হওয়া কোডের মাধ্যমে নয়। এর একমাত্র ব্যতিক্রম হল ইনস্ট্যান্স ইনিশিয়ালাইজার, যা invoke-direct দ্বারা আহ্বান করা হতে পারে।
A15 invoke-interface নির্দেশের C অপার‍্যান্ডকে অবশ্যই মেথড কনস্ট্যান্ট পুলে একটি সঠিক ইন্ডেক্স হতে হবে। রেফারেন্স করা method_id অবশ্যই একটি ইন্টারফেসের (ক্লাসের নয়) অন্তর্গত হতে হবে।
A16 invoke-interface/range নির্দেশের B অপার‍্যান্ডকে অবশ্যই মেথড কনস্ট্যান্ট পুলে একটি সঠিক ইন্ডেক্স হতে হবে। রেফারেন্স করা method_id অবশ্যই কোনও ইন্টারফেসের (কোনও ক্লাসের নয়) হতে হবে।
A17 const-class, check-cast, new-instance এবং filled-new-array/range নির্দেশাবলীর B অপার‍্যান্ডকে অবশ্যই টাইপ কনস্ট্যান্ট পুলে একটি সঠিক ইন্ডেক্স হতে হবে।
A18 instance-of, new-array এবং filled-new-array নির্দেশের C অপারেন্ডটি অবশ্যই টাইপ কনস্ট্যান্ট পুলে একটি সঠিক ইনডেক্স হতে হবে।
A19 new-array নির্দেশাবলী দ্বারা তৈরি অ্যারের ডাইমেনশন অবশ্যই 256-এর থেকে কম হতে হবে।
A20 newনির্দেশাবলীতে অ্যারে ক্লাস, ইন্টারফেস বা অ্যাবস্ট্রাক্ট ক্লাসের উল্লেখ করা যাবে না।
A21 new-array নির্দেশিকায় উল্লেখ করা ধরনটি অবশ্যই সঠিক, রেফারেন্স ছাড়া ধরন হতে হবে।
A22 সিঙ্গেল-উইডথ (নন-পেয়ার) ফ্যাশনে কোনও নির্দেশ দ্বারা উল্লেখ করা সমস্ত রেজিস্টার বর্তমান পদ্ধতির জন্য বৈধ হতে হবে। অর্থাৎ, তাদের ইন্ডেক্স নেগেটিভ ছাড়া হতে হবে এবং registers_size-এর থেকে ছোট হতে হবে।
A23 ডবল-উইথ (জোড়া) ফ্যাশনে নির্দেশাবলী দ্বারা উল্লেখ করা সমস্ত রেজিস্টারকে বর্তমান পদ্ধতির জন্য বৈধ হতে হবে। অর্থাৎ, তাদের ইন্ডেক্স নেগেটিভ ছাড়া হতে হবে এবং registers_size-1-এর থেকে ছোট হতে হবে।
A24 invoke-virtual এবং invoke-direct নির্দেশাবলীর method_id অপার‍্যান্ডকে অবশ্যই একটি ক্লাস (কোনও ইন্টারফেস নয়) হতে হবে। 037 ভার্সনের আগের Dex ফাইলে invoke-super ও invoke-static নির্দেশাবলীর ক্ষেত্রেও একই কথা প্রযোজ্য।
A25 invoke-virtual/range এবং invoke-direct/range নির্দেশাবলীর method_id অপার‍্যান্ডকে একটি ক্লাস (ইন্টারফেস নয়)-এর অংশ হতে হবে। 037 ভার্সনের আগের Dex ফাইলে 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 throw নির্দেশের A অপারেন্ডকে অবশ্যই 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 ছদ্ম-নির্দেশাবলী অবশ্যই কন্ট্রোল ফ্লো দ্বারা পৌঁছানো যাবে না।