एचआईडीएल सी++

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

एंड्रॉइड ओ डिवाइस-स्वतंत्र एंड्रॉइड प्लेटफॉर्म और डिवाइस- और विक्रेता-विशिष्ट कोड के बीच स्पष्ट इंटरफेस को परिभाषित करने के लिए एंड्रॉइड ओएस को फिर से आर्किटेक्ट करता है। एंड्रॉइड पहले से ही ऐसे कई इंटरफेस को एचएएल इंटरफेस के रूप में परिभाषित करता है, जिसे hardware/libhardware में सी हेडर के रूप में परिभाषित किया गया है। एचआईडीएल इन एचएएल इंटरफेस को स्थिर, वर्जन वाले इंटरफेस से बदल देता है, जो सी ++ (नीचे वर्णित) या जावा में क्लाइंट- और सर्वर-साइड एचआईडीएल इंटरफेस हो सकता है।

इस खंड के पृष्ठ एचआईडीएल इंटरफेस के सी ++ कार्यान्वयन का वर्णन करते हैं, जिसमें hidl-gen कंपाइलर द्वारा .hal फाइलों से ऑटो-जेनरेट की गई फाइलों के बारे में विवरण शामिल हैं, इन फाइलों को कैसे पैक किया जाता है, और इन फाइलों को सी ++ कोड के साथ कैसे एकीकृत किया जाए। उनका उपयोग करता है।

क्लाइंट और सर्वर कार्यान्वयन

एचआईडीएल इंटरफेस में क्लाइंट और सर्वर कार्यान्वयन हैं:

  • एक HIDL इंटरफ़ेस का क्लाइंट वह कोड होता है जो उस पर कॉलिंग विधियों द्वारा इंटरफ़ेस का उपयोग करता है।
  • एक सर्वर एक HIDL इंटरफ़ेस का कार्यान्वयन है जो क्लाइंट से कॉल प्राप्त करता है और परिणाम देता है (यदि आवश्यक हो)।

लिबहार्डवेयर एचएएल से libhardware एचएएल में संक्रमण में, एचएएल कार्यान्वयन सर्वर बन जाता है और एचएएल में कॉल करने की प्रक्रिया क्लाइंट बन जाती है। डिफ़ॉल्ट कार्यान्वयन पासथ्रू और बाइंडराइज्ड एचएएल दोनों की सेवा कर सकते हैं, और समय के साथ बदल सकते हैं:

चित्र 1. विरासती एचएएल के लिए विकास प्रगति।

एचएएल क्लाइंट बनाना

मेकफ़ाइल में एचएएल पुस्तकालयों को शामिल करके प्रारंभ करें:

  • बनाएं: LOCAL_SHARED_LIBRARIES += android.hardware.nfc@1.0
  • जल्द ही: shared_libs: [ …, android.hardware.nfc@1.0 ]

इसके बाद, HAL हेडर फाइलें शामिल करें:

#include <android/hardware/nfc/1.0/IFoo.h>
…
// in code:
sp<IFoo> client = IFoo::getService();
client->doThing();

एचएएल सर्वर बनाना

एचएएल कार्यान्वयन बनाने के लिए, आपके पास .hal फाइलें होनी चाहिए जो आपके एचएएल का प्रतिनिधित्व करती हैं और पहले से ही आपके एचएएल के लिए मेकफाइल्स उत्पन्न कर चुकी हैं -Lmakefile या -Landroidbp का उपयोग करके hidl-gen ( ./hardware/interfaces/update-makefiles.sh इसके लिए करता है आंतरिक एचएएल फाइलें और एक अच्छा संदर्भ है)। libhardware से libhardware को स्थानांतरित करते समय, आप c2hal का उपयोग करके इस काम का बहुत कुछ आसानी से कर सकते हैं।

अपने एचएएल को लागू करने के लिए आवश्यक फाइलें बनाने के लिए:

PACKAGE=android.hardware.nfc@1.0
LOC=hardware/interfaces/nfc/1.0/default/
m -j hidl-gen
hidl-gen -o $LOC -Lc++-impl -randroid.hardware:hardware/interfaces \
    -randroid.hidl:system/libhidl/transport $PACKAGE
hidl-gen -o $LOC -Landroidbp-impl -randroid.hardware:hardware/interfaces \
    -randroid.hidl:system/libhidl/transport $PACKAGE

HAL को पासथ्रू मोड में काम करने के लिए, आपके पास HIDL_FETCH_IModuleName फ़ंक्शन होना चाहिए जो /(system|vendor|...)/lib(64)?/hw/android.hardware.package@3.0-impl(OPTIONAL_IDENTIFIER /(system|vendor|...)/lib(64)?/hw/android.hardware.package@3.0-impl( OPTIONAL_IDENTIFIER ).so में रहता हो। जहां OPTIONAL_IDENTIFIER पासथ्रू कार्यान्वयन की पहचान करने वाला एक स्ट्रिंग है। पासथ्रू मोड की आवश्यकताएं उपरोक्त आदेशों द्वारा स्वचालित रूप से पूरी की जाती हैं, जो android.hardware.nfc@1.0-impl लक्ष्य भी बनाती हैं, लेकिन किसी भी एक्सटेंशन का उपयोग किया जा सकता है। उदाहरण के लिए android.hardware.nfc@1.0-impl-foo खुद को अलग करने के लिए -foo का उपयोग करता है।

यदि एक एचएएल एक छोटा संस्करण है या किसी अन्य एचएएल का विस्तार है, तो इस बाइनरी को नाम देने के लिए आधार एचएएल का उपयोग किया जाना चाहिए। उदाहरण के लिए, android.hardware.graphics.mapper@2.1 कार्यान्वयन अभी भी android.hardware.graphics.mapper@2.0-impl( OPTIONAL_IDENTIFIER ) नामक बाइनरी में होना चाहिए। आमतौर पर, यहाँ OPTIONAL_IDENTIFIER में वास्तविक HAL संस्करण शामिल होगा। इस तरह से बाइनरी नामकरण करके, 2.0 क्लाइंट इसे सीधे प्राप्त कर सकते हैं, और 2.1 क्लाइंट कार्यान्वयन को बढ़ा सकते हैं।

इसके बाद, स्टब्स को कार्यक्षमता से भरें और एक डेमॉन सेटअप करें। उदाहरण डेमॉन कोड (पासथ्रू का समर्थन):

#include <hidl/LegacySupport.h>

int main(int /* argc */, char* /* argv */ []) {
    return defaultPassthroughServiceImplementation<INfc>("nfc");
}

defaultPassthroughServiceImplementation प्रदान की -impl लाइब्रेरी को dlopen() करेगा और इसे एक बाइंडराइज्ड सेवा के रूप में प्रदान करेगा। उदाहरण डेमॉन कोड (शुद्ध बाइंडरीकृत सेवा के लिए):

int main(int /* argc */, char* /* argv */ []) {
    // This function must be called before you join to ensure the proper
    // number of threads are created. The threadpool will never exceed
    // size one because of this call.
    ::android::hardware::configureRpcThreadpool(1 /*threads*/, true /*willJoin*/);

    sp<INfc> nfc = new Nfc();
    const status_t status = nfc->registerAsService();
    if (status != ::android::OK) {
        return 1; // or handle error
    }

    // Adds this thread to the threadpool, resulting in one total
    // thread in the threadpool. We could also do other things, but
    // would have to specify 'false' to willJoin in configureRpcThreadpool.
    ::android::hardware::joinRpcThreadpool();
    return 1; // joinRpcThreadpool should never return
}

यह डेमॉन आमतौर पर $PACKAGE + "-service-suffix" (उदाहरण के लिए, android.hardware.nfc@1.0-service ) में रहता है, लेकिन यह कहीं भी हो सकता है। एचएएल के एक विशिष्ट वर्ग के लिए सेपॉलिसी विशेषता hal_<module> (उदाहरण के लिए, hal_nfc) । इस विशेषता को उस डेमॉन पर लागू किया जाना चाहिए जो एक विशेष एचएएल चलाता है (यदि एक ही प्रक्रिया कई एचएएल की सेवा करती है, तो उस पर कई विशेषताएं लागू की जा सकती हैं)।