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

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, सिर्फ़ Nfc-A (ISO/IEC 14443-3 टाइप A) टेक्नोलॉजी के साथ ISO-DEP को एमुलेट करने की ज़रूरी शर्तें तय करता है. एनएफ़सी-बी (ISO/IEC 14443-4 टाइप बी) टेक्नोलॉजी के साथ काम करना ज़रूरी नहीं है. तीसरी इमेज में, इन सभी स्पेसिफ़िकेशन की लेयरिंग दिखाई गई है.

एचसीई सेवाएं

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

सेवा चुनना

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

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

AID ग्रुप

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

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

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

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

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

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

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

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

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

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

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

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

यह देखना कि एचसीई काम करता है या नहीं

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

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

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

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

Kotlin

class MyHostApduService : HostApduService() {

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

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

Java

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 स्पेसिफ़िकेशन में बताया गया है. एपीडीयू, ऐप्लिकेशन-लेवल के पैकेट होते हैं. इन्हें एनएफ़सी रीडर और आपकी एचसीई सेवा के बीच शेयर किया जाता है. ऐप्लिकेशन-लेवल प्रोटोकॉल, हाफ-डुपलेक्स होता है: एनएफ़सी रीडर आपको एक कमांड एपीडीयू भेजता है और जवाब में एपीडीयू भेजने का इंतज़ार करता है.

ध्यान दें: ISO/IEC 7816-4 स्पेसिफ़िकेशन में, एक से ज़्यादा लॉजिकल चैनलों के कॉन्सेप्ट के बारे में भी बताया गया है. इसकी मदद से, अलग-अलग लॉजिकल चैनलों पर एक साथ कई APDU एक्सचेंज किए जा सकते हैं. हालांकि, Android पर एचसीई की सुविधा, सिर्फ़ एक लॉजिकल चैनल के साथ काम करती है. इसलिए, एपीडीयू का सिर्फ़ एक थ्रेड एक्सचेंज होता है.

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

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

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

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

इन दोनों मामलों में, आपकी क्लास के 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 ग्रुप की जानकारी हो.
• android:category एट्रिब्यूट को सेट करें, ताकि यह पता चल सके कि AID ग्रुप किस कैटगरी से जुड़ा है. जैसे, CATEGORY_PAYMENT या CATEGORY_OTHER से तय की गई स्ट्रिंग कॉन्स्टेंट.
• इसमें एक या एक से ज़्यादा <aid-filter> टैग होते हैं. हर टैग में एक AID होता है. AID को हैक्साडेसिमल फ़ॉर्मैट में डालें. साथ ही, पक्का करें कि इसमें वर्णों की संख्या सम हो.

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

AID conflict resolution

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

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

फ़ोरग्राउंड सेवा की प्राथमिकता

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

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>

Wallet ऐप्लिकेशन

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

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

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

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

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

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

निगरानी मोड

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

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

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

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

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

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

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

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

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

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

फ़ोरग्राउंड सेवा की प्राथमिकता

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

• उस सेवा के लिए मेनिफ़ेस्ट में shouldDefaultToObserveMode की स्थिति सेट करना.
• उस सेवा और स्थिति के साथ CardEmulation.setShouldDefaultToObserveModeForService() को शुरू करना.

स्क्रीन बंद होने और लॉक-स्क्रीन के काम करने का तरीका

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

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

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

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

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 (API लेवल 28) और उससे पहले के वर्शन वाले डिवाइसों पर, डिवाइस की स्क्रीन बंद होने पर, एनएफ़सी कंट्रोलर और ऐप्लिकेशन प्रोसेसर पूरी तरह से बंद हो जाते हैं. इसलिए, स्क्रीन बंद होने पर एचसीई सेवाएं काम नहीं करतीं.

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

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

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

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

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

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

ध्यान दें: Android, सुरक्षित एलिमेंट के साथ सीधे तौर पर कम्यूनिकेट करने के लिए एपीआई उपलब्ध नहीं कराता.

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

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

ध्यान दें: ISO/IEC 7816-4 में कुछ हद तक मैच होने की जानकारी भी दी गई है. हालांकि, Android HCE डिवाइसों पर यह सुविधा काम नहीं करती.

चौथे चित्र में इस आर्किटेक्चर के बारे में बताया गया है:

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

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

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

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

सिक्योर एलिमेंट का 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) प्रोटोकॉल, एंटी-कॉलिज़न, और चालू करने की सुविधा

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

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

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

ISO-DEP चालू करना

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

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

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

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

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