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

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

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

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

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

aidl_interface {
    name: "my-aidl",
    srcs: ["srcs/aidl/**/*.aidl"],
    local_include_dir: "srcs/aidl",
    imports: ["other-aidl"],
    versions: ["1", "2"],
    stability: "vintf",
    backend: {
        java: {
            enabled: true,
            platform_apis: true,
        },
        cpp: {
            enabled: true,
        },
        ndk: {
            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 के तहत जमे हुए हैं। यदि किसी इंटरफ़ेस का कोई फ़्रीज़ किया हुआ संस्करण नहीं है, तो इसे निर्दिष्ट नहीं किया जाना चाहिए, और संगतता जाँच नहीं होगी।
  • stability : इस इंटरफ़ेस के स्थिरता वादे के लिए वैकल्पिक ध्वज। वर्तमान में केवल "vintf" का समर्थन करता है। यदि यह सेट नहीं है, तो यह इस संकलन संदर्भ में स्थिरता के साथ एक इंटरफ़ेस से मेल खाता है (इसलिए यहां लोड किया गया इंटरफ़ेस केवल एक साथ संकलित चीजों के साथ उपयोग किया जा सकता है, उदाहरण के लिए system.img पर)। यदि यह "vintf" पर सेट है, तो यह एक स्थिरता वादे के अनुरूप है: इंटरफ़ेस को तब तक स्थिर रखा जाना चाहिए जब तक इसका उपयोग किया जाता है।
  • gen_trace : ट्रेसिंग को चालू या बंद करने के लिए वैकल्पिक फ़्लैग। डिफ़ॉल्ट false है।
  • host_supported : वैकल्पिक ध्वज जो true पर सेट होने पर उत्पन्न पुस्तकालयों को मेजबान वातावरण के लिए उपलब्ध कराता है।
  • unstable : वैकल्पिक ध्वज का उपयोग यह चिह्नित करने के लिए किया जाता है कि इस इंटरफ़ेस को स्थिर होने की आवश्यकता नहीं है। जब इसे सही पर सेट किया जाता true , तो बिल्ड सिस्टम न तो इंटरफ़ेस के लिए एपीआई डंप बनाता है और न ही इसे अपडेट करने की आवश्यकता होती है।
  • backend.<type>.enabled : ये फ़्लैग प्रत्येक बैकएंड को टॉगल करते हैं जिसके लिए AIDL कंपाइलर कोड जनरेट करेगा। वर्तमान में, तीन बैकएंड समर्थित हैं: java , cpp , और ndk । बैकएंड सभी डिफ़ॉल्ट रूप से सक्षम हैं। जब किसी विशिष्ट बैकएंड की आवश्यकता नहीं होती है, तो इसे स्पष्ट रूप से अक्षम करने की आवश्यकता होती है।
  • 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 पर सेट किया जाना चाहिए जब उत्पन्न पुस्तकालयों को एसडीके के बजाय प्लेटफॉर्म एपीआई के खिलाफ बनाने की आवश्यकता होती है।

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

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

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

// 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"],
    ...
}

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

#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

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

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

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

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

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

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

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

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

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

  • 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 । पूर्व ऐप्स के लिए है, और बाद वाला प्लेटफ़ॉर्म उपयोग के लिए है।

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

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

एंड्रॉइड 11 की तुलना में,

  • foo- backend , जो नवीनतम स्थिर संस्करण को संदर्भित करता है, foo- V2 - backend बन जाता है
  • foo-unstable- backend , जिसे टीओटी संस्करण के लिए संदर्भित किया जाता है, फू- foo- V3 - backend बन जाता है

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

  • संस्करण 1 के आधार पर: foo-V1-(cpp|ndk|ndk_platform).so
  • संस्करण 2 पर आधारित: foo-V2-(cpp|ndk|ndk_platform).so
  • ToT संस्करण के आधार पर: foo-V3-(cpp|ndk|ndk_platform).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 लौटाता है।

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

एंड्रॉइड टी (एओएसपी प्रयोगात्मक) और बाद में सी ++ में उदाहरण:

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