वेंडर APEX

APEX फ़ाइल फ़ॉर्मैट का इस्तेमाल करके, किसी एक फ़ॉर्मैट में निचले स्तर के Android OS मॉड्यूल इंस्टॉल करने के लिए कहा जा सकता है. यह स्वतंत्र बिल्डिंग और स्थानीय सेवाओं और लाइब्रेरी, एचएएल जैसे कॉम्पोनेंट को इंस्टॉल करना लागू करना, फ़र्मवेयर, कॉन्फ़िगरेशन फ़ाइलें वगैरह.

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

इस्तेमाल के उदाहरण

वेंडर की इमेज का मॉड्यूलराइज़ेशन

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

जब वेंडर की इमेज, स्वतंत्र रूप से बने वेंडर के कॉम्बिनेशन के तौर पर बनाई जाती हैं APEXes, डिवाइस निर्माता आसानी से आपके लिए जो वेंडर चाहते थे कि वे उनके डिवाइस पर लागू हों. मैन्युफ़ैक्चरर यह भी बना सकते हैं कि नया वेंडर APEX, अगर दिया गया कोई भी APEX उनकी ज़रूरतों के मुताबिक नहीं है या उनके पास नया कस्टम हार्डवेयर.

उदाहरण के लिए, OEM अपने डिवाइस को एओएसपी वाई-फ़ाई से जोड़ने का विकल्प चुन सकता है लागू करने के लिए APEX, SoC ब्लूटूथ इंप्लिमेंटेशन APEX, और पसंद के मुताबिक OEM टेलीफ़ोनी सुविधा लागू करने के लिए APEX.

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

डेवलपर को करना

वेंडर APEXes डेवलपर को, तेज़ी से काम करने के लिए किसी वेंडर के अंदर, पूरी सुविधा का बंडल बनाना, जैसे कि वाई-फ़ाई एचएएल एपेक्स इसके बाद, डेवलपर 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, ndk_library या llndk_library. इन डिपेंडेंसी को इनसे बाहर रखा जाता है पैकेजिंग, और डिपेंडेंसी को APEX मेनिफ़ेस्ट में रिकॉर्ड किया जाता है. मेनिफ़ेस्ट यह है linkerconfig से प्रोसेस किया जाता है, ताकि एक्सटर्नल नेटिव डिपेंडेंसी रनटाइम पर उपलब्ध होता है.

/system पार्टीशन में मौजूद APEXes के उलट, वेंडर APEXes आम तौर पर खास VNDK वर्शन के साथ काम करता है. VNDK लाइब्रेरी, रिलीज़ कर रहे हैं, ताकि हम 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"],
  ..
}

एचएएल लागू करना

HAL लागू करने के बारे में बताने के लिए, उससे जुड़ी बाइनरी और लाइब्रेरी उपलब्ध कराएं यहां दिए गए उदाहरणों की तरह, वेंडर APEX के अंदर:

• सेंसर एचएएल
• वाइब्रेटर एचएएल
• वाई-फ़ाई एचएएल
• टेलीफ़ोनी एचएएल

HAL लागू करने के तरीके को पूरी तरह से इनकैप्सुलेट करने के लिए, APEX को कोई काम के VINTF फ़्रैगमेंट और init स्क्रिप्ट.

VINTF फ़्रैगमेंट

जब फ़्रैगमेंट यहां मौजूद होते हैं, तो VINTF फ़्रैगमेंट किसी वेंडर APEX से दिखाए जा सकते हैं APEX का etc/vintf.

APEX में VINTF फ़्रैगमेंट एम्बेड करने के लिए, prebuilts प्रॉपर्टी का इस्तेमाल करें.

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

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

Init स्क्रिप्ट

APEXes दो तरीकों से इनिट स्क्रिप्ट शामिल कर सकता है: (A) APEX पेलोड या (B) /vendor/etc में एक सामान्य इनिट स्क्रिप्ट. आप दोनों को सेट कर सकते हैं एक ही APEX के लिए.

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

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

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

APEXes में इनिट स्क्रिप्ट में सिर्फ़ service परिभाषाएं हो सकती हैं. Init स्क्रिप्ट वेंडर APEXes में on <property> डायरेक्टिव भी हो सकते हैं.

on डायरेक्टिव का इस्तेमाल करते समय सावधानी बरतें. क्योंकि APEX में इनिट स्क्रिप्ट APEXS चालू करने के बाद पार्स और एक्ज़ीक्यूट किया गया, कुछ इवेंट या प्रॉपर्टी इस्तेमाल नहीं किया जा सकता. कार्रवाइयों को जल्द से जल्द ट्रिगर करने के लिए, 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
  ..
}

<apex name>/etc/firmware में prebuilt_firmware मॉड्यूल इंस्टॉल किए गए हैं की है. ueventd, /apex/*/etc/firmware डायरेक्ट्री को यहां स्कैन करता है मिल सकता है.

APEX के file_contexts में, फ़र्मवेयर पेलोड एंट्री का लेबल होना चाहिए ताकि यह पक्का किया जा सके कि इन फ़ाइलों को रनटाइम के दौरान ueventd से ऐक्सेस किया जा सकता है; आम तौर पर, vendor_file लेबल काफ़ी होता है. उदाहरण के लिए:

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

Kernel मॉड्यूल

वेंडर 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

Kernel मॉड्यूल साफ़ तौर पर इंस्टॉल किए जाने चाहिए. init स्क्रिप्ट का उदाहरण नीचे दिया गया है इस सेक्शन में, insmod के ज़रिए इंस्टॉल करने की जानकारी दिखती है:

my_init.rc:

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

रनटाइम रिसॉर्स ओवरले

उदाहरण:

• कटलफ़िश आरआरओ

वेंडर APEX में रनटाइम रिसॉर्स ओवरले एम्बेड करना rros प्रॉपर्टी का इस्तेमाल करके.

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 में पहले से बनाया गया. साथ ही, कई अन्य सुविधाएं जोड़ी जा रही हैं.

उदाहरणः

• सुविधा के एलान से जुड़ा एक्सएमएल
  • सेंसर, एक्सएमएल को इस तरह दिखाते हैं सेंसर वाले HAL वेंडर APEX में पहले से बनाया गया
• कॉन्फ़िगरेशन फ़ाइलें इनपुट करना
  • टचस्क्रीन कॉन्फ़िगरेशन इस तरह से होता है: सिर्फ़ कॉन्फ़िगरेशन वाले वेंडर APEX में पहले से बनाया गया

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

बूटअप पर APEX चुनाव

उदाहरण:

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

डेवलपर, वेंडर APEXes के ऐसे कई वर्शन भी इंस्टॉल कर सकते हैं जो उसी APEX नाम और कुंजी को चुनें. इसके बाद, चुनें कि हर एक प्रक्रिया के दौरान कौनसा वर्शन चालू हो परसिस्टेंट सिस्टमॉप का इस्तेमाल करके बूटअप करना. डेवलपर के कुछ इस्तेमाल के उदाहरणों के लिए, यह यह adb install का इस्तेमाल करके APEX की नई कॉपी इंस्टॉल करने से ज़्यादा आसान है.

इस्तेमाल के उदाहरणों के उदाहरण:

• वाई-फ़ाई HAL वेंडर APEX के तीन वर्शन इंस्टॉल करें: QA टीम, मैन्युअल तरीके से या एक वर्शन का इस्तेमाल करके अपने-आप टेस्ट किया जाता है. इसके बाद, उसे दूसरे वर्शन में फिर से चालू किया जाता है और फिर से टेस्ट करें, उसके बाद आखिरी नतीजों की तुलना करें.
• कैमरा HAL वेंडर APEX के दो वर्शन इंस्टॉल करें, मौजूदा और एक्सपेरिमेंट के तौर पर उपलब्ध: डॉगफ़ूडर, एक्सपेरिमेंट के तौर पर उपलब्ध वर्शन को इसके बिना भी इस्तेमाल कर सकते हैं अतिरिक्त फ़ाइल डाउनलोड और इंस्टॉल करना, ताकि वे आसानी से वापस स्वैप कर सकें.

बूटअप के दौरान apexd, एक खास फ़ॉर्मैट का इस्तेमाल करके सिस्टम प्रोप्स खोजता है, ताकि APEX का सही वर्शन चालू करना चाहिए.

प्रॉपर्टी कुंजी के लिए सही फ़ॉर्मैट हैं:

• बूटकॉन्फ़िगरेशन
  • 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:

# 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

डिवाइस बूट होने के बाद, परसिस्टेंट सिस्टमॉप:

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

अगर डिवाइस पर फ़्लैश होने के बाद बूट कॉन्फ़िगरेशन अपडेट करने की सुविधा (जैसे कि fastboot oem कमांड का इस्तेमाल करके) दी जाती है, तो एक से ज़्यादा इंस्टॉल किए गए डिवाइस के लिए बूट कॉन्फ़िगरेशन प्रॉपर्टी बदलें. APEX, बूटअप पर चालू किए गए वर्शन को भी बदल देता है.

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

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