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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

एंड्रॉइड 10 स्थिर एंड्रॉइड इंटरफेस डेफिनिशन लैंग्वेज (एआईडीएल) के लिए समर्थन जोड़ता है, एआईडीएल इंटरफेस द्वारा प्रदान किए गए एप्लिकेशन प्रोग्राम इंटरफेस (एपीआई) / एप्लिकेशन बाइनरी इंटरफेस (एबीआई) का ट्रैक रखने का एक नया तरीका। स्थिर एआईडीएल में एआईडीएल से निम्नलिखित प्रमुख अंतर हैं:

  • इंटरफेस को बिल्ड सिस्टम में aidl_interfaces के साथ परिभाषित किया गया है।
  • इंटरफेस में केवल संरचित डेटा हो सकता है। वांछित प्रकारों का प्रतिनिधित्व करने वाले पार्सलेबल स्वचालित रूप से उनकी एआईडीएल परिभाषा के आधार पर बनाए जाते हैं और स्वचालित रूप से मार्शल और अनारक्षित होते हैं।
  • इंटरफेस को स्थिर (पीछे की ओर संगत) के रूप में घोषित किया जा सकता है। जब ऐसा होता है, तो उनके एपीआई को एआईडीएल इंटरफेस के बगल में एक फाइल में ट्रैक और संस्करणित किया जाता है।

एआईडीएल इंटरफेस को परिभाषित करना

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: ["ohter-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 इंटरफ़ेस किसी इंटरफ़ेस का उपयोग करता है या किसी अन्य सहायता से aidl_interface है, तो उसका नाम यहाँ रखें। यह अपने आप में नाम हो सकता है, नवीनतम संस्करण को संदर्भित करने के लिए, या किसी विशिष्ट संस्करण को संदर्भित करने के लिए संस्करण प्रत्यय (जैसे -V1 ) के साथ नाम। एक संस्करण निर्दिष्ट करना Android 12 . के बाद से समर्थित है
  • versions : इंटरफ़ेस के पिछले संस्करण जो api_dir के तहत जमे हुए हैं, Android 11 में शुरू हो रहे हैं, versions aidl_api/ name के तहत जमे हुए हैं। यदि किसी इंटरफ़ेस का कोई फ़्रीज़ किया हुआ संस्करण नहीं है, तो इसे निर्दिष्ट नहीं किया जाना चाहिए, और संगतता जाँच नहीं होगी। इस फ़ील्ड को 13 और बाद के versions_with_info के लिए version_with_info से बदल दिया गया है।
  • version_with_info : versions_with_info की सूची, जिनमें से प्रत्येक में एक फ्रोजन संस्करण का नाम और अन्य aidl_interface मॉड्यूल के संस्करण आयात के साथ एक सूची शामिल है, जो कि aidl_interface के इस संस्करण को आयात किया गया है। AIDL इंटरफ़ेस IFACE के संस्करण V की परिभाषा पर स्थित है aidl_api/ IFACE / V । यह फ़ील्ड Android 13 में पेश किया गया था, और इसे सीधे Android.bp में संशोधित नहीं किया जाना चाहिए। *-अपडेट- *-update-api या *-freeze-api लागू करके फ़ील्ड को जोड़ा या अपडेट किया जाता है। साथ ही, जब कोई उपयोगकर्ता *-update- *-update-api या *-freeze-api आह्वान करता है, तो versions फ़ील्ड स्वचालित रूप से version_with_info में माइग्रेट हो जाते versions_with_info
  • stability : इस इंटरफ़ेस के स्थिरता वादे के लिए वैकल्पिक ध्वज। वर्तमान में केवल "vintf" का समर्थन करता है। यदि यह सेट नहीं है, तो यह इस संकलन संदर्भ में स्थिरता के साथ एक इंटरफ़ेस से मेल खाता है (इसलिए यहां लोड किया गया इंटरफ़ेस केवल एक साथ संकलित चीजों के साथ उपयोग किया जा सकता है, उदाहरण के लिए system.img पर)। यदि यह "vintf" पर सेट है, तो यह एक स्थिरता वादे के अनुरूप है: इंटरफ़ेस को तब तक स्थिर रखा जाना चाहिए जब तक इसका उपयोग किया जाता है।
  • gen_trace : ट्रेसिंग को चालू या बंद करने के लिए वैकल्पिक ध्वज। डिफ़ॉल्ट false है।
  • host_supported : वैकल्पिक ध्वज जो true पर सेट होने पर उत्पन्न पुस्तकालयों को मेजबान वातावरण में उपलब्ध कराता है।
  • unstable : वैकल्पिक ध्वज का उपयोग यह चिह्नित करने के लिए किया जाता है कि इस इंटरफ़ेस को स्थिर होने की आवश्यकता नहीं है। जब इसे सही पर सेट किया जाता true , तो बिल्ड सिस्टम न तो इंटरफ़ेस के लिए एपीआई डंप बनाता है और न ही इसे अपडेट करने की आवश्यकता होती है।
  • backend.<type>.enabled : ये फ़्लैग प्रत्येक बैकएंड को टॉगल करते हैं जिसके लिए AIDL कंपाइलर कोड जनरेट करता है। वर्तमान में, चार बैकएंड समर्थित हैं: जावा, सी ++, एनडीके, और रस्ट। जावा, सी++ और एनडीके बैकएंड डिफ़ॉल्ट रूप से सक्षम हैं। यदि इन तीनों में से किसी बैकएंड की आवश्यकता नहीं है, तो इसे स्पष्ट रूप से अक्षम करने की आवश्यकता है। जंग डिफ़ॉल्ट रूप से अक्षम है।
  • backend.<type>.apex_available : एपेक्स नामों की सूची जिसके लिए जनरेट की गई स्टब लाइब्रेरी उपलब्ध है।
  • backend.[cpp|java].gen_log : वैकल्पिक ध्वज जो नियंत्रित करता है कि लेनदेन के बारे में जानकारी एकत्र करने के लिए अतिरिक्त कोड उत्पन्न करना है या नहीं।
  • backend.[cpp|java].vndk.enabled : इस इंटरफ़ेस को VNDK का हिस्सा बनाने के लिए वैकल्पिक ध्वज। डिफ़ॉल्ट false है।
  • backend.java.platform_apis : वैकल्पिक फ़्लैग जो यह नियंत्रित करता है कि जावा स्टब लाइब्रेरी प्लेटफ़ॉर्म से निजी एपीआई के विरुद्ध बनाई गई है या नहीं। stability "vintf" पर सेट होने पर इसे "true" पर सेट किया जाना चाहिए।
  • backend.java.sdk_version : एसडीके के संस्करण को निर्दिष्ट करने के लिए वैकल्पिक ध्वज जिसके खिलाफ जावा स्टब पुस्तकालय बनाया गया है। डिफ़ॉल्ट "system_current" है। इसे तब सेट नहीं किया जाना चाहिए जब backend.java.platform_apis सत्य हो।
  • backend.java.platform_apis : वैकल्पिक ध्वज जिसे true पर सेट किया जाना चाहिए जब उत्पन्न पुस्तकालयों को एसडीके के बजाय प्लेटफॉर्म एपीआई के खिलाफ बनाने की आवश्यकता होती है।

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

एआईडीएल फाइलें लिखना

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

// 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 के लिए वर्तमान में एक डिफ़ॉल्ट समर्थित है (लेकिन आवश्यक नहीं)। एंड्रॉइड 12 में, उपयोगकर्ता द्वारा परिभाषित गणनाओं के लिए डिफ़ॉल्ट भी समर्थित हैं। जब कोई डिफ़ॉल्ट निर्दिष्ट नहीं होता है, तो 0-जैसा या खाली मान का उपयोग किया जाता है। एक डिफ़ॉल्ट मान के बिना गणनाओं को 0 से प्रारंभ किया जाता है, भले ही कोई शून्य गणक न हो।

स्टब लाइब्रेरी का उपयोग करना

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

cc_... {
    name: ...,
    shared_libs: ["my-module-name-cpp"],
    ...
}
# or
java_... {
    name: ...,
    // can also be shared_libs if desire 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: ...,
    rust_libs: ["my-module-name-rust"],
    ...
}

सी ++ में उदाहरण:

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

जावा में उदाहरण:

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

जंग में उदाहरण:

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

वर्जनिंग इंटरफेस

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

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

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

  • एक इंटरफ़ेस के अंत के तरीके (या स्पष्ट रूप से परिभाषित नए धारावाहिकों के साथ तरीके)
  • पार्सल के अंत तक के तत्व (प्रत्येक तत्व के लिए एक डिफ़ॉल्ट जोड़ने की आवश्यकता होती है)
  • लगातार मूल्य
  • Android 11 में, गणक
  • Android 12 में, संघ के अंत तक फ़ील्ड

किसी अन्य क्रिया की अनुमति नहीं है, और कोई भी इंटरफ़ेस को संशोधित नहीं कर सकता है (अन्यथा वे मालिक द्वारा किए गए परिवर्तनों के साथ टकराव का जोखिम उठाते हैं)।

यह जांचने के लिए कि सभी इंटरफेस रिलीज के लिए जमे हुए हैं, आप निम्नलिखित पर्यावरण चर सेट के साथ बना सकते हैं:

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

संस्करणित इंटरफेस का उपयोग करना

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

रनटाइम पर, पुराने सर्वर पर नई विधियों को कॉल करने का प्रयास करते समय, बैकएंड के आधार पर नए क्लाइंट को त्रुटि या अपवाद मिलता है।

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

इसे संभालने के लिए रणनीतियों के लिए संस्करणों को क्वेरी करना और डिफ़ॉल्ट का उपयोग करना देखें।

पार्सल योग्य

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

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

Enums और स्थिरांक

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

यूनियन

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

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

एंड्रॉइड 11 में, संस्करणों के प्रत्येक संयोजन और सक्षम बैकएंड के लिए, एक स्टब लाइब्रेरी मॉड्यूल स्वचालित रूप से बनाया जाता है। लिंक करने के लिए एक विशिष्ट स्टब लाइब्रेरी मॉड्यूल को संदर्भित करने के लिए, aidl_interface मॉड्यूल के नाम का उपयोग न करें, लेकिन स्टब लाइब्रेरी मॉड्यूल का नाम, जो कि ifacename - version - backend है, जहां

  • ifacename : aidl_interface मॉड्यूल का नाम
  • version या तो का है
    • जमे हुए संस्करणों के लिए V version-number
    • V latest-frozen-version-number + 1 टिप-ऑफ-ट्री (अभी तक जमे हुए) संस्करण के लिए
  • backend या तो का है
    • java बैकएंड के लिए जावा,
    • सी ++ बैकएंड के लिए cpp ,
    • ndk बैकएंड के लिए ndk या ndk_platform । पूर्व ऐप्स के लिए है, और बाद वाला प्लेटफ़ॉर्म उपयोग के लिए है,
    • rust बैकएंड के लिए जंग।

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

  • संस्करण 1 . के आधार पर
    • foo-V1-(java|cpp|ndk|ndk_platform|rust)
  • संस्करण 2 (नवीनतम स्थिर संस्करण) के आधार पर
    • foo-V2-(java|cpp|ndk|ndk_platform|rust)
  • टीओटी संस्करण के आधार पर
    • foo-V3-(java|cpp|ndk|ndk_platform|rust)

एंड्रॉइड 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 स्थिर AIDL के लिए कई मेटा इंटरफ़ेस विधियाँ जोड़ता है।

दूरस्थ वस्तु के इंटरफ़ेस संस्करण को क्वेरी करना

क्लाइंट इंटरफ़ेस के संस्करण और हैश को क्वेरी कर सकते हैं जिसे दूरस्थ ऑब्जेक्ट कार्यान्वित कर रहा है और क्लाइंट द्वारा उपयोग किए जा रहे इंटरफ़ेस के मानों के साथ लौटाए गए मानों की तुलना कर सकते हैं।

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();

जावा भाषा के लिए, दूरस्थ पक्ष को getInterfaceVersion() और getInterfaceHash() को निम्नानुसार लागू करना होगा:

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

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

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

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

यह संभव है कि क्लाइंट को AIDL इंटरफ़ेस के नए संस्करण के साथ अपडेट किया गया हो लेकिन सर्वर पुराने AIDL इंटरफ़ेस का उपयोग कर रहा हो। ऐसे मामलों में, पुराने इंटरफ़ेस पर किसी विधि को कॉल करना UNKNOWN_TRANSACTION लौटाता है।

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

एंड्रॉइड 13 और बाद में सी ++ में उदाहरण:

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

जावा में उदाहरण:

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


foo.anAddedMethod(...);

आपको AIDL इंटरफ़ेस में सभी विधियों का डिफ़ॉल्ट कार्यान्वयन प्रदान करने की आवश्यकता नहीं है। रिमोट साइड में लागू होने की गारंटी वाले तरीके (क्योंकि आप निश्चित हैं कि रिमोट तब बनाया गया था जब एआईडीएल इंटरफ़ेस विवरण में विधियां थीं) को डिफ़ॉल्ट impl क्लास में ओवरराइड करने की आवश्यकता नहीं है।

मौजूदा एआईडीएल को संरचित/स्थिर एआईडीएल में बदलना

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

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

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

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