एचआईडीएल

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

चेतावनी: Android 10 के बाद से, HIDL अब काम नहीं करता और इसे Android इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एआईडीएल).

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

HIDL इंटरफ़ेस में व्यवस्थित डेटा स्ट्रक्चर और मेथड सिग्नेचर को तय करता है (क्लास की तरह) जिन्हें पैकेज में इकट्ठा किया जाता है. HIDL का सिंटैक्स C++ और Java प्रोग्रामर, लेकिन कीवर्ड. HIDL, Java-स्टाइल एनोटेशन का भी इस्तेमाल करता है.

शब्दावली

इस सेक्शन में, HIDL से जुड़े इन शब्दों का इस्तेमाल किया गया है:

बाइंडराइज़्ड	इससे पता चलता है कि अलग-अलग प्रोसेस के बीच रिमोट प्रोसेस से कॉल करने के लिए, HIDL का इस्तेमाल किया जा रहा है, बाइंडर जैसी तकनीक पर लागू किया गया था. पासथ्रू भी देखें.
कॉलबैक, एसिंक्रोनस	ऐसा इंटरफ़ेस जो एचएएल उपयोगकर्ता ने दिखाया है, एचएएल को पास किया गया है (एचआईडीएल का इस्तेमाल करके), और किसी भी समय डेटा वापस करने के लिए एचएएल को कॉल करना चाहिए.
कॉलबैक, सिंक्रोनस	सर्वर के एचआईडीएल तरीके को लागू करने से, क्लाइंट को डेटा दिखाता है. इसका इस्तेमाल उन तरीकों के लिए नहीं किया जाता जो अमान्य या सिंगल प्रिमिटिव वैल्यू दिखाते हैं.
क्लाइंट	किसी खास इंटरफ़ेस के तरीकों को कॉल करने की प्रक्रिया. HAL या Android फ़्रेमवर्क प्रक्रिया एक इंटरफ़ेस का क्लाइंट और दूसरे का सर्वर हो सकती है. इन्हें भी देखें पासथ्रू.
बढ़ाएं	यह ऐसे इंटरफ़ेस के बारे में बताता है जो दूसरे इंटरफ़ेस में मेथड और/या टाइप जोड़ता है. एक इंटरफ़ेस केवल एक अन्य इंटरफ़ेस का विस्तार कर सकता है. इसका इस्तेमाल किसी नाबालिग के लिए किया जा सकता है उसी पैकेज नाम या किसी नए पैकेज के लिए वर्शन इंक्रीमेंट (उदाहरण के लिए, वेंडर) एक्सटेंशन) भी बनाया जा सकता है.
जनरेट करता है	यह इंटरफ़ेस तरीके के बारे में बताता है, जो क्लाइंट को वैल्यू दिखाता है. वापस जाने के लिए एक नॉन-प्रीमिटिव वैल्यू या एक से ज़्यादा वैल्यू, सिंक्रोनस कॉलबैक फ़ंक्शन जनरेट होता है.
इंटरफ़ेस	तरीकों और टाइप का कलेक्शन. C++ या Java में किसी क्लास में अनुवाद किया गया. सभी किसी इंटरफ़ेस में मेथड को एक ही दिशा में कॉल किया जाता है: क्लाइंट प्रोसेस उन तरीकों को शुरू करता है जो किसी सर्वर प्रोसेस से लागू होते हैं.
एकतरफ़ा	किसी HIDL तरीके पर लागू किए जाने पर, यह बताता है कि यह तरीका कोई वैल्यू नहीं दिखाता है और ब्लॉक नहीं करता.
पैकेज	वर्शन शेयर करने वाले इंटरफ़ेस और डेटा टाइप का कलेक्शन.
पास-थ्रू	एचआईडीएल का मोड, जिसमें सर्वर एक शेयर की गई लाइब्रेरी है, dlopened दिखाता है. पासथ्रू मोड में, क्लाइंट और सर्वर एक ही प्रक्रिया होते हैं, लेकिन अलग-अलग कोड बेस में स्टोर करने की सुविधा देता है. इसका इस्तेमाल सिर्फ़ लेगसी कोडबेस को HIDL मॉडल में लाने के लिए किया जाता है. बाइंडराइज़्ड भी देखें.
सर्वर	किसी इंटरफ़ेस के तरीकों को लागू करने वाली प्रक्रिया. इन्हें भी देखें पासथ्रू.
परिवहन	HIDL इन्फ़्रास्ट्रक्चर, जो डेटा को सर्वर और क्लाइंट के बीच ट्रांसफ़र करता है.
वर्शन	किसी पैकेज का वर्शन. इसमें दो पूर्णांक होते हैं, मेजर और माइनर. नाबालिग की तरफ़ से शिकायत करना वर्शन में होने वाली बढ़ोतरी से टाइप और मेथड जुड़ सकते हैं, लेकिन इनमें कोई बदलाव नहीं होता.

HIDL डिज़ाइन

एचआईडीएल का मकसद है कि Android फ़्रेमवर्क को बिना किसी बदलाव के बदला जा सके एचएएल को फिर से बनाना होगा. एचएएल, वेंडर या एसओसी मैन्युफ़ैक्चरर बनाते हैं. इन्हें डिवाइस पर /vendor पार्टीशन, Android फ़्रेमवर्क को अपने-आप चालू करता है वह सेगमेंट है जो एचएएल को फिर से कंपाइल किए बिना, ओटीए से बदला जाएगा.

HIDL डिज़ाइन में ये समस्याएं मौजूद हैं:

• इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना). अलग-अलग प्लैटफ़ॉर्म के साथ काम करने वाले ऐसे इंटरफ़ेस बनाना जो भरोसेमंद हों जो कई तरह के आर्किटेक्चर, टूलचेन, और प्रोसेस के आधार पर कंपाइल किए जा सकते हैं. कॉन्फ़िगरेशन बनाने के लिए किया जा सकता है. HIDL इंटरफ़ेस वर्शन किए गए हैं और इन्हें बदला नहीं जा सकता उन्हें पब्लिश करने के बाद उन्हें तुरंत दिखाया जा सकता है.
• दक्षता. HIDL, कॉपी की संख्या को कम करने की कोशिश करता है operations. HIDL से तय किया गया डेटा, C++ स्टैंडर्ड लेआउट में C++ कोड में डिलीवर किया जाता है ऐसे डेटा स्ट्रक्चर जो अनपैक किए बिना इस्तेमाल किए जा सकते हैं. HIDL में उपलब्ध कराया गया है. माना जाता है कि RPC पहले से कुछ धीमा होता है. इसलिए, HIDL RPC कॉल का इस्तेमाल किए बिना डेटा ट्रांसफ़र करने के तरीके: शेयर की गई मेमोरी और तेज़ मैसेज की सूची (FMQ).
• समझने में आसान. HIDL RPC के लिए सिर्फ़ in पैरामीटर का इस्तेमाल किया जा रहा है (देखें Android इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एआईडीएल)); वे वैल्यू जो बेहतर तरीके से काम नहीं करतीं तरीकों से दिखाई जाने वाली वैल्यू, कॉलबैक फ़ंक्शन के ज़रिए दिखाई जाती है. न तो पास किया जा रहा है और न ही डेटा पास हो रहा है HIDL में ट्रांसफ़र करने या HIDL से डेटा पाने के लिए, मालिकाना हक डेटा—मालिकाना हक हमेशा, कॉल करने की सुविधा के साथ बना रहता है. डेटा के लिए यह ज़रूरी है सिर्फ़ कॉल किए गए फ़ंक्शन की अवधि तक बने रहते हैं और इसे खत्म किया जा सकता है कॉल किए गए फ़ंक्शन के वापस आने के तुरंत बाद.

पासथ्रू मोड का इस्तेमाल करें

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

पासथ्रू मोड सिर्फ़ C++ क्लाइंट और लागू करने के लिए उपलब्ध है. Android के पुराने वर्शन पर चल रहे डिवाइसों में, Java में HAL नहीं होते हैं. इसलिए, Java एचएएल को आसानी से बाइंड किया जाता है.

पासथ्रू हेडर फ़ाइलें

जब किसी .hal फ़ाइल को कंपाइल किया जाता है, तो hidl-gen हेडर के अलावा, पासथ्रू हेडर फ़ाइल BsFoo.h का अतिरिक्त विकल्प बाइंडर कम्यूनिकेशन के लिए इस्तेमाल किया जाता है; यह हेडर फ़ंक्शन को dlopened. जब पासथ्रू एचएएल उसी प्रोसेस में चलते हैं जिसमें कहा जाता है, तो ज़्यादातर मामलों में पासथ्रू तरीकों का इस्तेमाल सीधे तौर पर फ़ंक्शन कॉल (एक ही थ्रेड). oneway तरीके अपने थ्रेड में चलते हैं ऐसा इसलिए होता है, क्योंकि एचएएल को प्रोसेस करने का इंतज़ार नहीं करना पड़ता. इसका मतलब है कि एचएएल जो पासथ्रू मोड में oneway तरीकों का इस्तेमाल करती है वह थ्रेड-सुरक्षित होना चाहिए).

IFoo.hal दिए जाने पर, BsFoo.h, HIDL से जनरेट किया गया रैप करता है अतिरिक्त सुविधाएँ उपलब्ध कराने के तरीक़े (जैसे, oneway बनाना) लेन-देन किसी दूसरी थ्रेड में चलाए जाते हैं). यह फ़ाइल इससे मिलती-जुलती है BpFoo.h, हालांकि बाइंडर का इस्तेमाल करके आईपीसी कॉल पास करने के बजाय, की ज़रूरत के हिसाब से सही फ़ंक्शन को सीधे तौर पर शुरू कर दिया जाता है. आने वाले समय में एचएएल को कैसे लागू किया जाएगा कई तरीकों से इस्तेमाल किया जा सकता है, जैसे कि FooFast HAL और फ़ूसटीक एचएएल. ऐसे मामलों में, हर अतिरिक्त लागू करने के लिए एक फ़ाइल बनाया जाना चाहिए (उदाहरण के लिए, PTFooFast.cpp और PTFooAccurate.cpp).

बाइंडिंग पासथ्रू एचएएल

पासथ्रू मोड के साथ काम करने वाले एचएएल इंप्लिमेंटेशन को बाइंड किया जा सकता है. यह देखते हुए HAL इंटरफ़ेस a.b.c.d@M.N::IFoo, दो पैकेज बनाए गए हैं:

• a.b.c.d@M.N::IFoo-impl. इसमें एचएएल को लागू करना शामिल है और फ़ंक्शन IFoo* HIDL_FETCH_IFoo(const char* name) दिखाता है. चालू है लेगसी डिवाइसों के लिए, यह पैकेज dlopen का है और इसे लागू किया गया है HIDL_FETCH_IFoo का इस्तेमाल करके इंस्टैंशिएट किया गया. बेस कोड जनरेट किया जा सकता है hidl-gen और -Lc++-impl का इस्तेमाल करके और -Landroidbp-impl.
• a.b.c.d@M.N::IFoo-service. पासथ्रू एचएएल को खोलता है और खुद को बाइंडराइज़्ड सेवा के तौर पर रजिस्टर करता है. इससे उसी एचएएल को लागू किया जाता है का इस्तेमाल पासथ्रू और बाइंडराइज़्ड, दोनों के तौर पर किया जाना चाहिए.

IFoo टाइप दिए जाने पर, किसी इंस्टेंस का ऐक्सेस पाने के लिए, sp<IFoo> IFoo::getService(string name, bool getStub) को कॉल किया जा सकता है IFoo पेज चुने जा सकते हैं. अगर getStub सही है, तो getService HAL को सिर्फ़ पासथ्रू मोड में खोलने की कोशिश करता है. अगर getStub है गलत, getService एक बाइंडराइज़्ड सेवा खोजने की कोशिश करता है; अगर वह विफल होता है, तो यह पासथ्रू सेवा को ढूंढने की कोशिश करता है. getStub पैरामीटर का उपयोग कभी भी नहीं किया जाना चाहिए defaultPassthroughServiceImplementation. (डिवाइस इसके साथ लॉन्च हो रहे हैं: Android O पूरी तरह से बाइंडर्ड डिवाइस हैं. इसलिए, किसी सेवा को पासथ्रू मोड में खोला जा रहा है की अनुमति नहीं है.)

HIDL व्याकरण

एचआईडीएल की भाषा, C की तरह ही होती है. हालांकि, इसमें C का इस्तेमाल नहीं किया जाता प्रीप्रोसेसर). सभी विराम चिह्न, जिनकी जानकारी नीचे नहीं दी गई है (सामान्य इस्तेमाल को छोड़कर) = और |) व्याकरण का हिस्सा है.

ध्यान दें: एचआईडीएल कोड की स्टाइल के बारे में ज़्यादा जानने के लिए, कोड स्टाइल गाइड.

• /** */, दस्तावेज़ पर की गई टिप्पणी को दिखाता है. इन्हें लागू किया जा सकता है का इस्तेमाल सिर्फ़ टाइप, तरीके, फ़ील्ड, और ईनम वैल्यू की जानकारी के लिए किया जा सकता है.
• /* */, मल्टीलाइन टिप्पणी को दिखाता है.
• //, लाइन के आखिर तक की गई टिप्पणी को दिखाता है. इसके अलावा // में नई लाइनें, बाकी खाली सफ़ेद जगह की तरह ही होती हैं.
• नीचे दिए गए व्याकरण के उदाहरण में, // से आखिर तक का टेक्स्ट पंक्ति व्याकरण का हिस्सा नहीं है, बल्कि वह व्याकरण पर एक टिप्पणी है.
• [empty] का मतलब है कि वह शब्द खाली हो सकता है.
• लिटरल या टर्म के बाद ? का मतलब है कि यह ज़रूरी नहीं है.
• ..., शून्य या उससे ज़्यादा आइटम वाले क्रम को दिखाता है दिए गए विराम चिह्न का इस्तेमाल करें. HIDL में कोई वैरायडिक आर्ग्युमेंट नहीं हैं.
• कॉमा, क्रम के एलिमेंट को अलग करते हैं.
• सेमीकोलन आखिरी एलिमेंट के साथ-साथ हर एलिमेंट को खत्म करते हैं.
• अपरकेस एक नॉन-टर्मिनल है.
• italics एक टोकन फ़ैमिली है, जैसे कि integer या identifier (स्टैंडर्ड C पार्स करने के नियम).
• constexpr एक C स्टाइल कॉन्सटेंट एक्सप्रेशन है (जैसे 1 + 1 और 1L << 3).
• import_name, पैकेज या इंटरफ़ेस का नाम है जैसा कि एचआईडीएल में बताया गया है वर्शन.
• लोअरकेस words, लिटरल टोकन होते हैं.

उदाहरण:

ROOT =
    PACKAGE IMPORTS PREAMBLE { ITEM ITEM ... }  // not for types.hal
  | PACKAGE IMPORTS ITEM ITEM...  // only for types.hal; no method definitions

ITEM =
    ANNOTATIONS? oneway? identifier(FIELD, FIELD ...) GENERATES?;
  |  safe_union identifier { UFIELD; UFIELD; ...};
  |  struct identifier { SFIELD; SFIELD; ...};  // Note - no forward declarations
  |  union identifier { UFIELD; UFIELD; ...};
  |  enum identifier: TYPE { ENUM_ENTRY, ENUM_ENTRY ... }; // TYPE = enum or scalar
  |  typedef TYPE identifier;

VERSION = integer.integer;

PACKAGE = package android.hardware.identifier[.identifier[...]]@VERSION;

PREAMBLE = interface identifier EXTENDS

EXTENDS = <empty> | extends import_name  // must be interface, not package

GENERATES = generates (FIELD, FIELD ...)

// allows the Binder interface to be used as a type
// (similar to typedef'ing the final identifier)
IMPORTS =
   [empty]
  |  IMPORTS import import_name;

TYPE =
  uint8_t | int8_t | uint16_t | int16_t | uint32_t | int32_t | uint64_t | int64_t |
 float | double | bool | string
|  identifier  // must be defined as a typedef, struct, union, enum or import
               // including those defined later in the file
|  memory
|  pointer
|  vec<TYPE>
|  bitfield<TYPE>  // TYPE is user-defined enum
|  fmq_sync<TYPE>
|  fmq_unsync<TYPE>
|  TYPE[SIZE]

FIELD =
   TYPE identifier

UFIELD =
   TYPE identifier
  |  safe_union identifier { FIELD; FIELD; ...} identifier;
  |  struct identifier { FIELD; FIELD; ...} identifier;
  |  union identifier { FIELD; FIELD; ...} identifier;

SFIELD =
   TYPE identifier
  |  safe_union identifier { FIELD; FIELD; ...};
  |  struct identifier { FIELD; FIELD; ...};
  |  union identifier { FIELD; FIELD; ...};
  |  safe_union identifier { FIELD; FIELD; ...} identifier;
  |  struct identifier { FIELD; FIELD; ...} identifier;
  |  union identifier { FIELD; FIELD; ...} identifier;

SIZE =  // Must be greater than zero
     constexpr

ANNOTATIONS =
     [empty]
  |  ANNOTATIONS ANNOTATION

ANNOTATION =
  |  @identifier
  |  @identifier(VALUE)
  |  @identifier(ANNO_ENTRY, ANNO_ENTRY  ...)

ANNO_ENTRY =
     identifier=VALUE

VALUE =
     "any text including \" and other escapes"
  |  constexpr
  |  {VALUE, VALUE ...}  // only in annotations

ENUM_ENTRY =
     identifier
  |  identifier = constexpr