इस पेज का अनुवाद Cloud Translation API से किया गया है.

विक्रेता एपेक्स

आप निचले स्तर के एंड्रॉइड ओएस मॉड्यूल को पैकेज और इंस्टॉल करने के लिए APEX फ़ाइल प्रारूप का उपयोग कर सकते हैं। यह देशी सेवाओं और पुस्तकालयों, एचएएल कार्यान्वयन, फर्मवेयर, कॉन्फ़िगरेशन फ़ाइलों आदि जैसे घटकों के स्वतंत्र निर्माण और स्थापना की अनुमति देता है।

विक्रेता APEXes को बिल्ड सिस्टम द्वारा /vendor विभाजन में स्वचालित रूप से स्थापित किया जाता है और अन्य विभाजनों में APEXes की तरह ही रनटाइम पर apexd द्वारा सक्रिय किया जाता है।

बक्सों का इस्तेमाल करें

विक्रेता छवियों का मॉड्यूलरीकरण

APEXes विक्रेता छवियों पर फीचर कार्यान्वयन के प्राकृतिक बंडलिंग और मॉड्यूलराइजेशन की सुविधा प्रदान करता है।

जब विक्रेता छवियां स्वतंत्र रूप से निर्मित विक्रेता APEXes के संयोजन के रूप में बनाई जाती हैं, तो डिवाइस निर्माता अपने डिवाइस पर वांछित विशिष्ट विक्रेता कार्यान्वयन को आसानी से चुनने और चुनने में सक्षम होते हैं। निर्माता एक नया विक्रेता APEX भी बना सकते हैं यदि प्रदान किए गए APEX में से कोई भी उनकी आवश्यकता के अनुरूप नहीं है, या उनके पास बिल्कुल नया कस्टम हार्डवेयर है।

उदाहरण के लिए, एक OEM अपने डिवाइस को AOSP वाईफाई कार्यान्वयन APEX, SoC ब्लूटूथ कार्यान्वयन APEX और एक कस्टम OEM टेलीफोनी कार्यान्वयन APEX के साथ बनाना चुन सकता है।

विक्रेता APEXes के बिना, विक्रेता घटकों के बीच इतनी अधिक निर्भरता वाले कार्यान्वयन के लिए सावधानीपूर्वक समन्वय और ट्रैकिंग की आवश्यकता होती है। क्रॉस-फीचर संचार के किसी भी बिंदु पर स्पष्ट रूप से परिभाषित इंटरफेस के साथ APEXes में सभी घटकों (कॉन्फ़िगरेशन फ़ाइलों और अतिरिक्त पुस्तकालयों सहित) को लपेटने से, विभिन्न घटक विनिमेय हो जाते हैं।

डेवलपर पुनरावृत्ति

विक्रेता APEX, विक्रेता APEX के अंदर वाईफाई HAL जैसे संपूर्ण सुविधा कार्यान्वयन को बंडल करके विक्रेता मॉड्यूल विकसित करते समय डेवलपर्स को तेजी से पुनरावृत्त करने में मदद करते हैं। इसके बाद डेवलपर्स संपूर्ण विक्रेता छवि को फिर से बनाने के बजाय, परिवर्तनों का परीक्षण करने के लिए विक्रेता 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 , ndk_library , या llndk_library के साथ cc_library शामिल है। इन निर्भरताओं को पैकेजिंग से बाहर रखा गया है, और निर्भरताएं एपेक्स मेनिफेस्ट में दर्ज की गई हैं। मेनिफेस्ट को linkerconfig द्वारा संसाधित किया जाता है ताकि बाहरी मूल निर्भरताएं रनटाइम पर उपलब्ध हों।

/system विभाजन में APEXes के विपरीत, विक्रेता APEXes आमतौर पर एक विशिष्ट VNDK संस्करण से बंधे होते हैं। VNDK लाइब्रेरीज़ रिलीज़ के भीतर ABI स्थिरता की गारंटी देती हैं, इसलिए हम VNDK लाइब्रेरीज़ को स्थिर मान सकते हैं और use_vndk_as_stable प्रॉपर्टी का उपयोग करके विक्रेता APEXes को APEXes से बाहर करके उनके आकार को कम कर सकते हैं।

नीचे दिए गए स्निपेट में, 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"],
  ..
}

एचएएल कार्यान्वयन

एचएएल कार्यान्वयन को परिभाषित करने के लिए, निम्नलिखित उदाहरणों के समान विक्रेता एपेक्स के अंदर संबंधित बायनेरिज़ और लाइब्रेरी प्रदान करें:

एचएएल कार्यान्वयन को पूरी तरह से समाहित करने के लिए, एपेक्स को किसी भी प्रासंगिक वीआईएनटीएफ टुकड़े और इनिट स्क्रिप्ट को भी निर्दिष्ट करना चाहिए।

VINTF टुकड़े

जब टुकड़े APEX के etc/vintf में स्थित होते हैं, तो VINTF टुकड़े विक्रेता APEX से परोसे जा सकते हैं।

APEX में VINTF अंशों को एम्बेड करने के लिए prebuilts प्रॉपर्टी का उपयोग करें।

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

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

इनिट स्क्रिप्ट

APEXes init स्क्रिप्ट को दो तरीकों से शामिल कर सकता है: (A) APEX पेलोड के भीतर एक पूर्वनिर्मित टेक्स्ट फ़ाइल, या (B) /vendor/etc में एक नियमित init स्क्रिप्ट। आप दोनों को एक ही APEX के लिए सेट कर सकते हैं।

एपेक्स में इनिट स्क्रिप्ट:

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

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

APEXes के भीतर Init स्क्रिप्ट में केवल service परिभाषाएँ हो सकती हैं। विक्रेता APEXes में Init स्क्रिप्ट में on <property> निर्देश भी हो सकते हैं।

निर्देशों on उपयोग करते समय सावधान रहें। चूँकि APEXes में init स्क्रिप्ट्स को APEXes सक्रिय होने के बाद पार्स और निष्पादित किया जाता है, इसलिए कुछ घटनाओं या गुणों का उपयोग नहीं किया जा सकता है। जितनी जल्दी हो सके कार्रवाई शुरू करने के लिए apex.all.ready=true का उपयोग करें।

फर्मवेयर

उदाहरण:

वाइब्रेटर सेवा फ़र्मवेयर

विक्रेता APEX में फर्मवेयर को prebuilt_firmware मॉड्यूल प्रकार के साथ निम्नानुसार एम्बेड करें।

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 विभिन्न अन्य कॉन्फ़िगरेशन फ़ाइलों का समर्थन करते हैं जो आमतौर पर विक्रेता APEXes के अंदर प्रीबिल्ट के रूप में विक्रेता विभाजन पर पाई जाती हैं, और अधिक जोड़े जा रहे हैं।

उदाहरण:

फ़ीचर घोषणा XMLs
- सेंसर एचएएल विक्रेता एपेक्स में प्रीबिल्ट के रूप में एक्सएमएल की सुविधा देते हैं
कॉन्फ़िग फ़ाइलें इनपुट करें
- टचस्क्रीन कॉन्फ़िगरेशन केवल-कॉन्फ़िगरेशन विक्रेता APEX में प्रीबिल्ट के रूप में कॉन्फ़िगर होता है

अतिरिक्त विकास सुविधाएँ

बूटअप पर एपेक्स चयन

उदाहरण:

कटलफिश एम्युलेटेड कैमरा एचएएल एपेक्स

डेवलपर्स विक्रेता APEXes के कई संस्करण भी स्थापित कर सकते हैं जो समान APEX नाम और कुंजी साझा करते हैं, और फिर लगातार sysprops का उपयोग करके प्रत्येक बूटअप के दौरान कौन सा संस्करण सक्रिय होता है उसे चुन सकते हैं। कुछ डेवलपर उपयोग मामलों के लिए, यह adb install का उपयोग करके APEX की एक नई प्रति स्थापित करने से अधिक आसान हो सकता है।

उदाहरण उपयोग के मामले:

वाईफ़ाई एचएएल विक्रेता एपेक्स के 3 संस्करण स्थापित करें: क्यूए टीमें एक संस्करण का उपयोग करके मैन्युअल या स्वचालित परीक्षण चला सकती हैं, फिर दूसरे संस्करण में रीबूट कर सकती हैं और परीक्षण फिर से चला सकती हैं, फिर अंतिम परिणामों की तुलना कर सकती हैं।
कैमरा एचएएल विक्रेता एपेक्स के 2 संस्करण स्थापित करें, वर्तमान और प्रयोगात्मक : डॉगफूडर्स अतिरिक्त फ़ाइल को डाउनलोड और इंस्टॉल किए बिना प्रयोगात्मक संस्करण का उपयोग कर सकते हैं, ताकि वे आसानी से वापस स्वैप कर सकें।

बूटअप के दौरान, apexd सही एपेक्स संस्करण को सक्रिय करने के लिए एक विशिष्ट प्रारूप का पालन करते हुए sysprops की तलाश करता है।

संपत्ति कुंजी के लिए अपेक्षित प्रारूप हैं:

बूटकॉन्फिग
- BoardConfig.mk में डिफ़ॉल्ट मान सेट करने के लिए उपयोग किया जाता है।
- androidboot.vendor.apex.<apex name>
लगातार सिसप्रॉप
- पहले से बूट किए गए डिवाइस पर सेट किए गए डिफ़ॉल्ट मान को बदलने के लिए उपयोग किया जाता है।
- यदि मौजूद है तो बूटकॉन्फिग मान को ओवरराइड करता है।
- 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 कमांड के माध्यम से), तो मल्टी-इंस्टॉल एपेक्स के लिए बूटकॉन्फिग प्रॉपर्टी बदलने से बूटअप पर सक्रिय संस्करण भी बदल जाता है।

कटलफिश पर आधारित वर्चुअल संदर्भ उपकरणों के लिए, आप लॉन्च करते समय सीधे बूटकॉन्फिग प्रॉपर्टी सेट करने के लिए --extra_bootconfig_args कमांड का उपयोग कर सकते हैं। उदाहरण के लिए:

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

बक्सों का इस्तेमाल करें

विक्रेता छवियों का मॉड्यूलरीकरण

डेवलपर पुनरावृत्ति

उदाहरण वर्कफ़्लो:

# 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 ...

उदाहरण

मूल बातें

Android.bp में, vendor: true प्रॉपर्टी सेट करने से एक APEX मॉड्यूल एक वेंडर APEX बन जाता है।

apex {
  ..
  vendor: true,
  ..
}

बायनेरिज़ और साझा लाइब्रेरी

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

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

एचएएल कार्यान्वयन

VINTF टुकड़े

APEX में VINTF अंशों को एम्बेड करने के लिए prebuilts प्रॉपर्टी का उपयोग करें।

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

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

इनिट स्क्रिप्ट

एपेक्स में इनिट स्क्रिप्ट:

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

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

फर्मवेयर

उदाहरण:

वाइब्रेटर सेवा फ़र्मवेयर

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

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

कर्नेल मॉड्यूल

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

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

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

अन्य कॉन्फ़िग फ़ाइलें

उदाहरण:

फ़ीचर घोषणा XMLs
- सेंसर एचएएल विक्रेता एपेक्स में प्रीबिल्ट के रूप में एक्सएमएल की सुविधा देते हैं
कॉन्फ़िग फ़ाइलें इनपुट करें
- टचस्क्रीन कॉन्फ़िगरेशन केवल-कॉन्फ़िगरेशन विक्रेता APEX में प्रीबिल्ट के रूप में कॉन्फ़िगर होता है

अतिरिक्त विकास सुविधाएँ

बूटअप पर एपेक्स चयन

उदाहरण:

कटलफिश एम्युलेटेड कैमरा एचएएल एपेक्स

उदाहरण उपयोग के मामले:

वाईफ़ाई एचएएल विक्रेता एपेक्स के 3 संस्करण स्थापित करें: क्यूए टीमें एक संस्करण का उपयोग करके मैन्युअल या स्वचालित परीक्षण चला सकती हैं, फिर दूसरे संस्करण में रीबूट कर सकती हैं और परीक्षण फिर से चला सकती हैं, फिर अंतिम परिणामों की तुलना कर सकती हैं।
कैमरा एचएएल विक्रेता एपेक्स के 2 संस्करण स्थापित करें, वर्तमान और प्रयोगात्मक : डॉगफूडर्स अतिरिक्त फ़ाइल को डाउनलोड और इंस्टॉल किए बिना प्रयोगात्मक संस्करण का उपयोग कर सकते हैं, ताकि वे आसानी से वापस स्वैप कर सकें।

संपत्ति कुंजी के लिए अपेक्षित प्रारूप हैं:

बूटकॉन्फिग
- BoardConfig.mk में डिफ़ॉल्ट मान सेट करने के लिए उपयोग किया जाता है।
- androidboot.vendor.apex.<apex name>
लगातार सिसप्रॉप
- पहले से बूट किए गए डिवाइस पर सेट किए गए डिफ़ॉल्ट मान को बदलने के लिए उपयोग किया जाता है।
- यदि मौजूद है तो बूटकॉन्फिग मान को ओवरराइड करता है।
- 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,
  ..
}

# 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;

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

बक्सों का इस्तेमाल करें

विक्रेता छवियों का मॉड्यूलरीकरण

डेवलपर पुनरावृत्ति

उदाहरण वर्कफ़्लो:

# 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 ...

उदाहरण

मूल बातें

Android.bp में, vendor: true प्रॉपर्टी सेट करने से एक APEX मॉड्यूल एक वेंडर APEX बन जाता है।

apex {
  ..
  vendor: true,
  ..
}

बायनेरिज़ और साझा लाइब्रेरी

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

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

एचएएल कार्यान्वयन

VINTF टुकड़े

APEX में VINTF अंशों को एम्बेड करने के लिए prebuilts प्रॉपर्टी का उपयोग करें।

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

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

इनिट स्क्रिप्ट

एपेक्स में इनिट स्क्रिप्ट:

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

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

फर्मवेयर

उदाहरण:

वाइब्रेटर सेवा फ़र्मवेयर

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

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

कर्नेल मॉड्यूल

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

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

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

अन्य कॉन्फ़िग फ़ाइलें

उदाहरण:

फ़ीचर घोषणा XMLs
- सेंसर एचएएल विक्रेता एपेक्स में प्रीबिल्ट के रूप में एक्सएमएल की सुविधा देते हैं
कॉन्फ़िग फ़ाइलें इनपुट करें
- टचस्क्रीन कॉन्फ़िगरेशन केवल-कॉन्फ़िगरेशन विक्रेता APEX में प्रीबिल्ट के रूप में कॉन्फ़िगर होता है

अतिरिक्त विकास सुविधाएँ

बूटअप पर एपेक्स चयन

उदाहरण:

कटलफिश एम्युलेटेड कैमरा एचएएल एपेक्स

उदाहरण उपयोग के मामले:

वाईफ़ाई एचएएल विक्रेता एपेक्स के 3 संस्करण स्थापित करें: क्यूए टीमें एक संस्करण का उपयोग करके मैन्युअल या स्वचालित परीक्षण चला सकती हैं, फिर दूसरे संस्करण में रीबूट कर सकती हैं और परीक्षण फिर से चला सकती हैं, फिर अंतिम परिणामों की तुलना कर सकती हैं।
कैमरा एचएएल विक्रेता एपेक्स के 2 संस्करण स्थापित करें, वर्तमान और प्रयोगात्मक : डॉगफूडर्स अतिरिक्त फ़ाइल को डाउनलोड और इंस्टॉल किए बिना प्रयोगात्मक संस्करण का उपयोग कर सकते हैं, ताकि वे आसानी से वापस स्वैप कर सकें।

संपत्ति कुंजी के लिए अपेक्षित प्रारूप हैं:

बूटकॉन्फिग
- BoardConfig.mk में डिफ़ॉल्ट मान सेट करने के लिए उपयोग किया जाता है।
- androidboot.vendor.apex.<apex name>
लगातार सिसप्रॉप
- पहले से बूट किए गए डिवाइस पर सेट किए गए डिफ़ॉल्ट मान को बदलने के लिए उपयोग किया जाता है।
- यदि मौजूद है तो बूटकॉन्फिग मान को ओवरराइड करता है।
- 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,
  ..
}

# 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;

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