এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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 ফাইল সনাক্ত করে। এটি 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 APEXes এর জন্য সংরক্ষিত। কোন কোম্পানি বা ডিভাইস অনন্য নয়.
com.<companyname>.*
- একটি কোম্পানির জন্য সংরক্ষিত. সম্ভাব্য সেই কোম্পানির একাধিক ডিভাইস দ্বারা ব্যবহৃত।
com.<companyname>.<devicename>.*
- একটি নির্দিষ্ট ডিভাইস (বা ডিভাইসের উপসেট) জন্য অনন্য APEXes জন্য সংরক্ষিত।

এপেক্স ম্যানেজার

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

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

একটি APEX ফাইল একটি প্যাকেজ ইনস্টলার অ্যাপ, ADB, বা অন্যান্য উত্সের মাধ্যমে ডাউনলোড করা হয়৷
প্যাকেজ ম্যানেজার ইনস্টলেশন প্রক্রিয়া শুরু করে। ফাইলটি একটি APEX তা স্বীকার করার পরে, প্যাকেজ ম্যানেজার APEX ম্যানেজারের কাছে নিয়ন্ত্রণ স্থানান্তর করে।
APEX ম্যানেজার APEX ফাইলটি যাচাই করে।
যদি APEX ফাইলটি যাচাই করা হয়, তাহলে APEX ম্যানেজারের অভ্যন্তরীণ ডাটাবেস আপডেট করা হয় যাতে প্রতিফলিত হয় যে APEX ফাইলটি পরবর্তী বুটে সক্রিয় হবে।
ইনস্টল করার অনুরোধকারী সফল প্যাকেজ যাচাইকরণের পরে একটি সম্প্রচার পায়।
ইনস্টলেশন চালিয়ে যেতে, সিস্টেম রিবুট করা আবশ্যক.
পরবর্তী বুটে, 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 , versionCode , এবং সূক্ষ্ম লক্ষ্যমাত্রার জন্য ঐচ্ছিক targetSdkVersion , minSdkVersion , এবং maxSdkVersion থাকে৷ এই তথ্যটি APEX ফাইলগুলিকে বিদ্যমান চ্যানেল যেমন প্যাকেজ ইনস্টলার অ্যাপস এবং ADB-এর মাধ্যমে বিতরণ করার অনুমতি দেয়।

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

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

নেটিভ শেয়ার করা libs
নেটিভ এক্সিকিউটেবল
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 মডিউলটি যাচাই করে।

লুপব্যাক ড্রাইভার এবং 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: পরবর্তী_ডিসেন্ডেন্ট ঠিক করুন ( 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 হতে হবে

একটি এপেক্স তৈরি করুন

এই বিভাগে 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-এ ফাইলের ধরন এবং অবস্থান

ফাইলের ধরন	এপেক্সে অবস্থান
ভাগ করা লাইব্রেরি	`/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-বিট বৈকল্পিক ইনস্টল করা হয়।

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 স্বাক্ষর করতে ব্যবহৃত কীটির 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_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 থেকে ফাইলগুলি পড়তে বা চালানোর জন্য বাইন্ড-মাউন্ট করা পথ ব্যবহার করতে পারে।

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

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

একটি APEX এর সাথে একটি পরিষেবা আপডেট করুন৷

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

সিস্টেম পার্টিশনে পরিষেবাটিকে আপডেটযোগ্য হিসাবে চিহ্নিত করুন। পরিষেবা সংজ্ঞাতে updatable বিকল্পটি যুক্ত করুন।
```
/system/etc/init/myservice.rc:

service myservice /system/bin/myservice
    class core
    user system
    ...
    updatable
```
আপডেট করা পরিষেবার জন্য একটি নতুন .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-এ my.apex /system/apex/my.apex/lib/libFoo.so এ ইনস্টল করা আছে।

একটি সমতল APEX সক্রিয় করার সাথে লুপ ডিভাইস জড়িত নয়৷ সম্পূর্ণ ডিরেক্টরি /system/apex/my.apex সরাসরি /apex/name@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 এ তাদের সংশ্লিষ্ট ফাইলগুলির অনুলিপি।

সংকুচিত এপেক্স তৈরি করুন

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 সক্রিয় করা হিসাবে বিবেচনা করুন।

/system/apex/com.android.foo.capex ভিতরের original_apex ফাইলটিকে /data/apex/decompressed/com.android.foo@37.apex এ ডিকম্প্রেস করা হয়েছে।
restorecon /data/apex/decompressed/com.android.foo@37.apex এটির একটি সঠিক SELinux লেবেল আছে কিনা তা যাচাই করার জন্য সঞ্চালিত হয়।
যাচাইকরণ পরীক্ষাগুলি /data/apex/decompressed/com.android.foo@37.apex এ এর বৈধতা নিশ্চিত করার জন্য সঞ্চালিত হয়: apexd /data/apex/decompressed/com.android.foo@37.apex এ বান্ডিল করা পাবলিক কী চেক করে যে এটি /system/apex/com.android.foo.capex এ বান্ডেল করা একটির সমান।
/data/apex/decompressed/com.android.foo@37.apex ফাইলটি /data/apex/active/com.android.foo@37.apex ডিরেক্টরির সাথে হার্ড-লিঙ্কযুক্ত।
আনকম্প্রেসড 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 অধীনে তাদের সংশ্লিষ্ট পাথগুলিতে পুনঃনির্দেশিত করা হয়। অ্যান্ড্রয়েড টিম এই বিকল্পটি বাতিল করেছে কারণ পাথ গ্রহণ করে এমন সমস্ত ফাংশন পরিবর্তন করা অসম্ভব। উদাহরণস্বরূপ, কিছু অ্যাপ স্থিরভাবে Bionic লিঙ্ক করে, যা ফাংশনগুলিকে প্রয়োগ করে। এই ধরনের ক্ষেত্রে, সেই অ্যাপগুলি পুনঃনির্দেশিত হয় না।

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

পটভূমি

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

ডিজাইন

APEX বিন্যাস

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

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

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

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

apex_manifest.json
AndroidManifest.xml
apex_payload.img
apex_pubkey

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

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

এপেক্স ম্যানেজার

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

একটি APEX ফাইল একটি প্যাকেজ ইনস্টলার অ্যাপ, ADB, বা অন্যান্য উত্সের মাধ্যমে ডাউনলোড করা হয়৷
প্যাকেজ ম্যানেজার ইনস্টলেশন পদ্ধতি শুরু করে। ফাইলটি একটি APEX তা স্বীকার করার পরে, প্যাকেজ ম্যানেজার APEX ম্যানেজারের কাছে নিয়ন্ত্রণ স্থানান্তর করে।
APEX ম্যানেজার APEX ফাইলটি যাচাই করে।
যদি APEX ফাইলটি যাচাই করা হয়, তাহলে APEX ম্যানেজারের অভ্যন্তরীণ ডাটাবেস আপডেট করা হয় যাতে প্রতিফলিত হয় যে APEX ফাইলটি পরবর্তী বুটে সক্রিয় হবে।
ইনস্টল করার অনুরোধকারী সফল প্যাকেজ যাচাইকরণের পরে একটি সম্প্রচার পায়।
ইনস্টলেশন চালিয়ে যেতে, সিস্টেম রিবুট করা আবশ্যক.
পরবর্তী বুটে, APEX ম্যানেজার শুরু হয়, অভ্যন্তরীণ ডাটাবেস পড়ে এবং তালিকাভুক্ত প্রতিটি APEX ফাইলের জন্য নিম্নলিখিতগুলি করে:
1. APEX ফাইল যাচাই করে।
2. APEX ফাইল থেকে একটি লুপব্যাক ডিভাইস তৈরি করে।
3. লুপব্যাক ডিভাইসের উপরে একটি ডিভাইস ম্যাপার ব্লক ডিভাইস তৈরি করে।
4. ডিভাইস ম্যাপার ব্লক ডিভাইসটিকে একটি অনন্য পাথে মাউন্ট করে (উদাহরণস্বরূপ, /apex/ name @ ver )।

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

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

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

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

সাইনিং অপশন

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

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

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

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

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

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

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

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

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

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

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

উজান: লুপ: লজিকাল ব্লকের আকার পরিবর্তন করার জন্য আইওসিটিএল যুক্ত করুন ( 4.4 )
ব্যাকপোর্ট: ব্লক/লুপ: এইচডাব্লু_সেক্টর সেট করুন ( 4.4 )
উজান: লুপ: কমপ্যাট আইওসিটিএল ( 4.4 ) এ লুপ_সেট_ব্লক_সাইজ যুক্ত করুন
অ্যান্ড্রয়েড: এমএনটি: নেক্সট_ডেসেন্ডেন্ট ফিক্স করুন ( 4.4 )
অ্যান্ড্রয়েড: এমএনটি: রিমাউন্ট দাসদের দাসদের কাছে প্রচার করা উচিত ( ৪.৪ )
অ্যান্ড্রয়েড: এমএনটি: পুনরুদ্ধারটি সঠিকভাবে প্রচার করুন ( 4.4 )
ফিরে "অ্যান্ড্রয়েড: ডিএম ভেরিটি: ন্যূনতম প্রিফেচ আকার যুক্ত করুন" ( 4.4 )
উজান: লুপ: অফসেট বা ব্লক_সাইজ পরিবর্তন করা হলে ক্যাশে ড্রপ করুন ( 4.4 )

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

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

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

নিম্নলিখিত তালিকায় অ্যান্ড্রয়েড 10 এ প্রবর্তিত অ্যাপেক্স মডিউলগুলিকে সমর্থন করার জন্য বেস কনফিগারেশন প্রয়োজনীয়তাগুলি দেখায়। একটি নক্ষত্র (*) সহ আইটেমগুলি অ্যান্ড্রয়েড 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

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

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

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

একটি শীর্ষ তৈরি

এই বিভাগটি অ্যান্ড্রয়েড বিল্ড সিস্টেমটি ব্যবহার করে কীভাবে শীর্ষস্থান তৈরি করবেন তা বর্ণনা করে। নীচে apex.test নামের একটি শীর্ষের জন্য 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

শীর্ষে ফাইলের ধরণ এবং অবস্থান

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

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

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

একাধিক আবিস পরিচালনা করুন

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

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

যদি ডিভাইসটি কেবল 32 বিট হয় তবে কেবল বাইনারিটির 32-বিট বৈকল্পিক ইনস্টল করা আছে।
যদি ডিভাইসটি কেবল 64 বিট হয় তবে বাইনারিটির কেবল 64-বিট বৈকল্পিক ইনস্টল করা আছে।

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

java , libraries এবং prebuilts বৈশিষ্ট্যগুলি এবিআই-অ্যাগনস্টিক।

এই উদাহরণটি এমন একটি ডিভাইসের জন্য যা 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_key মডিউল তৈরি করুন। কীটি ব্যবহার করে শীর্ষে স্বাক্ষর করতে key সম্পত্তিটি ব্যবহার করুন। পাবলিক কীটি 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 ) এর নাম কীটির আইডি হয়ে যায়। শীর্ষে স্বাক্ষর করতে ব্যবহৃত কীটির আইডি শীর্ষে লেখা আছে। রানটাইমে, apexd ডিভাইসে একই আইডি সহ একটি পাবলিক কী ব্যবহার করে শীর্ষগুলি যাচাই করে।

শীর্ষ স্বাক্ষর

আপনি অ্যাপকে স্বাক্ষর করার সাথে সাথে সাইন ইন করুন। সাইন দু'বার শীর্ষে; মিনি ফাইল সিস্টেমের জন্য একবার ( apex_payload.img ফাইল) এবং একবার পুরো ফাইলের জন্য।

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

সেট করা হয়নি: যদি কোনও মান সেট না করা হয় তবে শীর্ষস্থানটি PRODUCT_DEFAULT_DEV_CERTIFICATE অবস্থিত শংসাপত্রের সাথে স্বাক্ষরিত হয়। যদি কোনও পতাকা সেট না করা থাকে তবে পথটি build/target/product/security/testkey করতে ডিফল্ট হয়।
<name> : এপেক্সটি PRODUCT_DEFAULT_DEV_CERTIFICATE হিসাবে একই ডিরেক্টরিতে <name> শংসাপত্রের সাথে স্বাক্ষরিত হয়।
:<name> : অ্যাপেক্সটি শংসাপত্রের সাথে স্বাক্ষরিত হয় যা <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)
}

একটি শীর্ষ ইনস্টল করুন

একটি শীর্ষ ইনস্টল করতে, এডিবি ব্যবহার করুন।

adb install apex_file_name
adb reboot

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

adb install --force-non-staged apex_file_name

একটি শীর্ষ ব্যবহার করুন

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

ক্লায়েন্টরা অ্যাপেক্স থেকে ফাইলগুলি পড়তে বা সম্পাদন করতে বাইন্ড-মাউন্ট করা পথটি ব্যবহার করতে পারে।

শীর্ষগুলি সাধারণত নিম্নলিখিত হিসাবে ব্যবহৃত হয়:

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

একটি শীর্ষে একটি পরিষেবা আপডেট করুন

একটি শীর্ষ ব্যবহার করে একটি পরিষেবা আপডেট করতে:

সিস্টেম পার্টিশনে পরিষেবাটি আপডেটযোগ্য হিসাবে চিহ্নিত করুন। পরিষেবা সংজ্ঞাতে বিকল্প updatable যুক্ত করুন।
```
/system/etc/init/myservice.rc:

service myservice /system/bin/myservice
    class core
    user system
    ...
    updatable
```
আপডেট হওয়া পরিষেবার জন্য একটি নতুন .rc ফাইল তৈরি করুন। বিদ্যমান পরিষেবাটিকে নতুন করে সংজ্ঞায়িত করতে override বিকল্পটি ব্যবহার করুন।
```
/apex/my.apex/etc/init.rc:

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

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

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

অ্যাপেক্স আপডেটগুলি সমর্থন করতে সিস্টেম কনফিগার করুন

অ্যাপেক্স ফাইল আপডেটগুলি সমর্থন করার জন্য নিম্নলিখিত সিস্টেমের সম্পত্তিটি 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)

সমতল শীর্ষ

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

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

একটি সমতল অ্যাপেক্স সক্রিয় করা লুপ ডিভাইস জড়িত না। পুরো ডিরেক্টরি /system/apex/my.apex এমওয়াই.এপেক্স সরাসরি /apex/name@ver আবদ্ধ-মাউন্ট করা হয়।

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

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

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

সংকুচিত শীর্ষস্থানীয়

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

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

সংক্ষেপণ নিম্নলিখিতগুলিতে অপ্টিমাইজেশন সরবরাহ করে না:

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

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

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

Diagram shows the format of a compressed APEX file

চিত্র 2। সংকুচিত অ্যাপেক্স ফাইল ফর্ম্যাট

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

চারটি ফাইল একটি অ্যাপেক্স ফাইল রয়েছে:

original_apex : 9 এর সংক্ষেপণ স্তরের সাথে বিচ্ছিন্ন এটি এটি মূল, সংকুচিত অ্যাপেক্স ফাইল ।
apex_manifest.pb : কেবল সঞ্চিত
AndroidManifest.xml : কেবল সঞ্চিত
apex_pubkey : কেবল সঞ্চিত

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

সংকুচিত শীর্ষস্থান তৈরি করুন

সংকুচিত অ্যাপেক্সটি system/apex/tools অবস্থিত apex_compression_tool.py সরঞ্জাম ব্যবহার করে নির্মিত হতে পারে।

অ্যাপেক্স সংকোচনের সাথে সম্পর্কিত বেশ কয়েকটি পরামিতি বিল্ড সিস্টেমে উপলব্ধ।

Android.bp এ একটি অ্যাপেক্স ফাইল সংকোচনের কিনা তা compressible সম্পত্তি দ্বারা নিয়ন্ত্রিত হয়:

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

একটি PRODUCT_COMPRESSED_APEX পণ্য পতাকা নিয়ন্ত্রণ করে যে উত্স থেকে নির্মিত কোনও সিস্টেম চিত্রটিতে অবশ্যই সংকুচিত অ্যাপেক্স ফাইল থাকতে হবে কিনা।

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

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

সমর্থিত সংক্ষেপণ অ্যালগরিদম

অ্যান্ড্রয়েড 12 কেবলমাত্র ডিফ্লেট-জিপ সংক্ষেপণ সমর্থন করে।

বুট চলাকালীন একটি সংকুচিত অ্যাপেক্স ফাইল সক্রিয় করুন

একটি সংকুচিত অ্যাপেক্স সক্রিয় করার আগে, এর ভিতরে original_apex ফাইলটি /data/apex/decompressed ডিরেক্টরিতে ডিকম্প্রেসড। ফলস্বরূপ ডিকম্প্রেসড অ্যাপেক্স ফাইলটি /data/apex/active ডিরেক্টরিতে কঠোর লিঙ্কযুক্ত।

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

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

original_apex ফাইলটি /system/apex/com.android.foo.capex এপেক্স/কম.অ্যান্ড্রয়েড.ফু.ক্যাপেক্সের ভিতরে /data/apex/decompressed/com.android.foo@37.apex এপেক্স/ডেকম্প্রেসেড/কম.অ্যান্ড্রয়েড.ফু @37.apex এ ডিকম্প্রেসড।
restorecon /data/apex/decompressed/com.android.foo@37.apex এটি যাচাই করা হয় যে এটির একটি সঠিক সেলিনাক্স লেবেল রয়েছে তা যাচাই করতে সঞ্চালিত হয়।
যাচাইকরণ চেকগুলি /data/apex/decompressed/com.android.foo@37.apex @37.apex এ সঞ্চালিত হয় এর বৈধতা নিশ্চিত করার জন্য: apexd /ডিএটিএ/ডেকম্প্রেসড /data/apex/decompressed/com.android.foo@37.apex /system/apex/com.android.foo.capex .
/data/apex/decompressed/com.android.foo@37.apex ফাইলটি /data/apex/active/com.android.foo@37.apex @37.apex ডিরেক্টরিতে কঠোর লিঙ্কযুক্ত।
সংকুচিত এপেক্স ফাইলগুলির জন্য নিয়মিত অ্যাক্টিভেশন লজিক /data/apex/active/com.android.foo@37.apex এপেক্স/

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

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

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

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

একটি এ/বি ওটিএ আপডেটের ক্ষেত্রে, apexd পোস্টইনস্টল ওটিএ রুটিনের অংশ হিসাবে পটভূমিতে ডিকম্প্রেশন চেষ্টা করে। যদি ডিকম্প্রেশন ব্যর্থ হয়, apexd ওটিএ আপডেট প্রয়োগ করে এমন বুটের সময় ডিকম্প্রেশনটি সম্পাদন করে।

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

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

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

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

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

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

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

/সিস্টেম থেকে /শীর্ষে পাথগুলি পুনর্নির্দেশ করুন

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

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

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

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

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

পটভূমি

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

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

ডিজাইন

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

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

এপেক্স ফর্ম্যাট

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

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

চিত্র 1। অ্যাপেক্স ফাইল ফর্ম্যাট

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

একটি অ্যাপেক্স ফাইলে চারটি ফাইল হ'ল:

apex_manifest.json
AndroidManifest.xml
apex_payload.img
apex_pubkey

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

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

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

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

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

অ্যাপেক্স নামকরণের নির্দেশিকা

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

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

অ্যাপেক্স ম্যানেজার

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

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

একটি অ্যাপেক্স ফাইল একটি প্যাকেজ ইনস্টলার অ্যাপ্লিকেশন, এডিবি বা অন্য উত্সের মাধ্যমে ডাউনলোড করা হয়।
প্যাকেজ ম্যানেজার ইনস্টলেশন পদ্ধতি শুরু করে। ফাইলটি একটি শীর্ষস্থানীয় তা স্বীকৃতি দেওয়ার পরে, প্যাকেজ ম্যানেজার অ্যাপেক্স ম্যানেজারে নিয়ন্ত্রণ স্থানান্তর করে।
অ্যাপেক্স ম্যানেজার অ্যাপেক্স ফাইলটি যাচাই করে।
যদি এপেক্স ফাইলটি যাচাই করা হয়, অ্যাপেক্স ম্যানেজারের অভ্যন্তরীণ ডাটাবেসটি আপডেট করা হয় যে পরবর্তী বুটে অ্যাপেক্স ফাইলটি সক্রিয় হয়ে যায় তা প্রতিফলিত করতে।
ইনস্টল অনুরোধকারী সফল প্যাকেজ যাচাইয়ের উপর একটি সম্প্রচার গ্রহণ করে।
ইনস্টলেশন চালিয়ে যেতে, সিস্টেমটি পুনরায় বুট করতে হবে।
পরবর্তী বুটে, অ্যাপেক্স ম্যানেজার শুরু করে, অভ্যন্তরীণ ডাটাবেসটি পড়ে এবং তালিকাভুক্ত প্রতিটি অ্যাপেক্স ফাইলের জন্য নিম্নলিখিতগুলি করে:
1. অ্যাপেক্স ফাইল যাচাই করে।
2. অ্যাপেক্স ফাইল থেকে একটি লুপব্যাক ডিভাইস তৈরি করে।
3. লুপব্যাক ডিভাইসের উপরে একটি ডিভাইস ম্যাপার ব্লক ডিভাইস তৈরি করে।
4. ডিভাইস ম্যাপার ব্লক ডিভাইসটিকে একটি অনন্য পথে মাউন্ট করে (উদাহরণস্বরূপ, /apex/ name @ ver )।

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

অ্যাপেক্স ফাইলগুলি এপিকে ফাইলগুলি

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

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

ফাইল প্রকার সমর্থিত

অ্যাপেক্স ফর্ম্যাটটি এই ফাইলের প্রকারগুলিকে সমর্থন করে:

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

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

স্বাক্ষর বিকল্প

অ্যাপেক্স ফাইলগুলি দুটি উপায়ে স্বাক্ষরিত হয়। প্রথমত, apex_payload.img (বিশেষত, vbmeta বর্ণনাকারী apex_payload.img এ সংযুক্ত) ফাইলটি একটি কী দিয়ে স্বাক্ষরিত হয়েছে। তারপরে, পুরো অ্যাপেক্সটি এপিকে স্বাক্ষর স্কিম ভি 3 ব্যবহার করে স্বাক্ষরিত হয়। এই প্রক্রিয়াতে দুটি পৃথক কী ব্যবহৃত হয়।

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

অন্তর্নির্মিত পার্টিশনে শীর্ষস্থানীয়

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

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

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

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

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

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

উজান: লুপ: লজিকাল ব্লকের আকার পরিবর্তন করার জন্য আইওসিটিএল যুক্ত করুন ( 4.4 )
ব্যাকপোর্ট: ব্লক/লুপ: এইচডাব্লু_সেক্টর সেট করুন ( 4.4 )
উজান: লুপ: কমপ্যাট আইওসিটিএল ( 4.4 ) এ লুপ_সেট_ব্লক_সাইজ যুক্ত করুন
অ্যান্ড্রয়েড: এমএনটি: নেক্সট_ডেসেন্ডেন্ট ফিক্স করুন ( 4.4 )
অ্যান্ড্রয়েড: এমএনটি: রিমাউন্ট দাসদের দাসদের কাছে প্রচার করা উচিত ( ৪.৪ )
অ্যান্ড্রয়েড: এমএনটি: পুনরুদ্ধারটি সঠিকভাবে প্রচার করুন ( 4.4 )
ফিরে "অ্যান্ড্রয়েড: ডিএম ভেরিটি: ন্যূনতম প্রিফেচ আকার যুক্ত করুন" ( 4.4 )
উজান: লুপ: অফসেট বা ব্লক_সাইজ পরিবর্তন করা হলে ক্যাশে ড্রপ করুন ( 4.4 )

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

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

(*) 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

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

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

একটি শীর্ষ তৈরি

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

শীর্ষে ফাইলের ধরণ এবং অবস্থান

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

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

একাধিক আবিস পরিচালনা করুন

যদি ডিভাইসটি কেবল 32 বিট হয় তবে কেবল বাইনারিটির 32-বিট বৈকল্পিক ইনস্টল করা আছে।
যদি ডিভাইসটি কেবল 64 বিট হয় তবে বাইনারিটির কেবল 64-বিট বৈকল্পিক ইনস্টল করা আছে।

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

java , libraries এবং prebuilts বৈশিষ্ট্যগুলি এবিআই-অ্যাগনস্টিক।

এই উদাহরণটি এমন একটি ডিভাইসের জন্য যা 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 স্বাক্ষর

# 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",
}

শীর্ষ স্বাক্ষর

সেট করা হয়নি: যদি কোনও মান সেট না করা হয় তবে শীর্ষস্থানটি PRODUCT_DEFAULT_DEV_CERTIFICATE অবস্থিত শংসাপত্রের সাথে স্বাক্ষরিত হয়। যদি কোনও পতাকা সেট না করা থাকে তবে পথটি build/target/product/security/testkey করতে ডিফল্ট হয়।
<name> : এপেক্সটি PRODUCT_DEFAULT_DEV_CERTIFICATE হিসাবে একই ডিরেক্টরিতে <name> শংসাপত্রের সাথে স্বাক্ষরিত হয়।
:<name> : অ্যাপেক্সটি শংসাপত্রের সাথে স্বাক্ষরিত হয় যা <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)
}

একটি শীর্ষ ইনস্টল করুন

একটি শীর্ষ ইনস্টল করতে, এডিবি ব্যবহার করুন।

adb install apex_file_name
adb reboot

adb install --force-non-staged apex_file_name

একটি শীর্ষ ব্যবহার করুন

শীর্ষগুলি সাধারণত নিম্নলিখিত হিসাবে ব্যবহৃত হয়:

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

একটি শীর্ষে একটি পরিষেবা আপডেট করুন

একটি শীর্ষ ব্যবহার করে একটি পরিষেবা আপডেট করতে:

সিস্টেম পার্টিশনে পরিষেবাটি আপডেটযোগ্য হিসাবে চিহ্নিত করুন। পরিষেবা সংজ্ঞাতে বিকল্প updatable যুক্ত করুন।
```
/system/etc/init/myservice.rc:

service myservice /system/bin/myservice
    class core
    user system
    ...
    updatable
```
আপডেট হওয়া পরিষেবার জন্য একটি নতুন .rc ফাইল তৈরি করুন। বিদ্যমান পরিষেবাটিকে নতুন করে সংজ্ঞায়িত করতে override বিকল্পটি ব্যবহার করুন।
```
/apex/my.apex/etc/init.rc:

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

অ্যাপেক্স আপডেটগুলি সমর্থন করতে সিস্টেম কনফিগার করুন

Set the following system property to true to support APEX file updates.

<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)

Flattened APEX

For legacy devices, it's sometimes impossible or infeasible to update the old kernel to fully support APEX. For example, the kernel might have been built without CONFIG_BLK_DEV_LOOP=Y , which is crucial for mounting the file system image inside an APEX.

Flattened APEX is a specially built APEX that can be activated on devices with a legacy kernel. Files in a flattened APEX are directly installed to a directory under the built-in partition. For example, lib/libFoo.so in a flattened APEX my.apex is installed to /system/apex/my.apex/lib/libFoo.so .

Activating a flattened APEX doesn't involve the loop device. The entire directory /system/apex/my.apex is directly bind-mounted to /apex/name@ver .

Flattened APEXes can't be updated by downloading updated versions of the APEXes from network because the downloaded APEXes can't be flattened. Flattened APEXes can be updated only via a regular OTA.

Flattened APEX is the default configuration. This means that all APEXes are by default flattened unless you explicitly configure your device to build non-flattened APEXes to support APEX updates (as explained above).

Mixing flattened and non-flattened APEXes in a device is NOT supported. APEXes in a device must either be all non-flattened or all flattened. This is especially important when shipping pre-signed APEX prebuilts for projects such as Mainline. APEXes that aren't presigned (that is, built from the source) should also be non-flattened and signed with proper keys. The device should inherit from updatable_apex.mk as explained in Updating a service with an APEX .

Compressed APEXes

Android 12 and later feature APEX compression for reducing the storage impact of updatable APEX packages. After an update to an APEX is installed, although its pre-installed version isn't used anymore, it still occupies the same amount of space. That occupied space remains unavailable.

APEX compression minimizes this storage impact by using a highly compressed set of APEX files on read-only partitions (such as the /system partition). Android 12 and later use a DEFLATE zip compression algorithm.

Compression doesn't provide optimization to the following:

Bootstrap APEXes that are required to be mounted very early in the boot sequence.
Nonupdatable APEXes. Compression is only beneficial if an updated version of an APEX is installed on the /data partition. A full list of updatable APEXes is available on the Modular System Components page.
Dynamic shared libs APEXes. Since apexd always activates both versions of such APEXes (pre-installed and upgraded), compressing them doesn't add value.

Compressed APEX file format

This is the format of a compressed APEX file.

Diagram shows the format of a compressed APEX file

Figure 2. Compressed APEX file format

At the top level, a compressed APEX file is a zip file containing the original apex file in deflated form with a compression level of 9, and with other files stored uncompressed.

Four files comprise an APEX file:

original_apex : deflated with compression level of 9 This is the original, uncompressed APEX file .
apex_manifest.pb : stored only
AndroidManifest.xml : stored only
apex_pubkey : stored only

The apex_manifest.pb , AndroidManifest.xml , and apex_pubkey files are copies of their corresponding files in original_apex .

Build compressed APEX

Compressed APEX can be built using the apex_compression_tool.py tool located at system/apex/tools .

Several parameters related to APEX compression are available in the build system.

In Android.bp whether an APEX file is compressible is controlled by the compressible property:

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

A PRODUCT_COMPRESSED_APEX product flag controls whether a system image built from source must contain compressed APEX files.

For local experimentation you can force a build to compress APEXes by setting OVERRIDE_PRODUCT_COMPRESSED_APEX= to true .

Compressed APEX files generated by the build system have the .capex extension. The extension makes it easier to distinguish between compressed and uncompressed versions of an APEX file.

Supported compression algorithms

Android 12 only supports deflate-zip compression.

Activate a compressed APEX file during boot

Before a compressed APEX can be activated, the original_apex file inside it's decompressed into the /data/apex/decompressed directory. The resulting decompressed APEX file is hard-linked to the /data/apex/active directory.

Consider the following example as an illustration of the process described above.

Consider /system/apex/com.android.foo.capex as a compressed APEX being activated, with versionCode 37.

The original_apex file inside /system/apex/com.android.foo.capex is decompressed into /data/apex/decompressed/com.android.foo@37.apex .
restorecon /data/apex/decompressed/com.android.foo@37.apex is performed to verify that it has a correct SELinux label.
Verification checks are performed on /data/apex/decompressed/com.android.foo@37.apex to ensure its validity: apexd checks the public key bundled in /data/apex/decompressed/com.android.foo@37.apex to verify that it's equal to the one bundled in /system/apex/com.android.foo.capex .
The /data/apex/decompressed/com.android.foo@37.apex file is hard-linked to the /data/apex/active/com.android.foo@37.apex directory.
The regular activation logic for uncompressed APEX files is performed on /data/apex/active/com.android.foo@37.apex .

Interaction with OTA

Compressed APEX files have implications on OTA delivery and application. Since an OTA update might contain a compressed APEX file with a higher version level than what's active on a device, a certain amount of free space must be reserved before a device is rebooted to apply an OTA update.

To support the OTA system, apexd exposes these two binder APIs:

calculateSizeForCompressedApex - calculates the size required to decompress APEX files in an OTA package. This can be used to verify that a device has enough space before an OTA gets downloaded.
reserveSpaceForCompressedApex - reserves space on the disk for future use by apexd for decompressing compressed APEX files inside the OTA package.

In the case of an A/B OTA update, apexd attempts decompression in the background as part of the postinstall OTA routine. If decompression fails, apexd performs the decompression during the boot that applies the OTA update.

Alternatives considered when developing APEX

Here are some options that AOSP considered when designing the APEX file format, and why they were either included or excluded.

Regular package management systems

Linux distributions have package management systems like dpkg and rpm , which are powerful, mature, and robust. However, they weren't adopted for APEX because they can't protect the packages after installation. Verification is performed only when packages are being installed. Attackers can break the integrity of the installed packages, unnoticed. This is a regression for Android where all system components were stored in read-only file systems whose integrity is protected by dm-verity for every I/O. Any tampering to system components must either be prohibited, or be detectable so that the device can refuse to boot if compromised.

dm-crypt for integrity

The files in an APEX container are from built-in partitions (for example, the /system partition) that are protected by dm-verity, where any modification to the files are prohibited even after the partitions are mounted. To provide the same level of security to the files, all files in an APEX are stored in a file system image that is paired with a hash tree and a vbmeta descriptor. Without dm-verity, an APEX in the /data partition is vulnerable to unintended modifications that are made after it's been verified and installed.

In fact, the /data partition is also protected by encryption layers such as dm-crypt. Although this provides some level of protection against tampering, its primary purpose is privacy, not integrity. When an attacker gains access to the /data partition, there can be no further protection, and this again is a regression compared to every system component being in the /system partition. The hash tree inside an APEX file together with dm-verity provides the same level of content protection.

Redirect paths from /system to /apex

System component files packaged in an APEX are accessible via new paths like /apex/<name>/lib/libfoo.so . When the files were part of the /system partition, they were accessible via paths such as /system/lib/libfoo.so . A client of an APEX file (other APEX files or the platform) must use the new paths. You might need to update existing code as a result of the path change.

Although one way to avoid the path change is to overlay the file contents in an APEX file onto the /system partition, the Android team decided not to overlay files on the /system partition because this could impact performance as the number of files being overlaid (possibly even stacked one after another) increased.

Another option was to hijack file-access functions such as open , stat , and readlink , so that paths beginning with /system were redirected to their corresponding paths under /apex . The Android team discarded this option because it's infeasible to change all functions that accept paths. For example, some apps statically link Bionic, which implements the functions. In such cases, those apps don't get redirected.

The Android Pony EXpress (APEX) container format was introduced in Android 10 and it's used in the install flow for lower-level system modules. This format facilitates the updates of system components that don't fit into the standard Android application model. Some example components are native services and libraries, hardware abstraction layers ( HALs ), runtime ( ART ), and class libraries.

The term "APEX" can also refer to an APEX file.

পটভূমি

Although Android supports updates of modules that fit within the standard app model (for example, services, activities) via package installer apps (such as the Google Play Store app), using a similar model for lower-level OS components has the following drawbacks:

APK-based modules can't be used early in the boot sequence. The package manager is the central repository of information about apps and can only be started from the activity manager, which becomes ready in a later stage of the boot procedure.
The APK format (particularly the manifest) is designed for Android apps and system modules aren't always a good fit.

ডিজাইন

This section describes the high-level design of the APEX file format and the APEX manager, which is a service that manages APEX files.

For more information on why this design for APEX was selected, see Alternatives considered when developing APEX .

APEX format

This is the format of an APEX file.

APEX file format

Figure 1. APEX file format

At the top level, an APEX file is a zip file in which files are stored uncompressed and located at 4 KB boundaries.

The four files in an APEX file are:

apex_manifest.json
AndroidManifest.xml
apex_payload.img
apex_pubkey

The apex_manifest.json file contains the package name and version, which identify an APEX file. This is an ApexManifest protocol buffer in JSON format.

The AndroidManifest.xml file allows the APEX file to use APK-related tools and infrastructure such as ADB, PackageManager, and package installer apps (such as Play Store). For example, the APEX file can use an existing tool such as aapt to inspect basic metadata from the file. The file contains package name and version information. This information is generally also available in apex_manifest.json .

apex_manifest.json is recommended over AndroidManifest.xml for new code and systems that deal with APEX. AndroidManifest.xml might contain additional targeting information that can be used by the existing app publishing tools.

apex_payload.img is an ext4 file system image backed by dm-verity. The image is mounted at runtime via a loopback device. Specifically, the hash tree and metadata block are created using the libavb library. The file system payload isn't parsed (because the image should be mountable in place). Regular files are included inside the apex_payload.img file.

apex_pubkey is the public key used to sign the file system image. At runtime, this key ensures that the downloaded APEX is signed with the same entity that signs the same APEX in the built-in partitions.

APEX naming guidelines

To help prevent naming conflicts between new APEXes as the platform advances, use the following naming guidelines:

com.android.*
- Reserved for AOSP APEXes. Not unique to any company or device.
com.<companyname>.*
- Reserved for a company. Potentially used by multiple devices from that company.
com.<companyname>.<devicename>.*
- Reserved for APEXes unique to a specific device (or subset of devices).

APEX manager

The APEX manager (or apexd ) is a standalone native process responsible for verifying, installing, and uninstalling APEX files. This process is launched and is ready early in the boot sequence. APEX files are normally pre-installed on the device under /system/apex . The APEX manager defaults to using these packages if no updates are available.

The update sequence of an APEX uses the PackageManager class and is as follows.

An APEX file is downloaded via a package installer app, ADB, or other source.
The package manager starts the installation procedure. Upon recognizing that the file is an APEX, the package manager transfers control to the APEX manager.
The APEX manager verifies the APEX file.
If the APEX file is verified, the internal database of the APEX manager is updated to reflect that the APEX file gets activated at next boot.
The install requestor receives a broadcast upon successful package verification.
To continue the installation, the system must be rebooted.
At next boot, the APEX manager starts, reads the internal database, and does the following for each APEX file listed:
1. Verifies the APEX file.
2. Creates a loopback device from the APEX file.
3. Creates a device mapper block device on top of the loopback device.
4. Mounts the device mapper block device onto a unique path (for example, /apex/ name @ ver ).

When all APEX files listed in the internal database are mounted, the APEX manager provides a binder service for other system components to query information about the installed APEX files. For example, the other system components can query the list of APEX files installed in the device or query the exact path where a specific APEX is mounted, so the files can be accessed.

APEX files are APK files

APEX files are valid APK files because they're signed zip archives (using the APK signature scheme) containing an AndroidManifest.xml file. This allows APEX files to use the infrastructure for APK files, such as a package installer app, the signing utility, and the package manager.

The AndroidManifest.xml file inside an APEX file is minimal, consisting of the package name , versionCode , and optional targetSdkVersion , minSdkVersion , and maxSdkVersion for fine-grained targeting. This information allows APEX files to be delivered via existing channels such as package installer apps and ADB.

File types supported

The APEX format supports these file types:

Native shared libs
Native executables
JAR files
ডেটা ফাইল
কনফিগ ফাইল

This doesn't mean that APEX can update all of these file types. Whether a file type can be updated depends on the platform and how stable the definitions of the interfaces for the files types are.

Signing options

APEX files are signed in two ways. First, the apex_payload.img (specifically, the vbmeta descriptor appended to apex_payload.img ) file is signed with a key. Then, the entire APEX is signed using the APK signature scheme v3 . Two different keys are used in this process.

On the device side, a public key corresponding to the private key used to sign the vbmeta descriptor is installed. The APEX manager uses the public key to verify APEXes that are requested to be installed. Each APEX must be signed with different keys and is enforced both at build time and at runtime.

APEX in built-in partitions

APEX files can be located in built-in partitions such as /system . The partition is already over dm-verity, so the APEX files are mounted directly over the loopback device.

If an APEX is present in a built-in partition, the APEX can be updated by providing an APEX package with the same package name and a greater than or equal to version code. The new APEX is stored in /data and, similar to APKs, the newly installed version shadows the version already present in the built-in partition. But unlike APKs, the newly installed version of the APEX is only activated after reboot.

Kernel requirements

To support APEX mainline modules on an Android device, the following Linux kernel features are required: the loopback driver and dm-verity. The loopback driver mounts the file system image in an APEX module and dm-verity verifies the APEX module.

The performance of the loopback driver and dm-verity is important in achieving good system performance when using APEX modules.

Supported kernel versions

APEX mainline modules are supported on devices using kernel versions 4.4 or higher. New devices launching with Android 10 or higher must use kernel version 4.9 or higher to support APEX modules.

Required kernel patches

The required kernel patches for supporting APEX modules are included in the Android common tree. To get the patches to support APEX, use the latest version of the Android common tree.

Kernel version 4.4

This version is only supported for devices that are upgraded from Android 9 to Android 10 and want to support APEX modules. To get the required patches, a down-merge from the android-4.4 branch is strongly recommended. The following is a list of the required individual patches for kernel version 4.4.

UPSTREAM: loop: add ioctl for changing logical block size ( 4.4 )
BACKPORT: block/loop: set hw_sectors ( 4.4 )
UPSTREAM: loop: Add LOOP_SET_BLOCK_SIZE in compat ioctl ( 4.4 )
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 )
Revert "ANDROID: dm verity: add minimum prefetch size" ( 4.4 )
UPSTREAM: loop: drop caches if offset or block_size are changed ( 4.4 )

Kernel versions 4.9/4.14/4.19

To get the required patches for kernel versions 4.9/4.14/4.19, down-merge from the android-common branch.

Required kernel configuration options

The following list shows the base configuration requirements for supporting APEX modules that were introduced in Android 10. The items with an asterisk (*) are existing requirements from Android 9 and lower.

(*) 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

Kernel command-line parameter requirements

To support APEX, ensure the kernel command-line parameters meet the following requirements:

loop.max_loop must NOT be set
loop.max_part must be <= 8

Build an APEX

This section describes how to build an APEX using the Android build system. The following is an example of Android.bp for an APEX named apex.test .

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 example:

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

file_contexts example:

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

File types and locations in APEX

ফাইলের ধরন	Location in APEX
Shared libraries	`/lib` and `/lib64` ( `/lib/arm` for translated arm in x86)
Executables	`/bin`
Java libraries	`/javalib`
পূর্বনির্মাণ	`/etc`

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

APEX files automatically include transitive dependencies of native shared libs or executables. For example, if libFoo depends on libBar , the two libs are included when only libFoo is listed in the native_shared_libs property.

Handle multiple ABIs

Install the native_shared_libs property for both primary and secondary application binary interfaces (ABIs) of the device. If an APEX targets devices with a single ABI (that is, 32 bit only or 64 bit only), only libraries with the corresponding ABI are installed.

Install the binaries property only for the primary ABI of the device as described below:

If the device is 32 bit only, only the 32-bit variant of the binary is installed.
If the device is 64 bit only, then only the 64-bit variant of the binary is installed.

first : Matches the primary ABI of the device. This is the default for binaries.
lib32 : Matches the 32-bit ABI of the device, if supported.
lib64 : Matches the 64-bit ABI of the device, it supported.
prefer32 : Matches the 32-bit ABI of the device, if supported. If the 32-bit ABI isn't supported, matches the 64-bit ABI.
both : Matches both ABIs. This is the default for native_shared_libraries .

The java , libraries , and prebuilts properties are ABI-agnostic.

This example is for a device that supports 32/64 and doesn't prefer 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 signing

Sign each APEX with different keys. When a new key is required, create a public-private key pair and make an apex_key module. Use the key property to sign the APEX using the key. The public key is automatically included in the APEX with the name 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",
}

In the above example, the name of the public key ( foo ) becomes the ID of the key. The ID of the key used to sign an APEX is written in the APEX. At runtime, apexd verifies the APEX using a public key with the same ID in the device.

APEX signing

Sign APEXes in the same way as you sign APKs. Sign APEXes twice; once for the mini file system ( apex_payload.img file) and once for the entire file.

To sign an APEX at the file-level, set the certificate property in one of these three ways:

Not set: If no value is set, the APEX is signed with the certificate located at PRODUCT_DEFAULT_DEV_CERTIFICATE . If no flag is set, the path defaults to build/target/product/security/testkey .
<name> : The APEX is signed with the <name> certificate in the same directory as PRODUCT_DEFAULT_DEV_CERTIFICATE .
:<name> : The APEX is signed with the certificate that is defined by the Soong module named <name> . The certificate module can be defined as follows.

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)
}

Install an APEX

To install an APEX, use ADB.

adb install apex_file_name
adb reboot

If supportsRebootlessUpdate is set to true in apex_manifest.json and the currently installed APEX is unused (for instance, any services it contains have been stopped), then a new APEX can be installed without a reboot with the --force-non-staged flag.

adb install --force-non-staged apex_file_name

Use an APEX

After reboot, the APEX is mounted at the /apex/<apex_name>@<version> directory. Multiple versions of the same APEX can be mounted at the same time. Among the mount paths, the one that corresponds to the latest version is bind-mounted at /apex/<apex_name> .

Clients can use the bind-mounted path to read or execute files from APEX.

APEXes are typically used as follows:

An OEM or ODM preloads an APEX under /system/apex when the device is shipped.
Files in the APEX are accessed via the /apex/<apex_name>/ path.
When an updated version of the APEX is installed in /data/apex , the path points to the new APEX after reboot.

Update a service with an APEX

To update a service using an APEX:

Mark the service in the system partition as updatable. Add the option updatable to the service definition.

/system/etc/init/myservice.rc:

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

Create a new .rc file for the updated service. Use the override option to redefine the existing service.

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

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

Service definitions can only be defined in the .rc file of an APEX. Action triggers aren't supported in APEXes.

If a service marked as updatable starts before the APEXes are activated, the start is delayed until the activation of the APEXes is complete.

Configure system to support APEX updates

Set the following system property to true to support APEX file updates.

<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)

Flattened APEX

Activating a flattened APEX doesn't involve the loop device. The entire directory /system/apex/my.apex is directly bind-mounted to /apex/name@ver .

Flattened APEXes can't be updated by downloading updated versions of the APEXes from network because the downloaded APEXes can't be flattened. Flattened APEXes can be updated only via a regular OTA.

Compressed APEXes

Compression doesn't provide optimization to the following:

Bootstrap APEXes that are required to be mounted very early in the boot sequence.
Nonupdatable APEXes. Compression is only beneficial if an updated version of an APEX is installed on the /data partition. A full list of updatable APEXes is available on the Modular System Components page.
Dynamic shared libs APEXes. Since apexd always activates both versions of such APEXes (pre-installed and upgraded), compressing them doesn't add value.

Compressed APEX file format

This is the format of a compressed APEX file.

Diagram shows the format of a compressed APEX file

Figure 2. Compressed APEX file format

At the top level, a compressed APEX file is a zip file containing the original apex file in deflated form with a compression level of 9, and with other files stored uncompressed.

Four files comprise an APEX file:

original_apex : deflated with compression level of 9 This is the original, uncompressed APEX file .
apex_manifest.pb : stored only
AndroidManifest.xml : stored only
apex_pubkey : stored only

The apex_manifest.pb , AndroidManifest.xml , and apex_pubkey files are copies of their corresponding files in original_apex .

Build compressed APEX

Compressed APEX can be built using the apex_compression_tool.py tool located at system/apex/tools .

Several parameters related to APEX compression are available in the build system.

In Android.bp whether an APEX file is compressible is controlled by the compressible property:

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

A PRODUCT_COMPRESSED_APEX product flag controls whether a system image built from source must contain compressed APEX files.

For local experimentation you can force a build to compress APEXes by setting OVERRIDE_PRODUCT_COMPRESSED_APEX= to true .

Compressed APEX files generated by the build system have the .capex extension. The extension makes it easier to distinguish between compressed and uncompressed versions of an APEX file.

Supported compression algorithms

Android 12 only supports deflate-zip compression.

Activate a compressed APEX file during boot

Consider the following example as an illustration of the process described above.

Consider /system/apex/com.android.foo.capex as a compressed APEX being activated, with versionCode 37.

The original_apex file inside /system/apex/com.android.foo.capex is decompressed into /data/apex/decompressed/com.android.foo@37.apex .
restorecon /data/apex/decompressed/com.android.foo@37.apex is performed to verify that it has a correct SELinux label.
Verification checks are performed on /data/apex/decompressed/com.android.foo@37.apex to ensure its validity: apexd checks the public key bundled in /data/apex/decompressed/com.android.foo@37.apex to verify that it's equal to the one bundled in /system/apex/com.android.foo.capex .
The /data/apex/decompressed/com.android.foo@37.apex file is hard-linked to the /data/apex/active/com.android.foo@37.apex directory.
The regular activation logic for uncompressed APEX files is performed on /data/apex/active/com.android.foo@37.apex .

Interaction with OTA

To support the OTA system, apexd exposes these two binder APIs:

calculateSizeForCompressedApex - calculates the size required to decompress APEX files in an OTA package. This can be used to verify that a device has enough space before an OTA gets downloaded.
reserveSpaceForCompressedApex - reserves space on the disk for future use by apexd for decompressing compressed APEX files inside the OTA package.

Alternatives considered when developing APEX

Here are some options that AOSP considered when designing the APEX file format, and why they were either included or excluded.