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

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

फ्रेमवर्क घटकों के बीच संचार करने के लिए AIDL का उपयोग करने वाले vendor.img , जैसे कि system.img में, और हार्डवेयर घटक, जैसे कि वेंडर.img में, को स्थिर AIDL का उपयोग करना चाहिए। हालांकि, एक विभाजन के भीतर संचार करने के लिए, उदाहरण के लिए एक एचएएल से दूसरे में, आईपीसी तंत्र के उपयोग पर कोई प्रतिबंध नहीं है।

प्रेरणा

एआईडीएल एचआईडीएल की तुलना में लगभग लंबा रहा है, और इसका उपयोग कई अन्य स्थानों में किया जाता है, जैसे कि एंड्रॉइड फ्रेमवर्क घटकों या ऐप्स के बीच। अब जबकि एआईडीएल के पास स्थिरता समर्थन है, एक एकल आईपीसी रनटाइम के साथ पूरे स्टैक को लागू करना संभव है। AIDL में HIDL की तुलना में बेहतर वर्जनिंग सिस्टम भी है।

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

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

सिस्टम और विक्रेता के बीच उपयोग किए जाने वाले AIDL इंटरफ़ेस के लिए, इंटरफ़ेस को दो परिवर्तनों की आवश्यकता है:

  • हर प्रकार की परिभाषा को @VintfStability के साथ एनोटेट किया जाना चाहिए।
  • aidl_interface घोषणा में stability: "vintf", .

केवल इंटरफ़ेस का स्वामी ही ये परिवर्तन कर सकता है।

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

इसके अतिरिक्त, अधिकतम कोड पोर्टेबिलिटी के लिए और अनावश्यक अतिरिक्त लाइब्रेरी जैसी संभावित समस्याओं से बचने के लिए, CPP बैकएंड को अक्षम करें।

ध्यान दें कि नीचे दिए गए कोड उदाहरण में backends का उपयोग सही है, क्योंकि तीन बैकएंड (जावा, एनडीके, और सीपीपी) हैं। नीचे दिया गया कोड बताता है कि इसे अक्षम करने के लिए विशेष रूप से सीपीपी बैकएंड का चयन कैसे करें।

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

एआईडीएल एचएएल इंटरफेस ढूँढना

एचएएल के लिए एओएसपी स्थिर एआईडीएल इंटरफेस एचआईडीएल इंटरफेस के समान बेस डायरेक्टरी में हैं, aidl फोल्डर में।

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

आपको vendor या hardware में अन्य hardware/interfaces उपनिर्देशिकाओं में एक्सटेंशन इंटरफेस डालना चाहिए।

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

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

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

हालांकि एक एक्सटेंशन पंजीकृत है, जब विक्रेता-विशिष्ट (अर्थात् अपस्ट्रीम एओएसपी का हिस्सा नहीं) घटक इंटरफ़ेस का उपयोग करते हैं, तो विलय संघर्ष की कोई संभावना नहीं है। हालाँकि, जब अपस्ट्रीम AOSP घटकों में डाउनस्ट्रीम संशोधन किए जाते हैं, तो विलय के विरोध का परिणाम हो सकता है, और निम्नलिखित रणनीतियों की सिफारिश की जाती है:

  • इंटरफ़ेस परिवर्धन को अगली रिलीज़ में AOSP पर अपस्ट्रीम किया जा सकता है
  • इंटरफ़ेस परिवर्धन जो आगे लचीलेपन की अनुमति देते हैं, मर्ज विरोधों के बिना, अगली रिलीज़ में अपस्ट्रीम किया जा सकता है

एक्सटेंशन पार्सलेबल: पार्सलेबलहोल्डर

ParcelableHolder एक Parcelable है जिसमें एक और Parcelable हो सकता है। Parcelable का मुख्य उपयोग मामला ParcelableHolder को एक्स्टेंसिबल बनाना है। उदाहरण के लिए, छवि जो डिवाइस कार्यान्वयनकर्ता AOSP-परिभाषित Parcelable , AospDefinedParcelable का विस्तार करने में सक्षम होने की अपेक्षा करते हैं, ताकि उनकी मूल्य-वर्धित सुविधाओं को शामिल किया जा सके।

पहले ParcelableHolder के बिना, डिवाइस कार्यान्वयनकर्ता AOSP- परिभाषित स्थिर AIDL इंटरफ़ेस को संशोधित नहीं कर सकते थे क्योंकि यह अधिक फ़ील्ड जोड़ने में त्रुटि होगी:

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

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

ParcelableHolder का उपयोग करके, एक पार्सल योग्य का स्वामी एक Parcelable में एक विस्तार बिंदु को परिभाषित कर सकता है।

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

तब उपकरण कार्यान्वयनकर्ता अपने विस्तार के लिए अपने स्वयं के Parcelable को परिभाषित कर सकते हैं।

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

अंत में, नए Parcelable को ParcelableHolder फ़ील्ड के माध्यम से मूल Parcelable से जोड़ा जा सकता है।


// 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 रनटाइम के विरुद्ध निर्माण

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

एआईडीएल एचएएल सर्वर इंस्टेंस नाम

परंपरा के अनुसार, एआईडीएल एचएएल सेवाओं में $package.$type/$instance प्रारूप का एक उदाहरण नाम होता है। उदाहरण के लिए, वाइब्रेटर एचएएल का एक उदाहरण android.hardware.vibrator.IVibrator/default के रूप में पंजीकृत है।

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

@VintfStability AIDL सर्वर को 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 से AIDL में बदलना

HIDL इंटरफ़ेस को AIDL में बदलने के लिए hidl2aidl टूल का उपयोग करें।

hidl2aidl विशेषताएं:

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

.hal फ़ाइलों के पैकेज को .aidl फ़ाइलों में कनवर्ट करने के लिए इन चरणों का पालन करें:

  1. system/tools/hidl/hidl2aidl में स्थित टूल बनाएं।

    इस टूल को नवीनतम स्रोत से बनाना सबसे संपूर्ण अनुभव प्रदान करता है। आप पिछली रिलीज़ से पुरानी शाखाओं पर इंटरफ़ेस बदलने के लिए नवीनतम संस्करण का उपयोग कर सकते हैं।

    m hidl2aidl
    
  2. एक आउटपुट निर्देशिका के साथ टूल को निष्पादित करें जिसके बाद पैकेज को परिवर्तित किया जाना है।

    hidl2aidl -o <output directory> <package>
    

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

    hidl2aidl -o . android.hardware.nfc@1.2
    
  3. जेनरेट की गई फ़ाइलों को पढ़ें और रूपांतरण के साथ किसी भी समस्या को ठीक करें।

    • conversion.log में पहले ठीक करने के लिए कोई भी हैंडल न की गई समस्या है।
    • उत्पन्न .aidl फाइलों में चेतावनियां और सुझाव हो सकते हैं जिन पर कार्रवाई की आवश्यकता हो सकती है। ये टिप्पणियाँ // से शुरू होती हैं।
    • पैकेज में सफाई और सुधार करने का अवसर लें।
  4. केवल उन्हीं लक्ष्यों का निर्माण करें जिनकी आपको आवश्यकता है।

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

    • एआईडीएल की अंतर्निहित Status और अपवादों का उपयोग करने से आमतौर पर इंटरफ़ेस में सुधार होता है और किसी अन्य इंटरफ़ेस-विशिष्ट स्थिति प्रकार की आवश्यकता को हटा दिया जाता है।

एआईडीएल एचएएल के लिए सेपॉलिसी

एक एआईडीएल सेवा प्रकार जो विक्रेता कोड को दिखाई देता है, vendor_service विशेषता होनी चाहिए। अन्यथा, सेपॉलिसी कॉन्फ़िगरेशन किसी भी अन्य एआईडीएल सेवा के समान है (हालांकि एचएएल के लिए विशेष विशेषताएं हैं)। एचएएल सेवा संदर्भ की एक उदाहरण परिभाषा यहां दी गई है:

    type hal_foo_service, service_manager_type, vendor_service;

प्लेटफ़ॉर्म द्वारा परिभाषित अधिकांश सेवाओं के लिए, सही प्रकार के साथ एक सेवा संदर्भ पहले ही जोड़ा जा चुका है (उदाहरण के लिए, 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 विशेषता के लिए, हम संदर्भ या उदाहरण HALs के लिए hal_foo_default जैसा डोमेन भी बनाते हैं। हालांकि, कुछ डिवाइस इन डोमेन का उपयोग अपने सर्वर के लिए करते हैं। कई सर्वरों के लिए डोमेन के बीच अंतर केवल तभी मायने रखता है जब हमारे पास कई सर्वर हों जो एक ही इंटरफ़ेस की सेवा करते हैं और उनके कार्यान्वयन में एक अलग अनुमति सेट की आवश्यकता होती है। इन सभी मैक्रोज़ में, hal_foo वास्तव में एक सेपॉलिसी ऑब्जेक्ट नहीं है। इसके बजाय, इस टोकन का उपयोग इन मैक्रोज़ द्वारा क्लाइंट सर्वर जोड़ी से संबद्ध विशेषताओं के समूह को संदर्भित करने के लिए किया जाता है।

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

यह सब एक साथ रखकर, एक उदाहरण एचएएल इस तरह दिखता है:

    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, vendor_service, 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_call(hal_foo_server, servicemanager)

    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
    binder_use(some_hal_server_domain)
    hal_server_domain(some_hal_server_domain, hal_foo)

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

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

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

बाइंडर पर एक्सटेंशन सेट करने के लिए, निम्नलिखित API का उपयोग करें:

  • एनडीके बैकएंड में: AIBinder_setExtension
  • जावा बैकएंड में: android.os.Binder.setExtension
  • CPP बैकएंड में: android::Binder::setExtension

बाइंडर पर एक्सटेंशन प्राप्त करने के लिए, निम्नलिखित API का उपयोग करें:

  • एनडीके बैकएंड में: AIBinder_getExtension
  • जावा बैकएंड में: android.os.IBinder.getExtension
  • सीपीपी बैकएंड में: android::IBinder::getExtension

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

प्रमुख एआईडीएल/एचआईडीएल मतभेद

एआईडीएल एचएएल का उपयोग करते समय या एआईडीएल एचएएल इंटरफेस का उपयोग करते समय, एचआईडीएल एचएएल लिखने की तुलना में अंतरों से अवगत रहें।

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