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

এই ডকুমেন্টটি .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 দৃষ্টান্তগুলিকে অবশ্যই একই সংজ্ঞায়িত শ্রেণির উল্লেখ করতে হবে।

encoded_field বিন্যাস

encoded_method বিন্যাস

type_list

class_def_item এবং proto_id_item থেকে উল্লেখ করা হয়েছে

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

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

type_item বিন্যাস

কোড_আইটেম

encoded_method থেকে উল্লেখ করা হয়েছে

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

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

try_item বিন্যাস

encoded_catch_handler_list বিন্যাস

encoded_catch_handler বিন্যাস

encoded_type_addr_pair বিন্যাস

ডিবাগ_তথ্য_আইটেম

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

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

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

প্রতিটি debug_info_item একটি DWARF3-অনুপ্রাণিত বাইট-কোডেড স্টেট মেশিনকে সংজ্ঞায়িত করে যা ব্যাখ্যা করা হলে, অবস্থান টেবিল এবং (সম্ভাব্যভাবে) একটি 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 কোডের জন্য প্রতিটি রেজিস্টারে শেষ স্থানীয় ভেরিয়েবলের নাম এবং প্রকার ট্র্যাক করতে হবে।

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

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

বিশেষ অপকোড

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 থেকে উল্লেখ করা হয়েছে

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

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

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

ক্ষেত্র_টীকা বিন্যাস

পদ্ধতি_টীকা বিন্যাস

প্যারামিটার_টীকা বিন্যাস

annotation_set_ref_list

প্যারামিটার_এনোটেশন_আইটেম থেকে উল্লেখ করা হয়েছে

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

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

annotation_set_ref_item বিন্যাস

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

annotations_directory_item, field_annotations_item, method_annotations_item, এবং annotation_set_ref_item থেকে উল্লেখ করা হয়েছে

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

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

টীকা_বন্ধ_আইটেম বিন্যাস

টীকা_আইটেম

annotation_set_item থেকে উল্লেখ করা হয়েছে

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

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

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

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

encoded_array_item

class_def_item থেকে উল্লেখ করা হয়েছে

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

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

hiddenapi_class_data_item

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

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

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

সিস্টেম টীকা

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

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

ডালভিক.টীকা.টিকা ডিফল্ট

টীকা ইন্টারফেসে পদ্ধতিতে উপস্থিত হয়

একটি AnnotationDefault টীকা প্রতিটি টীকা ইন্টারফেসের সাথে সংযুক্ত থাকে যা ডিফল্ট বাঁধাই নির্দেশ করতে চায়।

dalvik.annotation.EnclosingClass

ক্লাসে হাজির হয়

একটি EnclosingClass টীকা প্রতিটি ক্লাসের সাথে সংযুক্ত থাকে যা হয় অন্য শ্রেণীর সদস্য হিসাবে সংজ্ঞায়িত করা হয়, প্রতি সে, অথবা বেনামী কিন্তু একটি পদ্ধতি বডির মধ্যে সংজ্ঞায়িত করা হয় না (যেমন, একটি সিন্থেটিক অভ্যন্তরীণ শ্রেণী)। এই টীকাটি আছে এমন প্রতিটি শ্রেণীতে অবশ্যই একটি InnerClass টীকা থাকতে হবে। উপরন্তু, একটি ক্লাসে একটি EnclosingClass এবং একটি EnclosingMethod টীকা উভয়ই থাকতে হবে না।

dalvik.annotation. Enclosing Method

ক্লাসে হাজির হয়

একটি EnclosingMethod টীকা প্রতিটি ক্লাসের সাথে সংযুক্ত থাকে যা একটি মেথড বডির ভিতরে সংজ্ঞায়িত করা হয়। এই টীকাটি আছে এমন প্রতিটি শ্রেণীতে অবশ্যই একটি InnerClass টীকা থাকতে হবে। উপরন্তু, একটি ক্লাসে একটি EnclosingClass এবং একটি EnclosingMethod টীকা উভয়ই থাকতে হবে না।

dalvik.annotation.InnerClass

ক্লাসে হাজির হয়

একটি InnerClass টীকা প্রতিটি শ্রেণীর সাথে সংযুক্ত থাকে যা অন্য শ্রেণীর সংজ্ঞার আভিধানিক সুযোগে সংজ্ঞায়িত করা হয়। এই টীকাটি আছে এমন যেকোন শ্রেণীতে অবশ্যই একটি EnclosingClass টীকা বা একটি EnclosingMethod টীকা থাকতে হবে।

ডালভিক.টীকা.মেম্বারক্লাস

ক্লাসে হাজির হয়

একটি MemberClasses টীকা প্রতিটি ক্লাসের সাথে সংযুক্ত থাকে যা সদস্য ক্লাস ঘোষণা করে। (একটি সদস্য শ্রেণী হল একটি সরাসরি অভ্যন্তরীণ শ্রেণী যার একটি নাম রয়েছে।)

dalvik.annotation.Method Parameters

পদ্ধতিতে উপস্থিত হয়

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

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

রানটাইমে প্যারামিটার মেটাডেটা প্রয়োজন না হলে একটি পদ্ধতি বা কনস্ট্রাক্টর থেকে টীকাটি নিরাপদে বাদ দেওয়া যেতে পারে। java.lang.reflect.Parameter.isNamePresent() একটি প্যারামিটারের জন্য মেটাডেটা উপস্থিত আছে কিনা তা পরীক্ষা করতে ব্যবহার করা যেতে পারে এবং সংশ্লিষ্ট প্রতিফলন পদ্ধতি যেমন java.lang.reflect.Parameter.getName() রানটাইমে ডিফল্ট আচরণে ফিরে আসবে। যদি তথ্য উপস্থিত না থাকে।

প্যারামিটার মেটাডেটা অন্তর্ভুক্ত করার সময়, কম্পাইলারদের অবশ্যই জেনারেট করা ক্লাসগুলির জন্য তথ্য অন্তর্ভুক্ত করতে হবে যেমন enums, যেহেতু প্যারামিটার মেটাডেটা একটি প্যারামিটার সিন্থেটিক বা বাধ্যতামূলক কিনা তা অন্তর্ভুক্ত করে।

একটি 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 টাইপ টীকা রিসিভার প্যারামিটার সম্পর্কে কোনো তথ্য অন্তর্ভুক্ত করবে না যা প্রকৃত পদ্ধতি স্বাক্ষরে বিদ্যমান নেই।

ডালভিক।টীকা।স্বাক্ষর

ক্লাস, ক্ষেত্র এবং পদ্ধতিতে উপস্থিত হয়

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

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

ডালভিক.টীকা.নিক্ষেপ

পদ্ধতিতে উপস্থিত হয়

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