एचआईडीएल इंटरफेस के आसपास बनाया गया है, व्यवहार को परिभाषित करने के लिए ऑब्जेक्ट-ओरिएंटेड भाषाओं में उपयोग किया जाने वाला एक अमूर्त प्रकार। प्रत्येक इंटरफ़ेस एक पैकेज का हिस्सा है।
संकुल
पैकेज नामों में package.subpackage
जैसे उपस्तर हो सकते हैं। प्रकाशित HIDL पैकेज के लिए मूल निर्देशिका hardware/interfaces
या vendor/vendorName
है (उदाहरण के लिए पिक्सेल उपकरणों के लिए vendor/google
)। पैकेज नाम रूट निर्देशिका के अंतर्गत एक या अधिक उपनिर्देशिकाएँ बनाता है; पैकेज को परिभाषित करने वाली सभी फ़ाइलें एक ही निर्देशिका में हैं। उदाहरण के लिए, package android.hardware.example.extension.light@2.0
hardware/interfaces/example/extension/light/2.0
के अंतर्गत पाया जा सकता है।
निम्न तालिका पैकेज उपसर्गों और स्थानों को सूचीबद्ध करती है:
पैकेज उपसर्ग | जगह | इंटरफ़ेस प्रकार |
---|---|---|
android.hardware.* | hardware/interfaces/* | एचएएल |
android.frameworks.* | frameworks/hardware/interfaces/* | ढाँचे/संबंधित |
android.system.* | system/hardware/interfaces/* | प्रणाली/संबंधित |
android.hidl.* | system/libhidl/transport/* | मुख्य |
पैकेज निर्देशिका में .hal
एक्सटेंशन वाली फ़ाइलें हैं। प्रत्येक फ़ाइल में एक package
स्टेटमेंट होना चाहिए जिसमें उस पैकेज और संस्करण का नाम दिया गया हो जिसका फ़ाइल हिस्सा है। फ़ाइल types.hal
, यदि मौजूद है, तो एक इंटरफ़ेस को परिभाषित नहीं करता है, बल्कि पैकेज में प्रत्येक इंटरफ़ेस के लिए पहुंच योग्य डेटा प्रकारों को परिभाषित करता है।
इंटरफ़ेस परिभाषा
types.hal
के अलावा, प्रत्येक अन्य .hal
फ़ाइल एक इंटरफ़ेस को परिभाषित करती है। एक इंटरफ़ेस को आम तौर पर इस प्रकार परिभाषित किया गया है:
interface IBar extends IFoo { // IFoo is another interface // embedded types struct MyStruct {/*...*/}; // interface methods create(int32_t id) generates (MyStruct s); close(); };
स्पष्ट extends
घोषणा के बिना एक इंटरफ़ेस अंतर्निहित रूप से android.hidl.base@1.0::IBase
(जावा में java.lang.Object
के समान) से विस्तारित होता है। IBase इंटरफ़ेस, अंतर्निहित रूप से आयातित, कई आरक्षित तरीकों की घोषणा करता है जिन्हें पुनः घोषित नहीं किया जाना चाहिए और न ही किया जा सकता है उपयोगकर्ता-परिभाषित इंटरफ़ेस में या अन्यथा उपयोग किया जाता है। इन विधियों में शामिल हैं:
-
ping
-
interfaceChain
-
interfaceDescriptor
-
notifySyspropsChanged
-
linkToDeath
-
unlinkToDeath
-
setHALInstrumentation
-
getDebugInfo
-
debug
-
getHashChain
आयात कर रहा है
import
विवरण दूसरे पैकेज में पैकेज इंटरफेस और प्रकारों तक पहुंचने के लिए एचआईडीएल तंत्र है। एक import
विवरण स्वयं दो संस्थाओं से संबंधित है:
- आयात इकाई, जो या तो एक पैकेज या एक इंटरफ़ेस हो सकती है; और
- आयातित इकाई, जो या तो एक पैकेज या एक इंटरफ़ेस हो सकती है।
आयात करने वाली इकाई का निर्धारण import
विवरण के स्थान से होता है। जब स्टेटमेंट किसी पैकेज के types.hal
के अंदर होता है, तो जो आयात किया जा रहा है वह पूरे पैकेज द्वारा दिखाई देता है; यह एक पैकेज-स्तरीय आयात है. जब कथन एक इंटरफ़ेस फ़ाइल के अंदर होता है, तो आयात करने वाली इकाई इंटरफ़ेस ही होती है; यह एक इंटरफ़ेस-स्तरीय आयात है.
आयातित इकाई import
कीवर्ड के बाद के मूल्य से निर्धारित होती है। मान को पूर्णतः योग्य नाम होना आवश्यक नहीं है; यदि कोई घटक छोड़ दिया जाता है, तो यह स्वचालित रूप से वर्तमान पैकेज से जानकारी से भर जाता है। पूर्णतः योग्य मानों के लिए, निम्नलिखित आयात मामले समर्थित हैं:
- संपूर्ण-पैकेज आयात . यदि मान एक पैकेज नाम और एक संस्करण (नीचे वर्णित वाक्यविन्यास) है, तो संपूर्ण पैकेज आयात करने वाली इकाई में आयात किया जाता है।
- आंशिक आयात . यदि मान है:
- एक इंटरफ़ेस, पैकेज के
types.hal
और उस इंटरफ़ेस को आयात करने वाली इकाई में आयात किया जाता है। - एक UDT को
types.hal
में परिभाषित किया गया है, तो केवल UDT को आयात करने वाली इकाई में आयात किया जाता है (types.hal
में अन्य प्रकार आयात नहीं किए जाते हैं)।
- एक इंटरफ़ेस, पैकेज के
- प्रकार-केवल आयात . यदि मान ऊपर वर्णित आंशिक आयात के सिंटैक्स का उपयोग करता है, लेकिन इंटरफ़ेस नाम के बजाय कीवर्ड
types
के साथ, निर्दिष्ट पैकेज के केवलtypes.hal
में यूडीटी आयात किए जाते हैं।
आयात करने वाली इकाई को इनके संयोजन तक पहुंच प्राप्त होती है:
- आयातित पैकेज के सामान्य यूडीटी को
types.hal
में परिभाषित किया गया है; - आयातित पैकेज के इंटरफेस (संपूर्ण-पैकेज आयात के लिए) या निर्दिष्ट इंटरफ़ेस (आंशिक आयात के लिए) उन्हें लागू करने, उन्हें हैंडल पास करने और/या उनसे विरासत में लेने के उद्देश्य से।
आयात विवरण आयात किए जा रहे पैकेज या इंटरफ़ेस का नाम और संस्करण प्रदान करने के लिए पूरी तरह से योग्य-प्रकार-नाम सिंटैक्स का उपयोग करता है:
import android.hardware.nfc@1.0; // import a whole package import android.hardware.example@1.0::IQuux; // import an interface and types.hal import android.hardware.example@1.0::types; // import just types.hal
इंटरफ़ेस विरासत
एक इंटरफ़ेस पहले से परिभाषित इंटरफ़ेस का विस्तार हो सकता है। एक्सटेंशन निम्नलिखित तीन प्रकारों में से एक हो सकते हैं:
- इंटरफ़ेस अपने एपीआई को अपरिवर्तित शामिल करते हुए किसी अन्य में कार्यक्षमता जोड़ सकता है।
- पैकेज अपने एपीआई को अपरिवर्तित शामिल करते हुए किसी अन्य में कार्यक्षमता जोड़ सकता है।
- इंटरफ़ेस किसी पैकेज से या किसी विशिष्ट इंटरफ़ेस से प्रकार आयात कर सकता है।
एक इंटरफ़ेस केवल एक अन्य इंटरफ़ेस (कोई मल्टीपल इनहेरिटेंस नहीं) का विस्तार कर सकता है। गैर-शून्य लघु संस्करण संख्या वाले पैकेज में प्रत्येक इंटरफ़ेस को पैकेज के पिछले संस्करण में एक इंटरफ़ेस का विस्तार करना होगा। उदाहरण के लिए, यदि पैकेज derivative
के संस्करण 4.0 में एक इंटरफ़ेस IBar
पैकेज original
के संस्करण 1.2 में एक इंटरफ़ेस IFoo
पर आधारित (विस्तारित) है, और पैकेज original
का एक संस्करण 1.3 बनाया गया है, IBar
संस्करण 4.1 IFoo
के संस्करण 1.3 का विस्तार नहीं कर सकता है। इसके बजाय, IBar
संस्करण 4.1 को IBar
संस्करण 4.0 का विस्तार करना होगा, जो IFoo
संस्करण 1.2 से जुड़ा हुआ है। यदि वांछित हो तो IBar
संस्करण 5.0, IFoo
संस्करण 1.3 का विस्तार कर सकता है।
इंटरफ़ेस एक्सटेंशन उत्पन्न कोड में लाइब्रेरी निर्भरता या क्रॉस-एचएएल समावेशन का संकेत नहीं देते हैं - वे केवल एचआईडीएल स्तर पर डेटा संरचना और विधि परिभाषाओं को आयात करते हैं। एचएएल में प्रत्येक विधि को उस एचएएल में लागू किया जाना चाहिए।
विक्रेता एक्सटेंशन
कुछ मामलों में, विक्रेता एक्सटेंशन को बेस ऑब्जेक्ट के उपवर्ग के रूप में कार्यान्वित किया जाएगा जो उनके द्वारा विस्तारित कोर इंटरफ़ेस का प्रतिनिधित्व करता है। वही ऑब्जेक्ट आधार एचएएल नाम और संस्करण के तहत, और एक्सटेंशन (विक्रेता) एचएएल नाम और संस्करण के तहत पंजीकृत किया जाएगा।
संस्करण
पैकेजों का संस्करण होता है, और इंटरफ़ेस के पास उनके पैकेज का संस्करण होता है। संस्करण दो पूर्णांकों, प्रमुख में व्यक्त किए जाते हैं। नाबालिग ।
- प्रमुख संस्करण पश्चगामी संगत नहीं हैं. प्रमुख संस्करण संख्या को बढ़ाने से लघु संस्करण संख्या 0 पर रीसेट हो जाती है।
- लघु संस्करण पश्चगामी संगत हैं। मामूली संख्या में वृद्धि यह दर्शाती है कि नया संस्करण पिछले संस्करण के साथ पूरी तरह से पिछड़ा संगत है। नई डेटा संरचनाएँ और विधियाँ जोड़ी जा सकती हैं, लेकिन कोई मौजूदा डेटा संरचनाएँ या विधि हस्ताक्षर नहीं बदले जा सकते।
एचएएल के कई प्रमुख या छोटे संस्करण एक डिवाइस पर एक साथ मौजूद हो सकते हैं। हालाँकि, एक प्रमुख संस्करण की तुलना में एक लघु संस्करण को प्राथमिकता दी जानी चाहिए क्योंकि क्लाइंट कोड जो पिछले लघु संस्करण इंटरफ़ेस के साथ काम करता है वह उसी इंटरफ़ेस के बाद के लघु संस्करणों के साथ भी काम करेगा। संस्करण और विक्रेता एक्सटेंशन पर अधिक विवरण के लिए, HIDL संस्करण देखें।
इंटरफ़ेस लेआउट सारांश
यह अनुभाग संक्षेप में बताता है कि एचआईडीएल इंटरफ़ेस पैकेज (जैसे hardware/interfaces
) को कैसे प्रबंधित किया जाए और पूरे एचआईडीएल अनुभाग में प्रस्तुत जानकारी को समेकित किया जाए। पढ़ने से पहले, सुनिश्चित करें कि आप HIDL वर्जनिंग , hidl-gen के साथ हैशिंग में हैशिंग अवधारणाओं, सामान्य रूप से HIDL के साथ काम करने के विवरण और निम्नलिखित परिभाषाओं से परिचित हैं:
अवधि | परिभाषा |
---|---|
एप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) | एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस + कोई बाइनरी लिंकेज आवश्यक। |
पूर्णतः योग्य नाम (fqName) | hidl प्रकार को अलग करने के लिए नाम। उदाहरण: android.hardware.foo@1.0::IFoo । |
पैकेट | पैकेज जिसमें HIDL इंटरफ़ेस और प्रकार शामिल हैं। उदाहरण: android.hardware.foo@1.0 । |
पैकेज रूट | रूट पैकेज जिसमें HIDL इंटरफ़ेस शामिल है। उदाहरण: HIDL इंटरफ़ेस android.hardware पैकेज रूट android.hardware.foo@1.0 में है। |
पैकेज रूट पथ | एंड्रॉइड सोर्स ट्री में वह स्थान जहां एक पैकेज रूट मैप होता है। |
अधिक परिभाषाओं के लिए, HIDL शब्दावली देखें।
प्रत्येक फ़ाइल को पैकेज रूट मैपिंग और उसके पूर्ण-योग्य नाम से पाया जा सकता है
पैकेज रूट्स को hidl-gen
को तर्क -r android.hardware:hardware/interfaces
के रूप में निर्दिष्ट किया गया है। उदाहरण के लिए, यदि पैकेज vendor.awesome.foo@1.0::IFoo
है और hidl-gen
भेजा गया है -r vendor.awesome:some/device/independent/path/interfaces
, तो इंटरफ़ेस फ़ाइल $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal
में स्थित होनी चाहिए $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal
।
व्यवहार में, awesome
नामक विक्रेता या ओईएम के लिए यह अनुशंसा की जाती है कि वे अपने मानक इंटरफेस को vendor.awesome
में रखें। पैकेज पथ का चयन करने के बाद, इसे बदला नहीं जाना चाहिए क्योंकि यह इंटरफ़ेस के एबीआई में बेक किया गया है।
पैकेज पथ मानचित्रण अद्वितीय होना चाहिए
उदाहरण के लिए, यदि आपके पास -rsome.package:$PATH_A
और -rsome.package:$PATH_B
, तो एक सुसंगत इंटरफ़ेस निर्देशिका के लिए $PATH_A
$PATH_B
के बराबर होना चाहिए (यह वर्जनिंग इंटरफ़ेस को भी बहुत आसान बनाता है)।
पैकेज रूट में एक वर्जनिंग फ़ाइल होनी चाहिए
यदि आप एक पैकेज पथ बनाते हैं जैसे -r vendor.awesome:vendor/awesome/interfaces
, तो आपको $ANDROID_BUILD_TOP/vendor/awesome/interfaces/current.txt
फ़ाइल भी बनानी चाहिए, जिसमें -Lhash
का उपयोग करके बनाए गए इंटरफ़ेस के हैश शामिल होने चाहिए hidl-gen
में विकल्प (इस पर hidl-gen के साथ हैशिंग में व्यापक रूप से चर्चा की गई है)।
इंटरफ़ेस डिवाइस-स्वतंत्र स्थानों में जाते हैं
व्यवहार में, शाखाओं के बीच इंटरफेस साझा करने की अनुशंसा की जाती है। यह अधिकतम कोड पुन: उपयोग और विभिन्न उपकरणों और उपयोग के मामलों में कोड के अधिकतम परीक्षण की अनुमति देता है।