APEX ফাইল ফরম্যাট

অ্যান্ড্রয়েড পনি এক্সপ্রেস (এপেক্স) কন্টেইনার ফর্ম্যাটটি অ্যান্ড্রয়েড ১০-এ চালু করা হয়েছিল এবং এটি নিম্ন-স্তরের সিস্টেম মডিউলগুলির ইনস্টল ফ্লোতে ব্যবহৃত হয়। এই ফর্ম্যাটটি স্ট্যান্ডার্ড অ্যান্ড্রয়েড অ্যাপ্লিকেশন মডেলের সাথে খাপ খায় না এমন সিস্টেম উপাদানগুলির আপডেটগুলিকে সহজতর করে। কিছু উদাহরণ উপাদান হল নেটিভ পরিষেবা এবং লাইব্রেরি, হার্ডওয়্যার অ্যাবস্ট্রাকশন স্তর ( HALs ), রানটাইম ( ART ), এবং ক্লাস লাইব্রেরি।

"APEX" শব্দটি একটি APEX ফাইলকেও বোঝাতে পারে।

পটভূমি

যদিও অ্যান্ড্রয়েড প্যাকেজ ইনস্টলার অ্যাপের (যেমন গুগল প্লে স্টোর অ্যাপ) মাধ্যমে স্ট্যান্ডার্ড অ্যাপ মডেলের (যেমন পরিষেবা, কার্যকলাপ) সাথে মানানসই মডিউলের আপডেট সমর্থন করে, নিম্ন-স্তরের OS উপাদানগুলির জন্য একই মডেল ব্যবহার করার নিম্নলিখিত অসুবিধাগুলি রয়েছে:

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

ডিজাইন

এই বিভাগটি APEX ফাইল ফর্ম্যাটের উচ্চ-স্তরের নকশা এবং APEX ম্যানেজার বর্ণনা করে, যা একটি পরিষেবা যা APEX ফাইল পরিচালনা করে।

APEX-এর জন্য এই নকশাটি কেন নির্বাচন করা হয়েছিল সে সম্পর্কে আরও তথ্যের জন্য, APEX তৈরি করার সময় বিবেচনা করা বিকল্পগুলি দেখুন।

APEX ফর্ম্যাট

এটি একটি APEX ফাইলের ফর্ম্যাট।

APEX ফাইল ফর্ম্যাট

চিত্র ১. APEX ফাইল ফরম্যাট

শীর্ষ স্তরে, একটি APEX ফাইল হল একটি জিপ ফাইল যেখানে ফাইলগুলি সংকুচিত না করে সংরক্ষণ করা হয় এবং 4 KB সীমানায় অবস্থিত।

একটি APEX ফাইলের চারটি ফাইল হল:

  • apex_manifest.json
  • AndroidManifest.xml
  • apex_payload.img
  • apex_pubkey

apex_manifest.json ফাইলটিতে প্যাকেজের নাম এবং সংস্করণ রয়েছে, যা একটি APEX ফাইলকে শনাক্ত করে। এটি JSON ফর্ম্যাটে একটি ApexManifest প্রোটোকল বাফার।

AndroidManifest.xml ফাইলটি APEX ফাইলটিকে APK-সম্পর্কিত টুল এবং অবকাঠামো যেমন ADB, PackageManager এবং প্যাকেজ ইনস্টলার অ্যাপ (যেমন Play Store) ব্যবহার করার অনুমতি দেয়। উদাহরণস্বরূপ, APEX ফাইলটি ফাইল থেকে মৌলিক মেটাডেটা পরীক্ষা করার জন্য aapt এর মতো একটি বিদ্যমান টুল ব্যবহার করতে পারে। ফাইলটিতে প্যাকেজের নাম এবং সংস্করণের তথ্য থাকে। এই তথ্য সাধারণত apex_manifest.json এও পাওয়া যায়।

APEX-এর সাথে সম্পর্কিত নতুন কোড এবং সিস্টেমের জন্য AndroidManifest.xml এর পরিবর্তে apex_manifest.json ব্যবহার করার পরামর্শ দেওয়া হচ্ছে। AndroidManifest.xml অতিরিক্ত টার্গেটিং তথ্য থাকতে পারে যা বিদ্যমান অ্যাপ প্রকাশনা সরঞ্জামগুলি ব্যবহার করতে পারে।

apex_payload.img হল একটি ext4 ফাইল সিস্টেম ইমেজ যা dm-verity দ্বারা সমর্থিত। ছবিটি রানটাইমে একটি লুপব্যাক ডিভাইসের মাধ্যমে মাউন্ট করা হয়। বিশেষ করে, হ্যাশ ট্রি এবং মেটাডেটা ব্লক libavb লাইব্রেরি ব্যবহার করে তৈরি করা হয়। ফাইল সিস্টেম পেলোড পার্স করা হয় না (কারণ ছবিটি জায়গায় মাউন্ট করা উচিত)। নিয়মিত ফাইলগুলি apex_payload.img ফাইলের ভিতরে অন্তর্ভুক্ত করা হয়।

apex_pubkey হল ফাইল সিস্টেম ইমেজ সাইন করার জন্য ব্যবহৃত পাবলিক কী। রানটাইমের সময়, এই কী নিশ্চিত করে যে ডাউনলোড করা APEX একই সত্তার সাথে সাইন করা আছে যা বিল্ট-ইন পার্টিশনে একই APEX সাইন করে।

APEX নামকরণের নির্দেশিকা

প্ল্যাটফর্মটি এগিয়ে যাওয়ার সাথে সাথে নতুন APEX গুলির মধ্যে নামকরণের দ্বন্দ্ব রোধ করতে, নিম্নলিখিত নামকরণ নির্দেশিকাগুলি ব্যবহার করুন:

  • com.android.*
    • AOSP APEX-এর জন্য সংরক্ষিত। কোনও কোম্পানি বা ডিভাইসের জন্য অনন্য নয়।
  • com.<companyname>.*
    • একটি কোম্পানির জন্য সংরক্ষিত। সম্ভাব্যভাবে সেই কোম্পানির একাধিক ডিভাইস দ্বারা ব্যবহৃত হতে পারে।
  • com.<companyname>.<devicename>.*
    • নির্দিষ্ট ডিভাইসের (অথবা ডিভাইসের উপসেট) অনন্য APEX-এর জন্য সংরক্ষিত।

APEX ম্যানেজার

APEX ম্যানেজার (অথবা apexd ) হল একটি স্বতন্ত্র নেটিভ প্রক্রিয়া যা APEX ফাইল যাচাই, ইনস্টল এবং আনইনস্টল করার জন্য দায়ী। এই প্রক্রিয়াটি শুরু হয় এবং বুট ক্রমের প্রথম দিকে প্রস্তুত থাকে। APEX ফাইলগুলি সাধারণত /system/apex এর অধীনে ডিভাইসে আগে থেকে ইনস্টল করা থাকে। যদি কোনও আপডেট উপলব্ধ না থাকে তবে APEX ম্যানেজার ডিফল্টভাবে এই প্যাকেজগুলি ব্যবহার করে।

একটি APEX এর আপডেট ক্রম প্যাকেজম্যানেজার ক্লাস ব্যবহার করে এবং নিম্নরূপ।

  1. একটি APEX ফাইল একটি প্যাকেজ ইনস্টলার অ্যাপ, ADB, অথবা অন্য কোন উৎসের মাধ্যমে ডাউনলোড করা হয়।
  2. প্যাকেজ ম্যানেজার ইনস্টলেশন প্রক্রিয়া শুরু করে। ফাইলটি একটি APEX তা স্বীকৃতি দেওয়ার পরে, প্যাকেজ ম্যানেজার নিয়ন্ত্রণ APEX ম্যানেজারের কাছে হস্তান্তর করে।
  3. APEX ম্যানেজার APEX ফাইলটি যাচাই করে।
  4. যদি APEX ফাইলটি যাচাই করা হয়, তাহলে APEX ম্যানেজারের অভ্যন্তরীণ ডাটাবেস আপডেট করা হয় যাতে দেখা যায় যে পরবর্তী বুটে APEX ফাইলটি সক্রিয় হয়েছে।
  5. সফল প্যাকেজ যাচাইকরণের পরে ইনস্টল অনুরোধকারী একটি সম্প্রচার পান।
  6. ইনস্টলেশন চালিয়ে যেতে, সিস্টেমটি পুনরায় বুট করতে হবে।

  7. পরবর্তী বুটে, APEX ম্যানেজার শুরু করে, অভ্যন্তরীণ ডাটাবেস পড়ে এবং তালিকাভুক্ত প্রতিটি APEX ফাইলের জন্য নিম্নলিখিত কাজ করে:

    1. APEX ফাইল যাচাই করে।
    2. APEX ফাইল থেকে একটি লুপব্যাক ডিভাইস তৈরি করে।
    3. লুপব্যাক ডিভাইসের উপরে একটি ডিভাইস ম্যাপার ব্লক ডিভাইস তৈরি করে।
    4. ডিভাইস ম্যাপার ব্লক ডিভাইসটিকে একটি অনন্য পাথে মাউন্ট করে (উদাহরণস্বরূপ, /apex/ name @ ver )।

যখন অভ্যন্তরীণ ডাটাবেসে তালিকাভুক্ত সমস্ত APEX ফাইল মাউন্ট করা হয়, তখন APEX ম্যানেজার অন্যান্য সিস্টেম উপাদানগুলিকে ইনস্টল করা APEX ফাইল সম্পর্কে তথ্য অনুসন্ধানের জন্য একটি বাইন্ডার পরিষেবা প্রদান করে। উদাহরণস্বরূপ, অন্যান্য সিস্টেম উপাদানগুলি ডিভাইসে ইনস্টল করা APEX ফাইলগুলির তালিকা অনুসন্ধান করতে পারে অথবা একটি নির্দিষ্ট APEX কোথায় মাউন্ট করা হয়েছে তা সঠিক পথ অনুসন্ধান করতে পারে, যাতে ফাইলগুলি অ্যাক্সেস করা যায়।

APEX ফাইলগুলি হল APK ফাইল

APEX ফাইলগুলি বৈধ APK ফাইল কারণ এগুলি স্বাক্ষরিত জিপ আর্কাইভ (APK স্বাক্ষর স্কিম ব্যবহার করে) যার মধ্যে একটি AndroidManifest.xml ফাইল রয়েছে। এটি APEX ফাইলগুলিকে APK ফাইলগুলির জন্য পরিকাঠামো ব্যবহার করার অনুমতি দেয়, যেমন একটি প্যাকেজ ইনস্টলার অ্যাপ, স্বাক্ষরকারী ইউটিলিটি এবং প্যাকেজ ম্যানেজার।

একটি APEX ফাইলের ভিতরে থাকা AndroidManifest.xml ফাইলটি ন্যূনতম, যার মধ্যে প্যাকেজের name , versionCode , এবং ঐচ্ছিক targetSdkVersion , minSdkVersion , এবং maxSdkVersion থাকে যা সূক্ষ্মভাবে লক্ষ্য করার জন্য তৈরি করা হয়। এই তথ্য APEX ফাইলগুলিকে প্যাকেজ ইনস্টলার অ্যাপ এবং ADB এর মতো বিদ্যমান চ্যানেলের মাধ্যমে বিতরণ করার অনুমতি দেয়।

ফাইলের ধরণ সমর্থিত

APEX ফর্ম্যাট এই ধরণের ফাইল সমর্থন করে:

  • নেটিভ শেয়ার্ড লিবস
  • নেটিভ এক্সিকিউটেবল
  • JAR ফাইল
  • ডেটা ফাইল
  • কনফিগ ফাইল

এর মানে এই নয় যে APEX এই সকল ফাইল টাইপ আপডেট করতে পারবে। কোন ফাইল টাইপ আপডেট করা যাবে কিনা তা নির্ভর করে প্ল্যাটফর্মের উপর এবং ফাইল টাইপের ইন্টারফেসের সংজ্ঞা কতটা স্থিতিশীল তার উপর।

স্বাক্ষরের বিকল্পগুলি

APEX ফাইল দুটি উপায়ে স্বাক্ষরিত হয়। প্রথমে, apex_payload.img (বিশেষ করে, apex_payload.img এর সাথে সংযুক্ত vbmeta বর্ণনাকারী) ফাইলটি একটি কী দিয়ে স্বাক্ষরিত হয়। তারপর, APK স্বাক্ষর স্কিম v3 ব্যবহার করে সম্পূর্ণ APEX স্বাক্ষরিত হয়। এই প্রক্রিয়ায় দুটি ভিন্ন কী ব্যবহার করা হয়।

ডিভাইসের পাশে, vbmeta বর্ণনাকারী স্বাক্ষর করার জন্য ব্যবহৃত প্রাইভেট কী-এর সাথে সম্পর্কিত একটি পাবলিক কী ইনস্টল করা আছে। APEX ম্যানেজার ইনস্টল করার জন্য অনুরোধ করা APEX গুলি যাচাই করার জন্য পাবলিক কী ব্যবহার করে। প্রতিটি APEX-কে আলাদা আলাদা কী দিয়ে স্বাক্ষর করতে হবে এবং বিল্ড সময় এবং রানটাইম উভয় সময়েই প্রয়োগ করা হয়।

অন্তর্নির্মিত পার্টিশনে APEX

APEX ফাইলগুলি /system এর মতো বিল্ট-ইন পার্টিশনে অবস্থিত হতে পারে। পার্টিশনটি ইতিমধ্যেই dm-verity এর উপরে রয়েছে, তাই APEX ফাইলগুলি সরাসরি লুপব্যাক ডিভাইসের উপরে মাউন্ট করা হয়।

যদি একটি APEX একটি বিল্ট-ইন পার্টিশনে উপস্থিত থাকে, তাহলে একই প্যাকেজ নামের এবং এর চেয়ে বড় বা সমান সংস্করণ কোড সহ একটি APEX প্যাকেজ প্রদান করে APEX আপডেট করা যেতে পারে। নতুন APEX /data তে সংরক্ষণ করা হয় এবং APK-এর মতো, নতুন ইনস্টল করা সংস্করণটি বিল্ট-ইন পার্টিশনে ইতিমধ্যে উপস্থিত সংস্করণটিকে ছায়া দেয়। কিন্তু APK-এর বিপরীতে, APEX-এর নতুন ইনস্টল করা সংস্করণটি কেবল রিবুট করার পরেই সক্রিয় হয়।

কার্নেলের প্রয়োজনীয়তা

একটি অ্যান্ড্রয়েড ডিভাইসে APEX মেইনলাইন মডিউল সমর্থন করার জন্য, নিম্নলিখিত লিনাক্স কার্নেল বৈশিষ্ট্যগুলি প্রয়োজন: লুপব্যাক ড্রাইভার এবং dm-verity। লুপব্যাক ড্রাইভার একটি APEX মডিউলে ফাইল সিস্টেম ইমেজ মাউন্ট করে এবং dm-verity APEX মডিউল যাচাই করে।

APEX মডিউল ব্যবহার করার সময় ভালো সিস্টেম কর্মক্ষমতা অর্জনের জন্য লুপব্যাক ড্রাইভার এবং dm-verity-এর কর্মক্ষমতা গুরুত্বপূর্ণ।

সমর্থিত কার্নেল সংস্করণ

APEX মেইনলাইন মডিউলগুলি কার্নেল সংস্করণ 4.4 বা উচ্চতর ব্যবহারকারী ডিভাইসগুলিতে সমর্থিত। Android 10 বা উচ্চতর সংস্করণের সাথে লঞ্চ হওয়া নতুন ডিভাইসগুলিকে APEX মডিউলগুলি সমর্থন করার জন্য কার্নেল সংস্করণ 4.9 বা উচ্চতর ব্যবহার করতে হবে।

প্রয়োজনীয় কার্নেল প্যাচ

APEX মডিউল সমর্থন করার জন্য প্রয়োজনীয় কার্নেল প্যাচগুলি Android common tree-তে অন্তর্ভুক্ত করা হয়েছে। APEX সমর্থন করার জন্য প্যাচগুলি পেতে, Android common tree-এর সর্বশেষ সংস্করণটি ব্যবহার করুন।

কার্নেল সংস্করণ ৪.৪

এই সংস্করণটি শুধুমাত্র সেই ডিভাইসগুলির জন্য সমর্থিত যেগুলি Android 9 থেকে Android 10 এ আপগ্রেড করা হয়েছে এবং APEX মডিউলগুলি সমর্থন করতে চায়। প্রয়োজনীয় প্যাচগুলি পেতে, android-4.4 শাখা থেকে ডাউন-মার্জ করার পরামর্শ দেওয়া হচ্ছে। কার্নেল সংস্করণ 4.4 এর জন্য প্রয়োজনীয় পৃথক প্যাচগুলির একটি তালিকা নীচে দেওয়া হল।

  • UPSTREAM: লুপ: লজিক্যাল ব্লকের আকার পরিবর্তন করার জন্য ioctl যোগ করুন ( 4.4 )
  • ব্যাকপোর্ট: ব্লক/লুপ: hw_sectors সেট করুন ( 4.4 )
  • UPSTREAM: লুপ: compat ioctl ( 4.4 ) এ LOOP_SET_BLOCK_SIZE যোগ করুন
  • অ্যান্ড্রয়েড: mnt: next_descendent ঠিক করুন ( 4.4 )
  • ANDROID: mnt: রিমাউন্ট ক্রীতদাসদের ক্রীতদাসদের কাছে প্রচারিত হওয়া উচিত ( 4.4 )
  • ANDROID: mnt: সঠিকভাবে রিমাউন্ট প্রচার করুন ( 4.4 )
  • "ANDROID: dm verity: ন্যূনতম প্রিফেচ আকার যোগ করুন" ( 4.4 ) পূর্বাবস্থায় ফেরান
  • UPSTREAM: লুপ: অফসেট বা ব্লক_সাইজ পরিবর্তন করা হলে ক্যাশে ড্রপ করুন ( 4.4 )

কার্নেল সংস্করণ 4.9/4.14/4.19

কার্নেল সংস্করণ 4.9/4.14/4.19 এর জন্য প্রয়োজনীয় প্যাচগুলি পেতে, android-common শাখা থেকে ডাউন-মার্জ করুন।

প্রয়োজনীয় কার্নেল কনফিগারেশন বিকল্পগুলি

নিম্নলিখিত তালিকাটি Android 10-এ প্রবর্তিত APEX মডিউলগুলিকে সমর্থন করার জন্য বেসিক কনফিগারেশন প্রয়োজনীয়তাগুলি দেখায়। তারকাচিহ্ন (*) সহ আইটেমগুলি Android 9 এবং তার নিচের সংস্করণগুলির জন্য বিদ্যমান প্রয়োজনীয়তা।

(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support

কার্নেল কমান্ড-লাইন প্যারামিটারের প্রয়োজনীয়তা

APEX সমর্থন করার জন্য, নিশ্চিত করুন যে কার্নেল কমান্ড-লাইন প্যারামিটারগুলি নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করে:

  • loop.max_loop সেট করা উচিত নয়
  • loop.max_part অবশ্যই <= 8 হতে হবে

একটি APEX তৈরি করুন

এই বিভাগে Android বিল্ড সিস্টেম ব্যবহার করে কীভাবে একটি APEX তৈরি করবেন তা বর্ণনা করা হয়েছে। apex.test নামের একটি APEX-এর জন্য Android.bp এর একটি উদাহরণ নিচে দেওয়া হল।

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    // libc.so and libcutils.so are included in the apex
    native_shared_libs: ["libc", "libcutils"],
    binaries: ["vold"],
    java_libs: ["core-all"],
    prebuilts: ["my_prebuilt"],
    compile_multilib: "both",
    key: "apex.test.key",
    certificate: "platform",
}

apex_manifest.json উদাহরণ:

{
  "name": "com.android.example.apex",
  "version": 1
}

file_contexts উদাহরণ:

(/.*)?           u:object_r:system_file:s0
/sub(/.*)?       u:object_r:sub_file:s0
/sub/file3       u:object_r:file3_file:s0

APEX-এ ফাইলের ধরণ এবং অবস্থান

ফাইলের ধরণ APEX-এ অবস্থান
শেয়ার করা লাইব্রেরি /lib এবং /lib64 ( x86 তে অনুবাদিত arm-এর জন্য /lib/arm )
এক্সিকিউটেবল /bin
জাভা লাইব্রেরি /javalib
পূর্বনির্মাণ /etc

ট্রানজিটিভ নির্ভরতা

APEX ফাইলগুলিতে স্বয়ংক্রিয়ভাবে নেটিভ শেয়ার্ড libs বা এক্সিকিউটেবলের ট্রানজিটিভ নির্ভরতা অন্তর্ভুক্ত থাকে। উদাহরণস্বরূপ, যদি libFoo libBar এর উপর নির্ভর করে, তাহলে native_shared_libs প্রোপার্টিতে শুধুমাত্র libFoo তালিকাভুক্ত থাকলে দুটি libs অন্তর্ভুক্ত করা হয়।

একাধিক ABI পরিচালনা করুন

ডিভাইসের প্রাথমিক এবং মাধ্যমিক অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABIs) উভয়ের জন্য native_shared_libs বৈশিষ্ট্যটি ইনস্টল করুন। যদি একটি APEX একটি একক ABI (অর্থাৎ, শুধুমাত্র 32 বিট বা শুধুমাত্র 64 বিট) সহ ডিভাইসগুলিকে লক্ষ্য করে, তবে কেবলমাত্র সংশ্লিষ্ট ABI সহ লাইব্রেরিগুলি ইনস্টল করা হবে।

নীচে বর্ণিত পদ্ধতি অনুসারে শুধুমাত্র ডিভাইসের প্রাথমিক ABI-এর জন্য binaries বৈশিষ্ট্যটি ইনস্টল করুন:

  • যদি ডিভাইসটি শুধুমাত্র ৩২ বিটের হয়, তাহলে শুধুমাত্র ৩২-বিট ভেরিয়েন্টের বাইনারিটি ইনস্টল করা হবে।
  • যদি ডিভাইসটি শুধুমাত্র ৬৪ বিট হয়, তাহলে শুধুমাত্র বাইনারিটির ৬৪-বিট ভেরিয়েন্টটি ইনস্টল করা হবে।

নেটিভ লাইব্রেরি এবং বাইনারিগুলির ABI-এর উপর সূক্ষ্ম নিয়ন্ত্রণ যোগ করতে, multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] বৈশিষ্ট্য ব্যবহার করুন।

  • first : ডিভাইসের প্রাথমিক ABI এর সাথে মেলে। এটি বাইনারিগুলির জন্য ডিফল্ট।
  • lib32 : যদি সমর্থিত হয়, তাহলে ডিভাইসের 32-বিট ABI এর সাথে মেলে।
  • lib64 : এটি সমর্থিত ডিভাইসের 64-বিট ABI এর সাথে মেলে।
  • prefer32 : যদি সমর্থিত হয়, তাহলে ডিভাইসের 32-বিট ABI এর সাথে মেলে। যদি 32-বিট ABI সমর্থিত না হয়, তাহলে 64-বিট ABI এর সাথে মেলে।
  • both : উভয় ABI-এর সাথে মিলে যায়। এটি native_shared_libraries জন্য ডিফল্ট।

java , libraries এবং prebuilts বৈশিষ্ট্যগুলি ABI-অজ্ঞেয়বাদী।

এই উদাহরণটি এমন একটি ডিভাইসের জন্য যা 32/64 সমর্থন করে এবং 32 পছন্দ করে না:

apex {
    // other properties are omitted
    native_shared_libs: ["libFoo"], // installed for 32 and 64
    binaries: ["exec1"], // installed for 64, but not for 32
    multilib: {
        first: {
            native_shared_libs: ["libBar"], // installed for 64, but not for 32
            binaries: ["exec2"], // same as binaries without multilib.first
        },
        both: {
            native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
            binaries: ["exec3"], // installed for 32 and 64
        },
        prefer32: {
            native_shared_libs: ["libX"], // installed for 32, but not for 64
        },
        lib64: {
            native_shared_libs: ["libY"], // installed for 64, but not for 32
        },
    },
}

vbmeta স্বাক্ষর

প্রতিটি APEX-এ আলাদা আলাদা কী দিয়ে সাইন ইন করুন। যখন একটি নতুন কী প্রয়োজন হয়, তখন একটি পাবলিক-প্রাইভেট কী জোড়া তৈরি করুন এবং একটি apex_key মডিউল তৈরি করুন। কী ব্যবহার করে APEX সাইন ইন করতে key প্রোপার্টি ব্যবহার করুন। পাবলিক কীটি স্বয়ংক্রিয়ভাবে avb_pubkey নামে APEX-এ অন্তর্ভুক্ত হয়ে যায়।

# create an rsa key pair
openssl genrsa -out foo.pem 4096

# extract the public key from the key pair
avbtool extract_public_key --key foo.pem --output foo.avbpubkey

# in Android.bp
apex_key {
    name: "apex.test.key",
    public_key: "foo.avbpubkey",
    private_key: "foo.pem",
}

উপরের উদাহরণে, পাবলিক কী ( foo ) এর নামটি কীটির আইডি হয়ে যায়। একটি APEX সাইন করার জন্য ব্যবহৃত কীটির আইডি APEX-তে লেখা থাকে। রানটাইমে, apexd ডিভাইসে একই আইডি সহ একটি পাবলিক কী ব্যবহার করে APEX যাচাই করে।

APEX স্বাক্ষর

APK গুলিতে স্বাক্ষর করার মতোই APEX গুলিতে স্বাক্ষর করুন। APEX গুলিতে দুবার স্বাক্ষর করুন; একবার মিনি ফাইল সিস্টেমের জন্য ( apex_payload.img ফাইল) এবং একবার পুরো ফাইলের জন্য।

ফাইল-স্তরে একটি APEX সাইন করতে, এই তিনটি উপায়ের একটিতে certificate বৈশিষ্ট্য সেট করুন:

  • সেট করা নেই: যদি কোনও মান সেট করা না থাকে, তাহলে APEX PRODUCT_DEFAULT_DEV_CERTIFICATE এ অবস্থিত সার্টিফিকেট দিয়ে স্বাক্ষরিত হয়। যদি কোনও পতাকা সেট করা না থাকে, তাহলে পাথটি ডিফল্টভাবে build/target/product/security/testkey এ চলে।
  • <name> : APEX PRODUCT_DEFAULT_DEV_CERTIFICATE এর মতো একই ডিরেক্টরিতে <name> সার্টিফিকেট দিয়ে স্বাক্ষরিত।
  • :<name> : APEX একটি সার্টিফিকেট দিয়ে স্বাক্ষরিত যা <name> নামক Soong মডিউল দ্বারা সংজ্ঞায়িত করা হয়েছে। সার্টিফিকেট মডিউলটি নিম্নরূপ সংজ্ঞায়িত করা যেতে পারে। 
android_app_certificate {
    name: "my_key_name",
    certificate: "dir/cert",
    // this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}

কী ব্যবস্থাপনা

ডেভেলপমেন্ট বিল্ডের জন্য টেস্ট কী ব্যবহার করা হয়, আর রিলিজ কী ব্যবহার করা হয় পাবলিক বিল্ড সাইন করার জন্য। APEX সাইনিং কী রিপ্লেসমেন্টে বর্ণিত হিসাবে, পাবলিক রিলিজের আগে সমস্ত টেস্ট কী সংশ্লিষ্ট রিলিজ কী দিয়ে প্রতিস্থাপন করতে হবে। OEM বিল্ড সার্ভারগুলি sign_target_files_apks হোস্ট টুলকে একীভূত করতে পারে, যা একটি টার্গেট-ফাইলস জিপ আর্কাইভের মধ্যে পাওয়া সমস্ত APEX ফাইলের জন্য ফাইল সিস্টেম ইমেজ এবং সম্পূর্ণ APEX ফাইল উভয়কেই পুনরায় সাইন করে।

নিরাপত্তার জন্য, কী ব্যবস্থাপনা এবং রিলিজ স্বাক্ষর কার্যক্রমের জন্য নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি মেনে চলা অত্যন্ত গুরুত্বপূর্ণ:

  • রিলিজ কীগুলিতে অ্যাক্সেস সীমিত করার জন্য একটি নিরাপদ পরিবেশে রাখুন।

  • একটি ACL-কে অবশ্যই মুক্তি স্বাক্ষর কার্যক্রমের সূচনা নিয়ন্ত্রণ করতে হবে।

  • মুক্তির জন্য পরীক্ষা এবং প্রত্যয়িত হওয়ার পরেই কেবল মুক্তির চাবি দিয়ে শিল্পকর্মগুলিতে স্বাক্ষর করুন।

  • একজন ব্যক্তিকে অবশ্যই রিলিজ সাইনিং অ্যাকশন শুরু করতে হবে; এই প্রক্রিয়াটি স্বয়ংক্রিয় করবেন না।

  • রিলিজ-কী-স্বাক্ষরিত শিল্পকর্মগুলি অবশ্যই একটি নিরাপদ পরিবেশে সংরক্ষণ করা উচিত।

  • রিলিজ-কী-স্বাক্ষরিত শিল্পকর্মগুলিতে অ্যাক্সেস বৈধ ব্যবসায়িক কারণে সীমাবদ্ধ থাকতে হবে।

  • OEM বিল্ড সার্ভারকে অবশ্যই প্রতিটি স্বাক্ষর অনুরোধের রেকর্ড একটি স্বাক্ষরকারী ডাটাবেসে রাখতে হবে।

একটি APEX ইনস্টল করুন

একটি APEX ইনস্টল করতে, ADB ব্যবহার করুন।

adb install apex_file_name
adb reboot

যদি supportsRebootlessUpdate apex_manifest.json এ true তে সেট করা থাকে এবং বর্তমানে ইনস্টল করা APEX অব্যবহৃত থাকে (উদাহরণস্বরূপ, এতে থাকা যেকোনো পরিষেবা বন্ধ করে দেওয়া হয়েছে), তাহলে --force-non-staged ফ্ল্যাগ ব্যবহার করে রিবুট ছাড়াই একটি নতুন APEX ইনস্টল করা যেতে পারে।

adb install --force-non-staged apex_file_name

একটি APEX ব্যবহার করুন

রিবুট করার পর, APEX /apex/<apex_name>@<version> ডিরেক্টরিতে মাউন্ট করা হয়। একই APEX এর একাধিক সংস্করণ একই সময়ে মাউন্ট করা যেতে পারে। মাউন্ট পাথগুলির মধ্যে, সর্বশেষ সংস্করণের সাথে সম্পর্কিত একটি হল /apex/<apex_name> এ বাইন্ড-মাউন্ট করা।

ক্লায়েন্টরা APEX থেকে ফাইলগুলি পড়তে বা চালানোর জন্য বাইন্ড-মাউন্ট করা পথ ব্যবহার করতে পারে।

APEX সাধারণত নিম্নরূপ ব্যবহৃত হয়:

  1. ডিভাইসটি পাঠানোর সময় একটি OEM বা ODM /system/apex অধীনে একটি APEX প্রিলোড করে।
  2. APEX-এর ফাইলগুলি /apex/<apex_name>/ পাথের মাধ্যমে অ্যাক্সেস করা হয়।
  3. যখন APEX এর একটি আপডেটেড সংস্করণ /data/apex এ ইনস্টল করা হয়, তখন রিবুট করার পরে পথটি নতুন APEX এর দিকে নির্দেশ করে।

একটি APEX দিয়ে একটি পরিষেবা আপডেট করুন

APEX ব্যবহার করে কোনও পরিষেবা আপডেট করতে:

  1. সিস্টেম পার্টিশনে পরিষেবাটিকে আপডেটযোগ্য হিসেবে চিহ্নিত করুন। পরিষেবার সংজ্ঞায় updatable বিকল্পটি যোগ করুন। 

    /system/etc/init/myservice.rc:

service myservice /system/bin/myservice
    class core
    user system
    ...
    updatable

  2. আপডেট করা পরিষেবার জন্য একটি নতুন .rc ফাইল তৈরি করুন। বিদ্যমান পরিষেবাটি পুনরায় সংজ্ঞায়িত করতে override বিকল্পটি ব্যবহার করুন। 

    /apex/my.apex/etc/init.rc:

service myservice /apex/my.apex/bin/myservice
    class core
    user system
    ...
    override

পরিষেবার সংজ্ঞা শুধুমাত্র একটি APEX এর .rc ফাইলেই সংজ্ঞায়িত করা যেতে পারে। APEX তে অ্যাকশন ট্রিগার সমর্থিত নয়।

যদি আপডেটযোগ্য হিসেবে চিহ্নিত কোনও পরিষেবা APEX সক্রিয় করার আগে শুরু হয়, তাহলে APEX সক্রিয়করণ সম্পূর্ণ না হওয়া পর্যন্ত শুরু বিলম্বিত হয়।

APEX আপডেট সমর্থন করার জন্য সিস্টেম কনফিগার করুন

APEX ফাইল আপডেট সমর্থন করার জন্য নিম্নলিখিত সিস্টেম বৈশিষ্ট্যটিকে true সেট করুন। 

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

অথবা শুধু 

<device.mk>:

$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)

সমতল APEX

লিগ্যাসি ডিভাইসের ক্ষেত্রে, কখনও কখনও APEX কে সম্পূর্ণরূপে সমর্থন করার জন্য পুরানো কার্নেল আপডেট করা অসম্ভব বা অসম্ভব। উদাহরণস্বরূপ, কার্নেলটি CONFIG_BLK_DEV_LOOP=Y ছাড়াই তৈরি করা হতে পারে, যা APEX এর ভিতরে ফাইল সিস্টেম ইমেজ মাউন্ট করার জন্য অত্যন্ত গুরুত্বপূর্ণ।

Flattened APEX হল একটি বিশেষভাবে নির্মিত APEX যা একটি লিগ্যাসি কার্নেলযুক্ত ডিভাইসে সক্রিয় করা যেতে পারে। একটি flattened APEX-এর ফাইলগুলি সরাসরি বিল্ট-ইন পার্টিশনের অধীনে একটি ডিরেক্টরিতে ইনস্টল করা হয়। উদাহরণস্বরূপ, lib/libFoo.so একটি flattened APEX-এ my.apex /system/apex/my.apex/lib/libFoo.so তে ইনস্টল করা হয়।

একটি ফ্ল্যাটেড APEX সক্রিয় করার জন্য লুপ ডিভাইস জড়িত নয়। সম্পূর্ণ /system/apex/my.apex ডিরেক্টরিটি সরাসরি /apex/name@ver এ বাইন্ড-মাউন্ট করা হয়।

নেটওয়ার্ক থেকে APEX-এর আপডেটেড ভার্সন ডাউনলোড করে ফ্ল্যাটেড APEX আপডেট করা যাবে না কারণ ডাউনলোড করা APEX-গুলো ফ্ল্যাটেড করা যাবে না। ফ্ল্যাটেড APEX শুধুমাত্র একটি নিয়মিত OTA-এর মাধ্যমে আপডেট করা যাবে।

ডিফল্ট কনফিগারেশন হল ফ্ল্যাটেড APEX। এর মানে হল যে সমস্ত APEX ডিফল্ট ফ্ল্যাটেড থাকে যদি না আপনি স্পষ্টভাবে আপনার ডিভাইসটিকে APEX আপডেট সমর্থন করার জন্য নন-ফ্ল্যাটেড APEX তৈরি করার জন্য কনফিগার করেন (যেমন উপরে ব্যাখ্যা করা হয়েছে)।

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

সংকুচিত অ্যাপেক্স

অ্যান্ড্রয়েড ১২ এবং উচ্চতর সংস্করণগুলিতে আপডেটযোগ্য APEX প্যাকেজের স্টোরেজ প্রভাব কমাতে APEX কম্প্রেশনের সুবিধা রয়েছে। APEX-এর আপডেট ইনস্টল করার পরে, যদিও এর আগে থেকে ইনস্টল করা সংস্করণটি আর ব্যবহার করা হয় না, তবুও এটি একই পরিমাণ জায়গা দখল করে। সেই দখলকৃত স্থানটি এখনও অনুপলব্ধ।

APEX কম্প্রেশন শুধুমাত্র পঠনযোগ্য পার্টিশনে (যেমন /system পার্টিশন) APEX ফাইলের একটি অত্যন্ত সংকুচিত সেট ব্যবহার করে এই স্টোরেজ প্রভাবকে কমিয়ে দেয়। Android 12 এবং উচ্চতর সংস্করণগুলি একটি Deflate zip কম্প্রেশন অ্যালগরিদম ব্যবহার করে।

কম্প্রেশন নিম্নলিখিতগুলিতে অপ্টিমাইজেশন প্রদান করে না:

  • বুটস্ট্র্যাপ APEX যা বুট সিকোয়েন্সের খুব শুরুতে মাউন্ট করতে হয়।

  • আপডেটযোগ্য নয় এমন APEX। /data পার্টিশনে APEX এর একটি আপডেটেড সংস্করণ ইনস্টল করা থাকলেই কেবল কম্প্রেশন উপকারী। আপডেটযোগ্য APEX এর একটি সম্পূর্ণ তালিকা মডুলার সিস্টেম কম্পোনেন্ট পৃষ্ঠায় পাওয়া যাবে।

  • ডায়নামিক শেয়ার্ড লিবস APEXes। যেহেতু apexd সর্বদা এই ধরনের APEXes-এর উভয় সংস্করণ (পূর্ব-ইনস্টল এবং আপগ্রেড) সক্রিয় করে, তাই তাদের সংকুচিত করলে কোনও মূল্য যোগ হয় না।

সংকুচিত APEX ফাইল ফর্ম্যাট

এটি একটি সংকুচিত APEX ফাইলের ফর্ম্যাট।

Diagram shows the format of a compressed APEX file

চিত্র ২। সংকুচিত APEX ফাইল ফর্ম্যাট

উপরের স্তরে, একটি সংকুচিত APEX ফাইল হল একটি জিপ ফাইল যাতে মূল অ্যাপেক্স ফাইলটি ডিফ্লেটেড আকারে থাকে যার কম্প্রেশন লেভেল 9 থাকে এবং অন্যান্য ফাইলগুলি সংকুচিত অবস্থায় সংরক্ষণ করা হয়।

চারটি ফাইলে একটি APEX ফাইল থাকে:

  • original_apex : 9 এর কম্প্রেশন লেভেল সহ ডিফ্লেটেড। এটি হল আসল, আনকম্প্রেসড APEX ফাইল ।
  • apex_manifest.pb : শুধুমাত্র সংরক্ষিত
  • AndroidManifest.xml : শুধুমাত্র সংরক্ষিত
  • apex_pubkey : শুধুমাত্র সংরক্ষিত

apex_manifest.pb , AndroidManifest.xml , এবং apex_pubkey ফাইলগুলি original_apex এ তাদের সংশ্লিষ্ট ফাইলগুলির অনুলিপি।

সংকুচিত APEX তৈরি করুন

system/apex/tools এ অবস্থিত apex_compression_tool.py টুল ব্যবহার করে কম্প্রেসড APEX তৈরি করা যেতে পারে।

বিল্ড সিস্টেমে APEX কম্প্রেশন সম্পর্কিত বেশ কিছু প্যারামিটার পাওয়া যায়।

Android.bp তে একটি APEX ফাইল সংকোচনযোগ্য কিনা তা compressible বৈশিষ্ট্য দ্বারা নিয়ন্ত্রিত হয়: 

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    compressible: true,
}

একটি PRODUCT_COMPRESSED_APEX পণ্য পতাকা নিয়ন্ত্রণ করে যে উৎস থেকে তৈরি একটি সিস্টেম ছবিতে সংকুচিত APEX ফাইল থাকতে হবে কিনা।

স্থানীয় পরীক্ষার জন্য আপনি OVERRIDE_PRODUCT_COMPRESSED_APEX= কে true এ সেট করে APEX গুলিকে সংকুচিত করতে বাধ্য করতে পারেন।

বিল্ড সিস্টেম দ্বারা তৈরি সংকুচিত APEX ফাইলগুলিতে .capex এক্সটেনশন থাকে। এই এক্সটেনশনটি APEX ফাইলের সংকুচিত এবং অসংকুচিত সংস্করণের মধ্যে পার্থক্য করা সহজ করে তোলে।

সমর্থিত কম্প্রেশন অ্যালগরিদম

অ্যান্ড্রয়েড ১২ শুধুমাত্র ডিফ্লেট জিপ কম্প্রেশন সমর্থন করে।

বুট করার সময় একটি সংকুচিত APEX ফাইল সক্রিয় করুন

একটি সংকুচিত APEX সক্রিয় করার আগে, এর ভিতরে থাকা original_apex ফাইলটি /data/apex/decompressed ডিরেক্টরিতে ডিকম্প্রেস করা হয়। ফলে ডিকম্প্রেস করা APEX ফাইলটি /data/apex/active ডিরেক্টরির সাথে হার্ড-লিঙ্ক করা হয়।

উপরে বর্ণিত প্রক্রিয়াটির একটি উদাহরণ হিসেবে নিম্নলিখিত উদাহরণটি বিবেচনা করুন।

/system/apex/com.android.foo.capex কে একটি সংকুচিত APEX হিসেবে বিবেচনা করুন, যার versionCode 37 সক্রিয় করা হচ্ছে।

  1. /system/apex/com.android.foo.capex এর ভিতরে থাকা original_apex ফাইলটি /data/apex/decompressed/com.android.foo@37.apex এ ডিকম্প্রেস করা হয়।
  2. restorecon /data/apex/decompressed/com.android.foo@37.apex এর সঠিক SELinux লেবেল আছে কিনা তা যাচাই করার জন্য এটি করা হয়।
  3. যাচাইকরণ পরীক্ষা /data/apex/decompressed/com.android.foo@37.apex এ করা হয় যাতে এর বৈধতা নিশ্চিত করা যায়: apexd /data/apex/decompressed/com.android.foo@37.apex এ বান্ডিল করা পাবলিক কীটি পরীক্ষা করে যাচাই করে যে এটি /system/apex/com.android.foo.capex এ বান্ডিল করা কী-এর সমান।
  4. /data/apex/decompressed/com.android.foo@37.apex ফাইলটি /data/apex/active/com.android.foo@37.apex ডিরেক্টরির সাথে হার্ড-লিঙ্কযুক্ত।
  5. আনকম্প্রেসড APEX ফাইলের জন্য নিয়মিত অ্যাক্টিভেশন লজিক /data/apex/active/com.android.foo@37.apex এ সঞ্চালিত হয়।

OTA এর সাথে মিথস্ক্রিয়া

সংকুচিত APEX ফাইলগুলি OTA ডেলিভারি এবং অ্যাপ্লিকেশনের উপর প্রভাব ফেলে। যেহেতু একটি OTA আপডেটে একটি সংকুচিত APEX ফাইল থাকতে পারে যার সংস্করণ স্তর ডিভাইসে সক্রিয় সংস্করণের চেয়ে উচ্চতর, তাই OTA আপডেট প্রয়োগ করার জন্য ডিভাইসটি পুনরায় বুট করার আগে একটি নির্দিষ্ট পরিমাণ খালি স্থান সংরক্ষণ করতে হবে।

OTA সিস্টেমকে সমর্থন করার জন্য, apexd এই দুটি বাইন্ডার API প্রকাশ করে:

  • calculateSizeForCompressedApex - একটি OTA প্যাকেজে APEX ফাইল ডিকম্প্রেস করার জন্য প্রয়োজনীয় আকার গণনা করে। এটি ব্যবহার করে OTA ডাউনলোড করার আগে একটি ডিভাইসে পর্যাপ্ত স্থান আছে কিনা তা যাচাই করা যেতে পারে।
  • reserveSpaceForCompressedApex - OTA প্যাকেজের ভিতরে সংকুচিত APEX ফাইলগুলিকে ডিকম্প্রেস করার জন্য apexd দ্বারা ভবিষ্যতে ব্যবহারের জন্য ডিস্কে স্থান সংরক্ষণ করে।

A/B OTA আপডেটের ক্ষেত্রে, apexd পোস্ট-ইনস্টল OTA রুটিনের অংশ হিসেবে ব্যাকগ্রাউন্ডে ডিকম্প্রেশন করার চেষ্টা করে। যদি ডিকম্প্রেশন ব্যর্থ হয়, তাহলে apexd OTA আপডেট প্রয়োগকারী বুটের সময় ডিকম্প্রেশন করে।

APEX তৈরির সময় বিবেচনা করা বিকল্পগুলি

APEX ফাইল ফর্ম্যাট ডিজাইন করার সময় AOSP যে কয়েকটি বিকল্প বিবেচনা করেছিল এবং কেন সেগুলি অন্তর্ভুক্ত বা বাদ দেওয়া হয়েছিল তা এখানে দেওয়া হল।

নিয়মিত প্যাকেজ ব্যবস্থাপনা সিস্টেম

লিনাক্স ডিস্ট্রিবিউশনগুলিতে dpkg এবং rpm এর মতো প্যাকেজ ম্যানেজমেন্ট সিস্টেম রয়েছে, যা শক্তিশালী, পরিপক্ক এবং শক্তিশালী। তবে, APEX-এর জন্য এগুলি গ্রহণ করা হয়নি কারণ তারা ইনস্টলেশনের পরে প্যাকেজগুলিকে সুরক্ষিত করতে পারে না। প্যাকেজগুলি ইনস্টল করার সময় কেবল যাচাইকরণ করা হয়। আক্রমণকারীরা অলক্ষিতভাবে ইনস্টল করা প্যাকেজগুলির অখণ্ডতা ভঙ্গ করতে পারে। এটি অ্যান্ড্রয়েডের জন্য একটি রিগ্রেশন যেখানে সমস্ত সিস্টেম উপাদানগুলি কেবল পঠনযোগ্য ফাইল সিস্টেমে সংরক্ষণ করা হয়েছিল যার অখণ্ডতা প্রতিটি I/O এর জন্য dm-verity দ্বারা সুরক্ষিত। সিস্টেম উপাদানগুলিতে যেকোনো ধরণের হস্তক্ষেপ নিষিদ্ধ করা উচিত, অথবা সনাক্তযোগ্য হওয়া উচিত যাতে আপোস করা হলে ডিভাইসটি বুট করতে অস্বীকার করতে পারে।

অখণ্ডতার জন্য dm-crypt

একটি APEX কন্টেইনারের ফাইলগুলি অন্তর্নির্মিত পার্টিশন (উদাহরণস্বরূপ, /system পার্টিশন) থেকে আসে যা dm-verity দ্বারা সুরক্ষিত থাকে, যেখানে পার্টিশনগুলি মাউন্ট করার পরেও ফাইলগুলিতে কোনও পরিবর্তন নিষিদ্ধ। ফাইলগুলিকে একই স্তরের সুরক্ষা প্রদানের জন্য, APEX-এর সমস্ত ফাইল একটি ফাইল সিস্টেম ইমেজে সংরক্ষণ করা হয় যা একটি হ্যাশ ট্রি এবং একটি vbmeta বর্ণনাকারীর সাথে যুক্ত থাকে। dm-verity ছাড়া, /data পার্টিশনের একটি APEX যাচাই এবং ইনস্টল করার পরে করা অনিচ্ছাকৃত পরিবর্তনগুলির জন্য ঝুঁকিপূর্ণ।

প্রকৃতপক্ষে, /data পার্টিশনটি dm-crypt এর মতো এনক্রিপশন স্তর দ্বারাও সুরক্ষিত। যদিও এটি টেম্পারিংয়ের বিরুদ্ধে কিছু স্তরের সুরক্ষা প্রদান করে, এর প্রাথমিক উদ্দেশ্য হল গোপনীয়তা, অখণ্ডতা নয়। যখন একজন আক্রমণকারী /data পার্টিশনে অ্যাক্সেস পায়, তখন আর কোনও সুরক্ষা থাকতে পারে না এবং এটি আবার /system পার্টিশনে থাকা প্রতিটি সিস্টেম উপাদানের তুলনায় একটি রিগ্রেশন। একটি APEX ফাইলের ভিতরে থাকা হ্যাশ ট্রি এবং dm-verity একই স্তরের সামগ্রী সুরক্ষা প্রদান করে।

/system থেকে /apex-এ পাথ পুনর্নির্দেশ করুন

APEX-তে প্যাকেজ করা সিস্টেম কম্পোনেন্ট ফাইলগুলি /apex/<name>/lib/libfoo.so এর মতো নতুন পাথের মাধ্যমে অ্যাক্সেসযোগ্য। যখন ফাইলগুলি /system পার্টিশনের অংশ ছিল, তখন সেগুলি /system/lib/libfoo.so এর মতো পাথের মাধ্যমে অ্যাক্সেসযোগ্য ছিল। APEX ফাইলের ক্লায়েন্ট (অন্যান্য APEX ফাইল বা প্ল্যাটফর্ম) অবশ্যই নতুন পাথ ব্যবহার করবে। পাথ পরিবর্তনের ফলে আপনাকে বিদ্যমান কোড আপডেট করতে হতে পারে।

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

আরেকটি বিকল্প ছিল open , stat এবং readlink এর মতো ফাইল-অ্যাক্সেস ফাংশনগুলিকে হাইজ্যাক করা, যাতে /system দিয়ে শুরু হওয়া পাথগুলিকে /apex অধীনে তাদের সংশ্লিষ্ট পাথে পুনঃনির্দেশিত করা হয়। অ্যান্ড্রয়েড টিম এই বিকল্পটি বাতিল করেছে কারণ পাথ গ্রহণকারী সমস্ত ফাংশন পরিবর্তন করা অসম্ভব। উদাহরণস্বরূপ, কিছু অ্যাপ স্ট্যাটিক্যালি বায়োনিককে লিঙ্ক করে, যা ফাংশনগুলি বাস্তবায়ন করে। এই ক্ষেত্রে, সেই অ্যাপগুলি পুনঃনির্দেশিত হয় না।