होस्ट पर आधारित कार्ड एम्युलेशन की खास जानकारी

Android वाले कई डिवाइसों में NFC की सुविधा पहले से ही मौजूद होती है. साथ ही, इनमें NFC कार्ड इम्यूलेशन की सुविधा भी काम करती है. ज़्यादातर मामलों में, डिवाइस में मौजूद एक अलग चिप की मदद से कार्ड को एमुलेट किया जाता है. इसे सुरक्षित एलिमेंट कहा जाता है. मोबाइल और इंटरनेट सेवा देने वाली कंपनियों के ज़रिए उपलब्ध कराए गए कई सिम कार्ड में एक सुरक्षा तत्व भी होता है.

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

सुरक्षित एलिमेंट के साथ कार्ड एम्युलेशन

जब किसी सुरक्षा तत्व का इस्तेमाल करके एनएफ़सी कार्ड एम्युलेशन दिया जाता है, तो एम्युलेट किए जाने वाले कार्ड को Android ऐप्लिकेशन के ज़रिए डिवाइस पर सुरक्षा तत्व में प्रावधान किया जाता है. इसके बाद, जब उपयोगकर्ता डिवाइस को किसी एनएफ़सी टर्मिनल पर रखता है, तो डिवाइस में मौजूद एनएफ़सी कंट्रोलर, रीडर से सारा डेटा सीधे सुरक्षित एलिमेंट पर भेजता है. पहली इमेज में यह कॉन्सेप्ट दिखाया गया है:

पहली इमेज. सुरक्षित एलिमेंट के साथ एनएफ़सी कार्ड इम्यूलेशन.

सुरक्षित एलिमेंट, एनएफ़सी टर्मिनल के साथ खुद ही संपर्क करता है. साथ ही, लेन-देन में कोई Android ऐप्लिकेशन शामिल नहीं होता. लेन-देन पूरा होने के बाद, कोई Android ऐप्लिकेशन सीधे तौर पर सुरक्षित एलिमेंट से लेन-देन की स्थिति के बारे में क्वेरी कर सकता है और उपयोगकर्ता को सूचना दे सकता है.

होस्ट-आधारित कार्ड एम्युलेशन

जब होस्ट-आधारित कार्ड एम्युलेशन का इस्तेमाल करके एनएफ़सी कार्ड को एम्युलेट किया जाता है, तो डेटा को किसी सुरक्षित एलिमेंट पर रूट करने के बजाय, सीधे होस्ट सीपीयू पर रूट किया जाता है. दूसरी इमेज में दिखाया गया है कि होस्ट पर आधारित कार्ड एम्युलेशन कैसे काम करता है:

दूसरी इमेज. सुरक्षित एलिमेंट के बिना एनएफ़सी कार्ड एम्युलेशन.

साथ काम करने वाले एनएफ़सी कार्ड और प्रोटोकॉल

तीसरी इमेज. Android का एचसीई प्रोटोकॉल स्टैक.

एनएफ़सी स्टैंडर्ड, कई अलग-अलग प्रोटोकॉल के साथ काम करते हैं. साथ ही, ऐसे कई तरह के कार्ड हैं जिन्हें एमुलेट किया जा सकता है.

Android 4.4 और इसके बाद के वर्शन, मार्केट में मौजूद कई सामान्य प्रोटोकॉल के साथ काम करते हैं. टच किए बिना पैसे चुकाने के कई मौजूदा कार्ड पहले से ही इन प्रोटोकॉल पर आधारित होते हैं, जैसे कि टच किए बिना पैसे चुकाने के लिए इस्तेमाल होने वाले कार्ड. फ़िलहाल, मार्केट में मौजूद कई एनएफ़सी रीडर भी इन प्रोटोकॉल के साथ काम करते हैं. इनमें, खुद रीडर के तौर पर काम करने वाले Android एनएफ़सी डिवाइस भी शामिल हैं. IsoDep क्लास देखें. इससे, सिर्फ़ Android डिवाइसों का इस्तेमाल करके, एचसीई के लिए एंड-टू-एंड एनएफ़सी समाधान बनाया और डिप्लॉय किया जा सकता है.

खास तौर पर, Android 4.4 और इसके बाद के वर्शन, एनएफ़सी-फ़ोरम ISO-DEP स्पेसिफ़िकेशन (ISO/IEC 14443-4 पर आधारित) पर आधारित कार्ड को एमुलेट करने की सुविधा देते हैं. साथ ही, ISO/IEC 7816-4 स्पेसिफ़िकेशन में बताए गए तरीके से, ऐप्लिकेशन प्रोटोकॉल डेटा यूनिट (एपीडीयू) को प्रोसेस करते हैं. Android के लिए, आईएसओ-डीईपी को सिर्फ़ एनएफ़सी-ए (ISO/IEC 14443-3 टाइप A) टेक्नोलॉजी के साथ एम्युलेट करना ज़रूरी है. एनएफ़सी-बी (ISO/IEC 14443-4 टाइप बी) टेक्नोलॉजी के साथ काम करना ज़रूरी नहीं है. तीसरी इमेज में, इन सभी स्पेसिफ़िकेशन की लेयरिंग दिखाई गई है.

HCE सेवाएं

Android का एचसीई आर्किटेक्चर, Android Service कॉम्पोनेंट (जिन्हें HCE सेवाएं कहा जाता है) पर आधारित है. किसी सेवा का एक मुख्य फ़ायदा यह है कि वह किसी भी यूज़र इंटरफ़ेस के बिना बैकग्राउंड में चल सकती है. यह कई एचसीई ऐप्लिकेशन के लिए सही है. जैसे, लॉयल्टी या ट्रांज़िट कार्ड, जिनका इस्तेमाल करने के लिए उपयोगकर्ता को ऐप्लिकेशन लॉन्च करने की ज़रूरत नहीं होती. इसके बजाय, अगर डिवाइस पहले से नहीं चल रहा है, तो एनएफ़सी रीडर पर टैप करने से सही सेवा शुरू हो जाती है और बैकग्राउंड में लेन-देन हो जाता है. हालांकि, ज़रूरत पड़ने पर अपनी सेवा से अन्य यूज़र इंटरफ़ेस (जैसे, उपयोगकर्ता सूचनाएं) लॉन्च किए जा सकते हैं.

सेवा चुनना

जब कोई व्यक्ति किसी डिवाइस पर एनएफ़सी रीडर पर टैप करता है, तब Android सिस्टम को यह जानने की ज़रूरत होती है कि एनएफ़सी रीडर को किस HCE सेवा से कनेक्ट करना है. ISO/IEC 7816-4 स्पेसिफ़िकेशन में ऐप्लिकेशन चुनने का तरीका बताया गया है. यह ऐप्लिकेशन आईडी (एआईडी) के आस-पास होता है. AID में ज़्यादा से ज़्यादा 16 बाइट होते हैं. अगर किसी मौजूदा एनएफ़सी रीडर इन्फ़्रास्ट्रक्चर के लिए कार्ड की नकल की जा रही है, तो उन लोगों को जो AID चाहिए वे आम तौर पर लोकप्रिय और सार्वजनिक तौर पर रजिस्टर होते हैं. उदाहरण के लिए, Visa और MasterCard जैसे पेमेंट नेटवर्क के AID.

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

AID ग्रुप

कुछ मामलों में, किसी खास ऐप्लिकेशन को लागू करने के लिए, एचसीई सेवा को कई एआईडी रजिस्टर करने पड़ सकते हैं. साथ ही, सभी एआईडी के लिए डिफ़ॉल्ट हैंडलर के तौर पर सेट किया जा सकता है. ग्रुप में शामिल कुछ AID किसी दूसरी सेवा पर जाने की सुविधा काम नहीं करते.

एक साथ रखी जाने वाली AID की सूची को AID ग्रुप कहा जाता है. किसी AID ग्रुप में मौजूद सभी AID के लिए, Android इनमें से किसी एक बात की गारंटी देता है:

• ग्रुप के सभी एआईडी, इस एचसीई सेवा पर भेजे जाते हैं.
• ग्रुप में मौजूद किसी भी एआईडी को इस एचसीई सेवा पर नहीं भेजा जाता. उदाहरण के लिए, ऐसा इसलिए होता है, क्योंकि उपयोगकर्ता ने किसी ऐसी सेवा को प्राथमिकता दी है जिसने आपके ग्रुप में मौजूद एक या उससे ज़्यादा एआईडी का अनुरोध किया है.

दूसरे शब्दों में, ऐसा कोई स्टेटस नहीं है जहां ग्रुप में कुछ एआईडी को एक एचसीई सेवा और कुछ को दूसरी सेवा पर भेजा जा सकता है.

AID ग्रुप और कैटगरी

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

Android 4.4 और इसके बाद के वर्शन पर, दो कैटगरी काम करती हैं:

• CATEGORY_PAYMENT (इसमें इंडस्ट्री स्टैंडर्ड पेमेंट ऐप्लिकेशन शामिल हैं)
• CATEGORY_OTHER (अन्य सभी एचसीई ऐप्लिकेशन के लिए)

एचसीई सेवा लागू करना

होस्ट-आधारित कार्ड इम्यूलेशन का इस्तेमाल करके, एनएफ़सी कार्ड को इम्यूलेट करने के लिए, आपको एक ऐसा Service कॉम्पोनेंट बनाना होगा जो एनएफ़सी लेन-देन को मैनेज करता हो.

यह देखना कि एचसीई (हाई-सिक्योरिटी क्रेडिट कार्ड) काम करता है या नहीं

आपका ऐप्लिकेशन, FEATURE_NFC_HOST_CARD_EMULATION सुविधा की जांच करके यह पता लगा सकता है कि कोई डिवाइस एचसीई के साथ काम करता है या नहीं. अपने ऐप्लिकेशन के मेनिफ़ेस्ट में <uses-feature> टैग का इस्तेमाल करके यह एलान करें कि आपका ऐप्लिकेशन एचसीई सुविधा का इस्तेमाल करता है. साथ ही, यह भी बताएं कि ऐप्लिकेशन के काम करने के लिए, इस सुविधा की ज़रूरत है या नहीं.

सेवा लागू करना

Android 4.4 और उसके बाद के वर्शन में, एक सुविधा Service क्लास दी जाती है. इसका इस्तेमाल, एचसीई सेवा लागू करने के लिए किया जा सकता है: HostApduService क्लास.

सबसे पहले, HostApduService को बड़ा करें, जैसा कि इस कोड सैंपल में दिखाया गया है:

class MyHostApduService : HostApduService() {

    override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
       ...
    }

    override fun onDeactivated(reason: Int) {
       ...
    }
}

public class MyHostApduService extends HostApduService {
    @Override
    public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
       ...
    }
    @Override
    public void onDeactivated(int reason) {
       ...
    }
}

HostApduService दो ऐब्स्ट्रैक्ट मैथड का एलान करता है. आपको इन्हें बदलना होगा और लागू करना होगा. जब भी कोई एनएफ़सी रीडर आपकी सेवा को ऐप्लिकेशन प्रोटोकॉल डेटा यूनिट (एपीडीयू) भेजता है, तो उनमें से एक, processCommandApdu() को कॉल किया जाता है. एपीडीयू के बारे में ISO/IEC 7816-4 स्पेसिफ़िकेशन में बताया गया है. एपीडीयू, ऐप्लिकेशन-लेवल के पैकेट होते हैं. इन्हें एनएफ़सी रीडर और आपकी एचसीई सेवा के बीच शेयर किया जाता है. ऐप्लिकेशन-लेवल प्रोटोकॉल हाफ़-डूप्लेक्स होता है: एनएफ़सी रीडर आपको एक निर्देश APDU भेजता है और यह इंतज़ार करता है कि आप इसके बदले में APDU जवाब भेजें.

जैसा कि हमने पहले बताया था, Android, AID का इस्तेमाल करके यह तय करता है कि रीडर को किस एचसीई सेवा से कनेक्ट करना है. आम तौर पर, एनएफ़सी रीडर आपके डिवाइस पर पहला एपीडीयू भेजता है, जो SELECT AID एपीडीयू होता है. इस एपीडीयू में वह एआईडी होता है जिससे रीडर को बात करनी होती है. Android, APDU से उस AID को निकालता है और उसे एचसीई सेवा में बदलता है. इसके बाद, उस APDU को बदली गई सेवा पर भेजता है.

processCommandApdu() से रिस्पॉन्स के तौर पर मिले APDU के बाइट दिखाकर, APDU जवाब भेजा जा सकता है. ध्यान दें कि इस तरीके को आपके ऐप्लिकेशन की मुख्य थ्रेड पर कॉल किया जाता है. इसे ब्लॉक नहीं किया जाना चाहिए. अगर तुरंत APDU रिस्पॉन्स का हिसाब नहीं लगाया जा सकता, तो इसकी वैल्यू को शून्य कर दें. इसके बाद, किसी दूसरी थ्रेड पर ज़रूरी काम किया जा सकता है. साथ ही, काम पूरा होने पर जवाब भेजने के लिए, HostApduService क्लास में बताए गए sendResponseApdu() तरीके का इस्तेमाल किया जा सकता है.

Android, रीडर से आपकी सेवा को नए APDU तब तक फ़ॉरवर्ड करता रहता है, जब तक इनमें से कोई एक काम नहीं हो जाता:

• एनएफ़सी रीडर, एक और SELECT AID एपीडीयू भेजता है, जिसे ओएस किसी दूसरी सेवा में बदल देता है.
• एनएफ़सी रीडर और आपके डिवाइस के बीच एनएफ़सी लिंक काम नहीं कर रहा है.

इन दोनों मामलों में, आपकी क्लास के onDeactivated() लागू करने के तरीके को तर्क के साथ कॉल किया जाता है, जो बताता है कि इन दोनों में से क्या हुआ था.

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

अगर आपने नया रीडर इन्फ़्रास्ट्रक्चर डिप्लॉय किया है और उसे कंट्रोल भी किया जा रहा है, तो आपके पास अपना प्रोटोकॉल और APDU क्रम तय करने का विकल्प है. एक्सचेंज किए जाने वाले डेटा के साइज़ और एपीडीयू की संख्या को सीमित करने की कोशिश करें: इससे यह पक्का होता है कि आपके उपयोगकर्ताओं को अपने डिवाइस को एनएफ़सी रीडर पर सिर्फ़ कुछ समय के लिए रखना पड़े. एक तय सीमा के हिसाब से, डेटा का साइज़ 1 केबी होना चाहिए. आम तौर पर, इसे 300 मिलीसेकंड में एक्सचेंज किया जा सकता है.

सेवा मेनिफ़ेस्ट का एलान और एआईडी रजिस्ट्रेशन

आपको मेनिफ़ेस्ट में अपनी सेवा के बारे में हमेशा की तरह जानकारी देनी होगी. हालांकि, आपको सेवा के एलान में कुछ और जानकारी भी जोड़नी होगी:

1. प्लैटफ़ॉर्म को यह बताने के लिए कि यह HostApduService इंटरफ़ेस लागू करने वाली एचसीई सेवा है, अपनी सेवा के एलान में SERVICE_INTERFACE ऐक्शन के लिए इंटेंट फ़िल्टर जोड़ें.

2. प्लैटफ़ॉर्म को यह बताने के लिए कि इस सेवा के लिए किन एआईडी ग्रुप का अनुरोध किया गया है, सेवा के एलान में एक SERVICE_META_DATA <meta-data> टैग शामिल करें. यह टैग, एचसीई सेवा के बारे में ज़्यादा जानकारी वाले एक्सएमएल रिसॉर्स पर ले जाता है.

3. android:exported एट्रिब्यूट को true पर सेट करें. साथ ही, सेवा के एलान में android.permission.BIND_NFC_SERVICE अनुमति की ज़रूरत है. पहले विकल्प से यह पक्का होता है कि सेवा को बाहरी ऐप्लिकेशन से बंधा जा सकता है. इसके बाद, यह पक्का किया जाता है कि सिर्फ़ ऐसे बाहरी ऐप्लिकेशन आपकी सेवा से कनेक्ट हो सकते हैं जिनके पास android.permission.BIND_NFC_SERVICE अनुमति हो. android.permission.BIND_NFC_SERVICE एक सिस्टम अनुमति है. इसलिए, इससे यह पक्का होता है कि सिर्फ़ Android OS आपकी सेवा से कनेक्ट हो सकता है.

यहां HostApduService मेनिफ़ेस्ट का एक उदाहरण दिया गया है:

<service android:name=".MyHostApduService" android:exported="true"
         android:permission="android.permission.BIND_NFC_SERVICE">
    <intent-filter>
        <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
    </intent-filter>
    <meta-data android:name="android.nfc.cardemulation.host_apdu_service"
               android:resource="@xml/apduservice"/>
</service>

यह मेटा-डेटा टैग, apduservice.xml फ़ाइल पर ले जाता है. यहां एक ऐसी फ़ाइल का उदाहरण दिया गया है जिसमें एक एआईडी ग्रुप का एलान किया गया है. इसमें दो मालिकाना एआईडी शामिल हैं:

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
           android:description="@string/servicedesc"
           android:requireDeviceUnlock="false">
    <aid-group android:description="@string/aiddescription"
               android:category="other">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</host-apdu-service>

<host-apdu-service> टैग में ऐसा <android:description> एट्रिब्यूट होना चाहिए जिसमें सेवा की जानकारी दी गई हो. इस एट्रिब्यूट को ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में दिखाया जा सके. requireDeviceUnlock एट्रिब्यूट का इस्तेमाल करके, यह बताया जा सकता है कि एपीडीयू को हैंडल करने के लिए इस सेवा को शुरू करने से पहले, डिवाइस अनलॉक है.

<host-apdu-service> में एक या एक से ज़्यादा <aid-group> टैग होने चाहिए. हर <aid-group> टैग को ये काम करने होंगे:

• इसमें ऐसा android:description एट्रिब्यूट शामिल होना चाहिए जिसमें AID ग्रुप के बारे में उपयोगकर्ताओं को आसानी से जानकारी दी गई हो. यह जानकारी यूज़र इंटरफ़ेस (यूआई) में दिखाने के लिए सही होती है.
• AID ग्रुप किस कैटगरी से जुड़ा है, यह बताने के लिए उसका android:category एट्रिब्यूट सेट करें. जैसे, CATEGORY_PAYMENT या CATEGORY_OTHER से तय की गई स्ट्रिंग कॉन्स्टेंट.
• इसमें एक या एक से ज़्यादा <aid-filter> टैग होते हैं. हर टैग में एक AID होता है. AID को हेक्साडेसिमल फ़ॉर्मैट में तय करें और पक्का करें कि उसमें समान संख्या में वर्ण हों.

आपके ऐप्लिकेशन के पास एचसीई सेवा के तौर पर रजिस्टर करने के लिए, NFC की अनुमति भी होनी चाहिए.

AID के लिए विवाद का समाधान

एक ही डिवाइस पर कई HostApduService कॉम्पोनेंट इंस्टॉल किए जा सकते हैं. साथ ही, एक ही एआईडी को एक से ज़्यादा सेवाओं से रजिस्टर किया जा सकता है. Android, इन चरणों का इस्तेमाल करके यह तय करता है कि किस सेवा को चालू करना है:

1. अगर उपयोगकर्ता ने जो डिफ़ॉल्ट वॉलेट ऐप्लिकेशन चुना है उसमें AID रजिस्टर किया गया है, तो उस ऐप्लिकेशन को चालू किया जाता है.
2. अगर डिफ़ॉल्ट वॉलेट ऐप्लिकेशन ने AID को रजिस्टर नहीं किया है, तो उस सेवा को चालू किया जाता है जिसने AID को रजिस्टर किया है.
3. अगर एक से ज़्यादा सेवाओं ने AID रजिस्टर किया है, तो Android उपयोगकर्ता से पूछता है कि किस सेवा को शुरू करना है.

यह देखना कि आपका ऐप्लिकेशन, डिफ़ॉल्ट वॉलेट ऐप्लिकेशन है या नहीं

ऐप्लिकेशन यह देख सकते हैं कि वे डिफ़ॉल्ट वॉलेट ऐप्लिकेशन हैं या नहीं. इसके लिए, उन्हें RoleManager.ROLE_WALLET को RoleManager.isRoleHeld() पर भेजना होगा.

अगर आपका ऐप्लिकेशन डिफ़ॉल्ट नहीं है, तो डिफ़ॉल्ट वॉलेट ऐप्लिकेशन के तौर पर इस्तेमाल करने का अनुरोध किया जा सकता है. इसके लिए, RoleManager.ROLE_WALLET को RoleManager.createRequestRoleIntent() पर पास करें.

Wallet ऐप्लिकेशन

Android, एचसीई सेवाओं को वॉलेट ऐप्लिकेशन के तौर पर तब ही मानता है, जब उन्होंने पेमेंट कैटगरी के साथ एआईडी ग्रुप का एलान किया हो. Android 15 और उसके बाद के वर्शन में, डिफ़ॉल्ट वॉलेट ऐप्लिकेशन की भूमिका शामिल होती है. उपयोगकर्ता, सेटिंग > ऐप्लिकेशन > डिफ़ॉल्ट ऐप्लिकेशन पर जाकर, इस भूमिका को चुन सकता है. इससे यह तय होता है कि पेमेंट टर्मिनल पर टैप करने पर, डिफ़ॉल्ट रूप से कौनसा Wallet ऐप्लिकेशन चालू होगा.

वॉलेट ऐप्लिकेशन के लिए ज़रूरी एसेट

उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, एचसीई वॉलेट ऐप्लिकेशन को सेवा का बैनर दिखाना ज़रूरी है.

Android 13 और उसके बाद के वर्शन

सेटिंग यूज़र इंटरफ़ेस (यूआई) में, पेमेंट के विकल्पों की डिफ़ॉल्ट सूची को बेहतर तरीके से फ़िट करने के लिए, बैनर की ज़रूरी शर्त को स्क्वेयर आइकॉन में बदलें. आम तौर पर, यह ऐप्लिकेशन लॉन्चर आइकॉन के डिज़ाइन से मेल खाना चाहिए. इस अडजस्टमेंट से, इमेज में एक जैसा रंग दिखता है और वह ज़्यादा साफ़ दिखती है.

Android 12 और उससे पहले वाले वर्शन के लिए

सेवा बैनर का साइज़ 260x96 dp पर सेट करें. इसके बाद, अपनी मेटाडेटा एक्सएमएल फ़ाइल में सेवा बैनर का साइज़ सेट करें. इसके लिए, <host-apdu-service> टैग में android:apduServiceBanner एट्रिब्यूट जोड़ें. यह टैग, ड्रॉ किए जा सकने वाले संसाधन पर ले जाता है. इसका एक उदाहरण है:

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
        android:description="@string/servicedesc"
        android:requireDeviceUnlock="false"
        android:apduServiceBanner="@drawable/my_banner">
    <aid-group android:description="@string/aiddescription"
               android:category="payment">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</host-apdu-service>

निगरानी मोड

Android 15 में निगरानी मोड की सुविधा जोड़ी गई है. चालू होने पर, निगरानी मोड की मदद से डिवाइस, एनएफ़सी पोलिंग लूप को निगरानी कर सकता है. साथ ही, इन लूप के बारे में सूचनाएं, सही HostApduService कॉम्पोनेंट को भेज सकता है, ताकि वे किसी एनएफ़सी टर्मिनल के साथ इंटरैक्ट करने के लिए तैयार हो सकें. HostApduService, setObserveModeEnabled() को true भेजकर, डिवाइस को ऑब्ज़र्व मोड में डाल सकता है. इससे एनएफ़सी स्टैक को एनएफ़सी लेन-देन की अनुमति नहीं मिलती. इसके बजाय, वह पोलिंग लूप को निष्क्रिय तौर पर देखता है.

पोलिंग लूप फ़िल्टर

HostApduService के लिए पोलिंग लूप फ़िल्टर को रजिस्टर करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करें:

• registerPollingLoopFilterForService() उन फ़िल्टर के लिए जो पोलिंग फ़्रेम से पूरी तरह मैच करने चाहिए.
• registerPollingLoopPatternFilterForService() उन फ़िल्टर के लिए जो पोलिंग फ़्रेम से रेगुलर एक्सप्रेशन से मैच करते हैं.

जब कोई पोलिंग लूप फ़िल्टर, नॉन-स्टैंडर्ड पोलिंग फ़्रेम से मैच होता है, तो एनएफ़सी स्टैक, उन पोलिंग फ़्रेम को उससे जुड़े HostApduService पर रूट कर देता है. इसके लिए, एनएफ़सी स्टैक, अपने processPollingFrames() तरीके का इस्तेमाल करता है. इससे सेवा को यह पक्का करने के लिए ज़रूरी कदम उठाने में मदद मिलती है कि उपयोगकर्ता लेन-देन के लिए तैयार है और वह ऐसा करना चाहता है. उदाहरण के लिए, उपयोगकर्ता की पुष्टि करना. अगर कोई एनएफ़सी रीडर अपने पोलिंग लूप में सिर्फ़ स्टैंडर्ड फ़्रेम का इस्तेमाल कर रहा है, तो एनएफ़सी स्टैक उन पोलिंग फ़्रेम को पसंदीदा फ़ोरग्राउंड सेवा पर भेज देता है. ऐसा तब होता है, जब वह सेवा फ़ोरग्राउंड में हो या डिफ़ॉल्ट वॉलेट रोल होल्डर.

पोलिंग फ़्रेम की सूचनाओं में, फ़ील्ड की क्षमता का वेंडर-स्पेसिफ़िक मेज़रमेंट भी शामिल होता है. इसे getVendorSpecificGain() को कॉल करके वापस पाया जा सकता है. वेंडर अपने स्केल का इस्तेमाल करके, मेज़रमेंट दे सकते हैं, बशर्ते वह एक बाइट में फ़िट हो जाए.

पोलिंग लूप का जवाब दें और ऑब्ज़र्व मोड से बाहर निकलें

जब सेवा लेन-देन के लिए तैयार हो जाती है, तो वह false को setObserveModeEnabled() पर भेजकर, निगरानी मोड से बाहर निकल सकती है. इसके बाद, एनएफ़सी स्टैक, लेन-देन की प्रोसेस को जारी रखने की अनुमति देगा.

HostApduService कॉम्पोनेंट यह बता सकते हैं कि जब भी वे पैसे चुकाने की पसंदीदा सेवा हों, तब ऑब्ज़र्व मोड चालू किया जाना चाहिए. इसके लिए, मेनिफ़ेस्ट में shouldDefaultToObserveMode को true पर सेट करें या CardEmulation.setShouldDefaultToObserveModeForService() को कॉल करें.

HostApduService और OffHostApduService कॉम्पोनेंट से यह भी पता चल सकता है कि मिले हुए पोलिंग लूप फ़्रेम से मैच करने वाले पोलिंग लूप फ़िल्टर, ऑब्ज़र्व मोड को अपने-आप बंद कर दें. साथ ही, मेनिफ़ेस्ट में PollingLoopFilter एलान में autoTransact को true पर सेट करके, लेन-देन को जारी रखने की अनुमति दें.

स्क्रीन बंद होने और लॉक स्क्रीन पर कार्रवाई

डिवाइस पर चल रहे Android वर्शन के हिसाब से, एचसीई सेवाओं का व्यवहार अलग-अलग होता है.

Android 12 और उसके बाद के वर्शन के लिए

Android 12 (एपीआई लेवल 31) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन में, डिवाइस की स्क्रीन चालू किए बिना एनएफ़सी से पेमेंट करने की सुविधा चालू की जा सकती है. इसके लिए, requireDeviceScreenOn को false पर सेट करें.

Android 10 और उसके बाद के वर्शन

Android 10 (एपीआई लेवल 29) या उसके बाद के वर्शन वाले डिवाइसों पर, सुरक्षित एनएफ़सी की सुविधा काम करती है. सुरक्षित एनएफ़सी की सुविधा चालू होने पर, डिवाइस की स्क्रीन बंद होने पर सभी कार्ड एमुलेटर (होस्ट ऐप्लिकेशन और ऑफ़-होस्ट ऐप्लिकेशन) उपलब्ध नहीं होते. सुरक्षित एनएफ़सी की सुविधा बंद होने पर, डिवाइस की स्क्रीन बंद होने पर ऑफ़-होस्ट ऐप्लिकेशन उपलब्ध होते हैं. isSecureNfcSupported() का इस्तेमाल करके, यह देखा जा सकता है कि डिवाइस पर सुरक्षित एनएफ़सी की सुविधा काम करती है या नहीं.

Android 10 और इसके बाद के वर्शन वाले डिवाइसों पर, android:requireDeviceUnlock को true पर सेट करने की सुविधा, Android 9 और उससे पहले के वर्शन वाले डिवाइसों पर सेट करने की सुविधा जैसी ही होती है. हालांकि, यह सुविधा सिर्फ़ तब काम करती है, जब सुरक्षित एनएफ़सी की सुविधा बंद हो. इसका मतलब है कि अगर सुरक्षित एनएफ़सी की सुविधा चालू है, तो android:requireDeviceUnlock की सेटिंग के बावजूद, लॉक-स्क्रीन से एचसीई सेवाएं काम नहीं कर सकतीं.

Android 9 और उससे पहले वाले वर्शन के लिए

Android 9 (एपीआई लेवल 28) और इससे पहले के वर्शन वाले डिवाइसों पर, डिवाइस की स्क्रीन बंद होने पर एनएफ़सी कंट्रोलर और ऐप्लिकेशन प्रोसेसर पूरी तरह से बंद हो जाते हैं. इसलिए, स्क्रीन बंद होने पर HCE सेवाएं काम नहीं करती हैं.

Android 9 और उससे पहले के वर्शन पर भी, एचसीई सेवाएं लॉक स्क्रीन से काम कर सकती हैं. हालांकि, इसे आपकी एचसीई सेवा के <host-apdu-service> टैग में मौजूद android:requireDeviceUnlock एट्रिब्यूट से कंट्रोल किया जाता है. डिफ़ॉल्ट रूप से, डिवाइस अनलॉक करने की ज़रूरत नहीं होती. साथ ही, डिवाइस लॉक होने पर भी आपकी सेवा चालू हो जाती है.

अगर आपने अपनी एचसीई सेवा के लिए android:requireDeviceUnlock एट्रिब्यूट को true पर सेट किया है, तो Android उपयोगकर्ता को डिवाइस अनलॉक करने के लिए तब कहता है, जब ये स्थितियां होती हैं:

• उपयोगकर्ता, एनएफ़सी रीडर पर टैप करता है.
• एनएफ़सी रीडर, आपकी सेवा के लिए हल किया गया कोई एआईडी चुनता है.

अनलॉक करने के बाद, Android एक डायलॉग दिखाता है. इसमें उपयोगकर्ता को लेन-देन पूरा करने के लिए, फिर से टैप करने के लिए कहा जाता है. ऐसा इसलिए ज़रूरी है, क्योंकि हो सकता है कि उपयोगकर्ता ने डिवाइस को अनलॉक करने के लिए, उसे एनएफ़सी रीडर से दूर कर दिया हो.

सुरक्षा एलिमेंट वाले कार्ड के साथ काम करना

यह सेक्शन उन डेवलपर के लिए है जिन्होंने कार्ड इम्यूलेशन के लिए, सुरक्षित एलिमेंट पर निर्भर ऐप्लिकेशन डिप्लॉय किया है. Android के HCE सेवा को इस तरह से डिज़ाइन किया गया है कि यह कार्ड एम्युलेशन लागू करने के दूसरे तरीकों के साथ-साथ काम करे. इनमें सुरक्षित एलिमेंट का इस्तेमाल भी शामिल है.

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

जब एनएफ़सी रीडर, SELECT AID के साथ APDU भेजता है, तो एनएफ़सी कंट्रोलर उसे पार्स करता है और देखता है कि AIDs, इसकी रूटिंग टेबल में दिए गए किसी AID से मेल खाते हैं या नहीं. अगर यह मैच होता है, तो उस APDU और उसके बाद के सभी APDU को AID से जुड़े डेस्टिनेशन पर भेजा जाता है. ऐसा तब तक किया जाता है, जब तक कोई दूसरा SELECT AID APDU नहीं मिल जाता या एनएफ़सी लिंक टूट नहीं जाता.

इमेज 4 में यह आर्किटेक्चर दिखाया गया है:

चौथी इमेज. सुरक्षा एलिमेंट और होस्ट-कार्ड एम्युलेशन, दोनों के साथ काम करने वाला Android.

आम तौर पर, एनएफ़सी कंट्रोलर में APDUs के लिए डिफ़ॉल्ट रूट भी होता है. जब रूटिंग टेबल में कोई एआईडी नहीं मिलता है, तो डिफ़ॉल्ट रूट का इस्तेमाल किया जाता है. यह सेटिंग, हर डिवाइस के लिए अलग-अलग हो सकती है. हालांकि, Android डिवाइसों के लिए यह ज़रूरी है कि आपके ऐप्लिकेशन से रजिस्टर किए जा रहे AID, होस्ट पर सही तरीके से भेजे जाएं.

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

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

सिक्योर एलिमेंट का AID रजिस्ट्रेशन

कार्ड एम्युलेशन के लिए सुरक्षा एलिमेंट का इस्तेमाल करने वाले ऐप्लिकेशन के मेनिफ़ेस्ट में, ऑफ़-होस्ट सेवा का एलान किया जा सकता है. इस तरह की सेवा का एलान, एचसीई सेवा के एलान से काफ़ी मिलता-जुलता है. इसके अपवाद ये हैं:

• इंटेंट फ़िल्टर में इस्तेमाल की गई कार्रवाई को SERVICE_INTERFACE पर सेट करना ज़रूरी है.
• मेटा-डेटा नाम एट्रिब्यूट, SERVICE_META_DATA पर सेट होना चाहिए.

• मेटा-डेटा एक्सएमएल फ़ाइल में <offhost-apdu-service> रूट टैग का इस्तेमाल करना ज़रूरी है.

  <service android:name=".MyOffHostApduService" android:exported="true"
         android:permission="android.permission.BIND_NFC_SERVICE">
    <intent-filter>
        <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/>
    </intent-filter>
    <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service"
               android:resource="@xml/apduservice"/>
  </service>

यहां दो AID रजिस्टर करने वाली apduservice.xml फ़ाइल का उदाहरण दिया गया है:

<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
           android:description="@string/servicedesc">
    <aid-group android:description="@string/subscription" android:category="other">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</offhost-apdu-service>

android:requireDeviceUnlock एट्रिब्यूट, ऑफ़-होस्ट सेवाओं पर लागू नहीं होता, क्योंकि लेन-देन में होस्ट सीपीयू शामिल नहीं होता. इसलिए, डिवाइस के लॉक होने पर, सुरक्षित एलिमेंट को लेन-देन करने से नहीं रोका जा सकता.

android:apduServiceBanner एट्रिब्यूट की वैल्यू देना, ऑफ़-होस्ट सेवाओं के लिए ज़रूरी है. ये सेवाएं, पैसे चुकाने के ऐप्लिकेशन होती हैं और इन्हें डिफ़ॉल्ट पैसे चुकाने के ऐप्लिकेशन के तौर पर चुना जा सकता है.

होस्ट के बाहर से सेवा को कॉल करना

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

एचसीई और सुरक्षा

एचसीई आर्किटेक्चर, सुरक्षा का एक मुख्य हिस्सा उपलब्ध कराता है: आपकी सेवा को BIND_NFC_SERVICE सिस्टम की अनुमति से सुरक्षित किया जाता है. इसलिए, सिर्फ़ ओएस आपकी सेवा से कनेक्ट और उससे कम्यूनिकेट कर सकता है. इससे यह पक्का होता है कि आपको जो भी APDU मिलता है वह असल में एक ऐसा APDU होता है जो एनएफ़सी कंट्रोलर से ओएस को मिला है. साथ ही, यह भी पक्का होता है कि आपका भेजा गया APDU सिर्फ़ ओएस को जाता है, जो सीधे तौर पर APDU को एनएफ़सी कंट्रोलर को भेजता है.

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

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

प्रोटोकॉल पैरामीटर और जानकारी

यह सेक्शन उन डेवलपर के लिए है जिन्हें यह समझना है कि एनएफ़सी प्रोटोकॉल के एंटी-कॉलिज़न और चालू करने के चरणों के दौरान, एचसीई डिवाइस कौनसे प्रोटोकॉल पैरामीटर इस्तेमाल करते हैं. इससे ऐसा रीडर इन्फ़्रास्ट्रक्चर बनाया जा सकता है जो Android HCE डिवाइसों के साथ काम करता हो.

Nfc-A (ISO/IEC 14443 टाइप A) प्रोटोकॉल, एंटी-कॉलिज़न, और चालू करने की सुविधा

एनएफ़सी-ए प्रोटोकॉल चालू करने के दौरान, कई फ़्रेम एक-दूसरे से बदले जाते हैं.

एक्सचेंज के पहले हिस्से में, HCE डिवाइस अपना यूआईडी दिखाता है. एचसीई डिवाइस को यूआईडी रैंडम तरीके से माना जाना चाहिए. इसका मतलब है कि हर टैप पर, पाठक को एक यूनीक यूआईडी दिखाया जाता है. इस वजह से, एनएफ़सी रीडर को पुष्टि करने या पहचान करने के लिए, एचसीई डिवाइसों के यूआईडी पर निर्भर नहीं होना चाहिए.

इसके बाद, एनएफ़सी रीडर, SEL_REQ कमांड भेजकर एचसीई डिवाइस को चुन सकता है. एचसीई डिवाइस के SEL_RES रिस्पॉन्स में कम से कम छठा बिट (0x20) सेट होता है. इससे पता चलता है कि डिवाइस पर ISO-DEP काम करता है. ध्यान दें कि SEL_RES में अन्य बिट भी सेट हो सकते हैं. उदाहरण के लिए, इससे पता चलता है कि डिवाइस पर NFC-DEP (p2p) प्रोटोकॉल काम करता है. अन्य बिट सेट किए जा सकते हैं. इसलिए, HCE डिवाइसों के साथ इंटरैक्ट करने वाले रीडर को सिर्फ़ छठे बिट की जांच करनी चाहिए. साथ ही, SEL_RES की पूरी वैल्यू की तुलना 0x20 से नहीं करनी चाहिए.

ISO-DEP चालू करना

Nfc-A प्रोटोकॉल चालू होने के बाद, एनएफ़सी रीडर ISO-DEP प्रोटोकॉल चालू करने की प्रोसेस शुरू करता है. यह RATS (Request for Answer To Select) कमांड भेजता है. एनएफ़सी कंट्रोलर, RATS रिस्पॉन्स, एटीएस जनरेट करता है. एटीएस को एचसीई सेवाओं से कॉन्फ़िगर नहीं किया जा सकता. हालांकि, एचसीई लागू करने के लिए, एटीएस रिस्पॉन्स के लिए एनएफ़सी फ़ोरम की ज़रूरी शर्तों को पूरा करना ज़रूरी है. इससे एनएफ़सी रीडर को यह भरोसा रहता है कि ये पैरामीटर, किसी भी एचसीई डिवाइस के लिए एनएफ़सी फ़ोरम की ज़रूरी शर्तों के मुताबिक सेट किए गए हैं.

यहां दिए गए सेक्शन में, एचसीई डिवाइस पर एनएफ़सी कंट्रोलर से मिले एटीएस रिस्पॉन्स के अलग-अलग बाइट के बारे में ज़्यादा जानकारी दी गई है:

• TL: एटीएस के जवाब की लंबाई. इसकी लंबाई 20 बाइट से ज़्यादा नहीं होनी चाहिए.
• T0: सभी HCE डिवाइसों पर बिट 5, 6, और 7 सेट होने चाहिए. इससे पता चलता है कि TA(1), TB(1), और TC(1) ATS रिस्पॉन्स में शामिल हैं. पहले से चौथे बिट तक, ज़्यादा से ज़्यादा फ़्रेम साइज़ को कोड करने वाले एफ़एससीआई के बारे में जानकारी मिलती है. एचसीई डिवाइसों पर, एफ़एससीआई की वैल्यू 0 घंटे से 8 घंटे के बीच होनी चाहिए.
• T(A)1: इससे रीडर और एमुलेटर के बीच बिटरेट तय होता है. साथ ही, यह भी तय होता है कि बिटरेट असिमेट्रिक हो सकते हैं या नहीं. HCE डिवाइसों के लिए, बिटरेट की कोई शर्त या गारंटी नहीं है.
• T(B)1: बिट 1 से 4, स्टार्ट-अप फ़्रेम गार्ड टाइम इंटिजर (SFGI) दिखाते हैं. एचसीई डिवाइसों पर, एसएफ़जीआई 8 घंटे से कम होना चाहिए. पांचवें से आठवें बिट में, फ़्रेम के इंतज़ार का समय इंटीजर (FWI) होता है. साथ ही, फ़्रेम के इंतज़ार का समय (FWT) कोड किया जाता है. एचसीई डिवाइसों पर, एफ़डब्ल्यूआई का समय 8 घंटे से कम होना चाहिए.
• T(C)1: बिट 5 से पता चलता है कि "बेहतर प्रोटोकॉल की सुविधाएं" काम करती हैं. एचसीई डिवाइसों पर, "बेहतर प्रोटोकॉल की सुविधाएं" काम कर सकती हैं या नहीं. बिट 2 से पता चलता है कि डीआईडी के साथ काम करने की सुविधा उपलब्ध है या नहीं. एचसीई डिवाइस, डीआईडी के साथ काम कर भी सकते हैं और नहीं भी. बिट 1 से पता चलता है कि डिवाइस में एनएडी की सुविधा है या नहीं. एचसीई डिवाइसों में एनएडी की सुविधा नहीं होनी चाहिए. साथ ही, बिट 1 को शून्य पर सेट करना चाहिए.
• पुराने बाइट: एचसीई डिवाइस, पुराने 15 बाइट तक दिखा सकते हैं. एचसीई सेवाओं के साथ इंटरैक्ट करने वाले एनएफ़सी रीडर को, पुराने बाइट के कॉन्टेंट या उनकी मौजूदगी के बारे में कोई अनुमान नहीं लगाना चाहिए.

ध्यान दें कि कई एचसीई डिवाइसों को प्रोटोकॉल की उन ज़रूरी शर्तों के मुताबिक बनाया गया है जिन्हें EMVCo में शामिल पेमेंट नेटवर्क ने अपने "टच किए बिना पैसे चुकाने के प्रोटोकॉल" में बताया है. खास तौर पर:

• T0 में FSCI, 2 घंटे से 8 घंटे के बीच होना चाहिए.
• T(A)1 को 0x80 पर सेट किया जाना चाहिए. इससे पता चलता है कि सिर्फ़ 106 kbit/s बिटरेट काम करता है. साथ ही, रीडर और एमुलेटर के बीच असिमेट्रिक बिटरेट काम नहीं करते.
• T(B)1 में FWI, 7 घंटे से कम होना चाहिए.

एपीडीयू डेटा एक्सचेंज

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