বিক্রেতা APEX

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

ভেন্ডর এপেক্সগুলি বিল্ড সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে /vendor পার্টিশনে ইনস্টল করা হয় এবং অন্যান্য পার্টিশনের APEX-এর মতো apexd দ্বারা রানটাইমে সক্রিয় করা হয়।

কেস ব্যবহার করুন

বিক্রেতা ইমেজ মডুলারাইজেশন

APEXes বিক্রেতার চিত্রগুলিতে বৈশিষ্ট্য বাস্তবায়নের একটি প্রাকৃতিক বান্ডলিং এবং মডুলারাইজেশনের সুবিধা দেয়।

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

উদাহরণস্বরূপ, একটি OEM তাদের ডিভাইসটি AOSP ওয়াইফাই বাস্তবায়ন APEX, SoC ব্লুটুথ বাস্তবায়ন APEX এবং একটি কাস্টম OEM টেলিফোনি বাস্তবায়ন APEX এর সাথে রচনা করতে বেছে নিতে পারে৷

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

বিকাশকারী পুনরাবৃত্তি

বিক্রেতা APEXs একটি বিক্রেতা APEX-এর ভিতরে, wifi HAL-এর মতো একটি সম্পূর্ণ বৈশিষ্ট্য বাস্তবায়ন বান্ডিল করে ভেন্ডর মডিউলগুলি তৈরি করার সময় বিকাশকারীদের দ্রুত পুনরাবৃত্তি করতে সহায়তা করে৷ বিকাশকারীরা তখন সম্পূর্ণ বিক্রেতার চিত্র পুনর্নির্মাণের পরিবর্তে পরিবর্তনগুলি পরীক্ষা করার জন্য বিক্রেতা APEX-কে তৈরি করতে এবং পৃথকভাবে চাপ দিতে পারে।

এটি বিকাশকারীদের জন্য বিকাশকারী পুনরাবৃত্তি চক্রকে সহজ করে এবং গতি বাড়ায় যারা প্রাথমিকভাবে একটি বৈশিষ্ট্য এলাকায় কাজ করে এবং শুধুমাত্র সেই বৈশিষ্ট্য এলাকায় পুনরাবৃত্তি করতে চায়।

একটি APEX-এ একটি বৈশিষ্ট্য অঞ্চলের প্রাকৃতিক বান্ডলিং সেই বৈশিষ্ট্য এলাকার জন্য পরিবর্তনগুলি তৈরি, ঠেলে দেওয়া এবং পরীক্ষা করার প্রক্রিয়াটিকেও সরল করে৷ উদাহরণস্বরূপ, একটি APEX পুনরায় ইনস্টল করা স্বয়ংক্রিয়ভাবে APEX-এর অন্তর্ভুক্ত যেকোন বান্ডিল লাইব্রেরি বা কনফিগার ফাইলগুলিকে আপডেট করে৷

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

উদাহরণ কর্মপ্রবাহ:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

উদাহরণ

বেসিক

ডিভাইসের প্রয়োজনীয়তা, ফাইল ফরম্যাটের বিশদ এবং ইনস্টলেশন পদক্ষেপ সহ জেনেরিক APEX তথ্যের জন্য প্রধান APEX ফাইল বিন্যাস পৃষ্ঠাটি দেখুন।

Android.bp এ, vendor: true সম্পত্তি একটি APEX মডিউলকে একটি বিক্রেতা APEX করে।

apex {
  ..
  vendor: true,
  ..
}

বাইনারি এবং শেয়ার করা লাইব্রেরি

একটি APEX APEX পেলোডের মধ্যে ট্রানজিটিভ নির্ভরতা অন্তর্ভুক্ত করে যদি না তাদের স্থিতিশীল ইন্টারফেস থাকে।

বিক্রেতা APEX নির্ভরতার জন্য স্থিতিশীল নেটিভ ইন্টারফেসের মধ্যে রয়েছে cc_library সহ stubs এবং LLNDK লাইব্রেরি। এই নির্ভরতাগুলি প্যাকেজিং থেকে বাদ দেওয়া হয়, এবং নির্ভরতাগুলি APEX ম্যানিফেস্টে রেকর্ড করা হয়। ম্যানিফেস্টটি linkerconfig দ্বারা প্রসেস করা হয় যাতে রানটাইমে এক্সটার্নাল নেটিভ নির্ভরতা পাওয়া যায়।

নিম্নলিখিত স্নিপেটে, APEX-এ বাইনারি ( my_service ) এবং এর অ-স্থিতিশীল নির্ভরতা ( *.so ফাইল) উভয়ই রয়েছে।

apex {
  ..
  vendor: true,
  binaries: ["my_service"],
  ..
}

নিম্নলিখিত স্নিপেটে, APEX-এ রয়েছে শেয়ার্ড লাইব্রেরি my_standalone_lib এবং এর যেকোনো অ-স্থিতিশীল নির্ভরতা (উপরে বর্ণিত)।

apex {
  ..
  vendor: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

APEX ছোট করুন

APEX বড় হতে পারে কারণ এটি অ-স্থিতিশীল নির্ভরতা বান্ডিল করে। আমরা স্ট্যাটিক লিঙ্কিং ব্যবহার করার পরামর্শ দিই। libc++.so এবং libbase.so মতো সাধারণ লাইব্রেরিগুলি HAL বাইনারিগুলির সাথে স্ট্যাটিকভাবে লিঙ্ক করা যেতে পারে। একটি স্থিতিশীল ইন্টারফেস প্রদানের জন্য একটি নির্ভরতা তৈরি করা আরেকটি বিকল্প হতে পারে। নির্ভরতা APEX এ বান্ডিল করা হবে না।

HAL বাস্তবায়ন

একটি HAL বাস্তবায়ন সংজ্ঞায়িত করতে, নিম্নলিখিত উদাহরণগুলির মতো একটি ভেন্ডর APEX-এর ভিতরে সংশ্লিষ্ট বাইনারি এবং লাইব্রেরিগুলি প্রদান করুন:

HAL বাস্তবায়নকে সম্পূর্ণরূপে এনক্যাপসুলেট করার জন্য, APEX-এর যেকোনো প্রাসঙ্গিক VINTF খণ্ড এবং init স্ক্রিপ্টগুলিও নির্দিষ্ট করা উচিত।

VINTF টুকরা

VINTF টুকরাগুলি APEX-এর etc/vintf এ থাকা অবস্থায় বিক্রেতা APEX থেকে পরিবেশন করা যেতে পারে৷

APEX-এ VINTF খণ্ডগুলি এম্বেড করতে prebuilts সম্পত্তি ব্যবহার করুন।

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

ক্যোয়ারী API

যখন VINTF খণ্ডগুলি APEX-এ যোগ করা হয়, HAL ইন্টারফেস এবং APEX নামের ম্যাপিং পেতে libbinder_ndk API ব্যবহার করুন।

  • AServiceManager_isUpdatableViaApex("com.android.foo.IFoo/default") : true যদি HAL উদাহরণটি APEX-এ সংজ্ঞায়িত করা হয়।
  • AServiceManager_getUpdatableApexName("com.android.foo.IFoo/default", ...) : APEX নাম পায় যা HAL উদাহরণকে সংজ্ঞায়িত করে।
  • AServiceManager_openDeclaredPassthroughHal("mapper", "instance", ...) : একটি পাসথ্রু HAL খুলতে এটি ব্যবহার করুন।

Init স্ক্রিপ্ট

APEXes দুটি উপায়ে init স্ক্রিপ্ট অন্তর্ভুক্ত করতে পারে: (A) APEX পেলোডের মধ্যে একটি পূর্বনির্মাণ টেক্সট ফাইল, অথবা (B) /vendor/etc এ একটি নিয়মিত init স্ক্রিপ্ট। আপনি একই APEX এর জন্য উভয় সেট করতে পারেন।

APEX এ Init স্ক্রিপ্ট:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

বিক্রেতা APEX-এর Init স্ক্রিপ্টে service সংজ্ঞা এবং on <property or event> নির্দেশাবলী থাকতে পারে।

নিশ্চিত করুন যে একটি service সংজ্ঞা একই APEX-এ একটি বাইনারি নির্দেশ করে৷ উদাহরণস্বরূপ, com.android.foo APEX foo-service নামে একটি পরিষেবা সংজ্ঞায়িত করতে পারে।

on foo-service /apex/com.android.foo/bin/foo
  ...

on ব্যবহার করার সময় সতর্কতা অবলম্বন করুন. যেহেতু APEXes-এর init স্ক্রিপ্টগুলি APEXes সক্রিয় হওয়ার পরে পার্স করা হয় এবং কার্যকর করা হয়, তাই কিছু ঘটনা বা বৈশিষ্ট্য ব্যবহার করা যাবে না। যত তাড়াতাড়ি সম্ভব ফায়ার অ্যাকশনের জন্য apex.all.ready=true ব্যবহার করুন। বুটস্ট্র্যাপ APEXes on init ব্যবহার করতে পারে, কিন্তু on early-init নয়।

ফার্মওয়্যার

উদাহরণ:

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

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

prebuilt_firmware মডিউলগুলি APEX-এর <apex name>/etc/firmware ডিরেক্টরিতে ইনস্টল করা আছে। ueventd ফার্মওয়্যার মডিউলগুলি খুঁজে পেতে /apex/*/etc/firmware ডিরেক্টরিগুলি স্ক্যান করে।

APEX-এর file_contexts যেকোন ফার্মওয়্যার পেলোড এন্ট্রিকে সঠিকভাবে লেবেল করা উচিত যাতে এই ফাইলগুলি রানটাইমে ueventd দ্বারা অ্যাক্সেসযোগ্য হয়; সাধারণত, vendor_file লেবেল যথেষ্ট। যেমন:

(/.*)? u:object_r:vendor_file:s0

কার্নেল মডিউল

একটি ভেন্ডর APEX-এ কার্নেল মডিউলগুলিকে পূর্বনির্মাণ মডিউল হিসাবে এম্বেড করুন, নিম্নরূপ।

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

APEX-এর file_contexts যেকোন কার্নেল মডিউল পেলোড এন্ট্রিকে সঠিকভাবে লেবেল করা উচিত। যেমন:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

কার্নেল মডিউল স্পষ্টভাবে ইনস্টল করা আবশ্যক. নিম্নলিখিত উদাহরণ init স্ক্রিপ্ট বিক্রেতা পার্টিশনে insmod মাধ্যমে ইনস্টলেশন দেখায়:

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

রানটাইম রিসোর্স ওভারলে

উদাহরণ:

rros সম্পত্তি ব্যবহার করে একটি ভেন্ডর APEX-এ রানটাইম রিসোর্স ওভারলে এম্বেড করুন।

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

অন্যান্য কনফিগারেশন ফাইল

ভেন্ডর APEXes বিভিন্ন অন্যান্য কনফিগার ফাইল সমর্থন করে যা সাধারণত ভেন্ডর পার্টিশনে পাওয়া যায় যেমন বিক্রেতা APEX-এর ভিতরে প্রি-বিল্ট করা হয় এবং আরও কিছু যোগ করা হচ্ছে।

উদাহরণ:

বুটস্ট্র্যাপ বিক্রেতা APEXes

APEXes সক্রিয় হওয়ার আগে keymint মতো কিছু HAL পরিষেবা পাওয়া উচিত। এই HALগুলি সাধারণত init স্ক্রিপ্টে তাদের পরিষেবা সংজ্ঞাতে early_hal সেট করে। আরেকটি উদাহরণ হল animation ক্লাস যা সাধারণত post-fs-data ইভেন্টের আগে শুরু হয়। যখন এই ধরনের একটি প্রারম্ভিক HAL পরিষেবা বিক্রেতা APEX-এ প্যাকেজ করা হয়, তখন শীর্ষস্থানটিকে "vendorBootstrap": true যাতে এটি আগে সক্রিয় করা যায়। মনে রাখবেন যে বুটস্ট্র্যাপ APEX-কে শুধুমাত্র পূর্বনির্মাণ অবস্থান থেকে সক্রিয় করা যেতে পারে যেমন /vendor/apex , /data/apex থেকে নয়।

সিস্টেম বৈশিষ্ট্য

এই সিস্টেমের বৈশিষ্ট্যগুলি যা ফ্রেমওয়ার্ক বিক্রেতা APEXesকে সমর্থন করার জন্য পড়ে:

  • input_device.config_file.apex=<apex name> - সেট করা হলে, ইনপুট কনফিগারেশন ফাইলগুলি ( *.idc , *.kl , এবং *.kcm ) APEX-এর /etc/usr ডিরেক্টরি থেকে অনুসন্ধান করা হয়।
  • ro.vulkan.apex=<apex name> - সেট করা হলে, Vulkan ড্রাইভার APEX থেকে লোড হয়। যেহেতু ভলকান ড্রাইভার প্রাথমিক HALs দ্বারা ব্যবহৃত হয়, তাই APEX বুটস্ট্র্যাপ APEX করুন এবং সেই লিঙ্কার নেমস্পেসটি দৃশ্যমান কনফিগার করুন।

setprop কমান্ড ব্যবহার করে init স্ক্রিপ্টে সিস্টেম বৈশিষ্ট্য সেট করুন।

অতিরিক্ত উন্নয়ন বৈশিষ্ট্য

বুটআপে APEX নির্বাচন

উদাহরণ:

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

উদাহরণ ব্যবহারের ক্ষেত্রে:

  • ওয়াইফাই HAL ভেন্ডর APEX-এর 3টি সংস্করণ ইনস্টল করুন: QA দলগুলি একটি সংস্করণ ব্যবহার করে ম্যানুয়াল বা স্বয়ংক্রিয় পরীক্ষা চালাতে পারে, তারপর অন্য সংস্করণে পুনরায় বুট করতে পারে এবং পরীক্ষাগুলি পুনরায় চালাতে পারে, তারপর চূড়ান্ত ফলাফলের তুলনা করতে পারে৷
  • ক্যামেরা HAL বিক্রেতা APEX-এর 2টি সংস্করণ ইনস্টল করুন, বর্তমান এবং পরীক্ষামূলক : Dogfooders একটি অতিরিক্ত ফাইল ডাউনলোড এবং ইনস্টল না করে পরীক্ষামূলক সংস্করণ ব্যবহার করতে পারে, যাতে তারা সহজেই ফিরে যেতে পারে৷

বুটআপের সময়, apexd সঠিক APEX সংস্করণ সক্রিয় করতে একটি নির্দিষ্ট বিন্যাস অনুসরণ করে sysprops সন্ধান করে।

সম্পত্তি কী জন্য প্রত্যাশিত বিন্যাস হল:

  • বুট কনফিগ
    • BoardConfig.mk এ ডিফল্ট মান সেট করতে ব্যবহৃত হয়।
    • androidboot.vendor.apex.<apex name>
  • ক্রমাগত sysprop
    • ডিফল্ট মান পরিবর্তন করতে ব্যবহৃত হয়, একটি ইতিমধ্যে বুট করা ডিভাইসে সেট করা হয়।
    • যদি উপস্থিত থাকে তাহলে bootconfig মান ওভাররাইড করে।
    • persist.vendor.apex.<apex name>

সম্পত্তির মান APEX এর ফাইলের নাম হওয়া উচিত যা সক্রিয় করা উচিত।

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

ডিফল্ট সংস্করণটি BoardConfig.mk এ bootconfig ব্যবহার করে কনফিগার করা উচিত:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

ডিভাইসটি বুট হওয়ার পরে, ক্রমাগত sysprop সেট করে সক্রিয় সংস্করণটি পরিবর্তন করুন:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

যদি ডিভাইসটি ফ্ল্যাশ করার পরে (যেমন fastboot oem কমান্ডের মাধ্যমে) বুটকনফিগ আপডেট করা সমর্থন করে, তাহলে মাল্টি-ইনস্টল করা APEX-এর জন্য বুটকনফিগ বৈশিষ্ট্য পরিবর্তন করলে বুটআপে সক্রিয় হওয়া সংস্করণও পরিবর্তন হয়।

Cuttlefish-এর উপর ভিত্তি করে ভার্চুয়াল রেফারেন্স ডিভাইসগুলির জন্য, আপনি লঞ্চ করার সময় সরাসরি bootconfig বৈশিষ্ট্য সেট করতে --extra_bootconfig_args কমান্ড ব্যবহার করতে পারেন। যেমন:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";
,

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

ভেন্ডর এপেক্সগুলি বিল্ড সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে /vendor পার্টিশনে ইনস্টল করা হয় এবং অন্যান্য পার্টিশনের APEX-এর মতো apexd দ্বারা রানটাইমে সক্রিয় করা হয়।

কেস ব্যবহার করুন

বিক্রেতা ইমেজ মডুলারাইজেশন

APEXes বিক্রেতার চিত্রগুলিতে বৈশিষ্ট্য বাস্তবায়নের একটি প্রাকৃতিক বান্ডলিং এবং মডুলারাইজেশনের সুবিধা দেয়।

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

উদাহরণস্বরূপ, একটি OEM তাদের ডিভাইসটি AOSP ওয়াইফাই বাস্তবায়ন APEX, SoC ব্লুটুথ বাস্তবায়ন APEX এবং একটি কাস্টম OEM টেলিফোনি বাস্তবায়ন APEX এর সাথে রচনা করতে বেছে নিতে পারে৷

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

বিকাশকারী পুনরাবৃত্তি

বিক্রেতা APEXs একটি বিক্রেতা APEX-এর ভিতরে, wifi HAL-এর মতো একটি সম্পূর্ণ বৈশিষ্ট্য বাস্তবায়ন বান্ডিল করে ভেন্ডর মডিউলগুলি তৈরি করার সময় বিকাশকারীদের দ্রুত পুনরাবৃত্তি করতে সহায়তা করে৷ বিকাশকারীরা তখন সম্পূর্ণ বিক্রেতার চিত্র পুনর্নির্মাণের পরিবর্তে পরিবর্তনগুলি পরীক্ষা করার জন্য বিক্রেতা APEX-কে তৈরি করতে এবং পৃথকভাবে চাপ দিতে পারে।

এটি বিকাশকারীদের জন্য বিকাশকারী পুনরাবৃত্তি চক্রকে সহজ করে এবং গতি বাড়ায় যারা প্রাথমিকভাবে একটি বৈশিষ্ট্য এলাকায় কাজ করে এবং শুধুমাত্র সেই বৈশিষ্ট্য এলাকায় পুনরাবৃত্তি করতে চায়।

একটি APEX-এ একটি বৈশিষ্ট্য অঞ্চলের প্রাকৃতিক বান্ডলিং সেই বৈশিষ্ট্য এলাকার জন্য পরিবর্তনগুলি তৈরি, ঠেলে দেওয়া এবং পরীক্ষা করার প্রক্রিয়াটিকেও সরল করে৷ উদাহরণস্বরূপ, একটি APEX পুনরায় ইনস্টল করা স্বয়ংক্রিয়ভাবে APEX-এর অন্তর্ভুক্ত যেকোন বান্ডিল লাইব্রেরি বা কনফিগার ফাইলগুলিকে আপডেট করে৷

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

উদাহরণ কর্মপ্রবাহ:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

উদাহরণ

বেসিক

ডিভাইসের প্রয়োজনীয়তা, ফাইল ফরম্যাটের বিশদ এবং ইনস্টলেশন পদক্ষেপ সহ জেনেরিক APEX তথ্যের জন্য প্রধান APEX ফাইল বিন্যাস পৃষ্ঠাটি দেখুন।

Android.bp এ, vendor: true সম্পত্তি একটি APEX মডিউলকে একটি বিক্রেতা APEX করে।

apex {
  ..
  vendor: true,
  ..
}

বাইনারি এবং শেয়ার করা লাইব্রেরি

একটি APEX APEX পেলোডের মধ্যে ট্রানজিটিভ নির্ভরতা অন্তর্ভুক্ত করে যদি না তাদের স্থিতিশীল ইন্টারফেস থাকে।

বিক্রেতা APEX নির্ভরতার জন্য স্থিতিশীল নেটিভ ইন্টারফেসের মধ্যে রয়েছে cc_library সহ stubs এবং LLNDK লাইব্রেরি। এই নির্ভরতাগুলি প্যাকেজিং থেকে বাদ দেওয়া হয়, এবং নির্ভরতাগুলি APEX ম্যানিফেস্টে রেকর্ড করা হয়। ম্যানিফেস্টটি linkerconfig দ্বারা প্রসেস করা হয় যাতে রানটাইমে এক্সটার্নাল নেটিভ নির্ভরতা পাওয়া যায়।

নিম্নলিখিত স্নিপেটে, APEX-এ বাইনারি ( my_service ) এবং এর অ-স্থিতিশীল নির্ভরতা ( *.so ফাইল) উভয়ই রয়েছে।

apex {
  ..
  vendor: true,
  binaries: ["my_service"],
  ..
}

নিম্নলিখিত স্নিপেটে, APEX-এ রয়েছে শেয়ার্ড লাইব্রেরি my_standalone_lib এবং এর যেকোনো অ-স্থিতিশীল নির্ভরতা (উপরে বর্ণিত)।

apex {
  ..
  vendor: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

APEX ছোট করুন

APEX বড় হতে পারে কারণ এটি অ-স্থিতিশীল নির্ভরতা বান্ডিল করে। আমরা স্ট্যাটিক লিঙ্কিং ব্যবহার করার পরামর্শ দিই। libc++.so এবং libbase.so মতো সাধারণ লাইব্রেরিগুলি HAL বাইনারিগুলির সাথে স্ট্যাটিকভাবে লিঙ্ক করা যেতে পারে। একটি স্থিতিশীল ইন্টারফেস প্রদানের জন্য একটি নির্ভরতা তৈরি করা আরেকটি বিকল্প হতে পারে। নির্ভরতা APEX এ বান্ডিল করা হবে না।

HAL বাস্তবায়ন

একটি HAL বাস্তবায়ন সংজ্ঞায়িত করতে, নিম্নলিখিত উদাহরণগুলির মতো একটি ভেন্ডর APEX-এর ভিতরে সংশ্লিষ্ট বাইনারি এবং লাইব্রেরিগুলি প্রদান করুন:

HAL বাস্তবায়নকে সম্পূর্ণরূপে এনক্যাপসুলেট করার জন্য, APEX-এর যেকোনো প্রাসঙ্গিক VINTF খণ্ড এবং init স্ক্রিপ্টগুলিও নির্দিষ্ট করা উচিত।

VINTF টুকরা

VINTF টুকরাগুলি APEX-এর etc/vintf এ থাকা অবস্থায় বিক্রেতা APEX থেকে পরিবেশন করা যেতে পারে৷

APEX-এ VINTF খণ্ডগুলি এম্বেড করতে prebuilts সম্পত্তি ব্যবহার করুন।

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

ক্যোয়ারী API

যখন VINTF খণ্ডগুলি APEX-এ যোগ করা হয়, HAL ইন্টারফেস এবং APEX নামের ম্যাপিং পেতে libbinder_ndk API ব্যবহার করুন।

  • AServiceManager_isUpdatableViaApex("com.android.foo.IFoo/default") : true যদি HAL উদাহরণটি APEX-এ সংজ্ঞায়িত করা হয়।
  • AServiceManager_getUpdatableApexName("com.android.foo.IFoo/default", ...) : APEX নাম পায় যা HAL উদাহরণকে সংজ্ঞায়িত করে।
  • AServiceManager_openDeclaredPassthroughHal("mapper", "instance", ...) : একটি পাসথ্রু HAL খুলতে এটি ব্যবহার করুন।

Init স্ক্রিপ্ট

APEXes দুটি উপায়ে init স্ক্রিপ্ট অন্তর্ভুক্ত করতে পারে: (A) APEX পেলোডের মধ্যে একটি পূর্বনির্মাণ টেক্সট ফাইল, অথবা (B) /vendor/etc এ একটি নিয়মিত init স্ক্রিপ্ট। আপনি একই APEX এর জন্য উভয় সেট করতে পারেন।

APEX এ Init স্ক্রিপ্ট:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

বিক্রেতা APEX-এ Init স্ক্রিপ্টে service সংজ্ঞা এবং on <property or event> নির্দেশাবলী থাকতে পারে।

নিশ্চিত করুন যে একটি service সংজ্ঞা একই APEX-এ একটি বাইনারি নির্দেশ করে৷ উদাহরণস্বরূপ, com.android.foo APEX foo-service নামে একটি পরিষেবা সংজ্ঞায়িত করতে পারে।

on foo-service /apex/com.android.foo/bin/foo
  ...

on ব্যবহার করার সময় সতর্কতা অবলম্বন করুন. যেহেতু APEXes-এর init স্ক্রিপ্টগুলি APEXes সক্রিয় হওয়ার পরে পার্স করা হয় এবং কার্যকর করা হয়, তাই কিছু ঘটনা বা বৈশিষ্ট্য ব্যবহার করা যাবে না। যত তাড়াতাড়ি সম্ভব ফায়ার অ্যাকশনের জন্য apex.all.ready=true ব্যবহার করুন। বুটস্ট্র্যাপ APEXes on init ব্যবহার করতে পারে, কিন্তু on early-init নয়।

ফার্মওয়্যার

উদাহরণ:

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

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

prebuilt_firmware মডিউলগুলি APEX-এর <apex name>/etc/firmware ডিরেক্টরিতে ইনস্টল করা আছে। ueventd ফার্মওয়্যার মডিউলগুলি খুঁজে পেতে /apex/*/etc/firmware ডিরেক্টরিগুলি স্ক্যান করে।

APEX-এর file_contexts যেকোন ফার্মওয়্যার পেলোড এন্ট্রিকে সঠিকভাবে লেবেল করা উচিত যাতে এই ফাইলগুলি রানটাইমে ueventd দ্বারা অ্যাক্সেসযোগ্য হয়; সাধারণত, vendor_file লেবেল যথেষ্ট। যেমন:

(/.*)? u:object_r:vendor_file:s0

কার্নেল মডিউল

একটি ভেন্ডর APEX-এ কার্নেল মডিউলগুলিকে পূর্বনির্মাণ মডিউল হিসাবে এম্বেড করুন, নিম্নরূপ।

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

APEX-এর file_contexts যেকোন কার্নেল মডিউল পেলোড এন্ট্রিকে সঠিকভাবে লেবেল করা উচিত। যেমন:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

কার্নেল মডিউল স্পষ্টভাবে ইনস্টল করা আবশ্যক. নিম্নলিখিত উদাহরণ init স্ক্রিপ্ট বিক্রেতা পার্টিশনে insmod মাধ্যমে ইনস্টলেশন দেখায়:

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

রানটাইম রিসোর্স ওভারলে

উদাহরণ:

rros সম্পত্তি ব্যবহার করে একটি ভেন্ডর APEX-এ রানটাইম রিসোর্স ওভারলে এম্বেড করুন।

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

অন্যান্য কনফিগারেশন ফাইল

ভেন্ডর APEXes বিভিন্ন অন্যান্য কনফিগার ফাইল সমর্থন করে যা সাধারণত ভেন্ডর পার্টিশনে পাওয়া যায় যেমন বিক্রেতা APEX-এর ভিতরে প্রি-বিল্ট করা হয় এবং আরও কিছু যোগ করা হচ্ছে।

উদাহরণ:

বুটস্ট্র্যাপ বিক্রেতা APEXes

APEXes সক্রিয় হওয়ার আগে keymint মতো কিছু HAL পরিষেবা পাওয়া উচিত। এই HALগুলি সাধারণত init স্ক্রিপ্টে তাদের পরিষেবা সংজ্ঞাতে early_hal সেট করে। আরেকটি উদাহরণ হল animation ক্লাস যা সাধারণত post-fs-data ইভেন্টের আগে শুরু হয়। যখন এই ধরনের একটি প্রারম্ভিক HAL পরিষেবা বিক্রেতা APEX-এ প্যাকেজ করা হয়, তখন শীর্ষস্থানটিকে "vendorBootstrap": true যাতে এটি আগে সক্রিয় করা যায়। মনে রাখবেন যে বুটস্ট্র্যাপ APEX-কে শুধুমাত্র পূর্বনির্মাণ অবস্থান থেকে সক্রিয় করা যেতে পারে যেমন /vendor/apex , /data/apex থেকে নয়।

সিস্টেম বৈশিষ্ট্য

এই সিস্টেমের বৈশিষ্ট্যগুলি যা ফ্রেমওয়ার্ক বিক্রেতা APEXesকে সমর্থন করার জন্য পড়ে:

  • input_device.config_file.apex=<apex name> - সেট করা হলে, ইনপুট কনফিগারেশন ফাইলগুলি ( *.idc , *.kl , এবং *.kcm ) APEX-এর /etc/usr ডিরেক্টরি থেকে অনুসন্ধান করা হয়।
  • ro.vulkan.apex=<apex name> - সেট করা হলে, Vulkan ড্রাইভার APEX থেকে লোড হয়। যেহেতু ভলকান ড্রাইভার প্রাথমিক HALs দ্বারা ব্যবহৃত হয়, তাই APEX বুটস্ট্র্যাপ APEX করুন এবং সেই লিঙ্কার নেমস্পেসটি দৃশ্যমান কনফিগার করুন।

setprop কমান্ড ব্যবহার করে init স্ক্রিপ্টে সিস্টেম বৈশিষ্ট্য সেট করুন।

অতিরিক্ত উন্নয়ন বৈশিষ্ট্য

বুটআপে APEX নির্বাচন

উদাহরণ:

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

উদাহরণ ব্যবহারের ক্ষেত্রে:

  • ওয়াইফাই HAL ভেন্ডর APEX-এর 3টি সংস্করণ ইনস্টল করুন: QA দলগুলি একটি সংস্করণ ব্যবহার করে ম্যানুয়াল বা স্বয়ংক্রিয় পরীক্ষা চালাতে পারে, তারপর অন্য সংস্করণে পুনরায় বুট করতে পারে এবং পরীক্ষাগুলি পুনরায় চালাতে পারে, তারপর চূড়ান্ত ফলাফলের তুলনা করতে পারে৷
  • ক্যামেরা HAL বিক্রেতা APEX-এর 2টি সংস্করণ ইনস্টল করুন, বর্তমান এবং পরীক্ষামূলক : Dogfooders একটি অতিরিক্ত ফাইল ডাউনলোড এবং ইনস্টল না করে পরীক্ষামূলক সংস্করণ ব্যবহার করতে পারে, যাতে তারা সহজেই ফিরে যেতে পারে৷

বুটআপের সময়, apexd সঠিক APEX সংস্করণ সক্রিয় করতে একটি নির্দিষ্ট বিন্যাস অনুসরণ করে sysprops সন্ধান করে।

সম্পত্তি কী জন্য প্রত্যাশিত বিন্যাস হল:

  • বুট কনফিগ
    • BoardConfig.mk এ ডিফল্ট মান সেট করতে ব্যবহৃত হয়।
    • androidboot.vendor.apex.<apex name>
  • ক্রমাগত sysprop
    • ডিফল্ট মান পরিবর্তন করতে ব্যবহৃত হয়, একটি ইতিমধ্যে বুট করা ডিভাইসে সেট করা হয়।
    • যদি উপস্থিত থাকে তাহলে bootconfig মান ওভাররাইড করে।
    • persist.vendor.apex.<apex name>

সম্পত্তির মান APEX এর ফাইলের নাম হওয়া উচিত যা সক্রিয় করা উচিত।

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

ডিফল্ট সংস্করণটি BoardConfig.mk এ bootconfig ব্যবহার করে কনফিগার করা উচিত:

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

ডিভাইসটি বুট হওয়ার পরে, ক্রমাগত sysprop সেট করে সক্রিয় সংস্করণটি পরিবর্তন করুন:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

যদি ডিভাইসটি ফ্ল্যাশ করার পরে (যেমন fastboot oem কমান্ডের মাধ্যমে) বুটকনফিগ আপডেট করা সমর্থন করে, তাহলে মাল্টি-ইনস্টল করা APEX-এর জন্য বুটকনফিগ বৈশিষ্ট্য পরিবর্তন করলে বুটআপে সক্রিয় হওয়া সংস্করণও পরিবর্তন হয়।

Cuttlefish-এর উপর ভিত্তি করে ভার্চুয়াল রেফারেন্স ডিভাইসগুলির জন্য, আপনি লঞ্চ করার সময় সরাসরি bootconfig বৈশিষ্ট্য সেট করতে --extra_bootconfig_args কমান্ড ব্যবহার করতে পারেন। যেমন:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";