स्थिर एआईडीएल

Android 10 के साथ बेहतर तरीके से काम करने वाला Android इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एआईडीएल), ऐप्लिकेशन प्रोग्राम को ट्रैक करने का एक नया तरीका है AIDL से मिला इंटरफ़ेस (एपीआई) और ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) इंटरफ़ेस. स्थिर एआईडीएल बिलकुल एआईडीएल की तरह काम करता है, लेकिन बिल्ड सिस्टम ट्रैक करता है इंटरफ़ेस काम करता है और इन पर कुछ पाबंदियां लगाई जाती हैं:

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

स्ट्रक्चर्ड बनाम स्टेबल एआईडीएल

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

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

एआईडीएल इंटरफ़ेस तय करना

aidl_interface की परिभाषा इस तरह दिखती है:

aidl_interface {
    name: "my-aidl",
    srcs: ["srcs/aidl/**/*.aidl"],
    local_include_dir: "srcs/aidl",
    imports: ["other-aidl"],
    versions_with_info: [
        {
            version: "1",
            imports: ["other-aidl-V1"],
        },
        {
            version: "2",
            imports: ["other-aidl-V3"],
        }
    ],
    stability: "vintf",
    backend: {
        java: {
            enabled: true,
            platform_apis: true,
        },
        cpp: {
            enabled: true,
        },
        ndk: {
            enabled: true,
        },
        rust: {
            enabled: true,
        },
    },

}

• name: एआईडीएल इंटरफ़ेस मॉड्यूल का नाम, जो किसी खास तरह के एआईडीएल इंटरफ़ेस एआईडीएल इंटरफ़ेस.
• srcs: इंटरफ़ेस बनाने वाली AIDL सोर्स फ़ाइलों की सूची. रास्ता com.acme पैकेज में तय किए गए AIDL टाइप Foo के लिए यह होना चाहिए: <base_path>/com/acme/Foo.aidl, जहां <base_path> कोई भी डायरेक्ट्री हो सकती है उस डायरेक्ट्री से जुड़ी होगी जिसमें Android.bp मौजूद है. पिछले उदाहरण में, <base_path>, srcs/aidl है.
• local_include_dir: वह पाथ जहां से पैकेज का नाम शुरू होता है. यह ऊपर बताई गई <base_path> से मेल खाती है.
• imports: aidl_interface मॉड्यूल की सूची जिनका यह इस्तेमाल किया जाता है. अगर आपके एआईडीएल इंटरफ़ेस, ऐसे इंटरफ़ेस या किसी दूसरे इंटरफ़ेस के पार्स किए जा सकने वाले इंटरफ़ेस का इस्तेमाल करते हैं aidl_interface, उसका नाम यहां रखें. अपने-आप में यह नाम हो सकता है, ताकि आपको सबसे नई वर्शन या वर्शन के सफ़िक्स के साथ नाम (जैसे कि -V1), जिसे की है. यह तय करना कि Android 12 और इसके बाद के वर्शन का इस्तेमाल किया जा रहा है या नहीं
• versions: इंटरफ़ेस के पिछले वर्शन जो api_dir में फ़्रीज़ किए गए वर्शन. Android 11 और versions, aidl_api/name में फ़्रीज़ किए गए हैं. अगर किसी इंटरफ़ेस का कोई फ़्रीज़ किया गया वर्शन नहीं है, इसे नहीं बताया जाना चाहिए और इसके साथ काम करने की जांच नहीं की जाएगी. Android के लिए, इस फ़ील्ड को versions_with_info से बदल दिया गया है 13 और उससे ज़्यादा.
• versions_with_info: टपल की सूची, जिनमें से हर एक में फ़्रीज़ किया गया वर्शन और किसी अन्य aidl_interface के वर्शन को इंपोर्ट करने वाली सूची ऐसे मॉड्यूल जिन्हें aidl_interface के इस वर्शन से इंपोर्ट किया गया था. परिभाषा एक AIDL इंटरफ़ेस IFACE के वर्शन V aidl_api/IFACE/V. इस फ़ील्ड को Android 13 में पेश किया गया था. और इसे सीधे Android.bp में बदला नहीं जाना चाहिए. फ़ील्ड है *-update-api या *-freeze-api का इस्तेमाल करके, जोड़ा या अपडेट किया गया. साथ ही, versions फ़ील्ड versions_with_info पर अपने-आप माइग्रेट हो जाते हैं जब कोई उपयोगकर्ता *-update-api या *-freeze-api को शुरू करता है.
• stability: इस इंटरफ़ेस की स्थिरता का वादा करने के लिए वैकल्पिक फ़्लैग. यह सिर्फ़ "vintf" के साथ काम करता है. अगर stability सेट नहीं है, तो बिल्ड सिस्टम यह जांच करता है कि इंटरफ़ेस पुराने सिस्टम के साथ काम करता है या नहीं unstable बताया गया है. अगर नीति को सेट नहीं किया जाता है, तो यह स्थिरता के लिए किया जा सकता है (इसलिए, सिस्टम की सभी चीज़ों को, उदाहरण के लिए, system.img और उससे जुड़े पार्टिशन या सभी वेंडर में मौजूद चीज़ें चीज़ें, जैसे कि vendor.img और उससे जुड़े पार्टिशन). अगर आपने stability को "vintf" पर सेट किया गया है. यह स्थिरता का वादा करता है: जब तक इंटरफ़ेस उपयोग किया जाता है, तब तक उसे स्थिर रखना चाहिए.
• gen_trace: ट्रेस करने की सुविधा को चालू या बंद करने के लिए वैकल्पिक फ़्लैग. इतने समय में शुरू होगा Android 14, cpp के लिए डिफ़ॉल्ट तौर पर true है. java बैकएंड.
• host_supported: वैकल्पिक फ़्लैग, जिसे true पर सेट करने से जनरेट की गई लाइब्रेरी, जो होस्ट एनवायरमेंट में उपलब्ध हैं.
• unstable: वैकल्पिक फ़्लैग का इस्तेमाल यह बताने के लिए किया जाता है कि यह इंटरफ़ेस काम नहीं करता स्थिर होना चाहिए. जब इसे true पर सेट किया जाता है, तो बिल्ड सिस्टम में से दोनों में से कोई भी नहीं सेट होता इंटरफ़ेस के लिए एपीआई डंप बनाता है और न ही उसे अपडेट करने की ज़रूरत होती है.
• frozen: वैकल्पिक फ़्लैग को true पर सेट करने का मतलब है कि इंटरफ़ेस इंटरफ़ेस के पिछले वर्शन के बाद से कोई बदलाव नहीं हुआ है. यह चालू करता है सुरक्षा की जांच करनी होती है. अगर इसे false पर सेट किया जाता है, तो इसका मतलब है कि इंटरफ़ेस जिसमें नए बदलाव किए गए हैं, इसलिए foo-freeze-api को चलाने से एक नया वर्शन डाउनलोड करने के लिए लिंक किया गया है और वैल्यू को अपने-आप true में बदल दिया जाएगा. पहली बार इसमें दिखाया गया Android 14.
• backend.<type>.enabled: ये फ़्लैग, हर उस बैकएंड को टॉगल करते हैं तो AIDL कंपाइलर इसके लिए कोड जनरेट करता है. चार बैकएंड हैं समर्थित: Java, C++, NDK, और Rust. Java, C++, और NDK बैकएंड चालू हैं डिफ़ॉल्ट रूप से. अगर इन तीनों में से किसी भी बैकएंड की ज़रूरत नहीं है, तो उसे अक्षम कर दिया जाएगा. Android तक, Rust की सुविधा डिफ़ॉल्ट रूप से बंद रहेगी 15.
• backend.<type>.apex_available: जनरेट किए गए APEX नामों की सूची स्टब लाइब्रेरी यहां उपलब्ध है.
• backend.[cpp|java].gen_log: यह एक वैकल्पिक फ़्लैग है, जो तय करता है कि लेन-देन की जानकारी इकट्ठा करने के लिए, अतिरिक्त कोड जनरेट करना.
• backend.[cpp|java].vndk.enabled: यह इंटरफ़ेस बनाने के लिए वैकल्पिक फ़्लैग का हिस्सा है. डिफ़ॉल्ट वैल्यू false है.
• backend.[cpp|ndk].additional_shared_libraries: पहली बार इसमें दिखाया गया यह फ़्लैग, Android 14 के लिए डिपेंडेंसी स्थानीय लाइब्रेरी. यह फ़्लैग ndk_header और cpp_header के लिए काम का है.
• backend.java.sdk_version: वर्शन तय करने के लिए वैकल्पिक फ़्लैग के हिसाब से बनाया गया है जिसके लिए Java स्टब लाइब्रेरी बनाई गई है. डिफ़ॉल्ट सेटिंग यह है "system_current". अगर backend.java.platform_apis है, तो इसे सेट नहीं करना चाहिए true है.
• backend.java.platform_apis: वह वैकल्पिक फ़्लैग जिसे इस पर सेट किया जाना चाहिए true जब जनरेट की गई लाइब्रेरी को प्लैटफ़ॉर्म एपीआई के ज़रिए बनाना हो इस्तेमाल करें.

वर्शन के हर कॉम्बिनेशन और चालू बैकएंड के लिए, एक स्टब लाइब्रेरी बनाई जाती है. स्टब लाइब्रेरी के खास वर्शन के बारे में बताने के लिए किसी खास बैकएंड के लिए, मॉड्यूल का नाम रखने के नियम देखें.

AIDL फ़ाइलें लिखें

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

// in a file like 'some/package/Thing.aidl'
package some.package;

parcelable SubThing {
    String a = "foo";
    int b;
}

boolean, char, के लिए डिफ़ॉल्ट तौर पर इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी नहीं है, float, double, byte, int, long, और String. Android में 12, उपयोगकर्ता-तय गिनती के लिए डिफ़ॉल्ट वैल्यू भी सेट की जाती हैं समर्थित हैं. जब कोई डिफ़ॉल्ट वैल्यू तय नहीं की गई हो, तो 0-लाइक या खाली वैल्यू का इस्तेमाल किया जाता है. बिना किसी डिफ़ॉल्ट वैल्यू वाली कैलकुलेशन, 0 पर शुरू होती हैं. ऐसा तब भी होता है, जब शून्य एन्यूमरेटर नहीं है.

स्टब लाइब्रेरी का इस्तेमाल करना

अपने मॉड्यूल पर डिपेंडेंसी के तौर पर स्टब लाइब्रेरी जोड़ने के बाद, आपको उन्हें अपनी फ़ाइलों में शामिल कर सकता है. यहां स्टब लाइब्रेरी के उदाहरण दिए गए हैं. बिल्ड सिस्टम (लेगसी मॉड्यूल की परिभाषाओं के लिए भी Android.mk का इस्तेमाल किया जा सकता है):

cc_... {
    name: ...,
    shared_libs: ["my-module-name-cpp"],
    ...
}
# or
java_... {
    name: ...,
    // can also be shared_libs if your preference is to load a library and share
    // it among multiple users or if you only need access to constants
    static_libs: ["my-module-name-java"],
    ...
}
# or
rust_... {
    name: ...,
    rustlibs: ["my-module-name-rust"],
    ...
}

C++ में उदाहरण:

#include "some/package/IFoo.h"
#include "some/package/Thing.h"
...
    // use just like traditional AIDL

Java में उदाहरण:

import some.package.IFoo;
import some.package.Thing;
...
    // use just like traditional AIDL

Rust में उदाहरण:

use aidl_interface_name::aidl::some::package::{IFoo, Thing};
...
    // use just like traditional AIDL

वर्शन बनाने के लिए इंटरफ़ेस

foo नाम वाले मॉड्यूल का एलान करने से बिल्ड सिस्टम में भी टारगेट बन जाता है जिसका इस्तेमाल करके मॉड्यूल के एपीआई को मैनेज किया जा सकता है. foo-freeze-api बनाने के बाद api_dir या Android वर्शन के हिसाब से aidl_api/name, और एक .hash फ़ाइल जोड़ता है, जो दोनों फ़ाइल फ़ॉर्मैट के नए फ़्रीज़ किए गए वर्शन को इंटरफ़ेस पर कॉपी करने की सुविधा मिलती है. foo-freeze-api की मदद से भी versions_with_info प्रॉपर्टी को अपडेट किया जा सकता है अतिरिक्त वर्शन और imports वर्शन दिखाने के लिए. बुनियादी तौर पर, versions_with_info की imports को imports फ़ील्ड से कॉपी किया गया. हालांकि, इसके लिए versions_with_info में imports में सबसे नए स्टेबल वर्शन की जानकारी दी गई है आयात करें, जिसका कोई स्पष्ट वर्शन नहीं है. versions_with_info प्रॉपर्टी तय होने के बाद, बिल्ड सिस्टम काम करता है फ़्रीज़ किए गए वर्शन और 'टॉप ऑफ़ ट्री' (ToT) के बीच भी कंपैटबिलिटी की जांच साथ ही, फ़्रीज़ किया गया नया वर्शन भी मौजूद रहेगा.

इसके अलावा, आपको ToT वर्शन की एपीआई डेफ़िनिशन को भी मैनेज करना होगा. जब भी कोई एपीआई अपडेट किया गया, अपडेट करने के लिए foo-update-api चलाएं aidl_api/name/current इसमें ToT वर्शन की एपीआई परिभाषा शामिल है.

इंटरफ़ेस को एक जैसा बनाए रखने के लिए, मालिक इसमें ये नई चीज़ें जोड़ सकते हैं:

• इंटरफ़ेस के आखिर तक के तरीके या साफ़ तौर पर नए के बारे में बताने वाले नए तरीके सीरियल)
• पार्स किए जा सकने वाले एलिमेंट के आखिर में मौजूद एलिमेंट (हर एलिमेंट के लिए डिफ़ॉल्ट वैल्यू जोड़ना ज़रूरी है एलिमेंट)
• कॉन्स्टेंट वैल्यू
• Android 11 में एन्यूमरेटर
• Android 12 में, यूनियन के आखिर तक के फ़ील्ड

किसी और कार्रवाई की अनुमति नहीं है और न ही कोई और इंटरफ़ेस में बदलाव कर सकता है (ऐसा न करने पर, मालिक के किए गए बदलावों का असर पड़ सकता है).

सभी इंटरफ़ेस रिलीज़ करने के लिए फ़्रीज़ किए गए हैं या नहीं, इसकी जांच करने के लिए पर्यावरण से जुड़े कौनसे वैरिएबल सेट किए गए हैं:

• AIDL_FROZEN_REL=true m ... - बिल्ड के लिए सभी स्थायी एआईडीएल इंटरफ़ेस ज़रूरी हैं को फ़्रीज़ किया जाना चाहिए, जिसमें कोई owner: फ़ील्ड तय नहीं किया गया हो.
• AIDL_FROZEN_OWNERS="aosp test" - बिल्ड के लिए सभी स्थायी एआईडीएल इंटरफ़ेस ज़रूरी हैं "aosp" के तौर पर बताए गए owner: फ़ील्ड के साथ फ़्रीज़ करने के लिए या "टेस्ट" होना चाहिए.

इंपोर्ट होने की स्थिरता

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

Android प्लैटफ़ॉर्म कोड में android.hardware.graphics.common सबसे बड़ा है देखें.

वर्शन वाले इंटरफ़ेस का इस्तेमाल करना

इंटरफ़ेस के तरीके

रनटाइम के दौरान, किसी पुराने सर्वर पर नए तरीकों को कॉल करने पर, नए क्लाइंट को कोई गड़बड़ी या अपवाद हो सकता है.

• cpp बैकएंड को ::android::UNKNOWN_TRANSACTION मिलता है.
• ndk बैकएंड को STATUS_UNKNOWN_TRANSACTION मिलता है.
• java बैकएंड को android.os.RemoteException मैसेज मिलता है, जिसमें यह लिखा होता है एपीआई लागू नहीं किया गया है.

इसे मैनेज करने की रणनीतियों के लिए, यह देखें क्वेरी वर्शन और डिफ़ॉल्ट का इस्तेमाल कर रहे हैं.

पार्स किए जा सकने वाले

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

क्लाइंट को यह उम्मीद नहीं करनी चाहिए कि सर्वर नए फ़ील्ड का इस्तेमाल तब तक करेंगे, जब तक कि उन्हें सर्वर ऐसा वर्शन लागू कर रहा है जिसमें फ़ील्ड परिभाषित है (देखें क्वेरी वर्शन).

Enum और कॉन्सटेंट

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

यूनियन

प्राप्तकर्ता पुराना होने पर नए फ़ील्ड के साथ यूनियन भेजने का प्रयास विफल हो जाता है और फ़ील्ड के बारे में नहीं जानता. लागू करने पर क्लिक करें. इस गड़बड़ी को अनदेखा किया जाता है, अगर एकतरफ़ा लेन-देन; ऐसा न होने पर, गड़बड़ी BAD_VALUE(C++ या NDK के लिए) होगी बैकएंड) या IllegalArgumentException(Java बैकएंड के लिए उपलब्ध है). गड़बड़ी यह है तभी प्राप्त होता है, जब ग्राहक नए फ़ील्ड में यूनियन सेट को किसी पुराने सर्वर या जब यह कोई पुराना क्लाइंट हो और नए सर्वर से यूनियन को प्राप्त हो रहा हो.

एक से ज़्यादा वर्शन मैनेज करना

Android में लिंकर नेमस्पेस में किसी खास aidl का सिर्फ़ एक वर्शन हो सकता है इंटरफ़ेस ऐसी स्थितियों से बचने के लिए जहां जनरेट किए गए aidl टाइप में एक से ज़्यादा है परिभाषाएं. C++ में एक परिभाषा नियम है, जिसके लिए सिर्फ़ एक परिभाषा की ज़रूरत होती है चिह्न शामिल करें.

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

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

cc_defaults {
  name: "my.aidl.my-process-group-ndk-shared",
  shared_libs: ["my.aidl-V3-ndk"],
  ...
}

cc_library {
  name: "foo",
  defaults: ["my.aidl.my-process-group-ndk-shared"],
  ...
}

cc_binary {
  name: "bar",
  defaults: ["my.aidl.my-process-group-ndk-shared"],
  ...
}

जब aidl_interface मॉड्यूल इससे बनने वाले अन्य aidl_interface मॉड्यूल इंपोर्ट करता है ऐसी अतिरिक्त डिपेंडेंसी जिन्हें एक साथ इस्तेमाल करने के लिए, खास वर्शन की ज़रूरत होती है. यह सामान्य aidl_interface होने पर, स्थिति को मैनेज करना मुश्किल हो सकता है एक से ज़्यादा aidl_interface मॉड्यूल में इंपोर्ट किए जाने वाले मॉड्यूल, जो इस्तेमाल किए जाते हैं एक साथ काम करते हैं.

aidl_interfaces_defaults का इस्तेमाल aidl_interface के लिए डिपेंडेंसी के नए वर्शन, जिनमें अपडेट किया जा सकता है एक ही जगह पर, और वे सभी aidl_interface मॉड्यूल इस्तेमाल करेंगे जिन्हें इंपोर्ट करना है उस सामान्य इंटरफ़ेस को खोज सके.

aidl_interface_defaults {
  name: "android.popular.common-latest-defaults",
  imports: ["android.popular.common-V3"],
  ...
}

aidl_interface {
  name: "android.foo",
  defaults: ["my.aidl.latest-ndk-shared"],
  ...
}

aidl_interface {
  name: "android.bar",
  defaults: ["my.aidl.latest-ndk-shared"],
  ...
}

फ़्लैग-आधारित डेवलपमेंट

रिलीज़ डिवाइसों पर इन-डेवलपमेंट (अनफ़्रीज़ किए गए) इंटरफ़ेस इस्तेमाल नहीं किए जा सकते, क्योंकि हालांकि, पुराने सिस्टम के साथ काम करने की कोई गारंटी नहीं होती.

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

एआईडीएल बिल्ड फ़्लैग

इस व्यवहार को कंट्रोल करने वाला फ़्लैग RELEASE_AIDL_USE_UNFROZEN है build/release/build_flags.bzl में परिभाषित किया गया है. true का मतलब है, इसका ऐसा वर्शन जो फ़्रीज़ नहीं किया गया है इंटरफ़ेस का इस्तेमाल रन टाइम पर किया जाता है और false का मतलब है, जिन वर्शन को फ़्रीज़ नहीं किया जाता है वे अपने पिछले फ़्रीज़ किए गए वर्शन की तरह काम करते हैं. आप इसके लिए फ़्लैग को true में बदल सकते हैं लेकिन रिलीज़ से पहले इसे false में वापस लाना होगा. आम तौर पर डेवलपमेंट एक ऐसे कॉन्फ़िगरेशन के साथ पूरा किया जाता है, जिसमें फ़्लैग true पर सेट होता है.

कंपैटबिलिटी मैट्रिक्स और मेनिफ़ेस्ट

वेंडर इंटरफ़ेस ऑब्जेक्ट (VINTF ऑब्जेक्ट) के बारे में जानकारी रिपोर्ट में कौनसे वर्शन की उम्मीद की जाती है और दोनों साइड पर कौनसे वर्शन उपलब्ध कराए जाते हैं वेंडर इंटरफ़ेस पर काम करती है.

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

मैट्रिक्स

पार्टनर के मालिकाना हक वाले इंटरफ़ेस, डिवाइस या किसी प्रॉडक्ट से जुड़े इंटरफ़ेस पर जोड़े जाते हैं कंपैटबिलिटी मैट्रिक्स, जिन्हें डिवाइस डेवलपमेंट के दौरान टारगेट करता है. इसलिए, जब किसी कंपैटबिलिटी मैट्रिक्स में, किसी इंटरफ़ेस का नया और फ़्रीज़ न किया गया वर्शन जोड़ा गया है, पिछले फ़्रीज़ किए गए वर्शन RELEASE_AIDL_USE_UNFROZEN=false. तो अलग-अलग अलग-अलग RELEASE_AIDL_USE_UNFROZEN के साथ काम करने वाली मैट्रिक्स फ़ाइलें कॉन्फ़िगरेशन या एक ही कंपैटबिलिटी मैट्रिक्स फ़ाइल में दोनों वर्शन की अनुमति देना इसका इस्तेमाल सभी कॉन्फ़िगरेशन में किया जाएगा.

उदाहरण के लिए, फ़्रीज़ न किए गए वर्शन 4 को जोड़ते समय, <version>3-4</version> का इस्तेमाल करें.

वर्शन 4 के फ़्रीज़ होने पर, काम करने वाले मैट्रिक्स से वर्शन 3 को हटाया जा सकता है क्योंकि फ़्रीज़ किए गए वर्शन 4 का इस्तेमाल तब किया जाता है, जब RELEASE_AIDL_USE_UNFROZEN false.

मेनिफ़ेस्ट

Android 15 में, libvintf में एक बदलाव पेश किया गया है बिल्ड के समय मेनिफ़ेस्ट फ़ाइलों में बदलाव RELEASE_AIDL_USE_UNFROZEN.

मेनिफ़ेस्ट और मेनिफ़ेस्ट फ़्रैगमेंट बताते हैं कि इंटरफ़ेस का कौनसा वर्शन लागू होता है. किसी इंटरफ़ेस के फ़्रीज़ न किए गए नए वर्शन का इस्तेमाल करते समय, इस नए वर्शन को दिखाने के लिए मेनिफ़ेस्ट को अपडेट करना होगा. टास्क कब शुरू होगा RELEASE_AIDL_USE_UNFROZEN=false मेनिफ़ेस्ट एंट्री में बदलाव जनरेट की गई एआईडीएल लाइब्रेरी में हुए बदलाव को दिखाने के लिए, libvintf. वर्शन को फ़्रीज़ नहीं किए गए वर्शन N से बदला गया है और फ़्रीज़ किया गया पिछला वर्शन N - 1 था. इसलिए, उपयोगकर्ताओं को कई विज्ञापनों अपनी हर सेवा के लिए मेनिफ़ेस्ट या मेनिफ़ेस्ट फ़्रैगमेंट.

एचएएल क्लाइंट में किए गए बदलाव

HAL क्लाइंट कोड, हर बार काम करने वाले पिछले फ़्रीज़ किए गए फ़ंक्शन के साथ पुराने सिस्टम के साथ काम करना चाहिए वर्शन है. जब RELEASE_AIDL_USE_UNFROZEN false हो, तो सेवाएं हमेशा दिखती हैं जैसे, पिछली बार फ़्रीज़ किया गया वर्शन या उससे पहले का वर्शन (उदाहरण के लिए, नए सॉफ़्टवेयर को फ़्रीज़ न करने की सुविधा के साथ कॉल करना) तरीकों से UNKNOWN_TRANSACTION मिलता है या parcelable के नए फ़ील्ड में डिफ़ॉल्ट वैल्यू). Android फ़्रेमवर्क क्लाइंट का बैक अप लेना ज़रूरी है पिछले वर्शन के साथ काम करता है, लेकिन यह पार्टनर के मालिकाना हक वाले इंटरफ़ेस के वेंडर क्लाइंट और क्लाइंट.

एचएएल को लागू करने के तरीके में बदलाव

झंडे पर आधारित डेवलपमेंट के साथ एचएएल डेवलपमेंट में सबसे बड़ा अंतर यह है कि एचएएल को लागू करने के लिए ज़रूरी है कि वह पिछले एपीआई के साथ पुराने सिस्टम के साथ काम करे RELEASE_AIDL_USE_UNFROZEN के false होने पर, फ़्रीज़ किया गया वर्शन काम करेगा. डिवाइस कोड और लागू करने के तरीके में पुराने सिस्टम के साथ काम करने की सुविधा को ध्यान में रखना व्यायाम. वर्शन वाले वर्शन का इस्तेमाल करें को देखें इंटरफ़ेस में बदल सकते हैं.

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

उदाहरण: किसी इंटरफ़ेस में तीन फ़्रीज़ किए गए वर्शन होते हैं. इंटरफ़ेस को इससे अपडेट किया जाता है: नया तरीका इस्तेमाल करें. क्लाइंट और सेवा, दोनों को नए वर्शन 4 का इस्तेमाल करने के लिए अपडेट किया जाता है लाइब्रेरी. क्योंकि V4 लाइब्रेरी, इंटरफ़ेस, वह पिछले रुका हुआ वर्शन, वर्शन 3 की तरह काम करता है, जब RELEASE_AIDL_USE_UNFROZEN, false है और नए तरीके के इस्तेमाल को रोकता है.

इंटरफ़ेस के फ़्रीज़ होने पर, RELEASE_AIDL_USE_UNFROZEN की सभी वैल्यू उसका इस्तेमाल करती हैं वर्शन को फ़्रीज़ किया जा सकता है और पुराने सिस्टम के साथ काम करने की सुविधा को मैनेज करने वाले कोड को हटाया जा सकता है.

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

// Get the callback along with the version of the callback
ScopedAStatus RegisterMyCallback(const std::shared_ptr<IMyCallback>& cb) override {
    mMyCallback = cb;
    // Get the version of the callback for later when we call methods on it
    auto status = mMyCallback->getInterfaceVersion(&mMyCallbackVersion);
    return status;
}

// Example of using the callback later
void NotifyCallbackLater() {
  // From the latest frozen version (V2)
  mMyCallback->foo();
  // Call this method from the unfrozen V3 only if the callback is at least V3
  if (mMyCallbackVersion >= 3) {
    mMyCallback->bar();
  }
}

मौजूदा टाइप के नए फ़ील्ड (parcelable, enum, union) में मौजूद नहीं होता या उसके डिफ़ॉल्ट मान नहीं होते, जब RELEASE_AIDL_USE_UNFROZEN false और सेवा जिन नए फ़ील्ड को भेजने की कोशिश करती है उनकी वैल्यू छोड़ दी जाती हैं हमें कुछ नया करने की ज़रूरत नहीं है.

फ़्रीज़ न किए गए इस वर्शन में जोड़े गए नए टाइप नहीं भेजे जा सकते जिसे इंटरफ़ेस से ऐक्सेस किया जा सकता है.

लागू करने की प्रक्रिया को कभी भी किसी भी क्लाइंट से नए तरीकों के लिए कॉल नहीं किया जाता RELEASE_AIDL_USE_UNFROZEN false है.

नए एन्यूमरेटर का इस्तेमाल सिर्फ़ उस वर्शन के साथ करें जिसमें उन्हें पेश किया गया है, न कि पिछला वर्शन.

आम तौर पर, रिमोट का वर्शन देखने के लिए foo->getInterfaceVersion() का इस्तेमाल किया जाता है इंटरफ़ेस का उपयोग कर रहा है. हालांकि फ़्लैग-आधारित वर्शन के साथ, आप दो अलग-अलग वर्शन लागू करना है, तो हो सकता है कि आप मौजूदा इंटरफ़ेस पर कॉपी करता है. आप इसका इंटरफ़ेस वर्शन प्राप्त करके ऐसा कर सकते हैं: मौजूदा ऑब्जेक्ट, उदाहरण के लिए, this->getInterfaceVersion() या दूसरा my_ver की गिनती करने का तरीका. रिमोट के इंटरफ़ेस वर्शन के बारे में क्वेरी करना देखें ऑब्जेक्ट हमारा वीडियो देखें.

नए VINTF और स्टेबल इंटरफ़ेस

जब कोई नया AIDL इंटरफ़ेस पैकेज जोड़ा जाता है, तो आखिरी बार फ़्रीज़ किया गया कोई वर्शन नहीं होता, इसलिए RELEASE_AIDL_USE_UNFROZEN के होने के बाद वापस आने का कोई व्यवहार नहीं है false. इन इंटरफ़ेस का इस्तेमाल न करें. जब RELEASE_AIDL_USE_UNFROZEN होता है false, सेवा मैनेजर, सेवा को इंटरफ़ेस रजिस्टर करने की अनुमति नहीं देगा और क्लाइंट इसे नहीं खोज पाते.

आप डिवाइस में मौजूद मेकफ़ाइल में RELEASE_AIDL_USE_UNFROZEN फ़्लैग:

ifeq ($(RELEASE_AIDL_USE_UNFROZEN),true)
PRODUCT_PACKAGES += \
    android.hardware.health.storage-service
endif

अगर सेवा किसी बड़ी प्रोसेस का हिस्सा है, तो आप उसे डिवाइस में नहीं जोड़ सकते कुछ शर्तों के साथ, यह देखा जा सकता है कि सेवा का एलान IServiceManager::isDeclared(). अगर इसका एलान किया गया है और रजिस्टर नहीं किया जा सका, तो प्रोसेस को रद्द करते हैं. अगर इसका एलान नहीं किया गया है, तो हो सकता है कि वह रजिस्टर न हो पाए.

डेवलपमेंट टूल के तौर पर कटलफ़िश

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

जब RELEASE_AIDL_USE_UNFROZEN की उम्र true होती है, तो कटलफ़िश यह होती है का इस्तेमाल, आने वाले समय में Android के रिलीज़ होने वाले वर्शन को डेवलप करने के लिए किया जाता है. इसका टारगेट Android के लिए, अगले साल तक रिलीज़ का FCM लेवल और PRODUCT_SHIPPING_API_LEVEL है, तो उसे पूरा करना ज़रूरी है वेंडर सॉफ़्टवेयर से जुड़ी ज़रूरी शर्तें (वीएसआर).

जब RELEASE_AIDL_USE_UNFROZEN की वैल्यू false है, तब कटलफ़िश के पास पहले वाले नतीजे होते हैं रिलीज़ डिवाइस को दिखाने के लिए target-level और PRODUCT_SHIPPING_API_LEVEL. Android 14 और उससे पहले के वर्शन में, यह फ़र्क़ सिर्फ़ अलग-अलग Git शाखाओं के साथ पूरा किया जाता है जो FCM में बदलाव नहीं करते target-level, शिपिंग एपीआई लेवल या अगले कोड को टारगेट करने वाला कोई दूसरा कोड रिलीज़.

मॉड्यूल का नाम रखने के नियम

Android 11 में, वर्शन और तो एक स्टब लाइब्रेरी मॉड्यूल अपने-आप बन जाता है. रेफ़र करने के लिए किसी खास स्टब लाइब्रेरी मॉड्यूल से लिंक करना है, तो aidl_interface मॉड्यूल, लेकिन स्टब लाइब्रेरी मॉड्यूल का नाम, जो कि ifacename-version-backend, जहां

• ifacename: aidl_interface मॉड्यूल का नाम
• version इनमें से कोई एक है
  • फ़्रीज़ किए गए वर्शन के लिए Vversion-number
  • Vlatest-frozen-version-number + 1 टिप-ऑफ़-ट्री (अभी-अभी फ़्रीज़ होना) वर्शन
• backend इनमें से कोई एक है
  • Java बैकएंड के लिए java,
  • C++ बैकएंड के लिए cpp,
  • NDK बैकएंड के लिए, ndk या ndk_platform. पहली इमेज ऐप्लिकेशन के लिए है और बाद वाला विकल्प, Android 13 तक के लिए प्लैटफ़ॉर्म का इस्तेमाल करने के लिए है. तय सीमा में Android 13 और उसके बाद के वर्शन में, सिर्फ़ ndk का इस्तेमाल किया जा सकता है.
  • Rust बैकएंड के लिए rust.

मान लें कि foo नाम वाला एक मॉड्यूल है और उसका सबसे नया वर्शन 2 है, और यह NDK और C++, दोनों पर काम करता है. इस मामले में, एआईडीएल ये मॉड्यूल जनरेट करता है:

• वर्शन 1 के मुताबिक
  • foo-V1-(java|cpp|ndk|ndk_platform|rust)
• वर्शन 2 (नया स्टेबल वर्शन) पर आधारित
  • foo-V2-(java|cpp|ndk|ndk_platform|rust)
• सेवा की शर्तों (ToT) के वर्शन के मुताबिक
  • foo-V3-(java|cpp|ndk|ndk_platform|rust)

Android 11 की तुलना में:

• foo-backend, जिसे नए स्टेबल ऑडियो के तौर पर जाना जाता है वर्शन foo-V2-backend हो जाता है
• foo-unstable-backend, यह सेवा की शर्तों के बारे में है वर्शन foo-V3-backend हो जाता है

आउटपुट फ़ाइल के नाम हमेशा मॉड्यूल के नाम जैसे होते हैं.

• वर्शन 1 पर आधारित: foo-V1-(cpp|ndk|ndk_platform|rust).so
• वर्शन 2 पर आधारित: foo-V2-(cpp|ndk|ndk_platform|rust).so
• सेवा की शर्तों (ToT) के वर्शन पर आधारित: foo-V3-(cpp|ndk|ndk_platform|rust).so

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

मेटा इंटरफ़ेस की नई विधियां

Android 10, स्थिर एआईडीएल.

रिमोट ऑब्जेक्ट के इंटरफ़ेस वर्शन की क्वेरी करें

क्लाइंट, उस इंटरफ़ेस के वर्शन और हैश से क्वेरी कर सकते हैं जो रिमोट ऑब्जेक्ट इंटरफ़ेस में दिखाई गई वैल्यू को लागू करके, दिखाई गई वैल्यू की तुलना इंटरफ़ेस में मौजूद वैल्यू से करता है इस्तेमाल कर रहा है.

cpp बैकएंड के साथ उदाहरण:

sp<IFoo> foo = ... // the remote object
int32_t my_ver = IFoo::VERSION;
int32_t remote_ver = foo->getInterfaceVersion();
if (remote_ver < my_ver) {
  // the remote side is using an older interface
}

std::string my_hash = IFoo::HASH;
std::string remote_hash = foo->getInterfaceHash();

ndk (और ndk_platform) बैकएंड के साथ उदाहरण:

IFoo* foo = ... // the remote object
int32_t my_ver = IFoo::version;
int32_t remote_ver = 0;
if (foo->getInterfaceVersion(&remote_ver).isOk() && remote_ver < my_ver) {
  // the remote side is using an older interface
}

std::string my_hash = IFoo::hash;
std::string remote_hash;
foo->getInterfaceHash(&remote_hash);

java बैकएंड के साथ उदाहरण:

IFoo foo = ... // the remote object
int myVer = IFoo.VERSION;
int remoteVer = foo.getInterfaceVersion();
if (remoteVer < myVer) {
  // the remote side is using an older interface
}

String myHash = IFoo.HASH;
String remoteHash = foo.getInterfaceHash();

Java की भाषा के लिए, रिमोट साइड को getInterfaceVersion() और getInterfaceHash() का इस्तेमाल इस तरह करें (इनसे बचने के लिए, IFoo के बजाय super का इस्तेमाल किया जाता है कॉपी करने और चिपकाने में हुई गलतियां. @SuppressWarnings("static") यह एनोटेशन कर सकता है javac कॉन्फ़िगरेशन के आधार पर, चेतावनियां बंद करने की ज़रूरत होगी):

class MyFoo extends IFoo.Stub {
    @Override
    public final int getInterfaceVersion() { return super.VERSION; }

    @Override
    public final String getInterfaceHash() { return super.HASH; }
}

इसकी वजह यह है कि जनरेट की गई क्लास (IFoo, IFoo.Stub वगैरह) शेयर की गई हैं और क्लाइंट और सर्वर के बीच सेट कर सकते हैं (उदाहरण के लिए, क्लास बूट में क्लास पाथ). जब क्लास शेयर की जाती हैं, तो सर्वर को क्लास का सबसे नया वर्शन दिया है, भले ही इसे किसी पुराने ज़माने की जानकारी के साथ बनाया गया हो एक वर्शन है. अगर यह मेटा इंटरफ़ेस शेयर किए गए क्लास है, तो यह हमेशा सबसे नया वर्शन लौटाता है. हालांकि, डाइग्नोस्टिक टूल का इस्तेमाल करके जैसा कि ऊपर बताया गया है, इंटरफ़ेस का वर्शन नंबर सर्वर के कोड में एम्बेड होता है (क्योंकि IFoo.VERSION एक static final int है, जिसे रेफ़रंस के समय इनलाइन किया जाता है) इस तरह, यह तरीका उसी वर्शन को दिखा सकता है जिससे सर्वर बनाया गया था.

पुराने इंटरफ़ेस से निपटें

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

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

Android 13 और उसके बाद के वर्शन में C++ पर इसका उदाहरण:

class MyDefault : public IFooDefault {
  Status anAddedMethod(...) {
   // do something default
  }
};

// once per an interface in a process
IFoo::setDefaultImpl(::android::sp<MyDefault>::make());

foo->anAddedMethod(...); // MyDefault::anAddedMethod() will be called if the
                         // remote side is not implementing it

Java में उदाहरण:

IFoo.Stub.setDefaultImpl(new IFoo.Default() {
    @Override
    public xxx anAddedMethod(...)  throws RemoteException {
        // do something default
    }
}); // once per an interface in a process

foo.anAddedMethod(...);

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

मौजूदा एआईडीएल को स्ट्रक्चर्ड या स्टेबल एआईडीएल में बदलें

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

1. अपने इंटरफ़ेस की सभी निर्भरताओं का पता लगाएं. हर पैकेज के लिए इंटरफ़ेस इस बात पर निर्भर करता है कि पैकेज स्टेबल एआईडीएल में है या नहीं. अगर आपने परिभाषित नहीं है, तो पैकेज को रूपांतरित किया जाना चाहिए.

2. अपने इंटरफ़ेस में मौजूद सभी पार्सल को स्टेबल पार्सेबल में बदलें ( इंटरफ़ेस फ़ाइलों में कोई बदलाव नहीं होता). इस तरीके से करें एआईडीएल फ़ाइलों में अपना स्ट्रक्चर सीधे तौर पर दिखाना होता है. मैनेजमेंट क्लास को यह ज़रूरी है इन नए प्रकारों का इस्तेमाल करने के लिए उन्हें फिर से लिखा जा सकता है. यह कार्रवाई करने से पहले किया जा सकता है aidl_interface पैकेज (नीचे).

3. ऐसा aidl_interface पैकेज बनाएं (जैसा कि ऊपर बताया गया है) जिसमें आपके मॉड्यूल का नाम, उसकी डिपेंडेंसी, और आपकी ज़रूरत की कोई भी अन्य जानकारी. इसे स्टेबलाइज़ करने के लिए (सिर्फ़ स्ट्रक्चर ही नहीं) करने के लिए, इसका वर्शन भी होना चाहिए. ज़्यादा जानकारी के लिए, वर्शन इंटरफ़ेस देखें.