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

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

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

পটভূমি

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

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

ডিজাইন

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

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

APEX বিন্যাস

এটি একটি APEX ফাইলের বিন্যাস।

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

চিত্র 1. APEX ফাইল বিন্যাস

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

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

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

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

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

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

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

apex_pubkey হল সর্বজনীন কী যা ফাইল সিস্টেম ইমেজ সাইন ইন করতে ব্যবহৃত হয়। রানটাইমে, এই কী নিশ্চিত করে যে ডাউনলোড করা 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 ফাইল কারণ তারা একটি AndroidManifest.xml ফাইল ধারণকারী জিপ সংরক্ষণাগার (এপিকে স্বাক্ষর স্কিম ব্যবহার করে) স্বাক্ষরিত৷ এটি APEX ফাইলগুলিকে APK ফাইলগুলির জন্য পরিকাঠামো ব্যবহার করার অনুমতি দেয়, যেমন একটি প্যাকেজ ইনস্টলার অ্যাপ, সাইনিং ইউটিলিটি এবং প্যাকেজ ম্যানেজার৷

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

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

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

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

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

স্বাক্ষর করছে

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

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

বিল্ট-ইন পার্টিশনে APEX

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

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

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

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

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

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

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

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

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

কার্নেল সংস্করণ 4.4

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

  • আপস্ট্রিম: লুপ: লজিক্যাল ব্লকের আকার পরিবর্তন করার জন্য ioctl যোগ করুন ( 4.4 )
  • ব্যাকপোর্ট: ব্লক/লুপ: সেট hw_sectors ( 4.4 )
  • UPSTREAM: লুপ: compat ioctl ( 4.4 ) এ LOOP_SET_BLOCK_SIZE যোগ করুন
  • ANDROID: mnt: Next_descendent ঠিক করুন ( 4.4 )
  • ANDROID: mnt: রিমাউন্টকে ক্রীতদাসদের দাসদের কাছে প্রচার করা উচিত ( 4.4 )
  • ANDROID: mnt: সঠিকভাবে রিমাউন্ট প্রচার করুন ( 4.4 )
  • প্রত্যাবর্তন করুন "ANDROID: dm verity: ন্যূনতম প্রিফেচ আকার যোগ করুন" ( 4.4 )
  • আপস্ট্রিম: লুপ: অফসেট বা ব্লক_সাইজ পরিবর্তন করা হলে ক্যাশে ড্রপ করুন ( 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 নির্মাণ

এই বিভাগে বর্ণনা করা হয়েছে কিভাবে অ্যান্ড্রয়েড বিল্ড সিস্টেম ব্যবহার করে একটি এপেক্স তৈরি করা যায়। নিচে 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-এ ফাইলের ধরন এবং অবস্থান

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

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

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

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

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

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

  • ডিভাইসটি শুধুমাত্র 32 বিট হলে, বাইনারিটির শুধুমাত্র 32-বিট বৈকল্পিক ইনস্টল করা হয়।
  • যদি ডিভাইসটি শুধুমাত্র 64 বিট হয়, তাহলে বাইনারিটির শুধুমাত্র 64-বিট বৈকল্পিক ইনস্টল করা হয়।

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

# 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 স্বাক্ষর করতে ব্যবহৃত কীটির ID APEX-এ লেখা থাকে। রানটাইমে, apexd ডিভাইসে একই ID সহ একটি পাবলিক কী ব্যবহার করে APEX যাচাই করে।

জিপ স্বাক্ষর

আপনি যেভাবে APK সাইন করেন সেভাবে APEX-এ সাইন ইন করুন। APEXes দুবার সাইন ইন করুন; একবার মিনি ফাইল সিস্টেমের জন্য ( 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> সুং মডিউল দ্বারা সংজ্ঞায়িত করা হয়েছে। শংসাপত্র মডিউল নিম্নরূপ সংজ্ঞায়িত করা যেতে পারে.
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 ইনস্টল করা হচ্ছে

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

adb install apex_file_name
adb reboot

একটি APEX ব্যবহার করে

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

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

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

  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 ফাইলে সংজ্ঞায়িত করা যেতে পারে। অ্যাকশন ট্রিগারগুলি APEXes-এ সমর্থিত নয়৷

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

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-এর মধ্যে ফাইল সিস্টেম ইমেজ মাউন্ট করার জন্য অত্যন্ত গুরুত্বপূর্ণ।

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

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

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

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

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

সংকুচিত APEXes

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

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

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

  • বুটস্ট্র্যাপ APEXes যেগুলি বুট সিকোয়েন্সে খুব তাড়াতাড়ি মাউন্ট করা প্রয়োজন।

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

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

সংকুচিত APEX ফাইল বিন্যাস

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

Diagram shows the format of a compressed APEX file

চিত্র 2. সংকুচিত 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 ফাইলের সংকুচিত এবং সংকুচিত সংস্করণগুলির মধ্যে পার্থক্য করা সহজ করে তোলে।

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

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

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

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

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

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

  1. /system/apex/com.android.foo.capex-এর ভিতরের original_apex ফাইলটিকে /system/apex/com.android.foo.capex এ ডিকম্প্রেস করা /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 এই দুটি বাইন্ডার এপিআই প্রকাশ করে:

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

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

APEX বিকাশ করার সময় বিকল্প বিবেচনা করা হয়

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

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

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

অখণ্ডতার জন্য dm-ক্রিপ্ট

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

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

/সিস্টেম থেকে /এপেক্সে পাথ পুনঃনির্দেশ করা হচ্ছে

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

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

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