বিক্রেতা 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 নির্ভরতার জন্য স্থিতিশীল নেটিভ ইন্টারফেসের মধ্যে রয়েছে stubs সহ cc_library , ndk_library , বা llndk_library । এই নির্ভরতাগুলি প্যাকেজিং থেকে বাদ দেওয়া হয়, এবং নির্ভরতাগুলি APEX ম্যানিফেস্টে রেকর্ড করা হয়। ম্যানিফেস্টটি linkerconfig দ্বারা প্রসেস করা হয় যাতে রানটাইমে এক্সটার্নাল নেটিভ নির্ভরতা পাওয়া যায়।

/system পার্টিশনে APEX-এর বিপরীতে, ভেন্ডর APEXs সাধারণত একটি নির্দিষ্ট VNDK সংস্করণের সাথে সংযুক্ত থাকে। VNDK লাইব্রেরিগুলি রিলিজের মধ্যে ABI স্থিতিশীলতার গ্যারান্টি দেয়, তাই আমরা VNDK লাইব্রেরিগুলিকে স্থিতিশীল হিসাবে বিবেচনা করতে পারি এবং use_vndk_as_stable প্রপার্টি ব্যবহার করে APEX থেকে বাদ দিয়ে ভেন্ডর APEX-এর আকার কমাতে পারি।

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

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

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

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

HAL বাস্তবায়ন

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

• সেন্সর HAL
• ভাইব্রেটর HAL
• ওয়াইফাই HAL
• টেলিফোনি HAL

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

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"],
  ..
}

APEXes-এর মধ্যে Init স্ক্রিপ্টগুলিতে শুধুমাত্র service সংজ্ঞা থাকতে পারে। Vendor APEXes-এর Init স্ক্রিপ্টে on <property> নির্দেশাবলীও থাকতে পারে।

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

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

উদাহরণ:

• ভাইব্রেটর সার্ভিস ফার্মওয়্যার

নিম্নরূপ 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-এর ভিতরে প্রি-বিল্ট করা হয় এবং আরও কিছু যোগ করা হচ্ছে।

উদাহরণ:

• বৈশিষ্ট্য ঘোষণা XMLs
  • সেন্সর HAL বিক্রেতা APEX-এ পূর্বনির্মাণ হিসাবে XML গুলিকে বৈশিষ্ট্যযুক্ত করে৷
• ইনপুট কনফিগার ফাইল
  • একটি কনফিগার-শুধু বিক্রেতা APEX-এ প্রিবিল্ট হিসাবে টাচস্ক্রিন কনফিগার করে

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

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

উদাহরণ:

• Cuttlefish এমুলেটেড ক্যামেরা HAL 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;

দ্রষ্টব্য: ক্রমাগত sysprop পরিবর্তন করা অবিলম্বে মাউন্ট করা APEX পরিবর্তন করে না; apexd কমান্ডের মাধ্যমে প্রপ লোড করতে এবং নতুন APEX সক্রিয় করতে ডিভাইসটিকে রিবুট করতে হবে।

যদি ডিভাইসটি ফ্ল্যাশ করার পরে (যেমন 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";