आप निचले स्तर के एंड्रॉइड ओएस मॉड्यूल को पैकेज और इंस्टॉल करने के लिए 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";
, आप निचले स्तर के एंड्रॉइड ओएस मॉड्यूल को पैकेज और इंस्टॉल करने के लिए 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";
, आप निचले स्तर के एंड्रॉइड ओएस मॉड्यूल को पैकेज और इंस्टॉल करने के लिए 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";