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

এই ডকুমেন্টটি .dex ফাইলের লেআউট এবং বিষয়বস্তু বর্ণনা করে, যেগুলি ক্লাস সংজ্ঞা এবং তাদের সংশ্লিষ্ট উপাত্তের একটি সেট রাখতে ব্যবহৃত হয়।

প্রকারের নির্দেশিকা

LEB128

LEB128 (" L ittle- E ndian B ase 128 ") হল একটি পরিবর্তনশীল-দৈর্ঘ্যের এনকোডিং যা ইচ্ছাকৃতভাবে স্বাক্ষরিত বা স্বাক্ষরবিহীন পূর্ণসংখ্যার পরিমাণের জন্য। বিন্যাসটি DWARF3 স্পেসিফিকেশন থেকে ধার করা হয়েছে। একটি .dex ফাইলে, LEB128 শুধুমাত্র 32-বিট পরিমাণ এনকোড করতে ব্যবহৃত হয়।

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

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

এখানে বিন্যাসের কিছু উদাহরণ রয়েছে:

ফাইল লেআউট

বিটফিল্ড, স্ট্রিং এবং ধ্রুবক সংজ্ঞা

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 9.0 রিলিজে ফর্ম্যাটের 039 সংস্করণের জন্য সমর্থন যোগ করা হয়েছিল, যা দুটি নতুন বাইটকোড, const-method-handle এবং const-method-type চালু করেছে। (এগুলি প্রতিটি বাইটকোড সেট টেবিলের সারাংশে বর্ণিত হয়েছে।) Android 10-এ, সংস্করণ 039 লুকানো API তথ্য অন্তর্ভুক্ত করার জন্য DEX ফাইল বিন্যাসকে প্রসারিত করে যা শুধুমাত্র বুট ক্লাস পাথের DEX ফাইলগুলির জন্য প্রযোজ্য।

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

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

দ্রষ্টব্য: সর্বজনীন সফ্টওয়্যার প্রকাশগুলিতে বিন্যাসের অন্তত কয়েকটি পূর্ববর্তী সংস্করণ ব্যবহার করা হয়েছে। উদাহরণস্বরূপ, সংস্করণ 009 অ্যান্ড্রয়েড প্ল্যাটফর্মের M3 রিলিজের জন্য ব্যবহার করা হয়েছিল (নভেম্বর-ডিসেম্বর 2007), এবং সংস্করণ 013 ব্যবহার করা হয়েছিল অ্যান্ড্রয়েড প্ল্যাটফর্মের M5 রিলিজের জন্য (ফেব্রুয়ারি-মার্চ 2008)। বিভিন্ন দিক থেকে, বিন্যাসের এই আগের সংস্করণগুলি এই নথিতে বর্ণিত সংস্করণ থেকে উল্লেখযোগ্যভাবে পৃথক।

ENDIAN_CONSTANT এবং REVERSE_ENDIAN_CONSTANT৷

header_item এ এমবেড করা হয়েছে

ধ্রুবক ENDIAN_CONSTANT যে ফাইলটিতে এটি পাওয়া যায় তার শেষতা নির্দেশ করতে ব্যবহৃত হয়। যদিও স্ট্যান্ডার্ড .dex ফরম্যাট সামান্য-এন্ডিয়ান, বাস্তবায়নগুলি বাইট-অদলবদল করতে বেছে নিতে পারে। যদি একটি ইমপ্লিমেন্টেশন একটি হেডারে আসে যার endian_tag ENDIAN_CONSTANT এর পরিবর্তে REVERSE_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

অ্যাক্সেস_ফ্ল্যাগ সংজ্ঞা

class_def_item, encoded_field, encoded_method এবং InnerClas এ এমবেড করা হয়েছে

এই পতাকার বিটফিল্ডগুলি ক্লাস এবং ক্লাস সদস্যদের অ্যাক্সেসযোগ্যতা এবং সামগ্রিক বৈশিষ্ট্যগুলি নির্দেশ করতে ব্যবহৃত হয়।

* শুধুমাত্র InnerClass টীকাগুলির জন্য অনুমোদিত, এবং কখনই একটি class_def_item এ চালু করা উচিত নয়।

পরিবর্তিত UTF-8 এনকোডিং

সহজ উত্তরাধিকার সমর্থনের জন্য ছাড় হিসাবে, .dex ফরম্যাট তার স্ট্রিং ডেটাকে একটি ডি ফ্যাক্টো স্ট্যান্ডার্ড পরিবর্তিত UTF-8 ফর্মে এনকোড করে, যা পরবর্তীতে MUTF-8 হিসাবে উল্লেখ করা হয়। এই ফর্মটি স্ট্যান্ডার্ড UTF-8 এর মতো, ছাড়া:

• শুধুমাত্র এক-, দুই- এবং তিন-বাইট এনকোডিং ব্যবহার করা হয়।
• U+10000 রেঞ্জের কোড পয়েন্ট … U+10ffff একটি সারোগেট জোড়া হিসাবে এনকোড করা হয়, যার প্রত্যেকটি একটি তিন-বাইট এনকোডেড মান হিসাবে উপস্থাপিত হয়।
• কোড পয়েন্ট U+0000 দুই-বাইট আকারে এনকোড করা হয়েছে।
• একটি সাধারণ নাল বাইট (মান 0 ) একটি স্ট্রিংয়ের শেষ নির্দেশ করে, যেমনটি স্ট্যান্ডার্ড সি ভাষার ব্যাখ্যা।

উপরের প্রথম দুটি আইটেম সংক্ষিপ্ত করা যেতে পারে এইভাবে: MUTF-8 হল UTF-16 এর জন্য একটি এনকোডিং বিন্যাস, ইউনিকোড অক্ষরের জন্য আরও সরাসরি এনকোডিং বিন্যাস না হয়ে।

উপরের চূড়ান্ত দুটি আইটেম একটি স্ট্রিং-এ কোড পয়েন্ট U+0000 অন্তর্ভুক্ত করা এবং এখনও এটিকে C-স্টাইলের নাল-টার্মিনেটেড স্ট্রিং হিসাবে ব্যবহার করা সম্ভব করে তোলে।

যাইহোক, U+0000 এর বিশেষ এনকোডিং এর অর্থ হল, সাধারণ UTF-8 এর বিপরীতে, MUTF-8 স্ট্রিংগুলির একটি জোড়ায় স্ট্যান্ডার্ড C ফাংশন strcmp() কল করার ফলাফল সবসময় অসম স্ট্রিংগুলির তুলনার সঠিকভাবে স্বাক্ষরিত ফলাফল নির্দেশ করে না। . যখন অর্ডার করা (শুধু সমতা নয়) একটি উদ্বেগের বিষয়, তখন MUTF-8 স্ট্রিংগুলির তুলনা করার সবচেয়ে সহজ উপায় হল তাদের অক্ষর অনুসারে অক্ষর ডিকোড করা এবং ডিকোড করা মানগুলির তুলনা করা। (তবে, আরও চতুর বাস্তবায়নও সম্ভব।)

অক্ষর এনকোডিং সম্পর্কে আরও তথ্যের জন্য অনুগ্রহ করে ইউনিকোড স্ট্যান্ডার্ড দেখুন। MUTF-8 প্রকৃতপক্ষে (অপেক্ষাকৃত কম সুপরিচিত) এনকোডিং CESU-8- এর থেকে UTF-8 প্রতি সে-এর কাছাকাছি।

encoded_value এনকোডিং

annotation_element এবং encoded_array_item এ এমবেড করা হয়েছে

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

মান বিন্যাস

encoded_array বিন্যাস

এনকোডেড_টীকা বিন্যাস

টীকা_এলিমেন্ট বিন্যাস

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

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

সরল নাম

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

সদস্যের নাম

field_id_item এবং method_id_item দ্বারা ব্যবহৃত

একটি সদস্য নাম হল একটি শ্রেণীর সদস্যের নাম, সদস্যরা ক্ষেত্র, পদ্ধতি এবং অভ্যন্তরীণ ক্লাস।

ফুলক্লাস নাম

একটি FullClassName হল একটি সম্পূর্ণ যোগ্য শ্রেণির নাম, একটি ঐচ্ছিক প্যাকেজ স্পেসিফায়ার সহ একটি প্রয়োজনীয় নাম অনুসরণ করে৷

TypeDescriptor

type_id_item দ্বারা ব্যবহৃত

একটি TypeDescriptor হল আদিম, শ্রেণী, অ্যারে এবং void সহ যেকোন প্রকারের উপস্থাপনা। বিভিন্ন সংস্করণের অর্থের জন্য নীচে দেখুন।

সংক্ষিপ্ত বর্ণনাকারী

proto_id_item দ্বারা ব্যবহৃত

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

TypeDescriptor শব্দার্থবিদ্যা

এটি TypeDescriptor এর প্রতিটি রূপের অর্থ।

আইটেম এবং সম্পর্কিত কাঠামো

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

হেডার_আইটেম

শিরোনাম বিভাগে প্রদর্শিত হয়

প্রান্তিককরণ: 4 বাইট

মানচিত্রের_তালিকা

ডেটা বিভাগে উপস্থিত হয়

হেডার_আইটেম থেকে উল্লেখ করা হয়েছে

প্রান্তিককরণ: 4 বাইট

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

map_item বিন্যাস

কোড টাইপ করুন

স্ট্রিং_আইডি_আইটেম

string_ids বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

স্ট্রিং_ডেটা_আইটেম

ডেটা বিভাগে উপস্থিত হয়

প্রান্তিককরণ: কোনোটিই নয় (বাইট-সারিবদ্ধ)

টাইপ_আইডি_আইটেম

type_ids বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

প্রোটো_আইডি_আইটেম

proto_ids বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

ক্ষেত্র_আইডি_আইটেম

field_ids বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

পদ্ধতি_আইডি_আইটেম

পদ্ধতি_আইডি বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

class_def_item

class_defs বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

কল_সাইট_আইডি_আইটেম

কল_সাইট_আইডি বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

কল_সাইট_আইটেম

ডেটা বিভাগে উপস্থিত হয়

প্রান্তিককরণ: কোনোটিই নয় (বাইট সারিবদ্ধ)

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

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

পদ্ধতি_হ্যান্ডেল_আইটেম

পদ্ধতি_হ্যান্ডেল বিভাগে উপস্থিত হয়

প্রান্তিককরণ: 4 বাইট

পদ্ধতি হ্যান্ডেল টাইপ কোড

ক্লাস_ডাটা_আইটিএম

CLASS_DEF_ITEM থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: কিছুই নয় (বাইট-সারিবদ্ধ)

দ্রষ্টব্য: সমস্ত উপাদানগুলির field_id এবং method_id দৃষ্টান্তগুলি অবশ্যই একই সংজ্ঞায়িত শ্রেণীর উল্লেখ করতে হবে।

এনকোডেড_ফিল্ড ফর্ম্যাট

এনকোডেড_মিথড ফর্ম্যাট

টাইপ_লিস্ট

CLAST_DEF_ITEM এবং PROTO_ID_ITEM থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: 4 বাইট

টাইপ_ আইটেম ফর্ম্যাট

কোড_ আইটেম

এনকোডেড_মথোড থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: 4 বাইট

চেষ্টা_ আইটেম ফর্ম্যাট

এনকোডড_ক্যাচ_হ্যান্ডলার_লিস্ট ফর্ম্যাট

এনকোডেড_ক্যাচ_হ্যান্ডলার ফর্ম্যাট

এনকোডেড_ টাইপ_এডিডিআর_পায়ার ফর্ম্যাট

debug_info_item

কোড_আইটিএম থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: কিছুই নয় (বাইট-সারিবদ্ধ)

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

রাজ্য মেশিনে পাঁচটি রেজিস্টার রয়েছে। address রেজিস্টারটি 16-বিট কোড ইউনিটে সম্পর্কিত insns_item এ অফসেটটির প্রতিনিধিত্ব করে। address রেজিস্টারটি প্রতিটি debug_info সিকোয়েন্সের শুরুতে 0 এ শুরু হয় এবং কেবল একঘেয়েভাবে বৃদ্ধি করতে হবে। line রেজিস্টারটি প্রতিনিধিত্ব করে যে কোন উত্স লাইন নম্বরটি রাষ্ট্রীয় মেশিন দ্বারা নির্গত পরবর্তী অবস্থানের টেবিল এন্ট্রির সাথে যুক্ত হওয়া উচিত। এটি সিকোয়েন্স শিরোনামে শুরু করা হয়েছে, এবং ইতিবাচক বা নেতিবাচক দিকগুলিতে পরিবর্তিত হতে পারে তবে কখনই 1 এর চেয়ে কম হতে হবে না। source_file রেজিস্টারটি উত্স ফাইলটি উপস্থাপন করে যা লাইন নম্বর এন্ট্রিগুলি উল্লেখ করে। এটি class_def_item এ source_file_idx মানকে সূচনা করা হয়েছে। অন্য দুটি ভেরিয়েবল, prologue_end এবং epilogue_begin হ'ল বুলিয়ান পতাকা ( false থেকে শুরু করে) যা নির্দেশ করে যে পরবর্তী অবস্থানটি নির্গত হওয়া কোনও পদ্ধতি প্রোলোগ বা এপিলোগ হিসাবে বিবেচনা করা উচিত কিনা। স্টেট মেশিনটি অবশ্যই DBG_RESTART_LOCAL কোডের জন্য প্রতিটি রেজিস্টারে সর্বশেষ স্থানীয় ভেরিয়েবলের লাইভের নাম এবং প্রকারটি ট্র্যাক করতে হবে।

শিরোনামটি নিম্নরূপ:

বাইট কোড মানগুলি নিম্নরূপ:

বিশেষ opcodes

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)

টীকাগুলি_ডাইরেক্টরি_আইটিএম

CLASS_DEF_ITEM থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: 4 বাইট

দ্রষ্টব্য: সমস্ত উপাদানগুলির field_id এবং method_id দৃষ্টান্তগুলি অবশ্যই একই সংজ্ঞায়িত শ্রেণীর উল্লেখ করতে হবে।

ফিল্ড_অ্যানোটেশন ফর্ম্যাট

পদ্ধতি_অনোটেশন ফর্ম্যাট

প্যারামিটার_অনোটেশন ফর্ম্যাট

টীকা_সেট_রেফ_লিস্ট

প্যারামিটার_অনোটেশনস_আইটিএম থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: 4 বাইট

টীকা_সেট_রেফ_আইটিএম ফর্ম্যাট

টীকা_সেট_আইটিএম

টীকাগুলি_ডাইরেক্টরি_আইটিএম, ফিল্ড_অ্যানোটেশনস_আইটিএম, পদ্ধতি_অনোটেশন_আইটিএম এবং টীকা_সেট_সেট_আরফ_আইটিএম থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: 4 বাইট

টীকা_অফ_ আইটেম ফর্ম্যাট

টীকা_ আইটেম

টীকা_সেট_আইটিএম থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: কিছুই নয় (বাইট-সারিবদ্ধ)

দৃশ্যমানতার মান

এগুলি একটি annotation_item -এ visibility ক্ষেত্রের বিকল্পগুলি:

এনকোডেড_আরে_আইটিএম

CLASS_DEF_ITEM থেকে রেফারেন্স

ডেটা বিভাগে প্রদর্শিত হবে

প্রান্তিককরণ: কিছুই নয় (বাইট-সারিবদ্ধ)

HIDEDAPI_CLASS_DATA_ITEM

এই বিভাগে প্রতিটি শ্রেণীর দ্বারা ব্যবহৃত সীমাবদ্ধ ইন্টারফেসগুলির ডেটা রয়েছে।

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

সীমাবদ্ধতা পতাকা প্রকার:

সিস্টেম টীকা

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

সিস্টেম টীকাগুলি VISIBILITY_SYSTEM সাথে দৃশ্যমানতার সাথে টীকা হিসাবে .dex ফাইলগুলিতে প্রতিনিধিত্ব করা হয়।

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

পদ্ধতিতে প্রদর্শিত হবে

দ্রষ্টব্য: অ্যান্ড্রয়েড 7.1 এর পরে এই টীকাটি যুক্ত করা হয়েছিল। পূর্ববর্তী অ্যান্ড্রয়েড রিলিজগুলিতে এর উপস্থিতি উপেক্ষা করা হবে।

একটি MethodParameters টীকাগুলি al চ্ছিক এবং প্যারামিটার মেটাডেটা যেমন প্যারামিটারের নাম এবং সংশোধক সরবরাহ করতে ব্যবহার করা যেতে পারে।

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

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

dalvik.annotation.trows

পদ্ধতিতে প্রদর্শিত হবে

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