Dalvik এক্সিকিউটেবল ফর্ম্যাট

এই ডকুমেন্টে .dex ফাইলের লেআউট ও কন্টেন্ট সম্পর্কে বর্ণনা করা হয়েছে, যেগুলি ক্লাস ডেফিনিশন ও তার সাথে যুক্ত অ্যাডজাঙ্ক্ট ডেটার সেট হোল্ড করতে ব্যবহার করা হয়।

বিভিন্ন ধরনের ব্যাপারে গাইড

LEB128

LEB128 ("Lিটল-ইন্ডিয়ান Bেস 128") হল যেকোনও সাইন করা বা সাইন না করা পূর্ণসংখ্যা কোয়ান্টিটির জন্য পরিবর্তনযোগ্য-দৈর্ঘ্যের এনকোডিং। এই ফর্ম্যাটটি DWARF3 স্পেসিফিকেশন থেকে ধার করা হয়েছে। .dex ফাইলে, LEB128 শুধুমাত্র ৩২-বিট পরিমাণ এনকোড করতে ব্যবহার করা হয়।

প্রতিটি LEB128 এনকোড করা ভ্যালুতে এক থেকে পাঁচটি বাইট থাকে, যা একসাথে একটি ৩২-বিট ভ্যালু দেখায়। প্রতিটি বাইটের সবচেয়ে গুরুত্বপূর্ণ বিট সেট করা থাকে, তবে সিকোয়েন্সের শেষ বাইটের ক্ষেত্রে সবচেয়ে গুরুত্বপূর্ণ বিটটি ক্লিয়ার করা থাকে। প্রতিটি বাইটের বাকি সাতটি বিট হল পেলোড, প্রথম বাইটে পরিমাণের সবচেয়ে কম গুরুত্বপূর্ণ সাতটি বিট, দ্বিতীয় বাইটে পরের সাতটি বিট এবং এইরকমভাবে চলতে থাকে। সাইন করা LEB128 (sleb128)-এর ক্ষেত্রে, চূড়ান্ত ভ্যালু তৈরি করার জন্য সিকোয়েন্সের চূড়ান্ত বাইটের সবচেয়ে গুরুত্বপূর্ণ পেলোড বিট সাইন-এক্সটেন্ড করা হয়। আনসাইনড ক্ষেত্রে (uleb128), স্পষ্টভাবে দেখানো হয়নি এমন যেকোনও বিটকে 0 হিসেবে ব্যাখ্যা করা হয়।

uleb128p1 ভেরিয়েন্টটি সাইন করা মান বোঝাতে ব্যবহার করা হয়, যেখানে uleb128 হিসেবে এনকোড করা মানটি হল এক যোগ করা। এর ফলে -1 (অন্যভাবে এটিকে আনসাইনড ভ্যালু 0xffffffff হিসেবেও বিবেচনা করা হয়) — কিন্তু অন্য কোনও নেগেটিভ সংখ্যা নয় — একটি বাইট হিসেবে এনকোড করা হয় এবং এটি ঠিক সেইসব ক্ষেত্রে উপযোগী যেখানে উপস্থাপিত সংখ্যাকে অবশ্যই নেগেটিভ নয় অথবা -1 (বা 0xffffffff) হতে হবে, এবং যেখানে অন্য কোনও নেগেটিভ ভ্যালু অনুমোদিত নয় (অথবা যেখানে বড় আনসাইনড ভ্যালুর প্রয়োজন হওয়ার সম্ভাবনা কম)।

এখানে ফর্ম্যাটের কিছু উদাহরণ দেওয়া হল:

ফাইল লেআউট

কন্টেনার ফর্ম্যাট

ভার্সন ৪১-এ DEX ডেটার জন্য একটি নতুন কন্টেনার ফর্ম্যাট চালু করা হয়েছে, এর উদ্দেশ্য হল স্পেস সেভ করা। এই কন্টেনার ফর্ম্যাট একাধিক লজিক্যাল DEX ফাইলকে একটি ফিজিক্যাল ফাইলে একত্রিত করতে দেয়। নতুন ফর্ম্যাটটি বেশিরভাগ ক্ষেত্রেই আগের ফর্ম্যাটে থাকা ফাইলগুলির একটি সাধারণ কনক্যাটেনেশন, তবে কিছু পার্থক্য রয়েছে:

• file_size হল লজিক্যাল ফাইলের সাইজ, ফিজিক্যাল ফাইলের সাইজ নয়। কন্টেনারের মধ্যে থাকা সব লজিক্যাল ফাইল ইটারেট করার জন্য এটি ব্যবহার করা যেতে পারে।
• লজিক্যাল dex ফাইল কন্টেনারে থাকা যেকোনও পরবর্তী ডেটা রেফার করতে পারে (তবে আগের ডেটা নয়)। এর ফলে dex ফাইলগুলি একে অপরের সাথে স্ট্রিংয়ের মতো ডেটা শেয়ার করতে পারে।
• সব অফসেট হল ফিজিক্যাল ফাইলের সাপেক্ষে। হেডারের সাথে সম্পর্কিত কোনও অফসেট নেই। এটি নিশ্চিত করে যে অফসেট সহ বিভাগগুলি লজিক্যাল ফাইলের মধ্যে শেয়ার করা যেতে পারে।
• কন্টেনারের সীমা বর্ণনা করার জন্য হেডার দুটি নতুন ফিল্ড যোগ করে। এটি অতিরিক্ত সামঞ্জস্য চেক এবং এর ফলে নতুন ফর্ম্যাটে কোড পোর্ট করা সহজ হয়।
• data_size ও data_off এখন আর ব্যবহার করা হচ্ছে না। ডেটা একাধিক লজিক্যাল ফাইল জুড়ে ছড়িয়ে থাকতে পারে এবং তা সংলগ্ন হতে হবে না।

বিটফিল্ড, স্ট্রিং এবং কনস্ট্যান্টের সংজ্ঞা

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"

মনে রাখবেন: Android 16 রিলিজের ক্ষেত্রে ফর্ম্যাটের 041 ভার্সনের জন্য সহায়তা হল পরীক্ষামূলক, যাতে কন্টেনার ফর্ম্যাট পরীক্ষা করা যায়। তবে, প্রোডাকশন কোডের জন্য ভার্সন 041 ব্যবহার করা উচিত নয়।

মনে রাখবেন: Android 10.0 রিলিজে 040 ভার্সনের ফর্ম্যাটের জন্য সহায়তা যোগ করা হয়েছে, যা SimpleNames-এ অনুমোদিত অক্ষরের সেটকে আরও বাড়িয়ে দিয়েছে।

মনে রাখবেন: Android 9.0 রিলিজের মাধ্যমে ফর্ম্যাটের 039 ভার্সনের জন্য সহায়তা যোগ করা হয়েছে, এর মধ্যে দুটি নতুন বাইটকোড, const-method-handle এবং const-method-type রয়েছে। (এগুলি বাইটকোড সেটের সারসংক্ষেপ টেবিলে প্রতিটি বর্ণনা করা হয়েছে।) Android 10-এ, 039 ভার্সন DEX ফাইল ফর্ম্যাটকে আরও বড় করে যাতে লুকানো API তথ্য অন্তর্ভুক্ত করা যায়। এটি শুধু বুট ক্লাস পাথে DEX ফাইলের ক্ষেত্রে প্রযোজ্য।

মনে রাখবেন: Android 8.0 রিলিজে ফর্ম্যাটের 038 ভার্সনের জন্য সহায়তা যোগ করা হয়েছে। ভার্সন 038 নতুন বাইটকোড যোগ করেছে (invoke-polymorphic এবং invoke-custom) এবং মেথড হ্যান্ডেলের জন্য ডেটা।

মনে রাখবেন: Android 7.0 রিলিজে ফর্ম্যাটের 037 ভার্সনের জন্য সহায়তা যোগ করা হয়েছে। 037-এর আগের বেশিরভাগ Android ভার্সনে 035 ভার্সনের ফর্ম্যাট ব্যবহার করা হয়েছে। 035 এবং 037 ভার্সনের মধ্যে একমাত্র পার্থক্য হল ডিফল্ট মেথড যোগ করা এবং invoke অ্যাডজাস্ট করা।

মনে রাখবেন: ফর্ম্যাটের অন্তত কয়েকটি আগের ভার্সন ব্যাপকভাবে উপলভ্য পাবলিক সফ্টওয়্যার রিলিজে ব্যবহার করা হয়েছে। যেমন, Android প্ল্যাটফর্মের M3 রিলিজের জন্য 009 ভার্সন (নভেম্বর–ডিসেম্বর ২০০৭) এবং Android প্ল্যাটফর্মের M5 রিলিজের জন্য 013 ভার্সন (ফেব্রুয়ারি–মার্চ ২০০৮) ব্যবহার করা হয়েছিল। এই ফর্ম্যাটের আগের ভার্সনগুলি বিভিন্ন দিক থেকে এই ডকুমেন্টে বর্ণিত ভার্সনের থেকে উল্লেখযোগ্যভাবে আলাদা।

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-এ কখনই ব্যবহার করা যাবে না।

পরিবর্তিত 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-এর মতো, MUTF-8 স্ট্রিংয়ের পেয়ারে স্ট্যান্ডার্ড C ফাংশন strcmp() কল করার ফলাফল সবসময় অসমান স্ট্রিংয়ের তুলনা করার সঠিকভাবে সাইন করা ফলাফল নির্দেশ করে না। সাজানোর ক্রম (শুধু সমান হওয়া নয়) যখন একটি সমস্যা হয়, তখন MUTF-8 স্ট্রিং তুলনা করার সবচেয়ে সহজ উপায় হল, সেগুলিকে অক্ষর পিছু ডিকোড করা এবং ডিকোড করা মানগুলির মধ্যে তুলনা করা। (তবে, আরও বুদ্ধিদীপ্ত প্রয়োগও সম্ভব।)

অক্ষর এনকোডিং সম্পর্কে আরও তথ্যের জন্য Unicode Standard দেখুন। MUTF-8 আসলে UTF-8-এর তুলনায় (তুলনামূলকভাবে কম পরিচিত) এনকোডিং CESU-8-এর বেশি কাছাকাছি।

encoded_value এনকোডিং

annotation_element ও encoded_array_item-এ এম্বেড করা আছে

encoded_value হল (প্রায়) ইচ্ছামতো হায়ারার্কি অনুযায়ী সাজানো স্ট্রাকচার্ড ডেটার এনকোড করা অংশ। এনকোডিং এমনভাবে করা হয় যাতে তা কম্প্যাক্ট হয় এবং সহজে পার্স করা যায়।

ভ্যালু ফর্ম্যাট

encoded_array ফর্ম্যাট

encoded_annotation ফর্ম্যাট

annotation_element ফর্ম্যাট

স্ট্রিং সিনট্যাক্স

.dex ফাইলে বিভিন্ন ধরনের আইটেম থাকে যা শেষ পর্যন্ত একটি স্ট্রিংয়ের রেফারেন্স দেয়। নিম্নলিখিত BNF-স্টাইলের সংজ্ঞা এইসব স্ট্রিংয়ের জন্য গ্রহণযোগ্য সিনট্যাক্স নির্দেশ করে।

SimpleName

SimpleName হল অন্যান্য জিনিসের নামের সিনট্যাক্সের ভিত্তি। .dex ফর্ম্যাটে এখানে যথেষ্ট স্বাধীনতা আছে (বেশিরভাগ সাধারণ সোর্স ভাষার থেকে অনেক বেশি)। সংক্ষেপে, একটি সাধারণ নামে যেকোনও লো-ASCII বর্ণমালা বা সংখ্যা, কয়েকটি নির্দিষ্ট লো-ASCII প্রতীক এবং কন্ট্রোল, স্পেস বা বিশেষ অক্ষর নয় এমন বেশিরভাগ নন-ASCII কোড পয়েন্ট থাকে। 040 ভার্সন থেকে শুরু করে এই ফর্ম্যাটে অতিরিক্ত স্পেস অক্ষর (Unicode Zs ক্যাটাগরি) ব্যবহার করা যায়। মনে রাখবেন, সারোগেট কোড পয়েন্ট (U+d800 … U+dfff রেঞ্জে) সরাসরি বৈধ নামের অক্ষর হিসেবে বিবেচিত হয় না, তবে ইউনিকোড সাপ্লিমেন্টাল অক্ষর বৈধ (যেগুলি SimpleNameChar-এর জন্য নিয়মের ফাইনাল অল্টারনেটিভ দ্বারা উপস্থাপিত হয়) এবং এগুলিকে MUTF-8 এনকোডিংয়ে সারোগেট কোড পয়েন্টের পেয়ার হিসেবে ফাইলে উপস্থাপন করতে হবে।

সদস্যের নাম

field_id_item ও method_id_item দ্বারা ব্যবহৃত

MemberName হল কোনও ক্লাসের মেম্বারের নাম, মেম্বার বলতে ফিল্ড, মেথড ও ইনার ক্লাসকে বোঝায়।

FullClassName

FullClassName হল সম্পূর্ণভাবে উপযুক্ত ক্লাস নেম, যার মধ্যে ঐচ্ছিক প্যাকেজ স্পেসিফায়ার এবং তারপরে প্রয়োজনীয় নাম থাকে।

TypeDescriptor

type_id_item ব্যবহার করে

TypeDescriptor হল যেকোনও ধরনের উপস্থাপনা, যার মধ্যে প্রিমিটিভ, ক্লাস, অ্যারে ও void অন্তর্ভুক্ত। বিভিন্ন ভার্সনের অর্থ জানতে নিচে দেখুন।

ShortyDescriptor

proto_id_item ব্যবহার করে

ShortyDescriptor হল রিটার্ন ও প্যারামিটার ধরন সহ কোনও মেথড প্রোটোটাইপের সংক্ষিপ্ত রূপ। তবে, বিভিন্ন রেফারেন্স (ক্লাস বা অ্যারে) ধরনের মধ্যে কোনও পার্থক্য নেই। পরিবর্তে, সব ধরনের রেফারেন্সকে একটি 'L' অক্ষর দিয়ে বোঝানো হয়।

TypeDescriptor সেম্যান্টিক্স

TypeDescriptor-এর প্রতিটি ভ্যারিয়েন্টের অর্থ এখানে দেওয়া হল।

আইটেম ও সম্পর্কিত স্ট্রাকচার

এই বিভাগে, .dex ফাইলে দেখা যেতে পারে এমন প্রতিটি টপ-লেভেল আইটেমের সংজ্ঞা অন্তর্ভুক্ত।

header_item

হেডার বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

map_list

ডেটা বিভাগে দেখা যায়

header_item থেকে রেফার করা হয়েছে

অ্যালাইনমেন্ট: ৪ বাইট

এটি হল কোনও ফাইলের সম্পূর্ণ কন্টেন্টের একটি তালিকা, যা ক্রমানুসারে সাজানো। এতে header_item-এর সাপেক্ষে কিছু রিডানডেন্সি আছে, তবে এটি একটি সম্পূর্ণ ফাইলের উপর ইটারেট করার জন্য ব্যবহার করার সহজ ফর্ম হিসেবে তৈরি করা হয়েছে। কোনও ম্যাপে প্রদত্ত ধরন সর্বাধিক একবারই থাকতে পারে, তবে কোন ক্রমে ধরনগুলি থাকতে পারে তার উপর কোনও বিধিনিষেধ নেই। তবে, ফর্ম্যাটের বাকি অংশ দ্বারা আরোপিত বিধিনিষেধ (যেমন, একটি header বিভাগ প্রথমে থাকতে হবে, তারপরে একটি string_ids বিভাগ ইত্যাদি) মেনে চলতে হবে। এছাড়াও, ম্যাপ এন্ট্রিগুলি অবশ্যই প্রাথমিক অফসেট দ্বারা অর্ডার করা উচিত এবং ওভারল্যাপ করা উচিত নয়।

map_item ফর্ম্যাট

কোড টাইপ করা

string_id_item

string_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

string_data_item

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট-অ্যালাইন করা)

type_id_item

type_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

proto_id_item

proto_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

field_id_item

field_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

method_id_item

method_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

class_def_item

class_defs বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

call_site_id_item

call_site_ids বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

call_site_item

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট অ্যালাইন করা)

call_site_item হল একটি encoded_array_item যার এলিমেন্টগুলি বুটস্ট্র্যাপ লিঙ্কার পদ্ধতিতে প্রদান করা আর্গুমেন্টের সাথে সম্পর্কিত। প্রথম তিনটি আর্গুমেন্ট হল:

1. একটি মেথড হ্যান্ডেল যা বুটস্ট্র্যাপ লিঙ্কার মেথড (VALUE_METHOD_HANDLE) দেখায়।
2. একটি পদ্ধতির নাম যা বুটস্ট্র্যাপ লিঙ্কারকে সমাধান করতে হবে (VALUE_STRING)।
3. সমাধান করতে হবে এমন পদ্ধতির নামের ধরনের সাথে সম্পর্কিত পদ্ধতির ধরন (VALUE_METHOD_TYPE)।

অতিরিক্ত আর্গুমেন্ট হল বুটস্ট্র্যাপ লিঙ্কার পদ্ধতিতে পাস করা ধ্রুবক মান। এইসব আর্গুমেন্ট ক্রম অনুযায়ী এবং কোনও ধরনের কনভার্সন ছাড়াই পাস করা হয়।

বুস্ট্র্যাপ লিঙ্কার পদ্ধতির প্রতিনিধিত্বকারী মেথড হ্যান্ডেলের রিটার্ন টাইপ java.lang.invoke.CallSite হতে হবে। প্রথম তিনটি প্যারামিটারের ধরন হল:

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

অতিরিক্ত আর্গুমেন্টের প্যারামিটারের ধরন তাদের কনস্ট্যান্ট ভ্যালু থেকে নির্ধারণ করা হয়।

method_handle_item

method_handles বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

মেথড হ্যান্ডেল টাইপ কোড

class_data_item

class_def_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট-অ্যালাইন করা)

মনে রাখবেন: সব এলিমেন্টের field_id এবং method_id ইনস্ট্যান্সকে একই ডিফাইন করা ক্লাসকে রেফার করতে হবে।

encoded_field ফর্ম্যাট

encoded_method ফর্ম্যাট

type_list

class_def_item ও proto_id_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

type_item format

code_item

encoded_method থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

try_item ফর্ম্যাট

encoded_catch_handler_list ফর্ম্যাট

encoded_catch_handler ফর্ম্যাট

encoded_type_addr_pair ফর্ম্যাট

debug_info_item

code_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট-অ্যালাইন করা)

প্রতিটি debug_info_item একটি DWARF3-অনুপ্রাণিত বাইট-কোডেড স্টেট মেশিনকে সংজ্ঞায়িত করে যা ব্যাখ্যা করা হলে, পজিশন টেবিল এবং (সম্ভাব্য) কোনও code_item-এর জন্য স্থানীয় ভেরিয়েবল সংক্রান্ত তথ্য নির্গত করে। সিকোয়েন্সটি পরিবর্তনশীল দৈর্ঘ্যের হেডার (যার দৈর্ঘ্য নির্ভর করে মেথড প্যারামিটারের সংখ্যার উপর) দিয়ে শুরু হয়, তারপরে স্টেট মেশিন বাইটকোড থাকে এবং DBG_END_SEQUENCE বাইট দিয়ে শেষ হয়।

স্টেট মেশিনে পাঁচটি রেজিস্টার থাকে। address রেজিস্টার ১৬-বিট কোড ইউনিটে সংশ্লিষ্ট insns_item-এ নির্দেশ অফসেটকে উপস্থাপন করে। প্রতিটি debug_info সিকোয়েন্সের শুরুতে address রেজিস্টার 0-এ শুরু হয় এবং এটি শুধুমাত্র একঘেয়েভাবে বৃদ্ধি পেতে হবে। line রেজিস্টারটি সেই সোর্স লাইন নম্বরকে বোঝায় যা স্টেট মেশিন দ্বারা নির্গত পরবর্তী পজিশন টেবিল এন্ট্রির সাথে যুক্ত থাকা উচিত। এটি সিকোয়েন্স হেডারে ইনিশিয়ালাইজ করা হয় এবং ধনাত্মক বা ঋণাত্মক দিকে পরিবর্তিত হতে পারে, তবে কখনই 1-এর চেয়ে কম হতে পারে না। source_file রেজিস্টার সোর্স ফাইলকে দেখায় যেখানে লাইন নম্বর এন্ট্রি রেফার করা হয়। এটি class_def_item-এ source_file_idx-এর ভ্যালুতে ইনিশিয়ালাইজ করা হয়। অন্য দুটি ভেরিয়েবল, 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)

annotations_directory_item

class_def_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

মনে রাখবেন: সব এলিমেন্টের field_id এবং method_id ইনস্ট্যান্সকে অবশ্যই একই ডিফাইনিং ক্লাসকে রেফার করতে হবে।

field_annotation ফর্ম্যাট

method_annotation ফর্ম্যাট

parameter_annotation ফর্ম্যাট

annotation_set_ref_list

parameter_annotations_item থেকে রেফার করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

annotation_set_ref_item format

annotation_set_item

annotations_directory_item, field_annotations_item, method_annotations_item এবং annotation_set_ref_item থেকে রেফার করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: ৪ বাইট

annotation_off_item ফর্ম্যাট

annotation_item

annotation_set_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট-অ্যালাইন করা)

দৃশ্যমানতা সংক্রান্ত ভ্যালু

annotation_item-এর মধ্যে visibility ফিল্ডের জন্য এইসব বিকল্প রয়েছে:

encoded_array_item

class_def_item থেকে রেফারেন্স করা হয়েছে

ডেটা বিভাগে দেখা যায়

অ্যালাইনমেন্ট: কোনওটিই নয় (বাইট-অ্যালাইন করা)

hiddenapi_class_data_item

এই বিভাগে প্রতিটি ক্লাসের ব্যবহার করা সীমিত ইন্টারফেস সংক্রান্ত ডেটা থাকে।

মনে রাখবেন: লুকানো API ফিচারটি Android 10.0-এ প্রথম চালু করা হয় এবং এটি শুধুমাত্র বুট ক্লাস পাথে ক্লাসের DEX ফাইলের ক্ষেত্রে প্রযোজ্য। Android-এর ভবিষ্যতের রিলিজগুলিতে নিচে বর্ণিত ফ্ল্যাগের তালিকা আরও বাড়ানো হতে পারে। আরও তথ্যের জন্য, নন-এসডিকে ইন্টারফেসের উপর বিধিনিষেধ দেখুন।

বিধিনিষেধের ফ্ল্যাগের ধরন:

সিস্টেম অ্যানোটেশন

ক্লাস (এবং পদ্ধতি ও ফিল্ড) সম্পর্কে বিভিন্ন ধরনের রিফ্লেক্টিভ তথ্য দেখানোর জন্য সিস্টেম অ্যানোটেশন ব্যবহার করা হয়। এই তথ্য সাধারণত ক্লায়েন্ট (নন-সিস্টেম) কোডের মাধ্যমে শুধুমাত্র পরোক্ষভাবে অ্যাক্সেস করা হয়।

সিস্টেম অ্যানোটেশন .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 ডেক্স স্ট্রাকচারের সমান সাইজের হতে হবে, অন্যথায় রানটাইমে একটি 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 ফর্ম্যাটটি স্বাক্ষরের ফর্ম্যাটকে সংজ্ঞায়িত করে না; এটি কেবলমাত্র সেই ভাষার শব্দার্থের সফল বাস্তবায়নের জন্য একটি সোর্স ভাষার প্রয়োজনীয় স্বাক্ষরগুলিকে উপস্থাপন করতে সক্ষম হওয়ার জন্য উদ্দেশ্য করা হয়েছে। এই কারণে, ভার্চুয়াল মেশিন ইমপ্লিমেন্টেশনের মাধ্যমে সাধারণত সিগনেচার পার্স (বা যাচাই) করা হয় না। সিগনেচারগুলি শুধুমাত্র উচ্চ-লেভেলের API এবং টুলে (যেমন, ডিবাগার) হ্যান্ড-অফ করা হয়। তাই, সিগনেচারের যেকোনও ব্যবহার এমনভাবে লেখা উচিত যাতে শুধুমাত্র বৈধ সিগনেচার পাওয়ার ব্যাপারে কোনও অনুমান না করা হয়, সিনট্যাক্সগতভাবে অবৈধ সিগনেচার পাওয়ার সম্ভাবনা থেকে নিজেকে স্পষ্টভাবে রক্ষা করা হয়।

সিগনেচার স্ট্রিংয়ে অনেক ডুপ্লিকেট কন্টেন্ট থাকে বলে, Signature অ্যানোটেশনকে স্ট্রিংয়ের অ্যারে হিসেবে সংজ্ঞায়িত করা হয়, যেখানে ডুপ্লিকেট এলিমেন্ট স্বাভাবিকভাবেই একই আন্ডারলায়িং ডেটাকে রেফার করে এবং সিগনেচারকে অ্যারের সব স্ট্রিংয়ের কনক্যাটেনেশন হিসেবে ধরা হয়। কোনও স্বাক্ষরকে আলাদা স্ট্রিংয়ে কীভাবে বিভক্ত করতে হবে সেই সম্পর্কে কোনও নিয়ম নেই; এটি সম্পূর্ণভাবে .dex ফাইল জেনারেট করা টুলের উপর নির্ভর করে।

dalvik.annotation.Throws

পদ্ধতিতে দেখা যায়

এক বা একাধিক ব্যতিক্রমের ধরন থ্রো করার জন্য ঘোষণা করা প্রতিটি পদ্ধতির সাথে একটি Throws অ্যানোটেশন যুক্ত করা হয়।