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

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

HIDL कोड स्ट्रक्चर

उपयोगकर्ता के हिसाब से तय किए गए HIDL कोड को व्यवस्थित किया जाता है प्रकार, इंटरफ़ेस, और पैकेज उपलब्ध हैं:

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

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

वर्शनिंग फ़िलॉसफ़ी

एक HIDL पैकेज (जैसे कि android.hardware.nfc), किसी दिए गए वर्शन (जैसे कि 1.0) के लिए पब्लिश किया गया है, तो उसमें बदलाव नहीं किया जा सकता; यह बदला नहीं जा सकता. पैकेज या किसी भी इंटरफ़ेस में मौजूद इंटरफ़ेस में बदलाव करना उसके यूडीटी में सिर्फ़ दूसरे पैकेज में बदलाव किए जा सकते हैं.

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

सैद्धांतिक रूप से, कोई पैकेज इनमें से किसी एक तरीके से दूसरे पैकेज से जुड़ सकता है:

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

इंटरफ़ेस स्ट्रक्चरिंग

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

ट्रेबल अलग से कंपाइल किए गए वेंडर और सिस्टम कॉम्पोनेंट का इस्तेमाल करता है जिनमें vendor.img किसी डिवाइस पर होता है और system.img अलग-अलग कंपाइल किया जाता है. vendor.img और के बीच के सभी इंटरैक्शन system.img को साफ़ तौर पर और अच्छी तरह से परिभाषित किया जाना चाहिए, ताकि वे कई सालों तक काम करना जारी रखा है. इसमें कई एपीआई प्लैटफ़ॉर्म शामिल हैं, लेकिन सरफ़ेस वह आईपीसी मैकेनिज़्म है जिसका इस्तेमाल HIDL, इंटरप्रोसेस कम्यूनिकेशन के लिए करता है system.img/vendor.img सीमा.

ज़रूरी शर्तें

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

  • एचआईडीएल में सीधे तौर पर (स्ट्रक्ट ईनम वगैरह का इस्तेमाल करके) में बताया जा सकता है सिमैंटिक नाम और उनका मतलब.
  • ISO/IEC 7816 जैसे सार्वजनिक मानक में बताया जा सकता है.
  • यह हार्डवेयर के स्टैंडर्ड या फ़िज़िकल लेआउट के ज़रिए बताई जा सकती है.
  • अगर ज़रूरी हो, तो हो सकता है कि डेटा में कोई अंतर न हो. जैसे, सार्वजनिक पासकोड, आईडी वगैरह.

अगर ओपेक डेटा का इस्तेमाल किया जाता है, तो इसे एचआईडीएल के एक हिस्से से ही पढ़ा जाना चाहिए इंटरफ़ेस पर कॉपी करने की सुविधा मिलती है. उदाहरण के लिए, अगर vendor.img कोड स्ट्रिंग मैसेज को system.img या vec<uint8_t> डेटा को system.img से पार्स नहीं किया जा सकता; यह कर सकता है इसे सिर्फ़ vendor.img में वापस पास करें. कब इस तारीख को vendor.img से वेंडर कोड में मान पास किया जा रहा है system.img या किसी दूसरे डिवाइस पर, डेटा का फ़ॉर्मैट और का सटीक रूप से वर्णन किया जाना चाहिए और अब भी इंटरफ़ेस होता है.

दिशा-निर्देश

ऐसा होने पर, आपको सिर्फ़ .hal फ़ाइलें (इसका मतलब है कि आपको Android का सोर्स या सार्वजनिक तौर पर देखने की ज़रूरत नहीं है मानकों के हिसाब से). हमारा सुझाव है कि आप सटीक ज़रूरी व्यवहार तय करें. इस तरह के स्टेटमेंट "किसी लागू करने पर A या B काम करेगा" लागू करने के लिए प्रोत्साहित करना अन्य क्लाइंट के साथ जुड़ना चाहते हैं.

HIDL कोड लेआउट

HIDL में कोर और वेंडर पैकेज शामिल हैं.

कोर HIDL इंटरफ़ेस वे होते हैं जिन्हें Google तय करता है. उनके पैकेज android.hardware. से शुरू करने के लिए और सबसिस्टम से नाम दिए जाते हैं. संभावित तौर पर, नेस्ट किए गए नामों के लेवल के साथ. उदाहरण के लिए, NFC पैकेज को नाम android.hardware.nfc और कैमरा पैकेज यह है android.hardware.camera. आम तौर पर, कोर पैकेज का नाम होता है android.hardware.[name1][name2].... एचआईडीएल पैकेज के नाम के अलावा एक वर्शन भी होता है. उदाहरण के लिए, android.hardware.camera, वर्शन 3.4 पर हो सकता है; यह है ज़रूरी है, क्योंकि पैकेज के वर्शन का असर सोर्स ट्री में इसके प्लेसमेंट पर पड़ता है.

सभी मुख्य पैकेज को इसमें hardware/interfaces/ के तहत रखा जाता है बिल्ड सिस्टम. पैकेज android.hardware.[name1][name2]... वर्शन $m.$n पर है hardware/interfaces/name1/name2/.../$m.$n/; पैकेज android.hardware.camera वर्शन 3.4, डायरेक्ट्री में है hardware/interfaces/camera/3.4/. हार्ड कोड की गई मैपिंग मौजूद है पैकेज प्रीफ़िक्स android.hardware. और पाथ के बीच hardware/interfaces/.

नॉन-कोर (वेंडर) पैकेज, वे होते हैं जिन्हें SoC वेंडर या ओडीएम बनाते हैं. कॉन्टेंट बनाने नॉन-कोर पैकेज के लिए प्रीफ़िक्स vendor.$(VENDOR).hardware. है, जहां $(VENDOR)का मतलब है SoC वेंडर या OEM/ODM. यह पाथ पर मैप होता है ट्री में vendor/$(VENDOR)/interfaces (यह मैपिंग भी हार्ड कोड किया गया होता है.

पूरी तरह क्वालिफ़ाइड उपयोगकर्ता के तय किए गए टाइप के नाम

HIDL में, हर UDT का नाम पूरी तरह क्वालिफ़ाइड नाम होता है, जिसमें यूडीटी का नाम शामिल होता है, पैकेज का नाम और पैकेज वर्शन. कॉन्टेंट बनाने पूरी तरह क्वालिफ़ाइड नाम का इस्तेमाल सिर्फ़ तब किया जाता है, जब टाइप के इंस्टेंस दिए गए हों और जहां टाइप को परिभाषित किया गया हो. उदाहरण के लिए, मान लें कि android.hardware.nfc, वर्शन 1.0, स्ट्रक्चर के बारे में बताता है NfcData नाम दिया गया है. एलान की साइट पर (भले ही types.hal या इंटरफ़ेस के एलान में, डिक्लेरेशन यह सिर्फ़ यह बताता है:

struct NfcData {
    vec<uint8_t> data;
};

इस टाइप के इंस्टेंस के बारे में बताते समय (किसी डेटा स्ट्रक्चर के अंदर या एक तरीका पैरामीटर के रूप में), पूरी तरह क्वालिफ़ाइड टाइप नाम का इस्तेमाल करें:

android.hardware.nfc@1.0::NfcData

सामान्य सिंटैक्स यह है PACKAGE@VERSION::UDT, जहां:

  • PACKAGE, HIDL पैकेज का बिंदु से अलग किया गया नाम है (उदाहरण के लिए, android.hardware.nfc).
  • VERSION बिंदु से अलग किया गयाMajor.minor-version है पैकेज का फ़ॉर्मैट (उदाहरण के लिए, 1.0).
  • UDT, HIDL UDT का बिंदु से अलग किया गया नाम है. HIDL, नेस्ट किए गए UDT के साथ काम करता है और HIDL इंटरफ़ेस में UDTs (एक तरह का नेस्ट किए गए डिक्लेरेशन), बिंदुओं का इस्तेमाल नाम ऐक्सेस करने के लिए किया जाता है.

उदाहरण के लिए, अगर नेस्ट किए गए नीचे दिए गए एलान को पैकेज android.hardware.example वर्शन में फ़ाइल टाइप करता है 1.0:

// types.hal
package android.hardware.example@1.0;
struct Foo {
    struct Bar {
        // …
    };
    Bar cheers;
};

Bar के लिए पूरी तरह क्वालिफ़ाइड नाम है android.hardware.example@1.0::Foo.Bar. अगर, समाचार संगठन ऊपर दिए गए पैकेज में, नेस्ट की गई डिक्लेरेशन IQuux:

// IQuux.hal
package android.hardware.example@1.0;
interface IQuux {
    struct Foo {
        struct Bar {
            // …
        };
        Bar cheers;
    };
    doSomething(Foo f) generates (Foo.Bar fb);
};

Bar के लिए पूरी तरह क्वालिफ़ाइड नाम है android.hardware.example@1.0::IQuux.Foo.Bar.

दोनों मामलों में, Bar को सिर्फ़ Bar कहा जा सकता है Foo की घोषणा के दायरे में आता है. पैकेज के लिए या इंटरफ़ेस स्तर, आपको Foo के माध्यम से Bar को देखना होगा: Foo.Bar, जैसा कि doSomething तरीके के एलान में बताया गया है पढ़ें. इसके अलावा, इस तरीके का एलान इस तरह किया जा सकता है:

// IQuux.hal
doSomething(android.hardware.example@1.0::IQuux.Foo f) generates (android.hardware.example@1.0::IQuux.Foo.Bar fb);

पूरी तरह क्वालिफ़ाइड इन्यूमरेशन वैल्यू

अगर यूडीटी एक ईनम टाइप है, तो ईनम टाइप की हर वैल्यू में पूरी तरह क्वालिफ़ाइड नाम, जो एनम टाइप के पूरी तरह क्वालिफ़ाइड नाम से शुरू होता हो, इसके बाद कोलन और इसके बाद ईनम की वैल्यू का नाम डालें. उदाहरण के लिए, पैकेज android.hardware.nfc, वर्शन 1.0 को मानें एनम टाइप NfcStatus को तय करता है:

enum NfcStatus {
    STATUS_OK,
    STATUS_FAILED
};

STATUS_OK के संदर्भ में, पूरी तरह क्वालिफ़ाइड नाम है:

android.hardware.nfc@1.0::NfcStatus:STATUS_OK

सामान्य सिंटैक्स यह है PACKAGE@VERSION::UDT:VALUE, कहां:

  • PACKAGE@VERSION::UDT ईनम टाइप के लिए, पूरी तरह क्वालिफ़ाइड नाम.
  • वैल्यू का नाम VALUE है.

अपने-आप अनुमान के नियम

पूरी तरह क्वालिफ़ाइड यूडीटी नाम बताना ज़रूरी नहीं है. यूडीटी का नाम यह कर सकता है नीचे दी गई चीज़ों को सुरक्षित तरीके से हटा दें:

  • पैकेज, जैसे @1.0::IFoo.Type
  • पैकेज और वर्शन, दोनों, जैसे कि IFoo.Type

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

पहला नियम

अगर कोई पैकेज और वर्शन नहीं दिया जाता है, तो लोकल नेम को खोजने की कोशिश की जाती है. उदाहरण:

interface Nfc {
    typedef string NfcErrorMessage;
    send(NfcData d) generates (@1.0::NfcStatus s, NfcErrorMessage m);
};

NfcErrorMessage को स्थानीय तौर पर खोजा गया और typedef दिया गया है. NfcData को स्थानीय तौर पर भी खोजा गया, लेकिन जैसा कि स्थानीय तौर पर तय नहीं किया गया है, तो नियम 2 और 3 का इस्तेमाल किया गया है. @1.0::NfcStatus वर्शन उपलब्ध कराता है, इसलिए पहला नियम लागू नहीं होता.

दूसरा नियम

अगर पहला नियम फ़ेल हो जाता है और पूरी तरह क्वालिफ़ाइड नाम वाला कोई कॉम्पोनेंट मौजूद नहीं है (पैकेज, वर्शन या पैकेज और वर्शन) का इस्तेमाल करते हैं, तो कॉम्पोनेंट में मौजूदा पैकेज की जानकारी. HIDL कंपाइलर बाद में अपने-आप भरने वाला, पूरी तरह क्वालिफ़ाइड नाम ढूंढने के लिए, मौजूदा फ़ाइल (और सभी इंपोर्ट) का इस्तेमाल करें. ऊपर दिए गए उदाहरण का इस्तेमाल करके, ExtendedNfcData का एलान करें उसी पैकेज (android.hardware.nfc) में बनाया गया था, जो वर्शन (1.0) का इस्तेमाल NfcData के तौर पर करें, इसके लिए नीचे दिया गया तरीका अपनाएं:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

HIDL कंपाइलर पूरी तरह क्वालिफ़ाइड यूडीटी नाम बनाने के लिए, मौजूदा पैकेज android.hardware.nfc@1.0::NfcData. जैसा कि इस नाम में मौजूद है मौजूदा पैकेज (यह मानते हुए कि इसे ठीक से आयात किया गया है), इसका उपयोग एलान के लिए उपलब्ध है.

मौजूदा पैकेज में कोई नाम सिर्फ़ तब इंपोर्ट किया जाता है, जब इनमें से कोई एक नाम सही:

  • इसे import स्टेटमेंट के साथ साफ़ तौर पर इंपोर्ट किया गया है.
  • इसकी जानकारी मौजूदा पैकेज में types.hal में दी गई है

अगर NfcData को सिर्फ़ मंज़ूरी मिली होती है, तो वही प्रक्रिया अपनाई जाती है वर्शन नंबर:

struct ExtendedNfcData {
    // autofill the current package name (android.hardware.nfc)
    @1.0::NfcData base;
    // … additional members
};

तीसरा नियम

अगर दूसरा नियम मैच नहीं कर पाता है (यूडीटी को मौजूदा पैकेज), HIDL कंपाइलर सभी इंपोर्ट किए गए पैकेज में से मैच करने के लिए स्कैन करता है. ऊपर दिए गए उदाहरण का इस्तेमाल करके, मान लें कि ExtendedNfcData का एलान पैकेज android.hardware.nfc का 1.1 वर्शन, 1.1, 1.0 को उसी तरह इंपोर्ट करता है जैसा इसे होना चाहिए (देखें पैकेज-लेवल एक्सटेंशन), और परिभाषा सिर्फ़ यूडीटी का नाम बताता है:

struct ExtendedNfcData {
    NfcData base;
    // … additional members
};

कंपाइलर NfcData नाम का कोई यूडीटी ढूंढता है और उसे 1.0 वर्शन पर android.hardware.nfc की वजह से, android.hardware.nfc@1.0::NfcData की पूरी तरह क्वालिफ़ाइड यूडीटी. अगर ज़्यादा दिए गए आंशिक रूप से क्वालिफ़ाइड यूडीटी के लिए, एक से ज़्यादा मैच मिलते हैं, जिसे HIDL कंपाइलर कहते हैं गड़बड़ी होती है.

उदाहरण

नियम 2 का इस्तेमाल करके, मौजूदा पैकेज में इंपोर्ट किए गए एक टाइप को प्राथमिकता दी जाती है किसी दूसरे पैकेज से इंपोर्ट किया गया टाइप:

// hardware/interfaces/foo/1.0/types.hal
package android.hardware.foo@1.0;
struct S {};

// hardware/interfaces/foo/1.0/IFooCallback.hal
package android.hardware.foo@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/types.hal
package android.hardware.bar@1.0;
typedef string S;

// hardware/interfaces/bar/1.0/IFooCallback.hal
package android.hardware.bar@1.0;
interface IFooCallback {};

// hardware/interfaces/bar/1.0/IBar.hal
package android.hardware.bar@1.0;
import android.hardware.foo@1.0;
interface IBar {
    baz1(S s); // android.hardware.bar@1.0::S
    baz2(IFooCallback s); // android.hardware.foo@1.0::IFooCallback
};
  • S को इस तरह इंटरपोलेट किया गया है android.hardware.bar@1.0::S, और यह इनमें पाया जाता है bar/1.0/types.hal (क्योंकि types.hal अपने-आप है इंपोर्ट किया गया).
  • IFooCallback को इस तरह इंटरपोलेट किया गया है दूसरे नियम का इस्तेमाल करके android.hardware.bar@1.0::IFooCallback, लेकिन यह खोजा नहीं जा सकता, क्योंकि bar/1.0/IFooCallback.hal को इंपोर्ट नहीं किया गया है (जैसा कि types.hal है). इस तरह, नियम 3 इसका समाधान करता है इसके बजाय android.hardware.foo@1.0::IFooCallback, जिसे इंपोर्ट किया गया है import android.hardware.foo@1.0; से होकर).

Type.hal

हर HIDL पैकेज में UDT वाली एक types.hal फ़ाइल होती है ऐसी फ़ाइलें जो उस पैकेज में हिस्सा लेने वाले सभी इंटरफ़ेस में शेयर की जाती हैं. HIDL टाइप हमेशा सार्वजनिक होते हैं; भले ही, types.hal या इंटरफ़ेस के एलान में, ये टाइप यहां दिए गए हैं इन्हें तय किए गए दायरे से बाहर ऐक्सेस किया जा सकता है. types.hal इसका मकसद किसी पैकेज के सार्वजनिक एपीआई के बारे में बताना नहीं है, बल्कि यूडीटी को होस्ट करना है का इस्तेमाल पैकेज के सभी इंटरफ़ेस में किया जाता है. एचआईडीएल की मौजूदगी की वजह से, सभी यूडीटी इंटरफ़ेस का हिस्सा हैं.

types.hal में यूडीटी और import स्टेटमेंट शामिल होते हैं. क्योंकि types.hal को इसके हर इंटरफ़ेस के लिए उपलब्ध कराया गया है पैकेज (यह इंप्लिसिट इंपोर्ट है), ये import स्टेटमेंट हैं परिभाषा के हिसाब से पैकेज-लेवल. types.hal के यूडीटी में ये भी शामिल किए जा सकते हैं इस तरह, यूडीटी और इंटरफ़ेस इंपोर्ट किए गए.

उदाहरण के लिए, IFoo.hal के लिए:

package android.hardware.foo@1.0;
// whole package import
import android.hardware.bar@1.0;
// types only import
import android.hardware.baz@1.0::types;
// partial imports
import android.hardware.qux@1.0::IQux.Quux;
// partial imports
import android.hardware.quuz@1.0::Quuz;

ये डेटा इंपोर्ट किए गए हैं:

  • android.hidl.base@1.0::IBase (अस्पष्ट रूप से)
  • android.hardware.foo@1.0::types (अस्पष्ट रूप से)
  • android.hardware.bar@1.0 में सब कुछ (इसमें सभी शामिल हैं इंटरफ़ेस और उसके types.hal)
  • android.hardware.baz@1.0::types के डेटा की तुलना में, types.hal प्रॉडक्ट की संख्या में बदलाव (android.hardware.baz@1.0 के इंटरफ़ेस इंपोर्ट नहीं किए जाते)
  • IQux.hal और types.hal से android.hardware.qux@1.0
  • android.hardware.quuz@1.0 से Quuz (यह मानते हुए कि Quuz को types.hal में परिभाषित किया गया है, जो types.hal फ़ाइल पार्स की गई है, लेकिन Quuz के अलावा अन्य टाइप भी हैं इंपोर्ट नहीं किए जाते).

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

किसी पैकेज में मौजूद हर इंटरफ़ेस अपनी फ़ाइल में मौजूद होता है. वह पैकेज इंटरफ़ेस का एलान करने के लिए, उसका इस्तेमाल package स्टेटमेंट. पैकेज के एलान के बाद, शून्य या उससे ज़्यादा इंटरफ़ेस-लेवल के इंपोर्ट (पार्शियल या फ़ुल-पैकेज) की सूची में शामिल किया जा सकता है. उदाहरण के लिए: 

package android.hardware.nfc@1.0;

HIDL में, इंटरफ़ेस extends कीवर्ड. किसी इंटरफ़ेस को अन्य इंटरफ़ेस तक विस्तृत करने के लिए, के पास import स्टेटमेंट के ज़रिए इसका ऐक्सेस होना चाहिए. इवेंट मैनेजर का नाम बढ़ाया जा रहा इंटरफ़ेस (बेस इंटरफ़ेस), टाइप-नाम के नियमों का पालन करता है योग्यता के बारे में ऊपर बताया गया है. किसी इंटरफ़ेस को सिर्फ़ एक इंटरफ़ेस से इनहेरिट किया जा सकता है; HIDL एक से ज़्यादा इनहेरिटेंस के साथ काम नहीं करता.

नीचे दिए गए, अपडेट किए गए वर्शन के उदाहरणों में इस पैकेज का इस्तेमाल किया गया है:

// types.hal
package android.hardware.example@1.0
struct Foo {
    struct Bar {
        vec<uint32_t> val;
    };
};

// IQuux.hal
package android.hardware.example@1.0
interface IQuux {
    fromFooToBar(Foo f) generates (Foo.Bar b);
}

अपरेव के नियम

पैकेज package@major.minor तय करने के लिए, या तो A या सभी B का पैकेज बनाएं सही होना चाहिए:

नियम A "क्या स्टार्ट माइनर वर्शन है": सभी पिछले माइनर वर्शन, package@major.0, package@major.1, ..., package@major.(minor-1) के बारे में नहीं बताया जाना चाहिए.
या
नियम B

नीचे दी गई सभी बातें सही हैं:

  1. "पिछला माइनर वर्शन मान्य है": package@major.(minor-1) को परिभाषित किया जाना चाहिए और समान नियम A का पालन करना चाहिए (इनमें से कोई नहीं package@major.0 से package@major.(minor-2) तय किए गए हैं) या नियम B (अगर यह @major.(minor-2) से हुआ है);

    और

  2. "एक ही नाम वाला कम से कम एक इंटरफ़ेस इनहेरिट करें": विस्तार करने वाला इंटरफ़ेस package@major.minor::IFoo package@major.(minor-1)::IFoo (अगर पिछले पैकेज में इंटरफ़ेस मौजूद हो);

    और

  3. "किसी अलग नाम वाला इनहेरिट किया गया कोई इंटरफ़ेस नहीं है": कोई इंटरफ़ेस मौजूद नहीं होना चाहिए package@major.minor::IBar की अवधि package@major.(minor-1)::IBaz, जहां IBar और IBaz दो अलग-अलग नाम हैं. अगर कोई इंटरफ़ेस है, तो समान नाम, package@major.minor::IBar को बढ़ाना होगा package@major.(minor-k)::IBar ऐसी इकाई के साथ कोई भी IBar मौजूद नहीं है छोटा के.

नियम A की वजह से:

  • पैकेज किसी भी माइनर वर्शन नंबर से शुरू हो सकता है (उदाहरण के लिए, android.hardware.biometrics.fingerprint शुरू होने का समय @2.1.)
  • "android.hardware.foo@1.0 के बारे में नहीं बताया गया है" शर्त इसका मतलब है hardware/interfaces/foo/1.0 डायरेक्ट्री मौजूद नहीं होनी चाहिए.

हालांकि, नियम A उसी पैकेज नाम वाले पैकेज पर असर नहीं डालता, लेकिन किसी दूसरे मुख्य वर्शन में शामिल हो सके (उदाहरण के लिए, android.hardware.camera.device के लिए, @1.0 और @3.2 के बारे में बताया गया है; @3.2 के लिए इससे इंटरैक्ट करने की ज़रूरत नहीं है @1.0.) इसलिए, @3.2::IExtFoo की अवधि बढ़ाई जा सकती है @1.0::IFoo.

बशर्ते पैकेज का नाम अलग हो, package@major.minor::IBar, कोई दूसरा नाम (उदाहरण के लिए, android.hardware.bar@1.0::IBar यह कर सकता है android.hardware.baz@2.2::IBaz तक बढ़ाएं). अगर कोई इंटरफ़ेस काम नहीं करता extend कीवर्ड के साथ किसी सुपर टाइप की जानकारी देता है, android.hidl.base@1.0::IBase को विस्तार देता है (IBase को छोड़कर) भी शामिल है).

B.2 और B.3 को एक साथ फ़ॉलो करना ज़रूरी है. उदाहरण के लिए, भले ही android.hardware.foo@1.1::IFoo बढ़ाएं नियम B.2 पास करने के लिए android.hardware.foo@1.0::IFoo, अगर कोई android.hardware.foo@1.1::IExtBar बढ़ाएं android.hardware.foo@1.0::IBar, यह अब भी मान्य बढ़ोतरी नहीं है.

UpRev इंटरफ़ेस

android.hardware.example@1.0 (ऊपर तय किया गया है) को बढ़ाकर @1.1:

// types.hal
package android.hardware.example@1.1;
import android.hardware.example@1.0;

// IQuux.hal
package android.hardware.example@1.1
interface IQuux extends @1.0::IQuux {
    fromBarToFoo(Foo.Bar b) generates (Foo f);
}

यह इसके 1.0 वर्शन का पैकेज-लेवल import है types.hal में android.hardware.example. हालांकि, कोई नया नहीं है यूडीटी को पैकेज के वर्शन 1.1 में जोड़ा जाता है. यह पैकेज के तौर पर, यूडीटी का रेफ़रंस देता है वर्शन 1.0 की अब भी ज़रूरत है. इसलिए, पैकेज-लेवल इंपोर्ट types.hal में. (ठीक इसी तरह, IQuux.hal में इंटरफ़ेस-लेवल इंपोर्ट.)

इसकी घोषणा extends @1.0::IQuux में की गई है IQuux, हमने IQuux का वह वर्शन बताया है जो इनहेरिट किया गया (साफ़ तौर पर बताना ज़रूरी है, क्योंकि IQuux का इस्तेमाल इन कामों के लिए किया गया है किसी इंटरफ़ेस के बारे में एलान करना होगा और उसे किसी इंटरफ़ेस से इनहेरिट करना होगा). जैसे कि एलान वे नाम जो आपकी साइट पर मौजूद सभी पैकेज और वर्शन एट्रिब्यूट को इनहेरिट करते हैं एलान के तौर पर, दी गई जानकारी को बेस इंटरफ़ेस के नाम में ही सबमिट किया जाना चाहिए; हम साथ ही, पूरी तरह क्वालिफ़ाइड यूडीटी का इस्तेमाल किया जा सकता था, लेकिन वह शायद ग़ैर-ज़रूरी.

नए इंटरफ़ेस IQuux में, तरीके का एलान नहीं किया गया है fromFooToBar() यह @1.0::IQuux से इनहेरिट करता है; बस इसे fromBarToFoo() को जोड़े जाने वाले नए तरीके की सूची बनाता है. HIDL में, इनहेरिट किया गया चाइल्ड इंटरफ़ेस में तरीकों का एलान फिर से नहीं किया जा सकता, इसलिए IQuux इंटरफ़ेस, fromFooToBar() का एलान नहीं कर सकता साफ़ तौर पर बताया गया है.

UpRev कन्वेंशन्स

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

// in parent hal file
enum Brightness : uint32_t { NONE, WHITE };

// in child hal file extending the existing set with additional similar values
enum Brightness : @1.0::Brightness { AUTOMATIC };

// extending the existing set with values that require a new, more descriptive name:
enum Color : @1.0::Brightness { HW_GREEN, RAINBOW };

अगर किसी तरीके का नया सिमैंटिक नाम हो सकता है (उदाहरण के लिए fooWithLocation) तो इसे प्राथमिकता दी जाएगी. अगर ऐसा नहीं है, तो दिए गए नाम वाले नाम से मिलता-जुलता है. उदाहरण के लिए, @1.1::IFoo में मौजूद foo_1_1, इस सुविधा की जगह ले सकता है अगर कोई बेहतर तरीका न हो, तो @1.0::IFoo में foo तरीके में से दूसरा नाम.

पैकेज-लेवल वर्शन

HIDL वर्शनिंग पैकेज लेवल पर होती है; पैकेज पब्लिश होने के बाद, बदला नहीं जा सकता. इसके इंटरफ़ेस और यूडीटी के सेट को बदला नहीं जा सकता. पैकेज यह कर सकते हैं एक-दूसरे से कई तरह से जुड़े होते हैं और ये सभी कंपोज़िशन के हिसाब से इंटरफ़ेस-लेवल इनहेरिटेंस और यूडीटी को तैयार करना.

हालांकि, एक तरह का संबंध सख्ती से तय होता है और उसे लागू किया जाना चाहिए: पैकेज-लेवल पर बैकवर्ड के साथ काम करने वाली इनहेरिटेंस. ऐसी स्थिति में, Parent पैकेज, वह पैकेज होता है जिसे चाइल्ड पैकेज वह है जो पैरंट के दायरे में आता है. पैकेज-लेवल पुराने सिस्टम के साथ काम करने वाली इनहेरिटेंस के नियम यहां दिए गए हैं:

  1. पैरंट पैकेज के सभी टॉप-लेवल इंटरफ़ेस, चाइल्ड पैकेज.
  2. नए इंटरफ़ेस भी नया पैकेज जोड़ा जा सकता है (कोई पाबंदी नहीं अन्य पैकेज में अन्य इंटरफ़ेस के साथ संबंध).
  3. अपग्रेड किए गए किसी नए तरीके से इस्तेमाल के लिए, नए डेटा टाइप भी जोड़े जा सकते हैं मौजूदा इंटरफ़ेस से या नए इंटरफ़ेस से कनेक्ट करें.

इन नियमों को HIDL इंटरफ़ेस-लेवल इनहेरिटेंस और UDT का इस्तेमाल करके लागू किया जा सकता है कंपोज़िशन के बारे में नहीं है, लेकिन इन संबंधों को जानने के लिए मेटा-लेवल की जानकारी होना ज़रूरी है ऐसा पैकेज एक्सटेंशन बनाना जो पुराने सिस्टम के साथ काम कर सके. इस जानकारी का अनुमान लगाया गया है इस तरह से:

अगर कोई पैकेज इस ज़रूरी शर्त को पूरा करता है, तो hidl-gen लागू करता है पुराने सिस्टम के साथ काम करने से जुड़े नियम.