एचएएल के लिए एआईडीएल

Android 11 वर्शन में, Android में एचएएल के लिए एआईडीएल का इस्तेमाल करने की सुविधा लॉन्च की गई है. इससे यह HIDL के बिना Android के हिस्सों को लागू करना संभव है. एआईडीएल का इस्तेमाल करने के लिए ट्रांज़िशन एचएएल खास तौर पर, जहां संभव हो (जब अपस्ट्रीम एचएएल, HIDL का इस्तेमाल करते हों, तो HIDL का इस्तेमाल करना चाहिए).

एचएएल, जो फ़्रेमवर्क के कॉम्पोनेंट के बीच संपर्क करने के लिए एआईडीएल का इस्तेमाल करते हैं. जैसे, system.img और हार्डवेयर कॉम्पोनेंट, जैसे कि vendor.img में मौजूद हार्डवेयर कॉम्पोनेंट को स्थिर एआईडीएल. हालांकि, किसी बंटवारे में कम्युनिकेट करने के लिए, उदाहरण के लिए, दूसरी ओर, एचएएल का इस्तेमाल करने पर आईपीसी के काम करने के तरीके पर कोई पाबंदी नहीं है.

वजह

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

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

एआईडीएल रनटाइम के मुताबिक बनाएं

AIDL के तीन अलग-अलग बैकएंड होते हैं: Java, NDK, और CPP. स्टेबल एआईडीएल का इस्तेमाल करने के लिए, आपको हमेशा system/lib*/libbinder.so पर libbinder की सिस्टम कॉपी का इस्तेमाल करें और बात करें /dev/binder को. वेंडर इमेज पर मौजूद कोड के लिए, इसका मतलब है कि libbinder (VNDK से) का इस्तेमाल नहीं किया जा सकता: इस लाइब्रेरी में स्थिर C++ API है और सिस्टम में गड़बड़ी. इसके बजाय, नेटिव वेंडर कोड को इसके NDK बैकएंड का इस्तेमाल करना चाहिए एआईडीएल, libbinder_ndk (जो सिस्टम libbinder.so पर काम करता है) से लिंक करें, और aidl_interface एंट्री से बनाई गई एनडीके लाइब्रेरी से लिंक करें. इसके लिए मॉड्यूल के सटीक नाम, देखें मॉड्यूल का नाम रखने के नियम.

AIDL HAL इंटरफ़ेस लिखना

सिस्टम और वेंडर के बीच एआईडीएल इंटरफ़ेस इस्तेमाल करने के लिए, इंटरफ़ेस को ज़रूरी दो परिवर्तन:

  • हर टाइप की परिभाषा के बारे में @VintfStability के साथ एनोटेट किया जाना चाहिए.
  • aidl_interface के एलान में stability: "vintf", शामिल होना चाहिए.

केवल इंटरफ़ेस का स्वामी ही ये बदलाव कर सकता है.

जब आप ये बदलाव करते हैं, तो इंटरफ़ेस VINTF मेनिफ़ेस्ट का इस्तेमाल करके सही तरीके से काम कर सकें. इसका टेस्ट करें और इससे जुड़े ज़रूरी शर्तें, जैसे कि यह पुष्टि करना कि रिलीज़ किए गए इंटरफ़ेस फ़्रीज़ हैं) वीटीएस टेस्ट vts_treble_vintf_vendor_test. @VintfStability का इस्तेमाल किया जा सकता है कॉल करके इंटरफ़ेस अलग-अलग कर सकते हैं. एनडीके बैकएंड में AIBinder_forceDowngradeToLocalStability, C++ बैकएंड में android::Stability::forceDowngradeToLocalStability है, या Java बैकएंड में android.os.Binder#forceDowngradeToSystemStability एक बाइंडर ऑब्जेक्ट पर रखें. किसी सेवा को डाउनग्रेड करना वेंडर के काम करने की सुविधा Java में काम नहीं करती, क्योंकि सभी ऐप्लिकेशन सिस्टम में चलते हैं संदर्भ.

इसके अलावा, कोड को ज़्यादा से ज़्यादा पोर्ट करने की सुविधा और संभावित समस्याओं से बचने के लिए, अतिरिक्त लाइब्रेरी के तौर पर, सीपीपी बैकएंड को बंद करें.

ध्यान दें कि यहां दिए गए कोड के उदाहरण में, backends का इस्तेमाल सही है, जैसा कि ये तीन बैकएंड हैं: Java, NDK, और CPP. नीचे दिया गया कोड बताता है कि खास तौर पर, सीपीपी बैकएंड को.

    aidl_interface: {
        ...
        backends: {
            cpp: {
                enabled: false,
            },
        },
    }

AIDL HAL इंटरफ़ेस ढूंढें

HAL के लिए AOSP स्थिर AIDL इंटरफ़ेस aidl फ़ोल्डर में HIDL इंटरफ़ेस.

  • हार्डवेयर/इंटरफ़ेस
  • फ़्रेमवर्क/हार्डवेयर/इंटरफ़ेस
  • सिस्टम/हार्डवेयर/इंटरफ़ेस

आपको एक्सटेंशन इंटरफ़ेस को अन्य hardware/interfaces में रखना चाहिए vendor या hardware में सबडायरेक्ट्री शामिल हैं.

एक्सटेंशन इंटरफ़ेस

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

एक्सटेंशन दो अलग-अलग तरीकों से रजिस्टर किए जा सकते हैं:

  • रनटाइम पर, अटैच किए गए एक्सटेंशन देखें.
  • यह सुविधा अलग से उपलब्ध होती है और दुनिया भर में रजिस्टर होती है. साथ ही, इसे VINTF में भी रजिस्टर किया जाता है.

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

  • अगली रिलीज़ में जोड़े गए इंटरफ़ेस एओएसपी में अप-स्ट्रीम किए जा सकते हैं
  • अतिरिक्त सुविधा, जो मर्ज विरोधाभास के बिना, अतिरिक्त सुविधा, अगली रिलीज़ में अपस्ट्रीम किए जा सकते हैं

पार्स किए जा सकने वाले एक्सटेंशन: Parcelable Holder

ParcelableHolder एक Parcelable है, जिसमें एक और Parcelable हो सकता है. ParcelableHolder का मुख्य इस्तेमाल उदाहरण, Parcelable को एक्सटेंसिबल बनाना है. उदाहरण के लिए, ऐसी इमेज जिसकी मदद से डिवाइस लागू करने वाले, एओएसपी की तय की गई Parcelable, AospDefinedParcelable, जिसमें वैल्यू बढ़ाने के लिए अतिरिक्त वैल्यू जोड़ी गई है सुविधाएँ.

पहले ParcelableHolder के बिना, डिवाइस लागू करने वाले लोग बदलाव नहीं कर सकते थे यह एओएसपी का तय किया गया स्थिर एआईडीएल इंटरफ़ेस है, क्योंकि ज़्यादा फ़ाइलें जोड़ने से गड़बड़ी हो सकती है फ़ील्ड:

parcelable AospDefinedParcelable {
  int a;
  String b;
  String x; // ERROR: added by a device implementer
  int[] y; // added by a device implementer
}

जैसा कि पिछले कोड में दिखाया गया है, यह तरीका काम नहीं करता, क्योंकि फ़ील्ड डिवाइस इंप्लिमेंटर से जोड़े गए डिवाइस में टकराव हो सकता है. उदाहरण के लिए, जब Parcelable Android की अगली रिलीज़ में बदलाव किए गए हैं.

ParcelableHolder का इस्तेमाल करके, पार्स किए जा सकने वाले एलिमेंट का मालिक, एक्सटेंशन तय कर सकता है एक Parcelable.

parcelable AospDefinedParcelable {
  int a;
  String b;
  ParcelableHolder extension;
}

इसके बाद, डिवाइस लागू करने वाले लोग अपने हिसाब से Parcelable तय कर सकते हैं एक्सटेंशन चुनें.

parcelable OemDefinedParcelable {
  String x;
  int[] y;
}

आखिर में, नए Parcelable को मूल Parcelable के साथ अटैच किया जा सकता है ParcelableHolder फ़ील्ड में.


// Java
AospDefinedParcelable ap = ...;
OemDefinedParcelable op = new OemDefinedParcelable();
op.x = ...;
op.y = ...;

ap.extension.setParcelable(op);

...

OemDefinedParcelable op = ap.extension.getParcelable(OemDefinedParcelable.class);

// C++
AospDefinedParcelable ap;
OemDefinedParcelable op;
std::shared_ptr<OemDefinedParcelable> op_ptr = make_shared<OemDefinedParcelable>();

ap.extension.setParcelable(op);
ap.extension.setParcelable(op_ptr);

...

std::shared_ptr<OemDefinedParcelable> op_ptr;

ap.extension.getParcelable(&op_ptr);

// NDK
AospDefinedParcelable ap;
OemDefinedParcelable op;
ap.extension.setParcelable(op);

...

std::optional<OemDefinedParcelable> op;
ap.extension.getParcelable(&op);

// Rust
let mut ap = AospDefinedParcelable { .. };
let op = Rc::new(OemDefinedParcelable { .. });

ap.extension.set_parcelable(Rc::clone(&op));

...

let op = ap.extension.get_parcelable::<OemDefinedParcelable>();

AIDL HAL सर्वर इंस्टेंस के नाम

आम तौर पर, एआईडीएल एचएएल सेवाओं का फ़ॉर्मैट एक इंस्टेंस नाम होता है $package.$type/$instance. उदाहरण के लिए, वाइब्रेटर एचएएल का एक इंस्टेंस android.hardware.vibrator.IVibrator/default के तौर पर रजिस्टर किया गया.

AIDL HAL सर्वर लिखना

@VintfStability एआईडीएल सर्वर के बारे में, VINTF मेनिफ़ेस्ट में बताया जाना चाहिए. इस तरह का उदाहरण:

    <hal format="aidl">
        <name>android.hardware.vibrator</name>
        <version>1</version>
        <fqname>IVibrator/default</fqname>
    </hal>

अगर ऐसा नहीं है, तो उन्हें एआईडीएल सेवा को सामान्य रूप से रजिस्टर करना चाहिए. वीटीएस चलाते समय इसलिए, हो सकता है कि एलान किए गए सभी एआईडीएल एचएएल उपलब्ध हों.

एआईडीएल क्लाइंट लिखना

एआईडीएल क्लाइंट को कंपैटबिलिटी मैट्रिक्स में खुद का एलान करना होगा. उदाहरण के लिए, इस तरह:

    <hal format="aidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1-2</version>
        <interface>
            <name>IVibrator</name>
            <instance>default</instance>
        </interface>
    </hal>

मौजूदा HAL को HIDL से एआईडीएल में बदलें

HIDL इंटरफ़ेस को एआईडीएल में बदलने के लिए, hidl2aidl टूल का इस्तेमाल करें.

hidl2aidl की सुविधाएं:

  • दिए गए पैकेज के लिए .hal फ़ाइलों के आधार पर .aidl फ़ाइलें बनाएं
  • नए बनाए गए एआईडीएल पैकेज के लिए, सभी बैकएंड के साथ बिल्ड नियम बनाएं सक्षम किया गया
  • अनुवाद करने के लिए Java, CPP, और NDK बैकएंड में अनुवाद के तरीके बनाएं HIDL टाइप से लेकर AIDL टाइप तक
  • ज़रूरी डिपेंडेंसी के साथ लाइब्रेरी का अनुवाद करने के लिए बिल्ड रूल बनाएं
  • स्टैटिक दावा बनाएं, ताकि यह पक्का किया जा सके कि HIDL और AIDL सीपीपी और एनडीके बैकएंड में एक जैसी वैल्यू

.hal फ़ाइलों के पैकेज को .aidl फ़ाइलों में बदलने के लिए, यह तरीका अपनाएं:

  1. system/tools/hidl/hidl2aidl में मौजूद टूल बनाएं.

    नए सोर्स से इस टूल को बनाने पर, आपको अनुभव. पुराने वर्शन पर इंटरफ़ेस बदलने के लिए, नए वर्शन का इस्तेमाल किया जा सकता है पिछली रिलीज़ में शामिल ब्रांच.

    m hidl2aidl

  2. टूल को एक आउटपुट डायरेक्ट्री के साथ एक्ज़ीक्यूट करें. इसके बाद, पैकेज को रूपांतरित.

    वैकल्पिक रूप से, नई लाइसेंस फ़ाइल का कॉन्टेंट जोड़ने के लिए -l आर्ग्युमेंट का इस्तेमाल करें . सही लाइसेंस और तारीख का इस्तेमाल करें.

    hidl2aidl -o <output directory> -l <file with license> <package>

    उदाहरण के लिए:

    hidl2aidl -o . -l my_license.txt android.hardware.nfc@1.2

  3. जनरेट की गई फ़ाइलों को पढ़ें और कन्वर्ज़न से जुड़ी समस्याओं को ठीक करें.

    • conversion.log में ऐसी समस्याएं मौजूद हैं जिन्हें हल नहीं किया गया है. इस समस्या को पहले ठीक करना ज़रूरी है.
    • जनरेट की गई .aidl फ़ाइलों में चेतावनियां और सुझाव हो सकते हैं कार्रवाई की ज़रूरत है. ये टिप्पणियां // से शुरू होती हैं.
    • अब पैकेज का स्टोरेज खाली करें और उसमें सुधार करें.
    • @JavaDerive देखें उन सुविधाओं के लिए एनोटेशन जिनकी ज़रूरत पड़ सकती है. जैसे, toString या equals.

  4. सिर्फ़ अपनी ज़रूरत के हिसाब से टारगेट बनाएं.

    • इस्तेमाल नहीं किए जाने वाले बैकएंड बंद करें. सीपीपी के बजाय, एनडीके बैकएंड को प्राथमिकता दें बैकएंड, रनटाइम चुनना देखें.
    • अनुवाद वाली लाइब्रेरी या उनका जनरेट किया गया ऐसा कोई भी कोड हटाएं जिसका इस्तेमाल नहीं किया जाएगा.

  5. मुख्य एआईडीएल/एचआईडीएल का अंतर देखें.

    • एआईडीएल के बिल्ट-इन Status और अपवादों का इस्तेमाल करने से, आम तौर पर इंटरफ़ेस करके अलग-अलग स्टेटस टाइप की ज़रूरत को हटाया जा सकता है.
    • तरीकों में एआईडीएल इंटरफ़ेस के आर्ग्युमेंट, डिफ़ॉल्ट रूप से @nullable के जैसे नहीं होते हैं HIDL में थे.

एआईडीएल एचएएल के लिए एसईनीति

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

    type hal_foo_service, service_manager_type, hal_service_type;

प्लैटफ़ॉर्म की ओर से तय की गई ज़्यादातर सेवाओं के लिए, सेवा का संदर्भ सही प्रकार पहले ही जोड़ा जा चुका है (उदाहरण के लिए, android.hardware.foo.IFoo/default पहले से hal_foo_service के तौर पर मार्क किया जाएगा). हालांकि, अगर कोई फ़्रेमवर्क क्लाइंट सपोर्ट करता है एक से ज़्यादा इंस्टेंस के नाम, अतिरिक्त इंस्टेंस के नाम डिवाइस के हिसाब से service_contexts फ़ाइलें.

    android.hardware.foo.IFoo/custom_instance u:object_r:hal_foo_service:s0

जब हम नए तरह का एचएएल बनाते हैं, तब एचएएल एट्रिब्यूट जोड़ने ज़रूरी हैं. खास एचएएल एट्रिब्यूट की वैल्यू एक से ज़्यादा सेवा टाइप से जुड़ी हो सकती है (जिनमें से हर एक के कई उदाहरण हैं, जैसा कि हमने अभी चर्चा की है). foo एचएएल के लिए, हमारे पास hal_attribute(foo). यह मैक्रो hal_foo_client और एट्रिब्यूट के बारे में बताता है hal_foo_server. किसी दिए गए डोमेन के लिए, hal_client_domain और hal_server_domain मैक्रो, किसी डोमेन को दिए गए एचएएल एट्रिब्यूट से जोड़ते हैं. इसके लिए उदाहरण के लिए, इस HAL का क्लाइंट होने के नाते सिस्टम सर्वर, इस नीति के तहत काम करता है hal_client_domain(system_server, hal_foo). इसी तरह, एचएएल सर्वर में hal_server_domain(my_hal_domain, hal_foo). आम तौर पर, किसी दिए गए एचएएल के लिए एट्रिब्यूट के तौर पर इस्तेमाल करते हैं, तो हम रेफ़रंस के लिए hal_foo_default जैसा डोमेन भी बनाते हैं या HAL के उदाहरण शामिल हैं. हालांकि, कुछ डिवाइस अपने सर्वर के लिए इन डोमेन का इस्तेमाल करते हैं. एक से ज़्यादा सर्वर के लिए डोमेन के बीच अंतर सिर्फ़ तब करना चाहिए, जब हमारे पास ऐसे कई सर्वर जो एक जैसे इंटरफ़ेस पर काम करते हैं और जिनके लिए अलग अनुमति की ज़रूरत होती है सेट अप करते हैं. इन सभी मैक्रो में, hal_foo वास्तव में से नीति ऑब्जेक्ट. इसके बजाय, ये मैक्रो क्लाइंट सर्वर के जोड़े से जुड़े एट्रिब्यूट का ग्रुप.

हालांकि, अब तक हमने hal_foo_service और hal_foo को असोसिएट नहीं किया है (hal_attribute(foo) का एट्रिब्यूट पेयर). एक एचएएल एट्रिब्यूट जुड़ा है hal_attribute_service मैक्रो का इस्तेमाल करने वाली AIDL HAL सेवाओं के साथ (HIDL HALs इस्तेमाल hal_attribute_hwservice मैक्रो). उदाहरण के लिए, hal_attribute_service(hal_foo, hal_foo_service). इसका मतलब है कि hal_foo_client प्रोसेस को एचएएल और hal_foo_server को रोका जा सकता है प्रोसेस, एचएएल को रजिस्टर कर सकती हैं. रजिस्ट्रेशन के इन नियमों को लागू करना है कॉन्टेक्स्ट मैनेजर (servicemanager) के ज़रिए किया जाएगा. ध्यान दें, सेवाओं के नाम हमेशा एचएएल एट्रिब्यूट के मुताबिक नहीं होता है. उदाहरण के लिए, हम hal_attribute_service(hal_foo, hal_foo2_service). हालांकि, आम तौर पर इसका मतलब यह है कि सेवाओं का उपयोग हमेशा एक साथ किया जाता है, इसलिए हम hal_foo2_service और हमारी सभी सेवाओं के लिए hal_foo_service का इस्तेमाल करने वाले संदर्भ. कई hal_attribute_service सेट करने वाले ज़्यादातर एचएएल, क्योंकि मूल HAL एट्रिब्यूट का नाम सामान्य नहीं है और इसे बदला नहीं जा सकता.

इन सभी को एक साथ मिलाकर देखें, तो उदाहरण के तौर पर दिया गया HAL कुछ ऐसा दिखता है:

    public/attributes:
    // define hal_foo, hal_foo_client, hal_foo_server
    hal_attribute(foo)

    public/service.te
    // define hal_foo_service
    type hal_foo_service, hal_service_type, protected_service, service_manager_type

    public/hal_foo.te:
    // allow binder connection from client to server
    binder_call(hal_foo_client, hal_foo_server)
    // allow client to find the service, allow server to register the service
    hal_attribute_service(hal_foo, hal_foo_service)
    // allow binder communication from server to service_manager
    binder_use(hal_foo_server)

    private/service_contexts:
    // bind an AIDL service name to the selinux type
    android.hardware.foo.IFooXxxx/default u:object_r:hal_foo_service:s0

    private/<some_domain>.te:
    // let this domain use the hal service
    binder_use(some_domain)
    hal_client_domain(some_domain, hal_foo)

    vendor/<some_hal_server_domain>.te
    // let this domain serve the hal service
    hal_server_domain(some_hal_server_domain, hal_foo)

अटैच किए गए एक्सटेंशन इंटरफ़ेस

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

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

बाइंडर पर एक्सटेंशन सेट करने के लिए, इन एपीआई का इस्तेमाल करें:

  • एनडीके बैकएंड में: AIBinder_setExtension
  • Java बैकएंड में: android.os.Binder.setExtension
  • सीपीपी बैकएंड में: android::Binder::setExtension
  • Rust बैकएंड में: binder::Binder::set_extension

बाइंडर पर एक्सटेंशन पाने के लिए, इन एपीआई का इस्तेमाल करें:

  • एनडीके बैकएंड में: AIBinder_getExtension
  • Java बैकएंड में: android.os.IBinder.getExtension
  • सीपीपी बैकएंड में: android::IBinder::getExtension
  • Rust बैकएंड में: binder::Binder::get_extension

आप इन एपीआई के बारे में ज़्यादा जानकारी, इसके दस्तावेज़ में देख सकते हैं getExtension फ़ंक्शन. इस्तेमाल करने के तरीके का एक उदाहरण एक्सटेंशन यहां मिल सकते हैं हार्डवेयर/इंटरफ़ेस/टेस्ट/एक्सटेंशन/वाइब्रेशन.

अहम एआईडीएल और एचआईडीएल में अंतर

एआईडीएल एचएएल या एआईडीएल एचएएल इंटरफ़ेस इस्तेमाल करते समय अंतर का ध्यान रखें एचआईडीएल एचएएल लिखने के मुकाबले.

  • एआईडीएल भाषा का सिंटैक्स Java के काफ़ी करीब है. HIDL सिंटैक्स, C++ की तरह है.
  • सभी एआईडीएल इंटरफ़ेस में गड़बड़ी की स्थितियां पहले से मौजूद होती हैं. अपनी पसंद के मुताबिक स्टेटस टाइप, इंटरफ़ेस फ़ाइलों में कॉन्सटेंट स्टेटस इंटेस बनाएं और सीपीपी/एनडीके बैकएंड में EX_SERVICE_SPECIFIC और ServiceSpecificException में उपलब्ध है. गड़बड़ी का पेज देखें हैंडलिंग.
  • बाइंडर ऑब्जेक्ट भेजे जाने पर, एआईडीएल, थ्रेडपूल अपने-आप शुरू नहीं करता है. उन्हें मैन्युअल रूप से शुरू किया जाना चाहिए (देखें थ्रेड मैनेजमेंट).
  • नहीं की गई ट्रांसपोर्ट वाली गड़बड़ियों के मामले में AIDL (HIDL Return रद्द नहीं होता) सही का निशान नहीं लगाया गया है).
  • एआईडीएल हर फ़ाइल के लिए सिर्फ़ एक टाइप के बारे में जानकारी दे सकता है.
  • एआईडीएल आर्ग्युमेंट को आउटपुट के साथ-साथ, इन/आउट/इनआउट के तौर पर भी सेट किया जा सकता है पैरामीटर (कोई "सिंक्रोनस कॉलबैक" नहीं होते).
  • एआईडीएल, हैंडल के बजाय प्रिमिटिव टाइप के तौर पर fd का इस्तेमाल करता है.
  • HIDL, असंगत बदलावों के लिए बड़े वर्शन और इनके लिए माइनर वर्शन का इस्तेमाल करता है साथ काम करने के लिए ज़रूरी हैं. एआईडीएल में पुराने सिस्टम के साथ काम करने की सुविधा वाले बदलाव अपने-आप लागू होते हैं. एआईडीएल में मेजर वर्शन का कोई कॉन्सेप्ट नहीं है; इसके बजाय, यह है शामिल कर लिया जाता है. उदाहरण के लिए, एआईडीएल पैकेज के नाम का इस्तेमाल कर सकता है bluetooth2.
  • एआईडीएल डिफ़ॉल्ट रूप से रीयलटाइम प्राथमिकता इनहेरिट नहीं करता. setInheritRt रीयलटाइम प्रायॉरिटी इनहेरिटेंस को चालू करने के लिए, हर बाइंडर के लिए फ़ंक्शन का इस्तेमाल करना ज़रूरी है.