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

Android 10 -এ Android Pony EXpress (APEX) কন্টেনার ফর্ম্যাট চালু করা হয়েছে এবং এটি লোয়ার-লেভেল সিস্টেম মডিউলের ইনস্টল ফ্লোতে ব্যবহার করা হয়। এই ফর্ম্যাটটি সিস্টেম কম্পোনেন্ট আপডেট করার সুবিধা দেয় যা স্ট্যান্ডার্ড Android অ্যাপ্লিকেশন মডেলে ফিট করে না। কিছু কম্পোনেন্টের উদাহরণ হল নেটিভ পরিষেবা ও লাইব্রেরি, হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL), রানটাইম (ART) ও ক্লাস লাইব্রেরি।

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

ব্যাকগ্রাউন্ড

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

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

ডিজাইন

এই বিভাগে APEX ফাইল ফর্ম্যাট ও APEX ম্যানেজারের হাই-লেভেল ডিজাইন বর্ণনা করা হয়েছে। APEX ম্যানেজার হল এমন একটি পরিষেবা যা APEX ফাইল ম্যানেজ করে।

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

APEX ফর্ম্যাট

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

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

ছবি ১. APEX ফাইলের ফর্ম্যাট

সবচেয়ে উপরের লেভেলে, APEX ফাইল হল একটি zip ফাইল, যার মধ্যে ফাইলগুলি আনকমপ্রেসড অবস্থায় স্টোর করা থাকে এবং ৪ 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 হল dm-verity দ্বারা ব্যাক-আপ নেওয়া একটি ext4 ফাইল সিস্টেম ইমেজ। লুপব্যাক ডিভাইসের মাধ্যমে রানটাইমে ছবি মাউন্ট করা হয়। বিশেষত, হ্যাশ ট্রি এবং মেটাডেটা ব্লক 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-এর আপডেট সিকোয়েন্স PackageManager class ব্যবহার করে এবং তা নিচে দেওয়া হল।

  1. প্যাকেজ ইনস্টলার অ্যাপ, ADB বা অন্য কোনও সোর্সের মাধ্যমে APEX ফাইল ডাউনলোড করা হয়।
  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 থাকে। এই তথ্য, প্যাকেজ ইনস্টলার অ্যাপ এবং ADB-এর মতো বিদ্যমান চ্যানেলের মাধ্যমে APEX ফাইল ডেলিভার করার অনুমতি দেয়।

এই ধরনের ফাইল কাজ করে

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-এর নতুন ইনস্টল করা ভার্সনটি শুধুমাত্র রিবুট করার পরেই অ্যাক্টিভেট হয়।

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

Android ডিভাইসে APEX মেইনলাইন মডিউল কাজ করার জন্য, নিম্নলিখিত Linux কার্নেল ফিচার প্রয়োজন: লুপব্যাক ড্রাইভার ও dm-verity. লুপব্যাক ড্রাইভার APEX মডিউলে ফাইল সিস্টেম ইমেজ মাউন্ট করে এবং dm-verity APEX মডিউল যাচাই করে।

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

যেসব কার্নেল ভার্সনে কাজ করে

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

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

APEX মডিউলকে সাপোর্ট করার জন্য প্রয়োজনীয় কার্নেল প্যাচ Android কমন ট্রিতে অন্তর্ভুক্ত করা হয়েছে। APEX-কে সাপোর্ট করার জন্য প্যাচ পেতে, Android কমন ট্রির লেটেস্ট ভার্সন ব্যবহার করুন।

কার্নেল ভার্সন 4.4

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

  • UPSTREAM: loop: add ioctl for changing logical block size (4.4)
  • ব্যাকপোর্ট: block/loop: set hw_sectors (4.4)
  • আপস্ট্রিম: লুপ: কম্প্যাট ioctl (4.4)-এ LOOP_SET_BLOCK_SIZE যোগ করুন
  • ANDROID: mnt: Fix next_descendent (4.4)
  • ANDROID: mnt: remount should propagate to slaves of slaves (4.4)
  • ANDROID: mnt: Propagate remount correctly (4.4)
  • "ANDROID: dm verity: add minimum prefetch size" কোডটি আগের অবস্থায় ফিরিয়ে আনুন (4.4)
  • আপস্ট্রিম: লুপ: অফসেট বা block_size পরিবর্তন করা হলে ক্যাশে ড্রপ করুন (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 অবশ্যই <= ৮ হতে হবে

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-এ অনুবাদিত আর্মের জন্য /lib/arm)
এক্সিকিউটেবল /bin
জাভা লাইব্রেরি /javalib
প্রিবিল্ট /etc

ট্রানজিটিভ ডিপেন্ডেন্সি

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

একাধিক ABI ম্যানেজ করা

ডিভাইসের প্রাথমিক ও গৌণ, উভয় অ্যাপ্লিকেশন বাইনারি ইন্টারফেসের (ABI) জন্য native_shared_libs প্রপার্টি ইনস্টল করুন। কোনও APEX যদি একটি ABI (অর্থাৎ, শুধুমাত্র ৩২ বিট বা শুধুমাত্র ৬৪ বিট) সহ ডিভাইসকে টার্গেট করে, তাহলে সংশ্লিষ্ট ABI সহ লাইব্রেরিগুলিই শুধুমাত্র ইনস্টল করা হয়।

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

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

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

  • first: ডিভাইসের প্রাথমিক ABI-এর সাথে ম্যাচ করে। বাইনারির জন্য এটি ডিফল্ট হিসেবে থাকে।
  • lib32: কাজ করলে ডিভাইসের ৩২-বিট ABI-এর সাথে ম্যাচ করে।
  • lib64: এটি কাজ করে এমন ডিভাইসের 64-বিট ABI-এর সাথে ম্যাচ করে।
  • prefer32: কাজ করলে ডিভাইসের ৩২-বিট ABI-এর সাথে ম্যাচ করে। ৩২-বিট ABI কাজ না করলে, ৬৪-বিট ABI-এর সাথে ম্যাচ করে।
  • both: দুটি ABI-এর সাথেই ম্যাচ করে। এটি native_shared_libraries-এর জন্য ডিফল্ট।

java, libraries ও prebuilts প্রপার্টি ABI-অ্যাগনস্টিক।

এই উদাহরণটি এমন একটি ডিভাইসের জন্য যা ৩২/৬৪ বিট ভার্সনে কাজ করে এবং ৩২ বিট ভার্সন পছন্দ করে না:

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 প্রপার্টি সেট করুন:

  • সেট করা নেই: কোনও ভ্যালু সেট করা না থাকলে, PRODUCT_DEFAULT_DEV_CERTIFICATE-এ থাকা সার্টিফিকেট দিয়ে APEX সই করা হয়। কোনও ফ্ল্যাগ সেট করা না থাকলে, পাথ ডিফল্ট হিসেবে 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

apex_manifest.json-এ supportsRebootlessUpdate-কে 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. /data/apex-এ 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 যা লিগ্যাসি কার্নেল সহ ডিভাইসে অ্যাক্টিভেট করা যেতে পারে। ফ্ল্যাটেন করা APEX-এর ফাইলগুলি সরাসরি বিল্ট-ইন পার্টিশনের অধীনে একটি ডিরেক্টরিতে ইনস্টল করা হয়। যেমন, ফ্ল্যাটেন করা APEX-এ থাকা lib/libFoo.so 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 হয় ফ্ল্যাটেন করা থাকবে, নয়তো ফ্ল্যাটেন করা থাকবে না। Mainline-এর মতো প্রজেক্টের জন্য আগে থেকেই সাইন করা APEX প্রি-বিল্ট পাঠানোর সময় এটি বিশেষভাবে গুরুত্বপূর্ণ। যেসব APEX আগে থেকে সাইন করা নেই (অর্থাৎ, সোর্স থেকে তৈরি করা হয়েছে) সেগুলিও নন-ফ্ল্যাটেনড হতে হবে এবং সঠিক 'কী' দিয়ে সাইন করতে হবে। APEX-এর মাধ্যমে পরিষেবা আপডেট করা লিঙ্কে যেভাবে ব্যাখ্যা করা হয়েছে, ডিভাইসকে সেইভাবে updatable_apex.mk থেকে ইনহেরিট করতে হবে।

কম্প্রেস করা APEX

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

রিড-অনলি পার্টিশনে (যেমন /system পার্টিশন) APEX ফাইলের অত্যন্ত কম্প্রেস করা সেট ব্যবহার করে APEX কম্প্রেশন এই স্টোরেজ প্রভাবকে কমিয়ে দেয়। Android 12 ও তার পরবর্তী যেকোনও ভার্সনে Deflate zip কম্প্রেসন অ্যালগরিদম ব্যবহার করা হয়।

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

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

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

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

কম্প্রেস করা APEX ফাইল ফর্ম্যাট

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

ডায়াগ্রামে কম্প্রেস করা APEX ফাইলের ফর্ম্যাট দেখানো হয়েছে

ছবি ২. কম্প্রেস করা APEX ফাইল ফর্ম্যাট

সবচেয়ে উপরের লেভেলে, কম্প্রেস করা APEX ফাইল হল একটি zip ফাইল, যার মধ্যে আসল apex ফাইলটি ৯-এর কম্প্রেশন লেভেল সহ ডিফ্লেটেড ফর্মে থাকে এবং অন্যান্য ফাইল কম্প্রেস না করেই স্টোর করা হয়।

চারটি ফাইল নিয়ে একটি APEX ফাইল তৈরি হয়:

  • original_apex: ৯ কম্প্রেশন লেভেল সহ ডিফ্লেট করা হয়েছে এটি হল আসল, আনকমপ্রেসড 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 ফাইলের কম্প্রেস করা এবং কম্প্রেস না করা ভার্সনের মধ্যে পার্থক্য করা সহজ করে তোলে।

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

Android 12-এ শুধু Deflate জিপ কম্প্রেশন কাজ করে।

বুট করার সময় কম্প্রেস করা APEX ফাইল অ্যাক্টিভেট করা

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

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

/system/apex/com.android.foo.capex-কে versionCode 37 সহ অ্যাক্টিভেট করা কম্প্রেস করা APEX হিসেবে বিবেচনা করুন।

  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 ডেভেলপ করার সময় বিবেচনা করা বিকল্প

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

সাধারণ প্যাকেজ ম্যানেজমেন্ট সিস্টেম

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

ইন্টিগ্রিটির জন্য dm-crypt

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

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

/system থেকে /apex-এ রিডাইরেক্ট করার পাথ

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

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

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