হোস্ট-ভিত্তিক কার্ড ইমুলেশন এক নজরে

NFC কার্যকারিতা অফার করে এমন অনেক Android-চালিত ডিভাইস ইতিমধ্যেই NFC কার্ড এমুলেশন সমর্থন করে। অধিকাংশ ক্ষেত্রে, ডিভাইসে থাকা একটি আলাদা চিপের মাধ্যমে কার্ডটি এমুলেট করা হয়, যাকে নিরাপদ উপাদান বলা হয়। ওয়্যারলেস পরিষেবা প্রদানকারীর দেওয়া অনেক সিম কার্ডেও নিরাপদ উপাদান থাকে।

Android 4.4 এবং তার পরবর্তী ভার্সনে কার্ড এমুলেশনের একটি অতিরিক্ত পদ্ধতি প্রদান করা হয়, যেটিতে কোনও নিরাপদ উপাদান থাকে না, একে হোস্ট-ভিত্তিক কার্ড এমুলেশন বলা হয়। এটি যেকোনও Android অ্যাপ্লিকেশনকে একটি কার্ড অনুকরণ করতে এবং NFC রিডারের সাথে সরাসরি কথা বলতে অনুমতি দেয়। এই বিষয়ে হোস্ট-ভিত্তিক কার্ড এমুলেশন (HCE) কীভাবে Android-এ কাজ করে এবং আপনি কীভাবে এই টেকনিক ব্যবহার করে NFC কার্ড এমুলেট করে এমন অ্যাপ তৈরি করতে পারবেন তা বর্ণনা করা হয়েছে।

নিরাপদ উপাদানের মাধ্যমে কার্ড ইমুলেশন

নিরাপদ উপাদান ব্যবহার করে NFC কার্ড ইমুলেশন প্রদান করা হলে, ইমুলেট করা কার্ডটি Android অ্যাপ্লিকেশনের মাধ্যমে ডিভাইসের নিরাপদ উপাদানে প্রোভিশন করা হয়। তারপর, ব্যবহারকারী যখন NFC টার্মিনালের উপর ডিভাইসটি ধরেন, তখন ডিভাইসের NFC কন্ট্রোলার রিডার থেকে সমস্ত ডেটা সরাসরি নিরাপদ উপাদানে পাঠায়। ছবি ১-এ এই ধারণাটি ব্যাখ্যা করা হয়েছে:

ছবি ১. নিরাপদ উপাদান সহ NFC কার্ড ইমুলেশন।

নিরাপদ উপাদান নিজেই NFC টার্মিনালের সাথে যোগাযোগ করে এবং ট্রানজ্যাকশনে কোনও Android অ্যাপ্লিকেশন জড়িত থাকে না। ট্রানজ্যাকশন সম্পূর্ণ হওয়ার পরে, কোনও Android অ্যাপ্লিকেশন ট্রানজ্যাকশনের স্ট্যাটাস জানার জন্য সরাসরি নিরাপদ উপাদানকে কোয়েরি করতে এবং ব্যবহারকারীকে বিজ্ঞপ্তি পাঠাতে পারে।

হোস্ট-বেসড কার্ড ইমুলেশন

হোস্ট-ভিত্তিক কার্ড ইমুলেশন ব্যবহার করে কোনও NFC কার্ড ইমুলেট করা হলে, ডেটা সরাসরি হোস্ট CPU-তে রাউট করা হয়, নিরাপদ উপাদানে রাউট করা হয় না। ছবি ২ হোস্ট-ভিত্তিক কার্ড এমুলেশন কীভাবে কাজ করে তা ব্যাখ্যা করে:

ছবি ২. নিরাপদ উপাদান ছাড়াই NFC কার্ড ইমুলেশন।

কাজ করে এমন NFC কার্ড ও প্রোটোকল

ছবি ৩. Android-এর HCE প্রোটোকল স্ট্যাক।

NFC স্ট্যান্ডার্ডে বিভিন্ন প্রোটোকলের জন্য সহায়তা প্রদান করা হয় এবং আপনি বিভিন্ন ধরনের কার্ড এমুলেট করতে পারবেন।

Android 4.4 এবং তার পরবর্তী ভার্সনগুলি বর্তমানে বাজারে প্রচলিত বেশ কয়েকটি প্রোটোকলকে সমর্থন করে। আগে থেকে থাকা অনেক কন্ট্যাক্টলেস কার্ড এইসব প্রোটোকলের উপর ভিত্তি করে তৈরি করা হয়, যেমন কন্ট্যাক্টলেস পেমেন্ট কার্ড। এই প্রোটোকলগুলি বর্তমানে বাজারে থাকা অনেক NFC রিডার দ্বারাও সমর্থিত, যার মধ্যে রয়েছে Android NFC ডিভাইস যা রিডার হিসেবে কাজ করে (IsoDep ক্লাস দেখুন)। এটি আপনাকে শুধুমাত্র Android-চালিত ডিভাইস ব্যবহার করে HCE-এর আশেপাশে একটি এন্ড-টু-এন্ড NFC সমাধান তৈরি এবং স্থাপন করতে দেয়।

বিশেষ করে, Android 4.4 এবং তার পরবর্তী ভার্সন NFC-Forum ISO-DEP স্পেসিফিকেশন (ISO/IEC 14443-4-এর উপর ভিত্তি করে) এবং ISO/IEC 7816-4 স্পেসিফিকেশনে যেভাবে উল্লেখ করা আছে সেই অনুযায়ী প্রসেস অ্যাপ্লিকেশন প্রোটোকল ডেটা ইউনিট (APDU)-এর উপর ভিত্তি করে কার্ড এমুলেট করাকে সমর্থন করে। Android-এর ক্ষেত্রে Nfc-A (ISO/IEC 14443-3 Type A) প্রযুক্তির উপরেই ISO-DEP এমুলেট করা বাধ্যতামূলক। Nfc-B (ISO/IEC 14443-4 Type B) টেকনোলজির জন্য সহায়তা ঐচ্ছিক। ৩ নম্বর ছবিতে এই সব স্পেসিফিকেশনের লেয়ারিং দেখানো হয়েছে।

HCE পরিষেবা

Android-এ HCE আর্কিটেকচার Android Service কম্পোনেন্টের (HCE পরিষেবা হিসেবে পরিচিত) উপর ভিত্তি করে তৈরি। পরিষেবার একটি মূল সুবিধা হল যে এটি কোনও ইউজার ইন্টারফেস ছাড়াই ব্যাকগ্রাউন্ডে রান করতে পারে। এটি অনেক HCE অ্যাপ্লিকেশনের জন্য স্বাভাবিকভাবেই উপযুক্ত, যেমন লয়ালটি বা ট্রানজিট কার্ড, যা ব্যবহার করার জন্য ব্যবহারকারীকে কোনও অ্যাপ চালু করতে হবে না। পরিবর্তে, NFC রিডারের কাছে ডিভাইস ট্যাপ করলে, সঠিক পরিষেবা আগে থেকে চালু না থাকলে, সেটি চালু হয়ে যায় এবং ব্যাকগ্রাউন্ডে ট্রানজ্যাকশন সম্পূর্ণ হয়। অবশ্যই, আপনি উপযুক্ত সময়ে আপনার পরিষেবা থেকে অতিরিক্ত UI (যেমন ব্যবহারকারীর বিজ্ঞপ্তি) লঞ্চ করতে পারেন।

পরিষেবা বেছে নেওয়া

ব্যবহারকারী যখন কোনও ডিভাইসে NFC রিডার ট্যাপ করেন, তখন Android সিস্টেমকে জানতে হয় NFC রিডার কোন HCE পরিষেবার সাথে যোগাযোগ করতে চায়। ISO/IEC 7816-4 স্পেসিফিকেশন, অ্যাপ্লিকেশন আইডি (AID)-এর উপর ভিত্তি করে অ্যাপ্লিকেশন বেছে নেওয়ার একটি উপায় নির্ধারণ করে। AID-তে সর্বাধিক ১৬ বাইট থাকে। আপনি যদি আগে থেকে থাকা NFC রিডার ইনফ্রাস্ট্রাকচারের জন্য কার্ড এমুলেট করেন, তাহলে সেইসব রিডার সাধারণত সুপরিচিত এবং সর্বজনীনভাবে রেজিস্টার করা AID খোঁজে (যেমন, Visa এবং MasterCard-এর মতো পেমেন্ট নেটওয়ার্কের AID)।

আপনার নিজের অ্যাপ্লিকেশনের জন্য নতুন রিডার ইনফ্রাস্ট্রাকচার ডিপ্লয় করতে চাইলে, আপনাকে অবশ্যই নিজের AID রেজিস্টার করতে হবে। AID-এর রেজিস্ট্রেশন পদ্ধতি ISO/IEC 7816-5 স্পেসিফিকেশনে সংজ্ঞায়িত করা আছে। আপনি Android-এর জন্য HCE অ্যাপ্লিকেশন ডিপ্লয় করলে, আমরা 7816-5 অনুযায়ী AID রেজিস্টার করার সাজেশন দিই, কারণ এটি অন্যান্য অ্যাপ্লিকেশনের সাথে সংঘর্ষ এড়ায়।

AID গ্রুপ

কিছু ক্ষেত্রে, কোনও নির্দিষ্ট অ্যাপ্লিকেশন প্রয়োগ করার জন্য, HCE পরিষেবাকে একাধিক AID রেজিস্টার করতে হতে পারে এবং সব AID-এর জন্য ডিফল্ট হ্যান্ডলার হিসেবে সেট করতে হতে পারে। গ্রুপের কিছু AID অন্য পরিষেবায় কাজ করে না।

একসাথে রাখা AID-এর তালিকাকে AID গ্রুপ বলা হয়। একটি AID গ্রুপের সব AID-এর জন্য, Android নিম্নলিখিতগুলির মধ্যে একটির গ্যারান্টি দেয়:

• গ্রুপের সব AID এই HCE পরিষেবায় রাউট করা হয়।
• গ্রুপের কোনও AID এই HCE পরিষেবায় রাউট করা হয়নি (যেমন, ব্যবহারকারী অন্য কোনও পরিষেবা পছন্দ করেছেন যা আপনার গ্রুপের এক বা একাধিক AID-এর জন্যও অনুরোধ করেছে)।

অন্যভাবে বলতে গেলে, কোনও মধ্যবর্তী অবস্থা নেই, যেখানে গ্রুপের কিছু AID একটি HCE পরিষেবাতে এবং কিছু অন্যটিতে রুট করা যেতে পারে।

AID গ্রুপ ও বিভাগ

আপনি প্রতিটি AID গ্রুপকে একটি বিভাগের সাথে যুক্ত করতে পারেন। এটি Android-কে বিভাগ অনুযায়ী HCE পরিষেবা একসাথে গ্রুপ করার অনুমতি দেয় এবং এর ফলে ব্যবহারকারী AID লেভেলের পরিবর্তে বিভাগ লেভেলে ডিফল্ট সেট করতে পারেন। আপনার অ্যাপ্লিকেশনের ব্যবহারকারী নিজে ইন্টার‌্যাক্ট করতে পারেন এমন কোনও অংশে AID উল্লেখ করা এড়িয়ে চলুন, কারণ সাধারণ ব্যবহারকারীর কাছে এর কোনও অর্থ নেই।

Android 4.4 এবং তার পরবর্তী যেকোনও ভার্সনে দুটি বিভাগ কাজ করে:

• CATEGORY_PAYMENT (ইন্ডাস্ট্রি-স্ট্যান্ডার্ড পেমেন্ট অ্যাপ কভার করে)
• CATEGORY_OTHER (অন্যান্য সব HCE অ্যাপের জন্য)

মনে রাখবেন: যেকোনও সময় সিস্টেমে CATEGORY_PAYMENT বিভাগের মধ্যে শুধুমাত্র একটি AID গ্রুপ চালু করা যেতে পারে। সাধারণত, এটি এমন একটি অ্যাপ যা প্রধান ক্রেডিট কার্ড পেমেন্ট প্রোটোকল বোঝে এবং যা যেকোনও মার্চেন্টের ক্ষেত্রে কাজ করতে পারে।

ক্লোজড-লুপ পেমেন্ট অ্যাপের জন্য যা শুধুমাত্র একজন মার্চেন্টের ক্ষেত্রে কাজ করে (যেমন স্টোরড-ভ্যালু কার্ড), CATEGORY_OTHER ব্যবহার করুন। এই বিভাগের AID গ্রুপ সবসময় অ্যাক্টিভ থাকতে পারে এবং প্রয়োজন হলে AID বেছে নেওয়ার সময় NFC রিডার অগ্রাধিকার দিতে পারে।

CATEGORY_PAYMENT-এর অধীনে AID রেজিস্টার করা অ্যাপ শুধুমাত্র তখনই ট্রানজ্যাকশন প্রসেস করতে পারে যদি:

• ব্যবহারকারী অ্যাপটিকে ডিফল্ট পেমেন্ট অ্যাপ হিসেবে সেট করেন (Android 15+ ডিভাইসে Wallet রোল হোল্ডার), অথবা
• অ্যাপটি ফোরগ্রাউন্ডে আছে এবং setPreferredService চালু করে।

HCE পরিষেবা প্রয়োগ করা

হোস্ট-ভিত্তিক কার্ড এমুলেশন ব্যবহার করে NFC কার্ড এমুলেট করতে, আপনাকে একটি Service কম্পোনেন্ট তৈরি করতে হবে যা NFC ট্রানজ্যাকশন ম্যানেজ করে।

HCE সাপোর্ট চেক করুন

আপনার অ্যাপ্লিকেশন, FEATURE_NFC_HOST_CARD_EMULATION ফিচার চেক করে, কোনও ডিভাইসে HCE কাজ করে কিনা তা চেক করতে পারে। আপনার অ্যাপ HCE ফিচার ব্যবহার করে কিনা এবং অ্যাপের কাজ করার জন্য এটি প্রয়োজন কিনা তা ঘোষণা করতে, আপনার অ্যাপ্লিকেশনের ম্যানিফেস্টে <uses-feature> ট্যাগ ব্যবহার করুন।

পরিষেবা প্রয়োগ করা

Android 4.4 এবং তার পরবর্তী ভার্সনে একটি সুবিধাজনক Service ক্লাস প্রদান করা হয় যা আপনি HCE পরিষেবা প্রয়োগ করার ভিত্তি হিসেবে ব্যবহার করতে পারবেন: HostApduService ক্লাস।

প্রথম ধাপ হল HostApduService এক্সটেন্ড করা, যেমনটি নিম্নলিখিত কোড স্যাম্পেলে দেখানো হয়েছে:

Kotlin

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(), NFC রিডার আপনার পরিষেবায় অ্যাপ্লিকেশন প্রোটোকল ডেটা ইউনিট (APDU) পাঠালেই কল করা হয়। ISO/IEC 7816-4 স্পেসিফিকেশনে APDU সংজ্ঞায়িত করা আছে। APDU হল অ্যাপ্লিকেশন-লেভেল প্যাকেট যা NFC রিডার ও আপনার HCE পরিষেবার মধ্যে আদান-প্রদান করা হয়। অ্যাপ্লিকেশন-লেভেল প্রোটোকল হল অর্দ্ধেক-ডুপ্লেক্স: NFC রিডার আপনাকে একটি কমান্ড APDU পাঠায় এবং এর উত্তরে আপনি APDU না পাঠানো পর্যন্ত অপেক্ষা করে।

মনে রাখবেন: ISO/IEC 7816-4 স্পেসিফিকেশন একাধিক লজিক্যাল চ্যানেলের ধারণাকেও সংজ্ঞায়িত করে, যা আপনাকে আলাদা লজিক্যাল চ্যানেলে একাধিক সমান্তরাল APDU এক্সচেঞ্জ করতে দেয়। তবে, Android-এর HCE ইমপ্লিমেন্টেশন, শুধুমাত্র একটি লজিক্যাল চ্যানেল সাপোর্ট করে, তাই APDU-এর সিঙ্গেল-থ্রেডেড এক্সচেঞ্জ হয়।

আগে যেমন উল্লেখ করা হয়েছে, রিডার কোন HCE পরিষেবার সাথে যোগাযোগ করতে চায় তা নির্ধারণ করতে Android, AID ব্যবহার করে। সাধারণত, আপনার ডিভাইসে NFC রিডার যে প্রথম APDU পাঠায় সেটি হল SELECT AID APDU; এই APDU-তে AID থাকে যার সাথে রিডার যোগাযোগ করতে চায়। Android, APDU থেকে AID এক্সট্র্যাক্ট করে, এটি HCE পরিষেবায় রিজলভ করে এবং তারপর রিজলভ করা পরিষেবায় APDU ফরওয়ার্ড করে।

আপনি processCommandApdu() থেকে রেসপন্স APDU-এর বাইট ফিরিয়ে দিয়ে রেসপন্স APDU পাঠাতে পারবেন। মনে রাখবেন যে এই পদ্ধতিটি আপনার অ্যাপ্লিকেশনের মূল থ্রেডে কল করা হয়, যা আপনার ব্লক করা উচিত নয়। আপনি যদি অবিলম্বে একটি প্রতিক্রিয়া APDU গণনা করতে এবং ফেরত দিতে না পারেন, তাহলে শূন্য ফেরত দিন। আপনি অন্য থ্রেডে প্রয়োজনীয় কাজ করতে পারেন এবং কাজ হয়ে গেলে উত্তর পাঠানোর জন্য HostApduService ক্লাসে উল্লেখ করা sendResponseApdu() পদ্ধতি ব্যবহার করতে পারেন।

Android, রিডার থেকে আপনার পরিষেবায় নতুন APDU ফরওয়ার্ড করতে থাকে, যতক্ষণ না নিম্নলিখিতগুলির মধ্যে কোনও একটি ঘটে:

• NFC রিডার আরেকটি SELECT AID APDU পাঠায়, যা OS অন্য একটি পরিষেবায় রিজলভ করে।
• NFC রিডার ও আপনার ডিভাইসের মধ্যে NFC লিঙ্ক কাজ করছে না।

এই দুটি ক্ষেত্রেই, আপনার ক্লাসের onDeactivated() ইমপ্লিমেন্টেশনকে একটি আর্গুমেন্ট সহ কল করা হয় যা নির্দেশ করে যে দুটির মধ্যে কোনটি ঘটেছে।

আপনি যদি আগে থেকে থাকা রিডার ইনফ্রাস্ট্রাকচারের সাথে কাজ করেন, তাহলে আপনাকে অবশ্যই আগে থেকে থাকা অ্যাপ্লিকেশন-লেভেল প্রোটোকল প্রয়োগ করতে হবে যা রিডাররা আপনার HCE পরিষেবাতে আশা করে।

আপনি যদি নতুন রিডার ইনফ্রাস্ট্রাকচার ডিপ্লয় করেন যা আপনি নিয়ন্ত্রণও করেন, তাহলে আপনি নিজের প্রোটোকল ও APDU সিকোয়েন্স নির্ধারণ করতে পারবেন। APDUs-এর পরিমাণ এবং এক্সচেঞ্জ করার জন্য ডেটার সাইজ সীমিত করার চেষ্টা করুন: এটি নিশ্চিত করে যে আপনার ব্যবহারকারীদের শুধুমাত্র অল্প সময়ের জন্য NFC রিডারের উপর তাদের ডিভাইস ধরে রাখতে হবে। ডেটার সর্বোচ্চ সীমা হল ১ কেবি, যা সাধারণত ৩০০ মিলিসেকেন্ডের মধ্যে এক্সচেঞ্জ করা যায়।

পরিষেবা ম্যানিফেস্ট ঘোষণা এবং AID রেজিস্ট্রেশন

আপনাকে ম্যানিফেস্টে আপনার পরিষেবা ঘোষণা করতে হবে, তবে আপনাকে পরিষেবা ঘোষণায় কিছু অতিরিক্ত অংশও যোগ করতে হবে:

1. এটি যে HostApduService ইন্টারফেস প্রয়োগকারী HCE পরিষেবা তা প্ল্যাটফর্মকে জানাতে, আপনার পরিষেবা ঘোষণায় SERVICE_INTERFACE অ্যাকশনের জন্য ইনটেন্ট ফিল্টার যোগ করুন।

2. এই পরিষেবার মাধ্যমে কোন কোন AID গ্রুপ অনুরোধ করা হয়েছে তা প্ল্যাটফর্মকে জানাতে, পরিষেবার ঘোষণায় একটি SERVICE_META_DATA <meta-data> ট্যাগ যোগ করুন, যা HCE পরিষেবা সম্পর্কে অতিরিক্ত তথ্য সহ একটি XML রিসোর্সকে নির্দেশ করে।

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 ফাইলকে নির্দেশ করে। নিচে এই ধরনের ফাইলের উদাহরণ দেওয়া হল, যেখানে একটি AID গ্রুপ ডিক্লারেশনে দুটি মালিকানাধীন AID আছে:

<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> অ্যাট্রিবিউট থাকতে হবে যা পরিষেবার একটি ব্যবহারকারী-বান্ধব বিবরণ ধারণ করে যা আপনি অ্যাপ UI-তে দেখাতে পারেন। APDUs ম্যানেজ করার জন্য এই পরিষেবা চালু করার আগে ডিভাইস আনলক করা আছে কিনা তা নির্দিষ্ট করতে আপনি requireDeviceUnlock অ্যাট্রিবিউট ব্যবহার করতে পারেন।

<host-apdu-service>-এ এক বা একাধিক <aid-group> ট্যাগ থাকতে হবে। প্রতিটি <aid-group> ট্যাগের জন্য নিম্নলিখিত কাজগুলি করতে হবে:

• এতে একটি android:description অ্যাট্রিবিউট থাকে যাতে AID গ্রুপের ব্যবহার করা সহজ বিবরণ থাকে, যা UI-তে দেখানোর জন্য উপযুক্ত।
• AID গ্রুপটি কোন বিভাগের অন্তর্গত তা নির্দেশ করার জন্য এর android:category অ্যাট্রিবিউট সেট করা আছে, যেমন CATEGORY_PAYMENT বা CATEGORY_OTHER দ্বারা সংজ্ঞায়িত স্ট্রিং কনস্ট্যান্ট।
• এক বা একাধিক <aid-filter> ট্যাগ থাকে, যার প্রতিটিতে একটি করে AID থাকে। হেক্সাডেসিমাল ফর্ম্যাটে AID উল্লেখ করুন এবং এতে জোড় সংখ্যায় অক্ষর আছে কিনা তা ভাল করে দেখে নিন।

এছাড়াও, HCE পরিষেবা হিসেবে রেজিস্টার করার জন্য আপনার অ্যাপ্লিকেশনের কাছে NFC অনুমতি থাকতে হবে।

AID সংক্রান্ত বিরোধের সমাধান

একটি ডিভাইসে একাধিক HostApduService কম্পোনেন্ট ইনস্টল করা থাকতে পারে এবং একই AID একাধিক পরিষেবার মাধ্যমে রেজিস্টার করা হতে পারে। Android নিম্নলিখিত ধাপগুলি ব্যবহার করে কোন পরিষেবাটি চালু করতে হবে তা নির্ধারণ করে:

1. ব্যবহারকারীর বেছে নেওয়া ডিফল্ট ওয়ালেট অ্যাপ যদি AID রেজিস্টার করে থাকে, তাহলে সেই অ্যাপ চালু করা হয়।
2. ডিফল্ট Wallet অ্যাপ AID রেজিস্টার না করলে, যে পরিষেবা AID রেজিস্টার করেছে সেটি ইনভোক করা হয়।
3. একাধিক পরিষেবা AID রেজিস্টার করলে, Android ব্যবহারকারীকে জিজ্ঞাসা করে কোন পরিষেবা চালু করতে হবে।

ফোরগ্রাউন্ড সার্ভিস সংক্রান্ত পছন্দ

ফোরগ্রাউন্ডে থাকা অ্যাপ setPreferredService চালু করতে পারে যাতে নির্দিষ্ট অ্যাক্টিভিটি ফোরগ্রাউন্ডে থাকার সময় কোন কার্ড ইমুলেশন পরিষেবা পছন্দ করা উচিত তা নির্দিষ্ট করা যায়। এই ফোরগ্রাউন্ড অ্যাপ সংক্রান্ত পছন্দ AID দ্বন্দ্ব সমাধানকে ওভাররাইড করে। অ্যাপ যখন অনুমান করে যে ব্যবহারকারী NFC কার্ড ইমুলেশন ব্যবহার করতে পারেন, তখন এই পদ্ধতি অনুসরণ করার সাজেশন দেওয়া হয়।

Android 13 ও তার পরের যেকোনও ভার্সন

সেটিংস UI-তে ডিফল্ট পেমেন্ট বেছে নেওয়ার তালিকা আরও ভালোভাবে ফিট করতে, ব্যানারের প্রয়োজনীয়তা একটি বর্গাকার আইকনে অ্যাডজাস্ট করুন। সাধারণত, এটি অ্যাপ্লিকেশন লঞ্চার আইকন ডিজাইনের মতোই হতে হবে। এই অ্যাডজাস্টমেন্ট আরও ধারাবাহিকতা এবং একটি ক্লিনার লুক তৈরি করে।

Android 12 ও এর আগের যেকোনও ভার্সন

পরিষেবা ব্যানারের সাইজ ২৬০x৯৬ ডিপি হিসেবে সেট করুন, তারপর আপনার মেটাডেটা XML ফাইলে পরিষেবা ব্যানারের সাইজ সেট করুন। এর জন্য <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 সেইসব HCE পরিষেবাকে ওয়ালেট অ্যাপ্লিকেশন হিসেবে বিবেচনা করে যেগুলি পেমেন্ট ক্যাটেগরি সহ AID গ্রুপ ঘোষণা করেছে।

আপনার অ্যাপটি ডিফল্ট ওয়ালেট অ্যাপ কিনা তা চেক করুন

অ্যাপগুলি ডিফল্ট ওয়ালেট অ্যাপ কিনা তা চেক করতে পারে RoleManager.ROLE_WALLET থেকে RoleManager.isRoleHeld()-এ পাস করে।

আপনার অ্যাপ ডিফল্ট না হলে, আপনি RoleManager.ROLE_WALLET-কে RoleManager.createRequestRoleIntent()-এ পাস করে ডিফল্ট ওয়ালেট রোলের জন্য অনুরোধ করতে পারেন।

Wallet অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় অ্যাসেট

ব্যবহারকারীকে আরও আকর্ষণীয় অভিজ্ঞতা প্রদান করতে, HCE ওয়ালেট অ্যাপ্লিকেশনকে পরিষেবা ব্যানার প্রদান করতে হবে।

অবজার্ভ মোড

Android 15-এ অবজার্ভ মোড ফিচার নিয়ে আসা হয়েছে। চালু করা থাকলে, 'অবজার্ভ মোড' ডিভাইসকে NFC পোলিং লুপ পর্যবেক্ষণ করার এবং সেই সম্পর্কে উপযুক্ত HostApduService কম্পোনেন্টে বিজ্ঞপ্তি পাঠানোর অনুমতি দেয় যাতে তারা প্রদত্ত NFC টার্মিনালের সাথে ইন্টার‍্যাক্ট করার জন্য প্রস্তুত হতে পারে। HostApduService, true-কে setObserveModeEnabled()-এ পাস করে ডিভাইসকে অবজার্ভ মোডে রাখতে পারে। এটি NFC স্ট্যাককে NFC ট্রানজ্যাকশনের অনুমতি না দিতে এবং পরিবর্তে প্যাসিভভাবে পোলিং লুপ পর্যবেক্ষণ করতে নির্দেশ দেয়।

পোলিং লুপ ফিল্টার

আপনি নিম্নলিখিত পদ্ধতিগুলির মধ্যে যেকোনও একটি ব্যবহার করে HostApduService-এর জন্য পোলিং লুপ ফিল্টার রেজিস্টার করতে পারেন:

• registerPollingLoopFilterForService() ফিল্টারের জন্য যা অবশ্যই পোলিং ফ্রেমের সাথে হুবহু মিলতে হবে।
• registerPollingLoopPatternFilterForService() পোলিং ফ্রেমের সাথে রেগুলার এক্সপ্রেশন ম্যাচ করে এমন ফিল্টারের জন্য।

পোলিং লুপ ফিল্টার নন-স্ট্যান্ডার্ড পোলিং ফ্রেমের সাথে ম্যাচ করলে, NFC স্ট্যাক সেগুলি সংশ্লিষ্ট HostApduService-এ তার processPollingFrames() মেথড কল করার মাধ্যমে পাঠায়। এর ফলে, ব্যবহারকারী ট্রানজ্যাকশন করার জন্য প্রস্তুত এবং ট্রানজ্যাকশন করতে চান কিনা তা নিশ্চিত করার জন্য পরিষেবাটি প্রয়োজনীয় পদক্ষেপ নিতে পারে—যেমন, ব্যবহারকারীকে যাচাই করা। NFC রিডার যদি তার পোলিং লুপে শুধুমাত্র স্ট্যান্ডার্ড ফ্রেম ব্যবহার করে, তাহলে NFC স্ট্যাক সেই পোলিং ফ্রেমগুলিকে পছন্দের ফোরগ্রাউন্ড সার্ভিসে রুট করে, যদি সেই সার্ভিসটি ফোরগ্রাউন্ডে থাকে বা অন্যথায় ডিফল্ট ওয়ালেট রোল হোল্ডারে থাকে।

পোলিং ফ্রেম বিজ্ঞপ্তিতে ফিল্ডের শক্তির ভেন্ডর-নির্দিষ্ট পরিমাপও অন্তর্ভুক্ত থাকে যা আপনি getVendorSpecificGain() কল করে পেতে পারেন। বিক্রেতারা তাদের নিজস্ব স্কেল ব্যবহার করে পরিমাপ প্রদান করতে পারেন, যতক্ষণ না এটি একটি বাইটের মধ্যে ফিট করে।

পোলিং লুপে উত্তর দিন এবং অবজার্ভ মোড থেকে বেরিয়ে আসুন

পরিষেবাটি ট্রানজ্যাকশনের জন্য প্রস্তুত হলে, এটি false থেকে setObserveModeEnabled()-এ পাস করে অবজার্ভ মোড থেকে বেরিয়ে আসতে পারে। NFC স্ট্যাক তখন ট্রানজ্যাকশন চালিয়ে যাওয়ার অনুমতি দেবে।

HostApduService কম্পোনেন্ট ইঙ্গিত করতে পারে যে যখনই তারা ম্যানিফেস্টে shouldDefaultToObserveMode-কে true-এ সেট করে বা CardEmulation.setShouldDefaultToObserveModeForService()-কে কল করে পছন্দের পেমেন্ট পরিষেবা হবে, তখনই অবজার্ভ মোড চালু করা উচিত।

HostApduService এবং OffHostApduService কম্পোনেন্টও এটি ইঙ্গিত করতে পারে যে পোলিং লুপ ফিল্টার যা প্রাপ্ত পোলিং লুপ ফ্রেমের সাথে মেলে, সেটি অটোমেটিক 'অবজার্ভ মোড' বন্ধ করে দেবে এবং ম্যানিফেস্টে PollingLoopFilter ডিক্লারেশনে autoTransact থেকে true সেট করে ট্রানজ্যাকশন চালিয়ে যাওয়ার অনুমতি দেবে।

ফোরগ্রাউন্ড সার্ভিস সংক্রান্ত পছন্দ

ফোরগ্রাউন্ডে থাকা অ্যাপ setPreferredService ইনভোক করতে পারে যাতে নির্দিষ্ট অ্যাক্টিভিটি ফোরগ্রাউন্ডে থাকার সময় কোন কার্ড ইমুলেশন পরিষেবা ব্যবহার করা উচিত তা নির্দিষ্ট করা যায়। এই ফোরগ্রাউন্ড অ্যাপ সংক্রান্ত পছন্দ, প্রদত্ত পরিষেবার জন্য shouldDefaultToObserveMode-এর ভ্যালুর সাথে সম্পর্কিত ডিভাইসের অবজার্ভ মোড স্টেটকে ওভাররাইড করে, যা নিম্নলিখিত উপায়ের মধ্যে যেকোনও একটির মাধ্যমে সেট করা যেতে পারে:

• সেই পরিষেবার জন্য ম্যানিফেস্টে shouldDefaultToObserveMode-এর স্ট্যাটাস সেট করা।
• সংশ্লিষ্ট পরিষেবা ও স্ট্যাটাস সহ CardEmulation.setShouldDefaultToObserveModeForService() ইনভোক করা হচ্ছে।

স্ক্রিন বন্ধ ও লক-স্ক্রিন সংক্রান্ত আচরণ

ডিভাইসে Android-এর যে ভার্সন চলছে তার উপর ভিত্তি করে HCE পরিষেবার আচরণ আলাদা আলাদা হয়।

Android 15 ও তার পরের যেকোনও ভার্সনে

ডিফল্ট ওয়ালেট অ্যাপ যদি এমন কোনও ডিভাইসে 'অবজার্ভ মোড' চালু করে যা এটি সাপোর্ট করে, তাহলে সেই অ্যাপ আনলক ও স্ক্রিন-অফ আচরণ ওভাররাইড করে, কারণ এটি ট্রানজ্যাকশন কখন করা যাবে তা নিয়ন্ত্রণ করে। অবজার্ভ মোড যদি কোনও শনাক্তযোগ্য পোলিং লুপ প্যাটার্ন শনাক্ত না করে, তাহলে কিছু ওয়ালেট অ্যাপে ট্রানজ্যাকশন করার আগে ডিভাইস আনলক করতে হতে পারে।

ডেভেলপারদের তাদের রিডার ডিভাইসের সাথে কাজ করতে উৎসাহিত করা হয় যাতে শনাক্তযোগ্য পোলিং লুপ প্যাটার্ন নির্গত হয় এবং তাদের অ্যাপ থেকে সেই প্যাটার্নগুলি ম্যানেজ করার জন্য রেজিস্টার করা হয়।

Android 12 ও তার পরের যেকোনও ভার্সনে

Android 12 (API লেভেল ৩১) ও তার পরবর্তী যেকোনও ভার্সন টার্গেট করে এমন অ্যাপে, ডিভাইসের স্ক্রিন চালু না করেই আপনি NFC পেমেন্ট চালু করতে পারবেন। এর জন্য requireDeviceScreenOn-কে false-এ সেট করতে হবে।

Android 10 ও তার পরের যেকোনও ভার্সন

Android 10 (API লেভেল ২৯) বা তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে সুরক্ষিত NFC কাজ করে। সুরক্ষিত NFC চালু থাকলে, ডিভাইসের স্ক্রিন বন্ধ থাকলে সব কার্ড এমুলেটর (হোস্ট অ্যাপ্লিকেশন এবং অফ-হোস্ট অ্যাপ্লিকেশন) উপলভ্য থাকে না। সুরক্ষিত NFC বন্ধ থাকলে, ডিভাইসের স্ক্রিন বন্ধ থাকলে অফ-হোস্ট অ্যাপ্লিকেশন উপলভ্য থাকে। আপনি isSecureNfcSupported() ব্যবহার করে সুরক্ষিত NFC কাজ করে কিনা তা চেক করতে পারেন।

Android 10 ও তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে, android:requireDeviceUnlock থেকে true-এ সেট করার একই কার্যকারিতা Android 9 ও তার পূর্ববর্তী যেকোনও ভার্সনে চলা ডিভাইসের ক্ষেত্রে প্রযোজ্য, তবে শুধুমাত্র তখনই যখন সুরক্ষিত NFC বন্ধ থাকে। অর্থাৎ, সুরক্ষিত NFC চালু থাকলে, android:requireDeviceUnlock-এর সেটিং যাই হোক না কেন, লক-স্ক্রিন থেকে HCE পরিষেবা কাজ করতে পারে না।

Android 9 ও তার আগের যেকোনও ভার্সন

Android 9 (API লেভেল ২৮) এবং তার আগের ভার্সন দ্বারা পরিচালিত ডিভাইসে, ডিভাইসের স্ক্রিন বন্ধ থাকলে NFC কন্ট্রোলার এবং অ্যাপ্লিকেশন প্রসেসর সম্পূর্ণভাবে বন্ধ থাকে। তাই স্ক্রিন বন্ধ থাকলে HCE পরিষেবা কাজ করে না।

এছাড়াও, Android 9 ও তার আগের ভার্সনে, লক স্ক্রিন থেকে HCE পরিষেবা কাজ করতে পারে। তবে, এটি আপনার HCE পরিষেবার <host-apdu-service> ট্যাগে android:requireDeviceUnlock অ্যাট্রিবিউট দ্বারা নিয়ন্ত্রিত হয়। ডিফল্ট হিসেবে, ডিভাইস আনলক করার প্রয়োজন হয় না এবং ডিভাইস লক করা থাকলেও আপনার পরিষেবা চালু করা হয়।

আপনার HCE পরিষেবার জন্য android:requireDeviceUnlock অ্যাট্রিবিউট true-এ সেট করলে, নিম্নলিখিত ঘটনা ঘটলে Android ব্যবহারকারীকে ডিভাইস আনলক করার জন্য প্রম্পট করে:

• ব্যবহারকারী NFC রিডারে ট্যাপ করেন।
• NFC রিডার এমন একটি AID বেছে নেয় যা আপনার পরিষেবার সাথে মিলে যায়।

আনলক করার পরে, Android একটি ডায়ালগ দেখায় যা ব্যবহারকারীকে ট্রানজ্যাকশন সম্পূর্ণ করার জন্য আবার ট্যাপ করতে প্রম্পট করে। এটি করা প্রয়োজন কারণ ব্যবহারকারী ডিভাইস আনলক করার জন্য NFC রিডার থেকে ডিভাইসটি সরিয়ে নিয়ে থাকতে পারেন।

সুরক্ষিত এলিমেন্ট সহ কার্ডের সাথে সহাবস্থান

এই বিভাগটি সেইসব ডেভেলপারদের জন্য যারা কার্ড এমুলেশনের জন্য নিরাপদ উপাদানের উপর নির্ভর করে এমন অ্যাপ্লিকেশন ব্যবহার করেছেন। Android-এর HCE ইমপ্লিমেন্টেশন কার্ড এমুলেশন ইমপ্লিমেন্ট করার অন্যান্য পদ্ধতির সাথে সমান্তরালভাবে কাজ করার জন্য ডিজাইন করা হয়েছে, যার মধ্যে নিরাপদ উপাদানের ব্যবহারও অন্তর্ভুক্ত।

মনে রাখবেন: Android-এ সরাসরি নিরাপদ উপাদানের সাথে যোগাযোগ করার জন্য কোনও API নেই।

এই সহাবস্থান AID রাউটিং নামক একটি নীতির উপর ভিত্তি করে তৈরি। NFC কন্ট্রোলারে একটি রাউটিং টেবিল থাকে যাতে রাউটিং নিয়মের একটি (নির্দিষ্ট) তালিকা থাকে। প্রতিটি রাউটিং নিয়মে একটি AID ও একটি গন্তব্য থাকে। গন্তব্যটি হয় হোস্ট CPU হতে পারে, যেখানে Android অ্যাপ চলছে, অথবা একটি কানেক্ট করা নিরাপদ উপাদান হতে পারে।

NFC রিডার SELECT AID সহ APDU পাঠালে, NFC কন্ট্রোলার এটি পার্স করে এবং চেক করে দেখে যে AID-এর সাথে এর রাউটিং টেবিলের কোনও AID মিলছে কিনা। এটি মিলে গেলে, সেই APDU এবং তার পরের সব APDU, AID-এর সাথে সম্পর্কিত গন্তব্যে পাঠানো হয়, যতক্ষণ না অন্য কোনও SELECT AID APDU পাওয়া যায় অথবা NFC লিঙ্ক ভেঙে যায়।

মনে রাখবেন: ISO/IEC 7816-4-এ আংশিক মিল-এর ধারণাও সংজ্ঞায়িত করা আছে, তবে Android HCE ডিভাইসে এটি কাজ করে না।

ছবি ৪-এ এই আর্কিটেকচার দেখানো হয়েছে:

ছবি ৪. নিরাপদ উপাদান ও হোস্ট-কার্ড ইমুলেশন, দুটির সাথেই Android কাজ করে।

NFC কন্ট্রোলারে সাধারণত APDU-এর জন্য একটি ডিফল্ট রুটও থাকে। রাউটিং টেবিলে AID খুঁজে পাওয়া না গেলে, ডিফল্ট রুট ব্যবহার করা হয়। এই সেটিং ডিভাইস অনুযায়ী আলাদা হতে পারে, তবে Android ডিভাইসের ক্ষেত্রে এটি নিশ্চিত করতে হবে যে আপনার অ্যাপের মাধ্যমে রেজিস্টার করা AID যেন হোস্টের কাছে সঠিকভাবে রাউট করা হয়।

যেসব Android অ্যাপ্লিকেশন HCE পরিষেবা প্রয়োগ করে বা নিরাপদ উপাদান ব্যবহার করে, তাদের রাউটিং টেবিল কনফিগার করার ব্যাপারে চিন্তা করতে হয় না; Android অটোমেটিক সেটি ম্যানেজ করে। Android-এর শুধু জানা প্রয়োজন যে কোন AID-গুলি HCE পরিষেবা দ্বারা এবং কোনগুলি নিরাপদ উপাদান দ্বারা ম্যানেজ করা যাবে। কোন পরিষেবা ইনস্টল করা আছে এবং ব্যবহারকারী কোনটিকে পছন্দ হিসেবে কনফিগার করেছেন তার উপর ভিত্তি করে রাউটিং টেবিল অটোমেটিক কনফিগার করা হয়।

কার্ড এমুলেশনের জন্য নিরাপদ উপাদান ব্যবহার করে এমন অ্যাপ্লিকেশনের জন্য কীভাবে AID ঘোষণা করতে হয় তা নিম্নলিখিত বিভাগে ব্যাখ্যা করা হয়েছে।

নিরাপদ এলিমেন্ট AID রেজিস্ট্রেশন

কার্ড ইমুলেশনের জন্য নিরাপদ উপাদান ব্যবহার করা অ্যাপ তাদের ম্যানিফেস্টে অফ-হোস্ট পরিষেবা ঘোষণা করতে পারে। এই ধরনের পরিষেবার ঘোষণা HCE পরিষেবার ঘোষণার প্রায় অনুরূপ। ব্যতিক্রমগুলি নিচে উল্লেখ করা হল:

• ইনটেন্ট ফিল্টারে ব্যবহৃত অ্যাকশন অবশ্যই SERVICE_INTERFACE-এ সেট করতে হবে।
• মেটা-ডেটা নামের অ্যাট্রিবিউট অবশ্যই SERVICE_META_DATA-এ সেট করতে হবে।

• মেটা-ডেটা XML ফাইলে অবশ্যই <offhost-apdu-service> রুট ট্যাগ ব্যবহার করতে হবে।

  <service android:name=".MyOffHostApduService" android:secureElementName="eSE"
         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 অ্যাট্রিবিউট অফ-হোস্ট পরিষেবার ক্ষেত্রে প্রযোজ্য নয়, কারণ হোস্ট CPU ট্রানজ্যাকশনের সাথে যুক্ত নয় এবং তাই ডিভাইস লক করা থাকলে নিরাপদ এলিমেন্টকে ট্রানজ্যাকশন কার্যকর করা থেকে আটকাতে পারে না।

অফ-হোস্ট পরিষেবার জন্য android:apduServiceBanner অ্যাট্রিবিউট প্রয়োজন যা পেমেন্ট অ্যাপ্লিকেশন এবং ডিফল্ট পেমেন্ট অ্যাপ্লিকেশন হিসেবে বেছে নিতে হবে।

অফ-হোস্ট পরিষেবা ইনভোকেশন

Android কখনই "অফ-হোস্ট" হিসেবে ঘোষিত কোনও পরিষেবা শুরু বা তার সাথে বাইন্ড করে না, কারণ আসল ট্রানজ্যাকশন নিরাপদ উপাদান দ্বারা সম্পাদিত হয়, Android পরিষেবা দ্বারা নয়। পরিষেবা ঘোষণা শুধুমাত্র অ্যাপ্লিকেশনকে নিরাপদ এলিমেন্টে উপস্থিত AID রেজিস্টার করার অনুমতি দেয়।

HCE এবং নিরাপত্তা

HCE আর্কিটেকচার নিরাপত্তার একটি মূল অংশ প্রদান করে: কারণ আপনার পরিষেবা BIND_NFC_SERVICE সিস্টেম অনুমতির মাধ্যমে সুরক্ষিত, তাই শুধুমাত্র OS আপনার পরিষেবার সাথে বাইন্ড করতে এবং যোগাযোগ করতে পারে। এটি নিশ্চিত করে যে আপনি যে APDU পান তা আসলে এমন একটি APDU যা NFC কন্ট্রোলার থেকে OS দ্বারা প্রাপ্ত হয়েছে এবং আপনি যে APDU ফেরত পাঠান তা শুধুমাত্র OS-এ যায়, যা সরাসরি APDU-কে NFC কন্ট্রোলারে ফরওয়ার্ড করে।

শেষ যে বিষয়টি নিয়ে চিন্তা থেকে যায় তা হল, আপনার অ্যাপ NFC রিডারে যে ডেটা পাঠায় তা আপনি কোথা থেকে পান। HCE ডিজাইনে এটি ইচ্ছাকৃতভাবে ডিকাপল করা হয়েছে; ডেটা কোথা থেকে আসছে তা নিয়ে এটি মাথা ঘামায় না, এটি শুধু নিশ্চিত করে যে ডেটা নিরাপদে NFC কন্ট্রোলারে ট্রান্সপোর্ট করা হয়েছে এবং NFC রিডারে পাঠানো হয়েছে।

আপনার HCE পরিষেবা থেকে যে ডেটা পাঠাতে চান তা নিরাপদে স্টোর ও ফিরিয়ে আনার জন্য, আপনি, উদাহরণস্বরূপ, Android অ্যাপ্লিকেশন স্যান্ডবক্সের উপর নির্ভর করতে পারেন, যা আপনার অ্যাপের ডেটাকে অন্যান্য অ্যাপ থেকে আলাদা করে। Android-এর নিরাপত্তা সম্পর্কে আরও জানতে, নিরাপত্তা সংক্রান্ত পরামর্শ পড়ুন।

প্রোটোকল প্যারামিটার ও বিবরণ

NFC প্রোটোকলের অ্যান্টি-কলিশন ও অ্যাক্টিভেশন ফেজে HCE ডিভাইস কোন প্রোটোকল প্যারামিটার ব্যবহার করে তা বুঝতে আগ্রহী ডেভেলপারদের জন্য এই বিভাগটি তৈরি করা হয়েছে। এটি এমন একটি রিডার ইনফ্রাস্ট্রাকচার তৈরি করতে সাহায্য করে যা Android HCE ডিভাইসের সাথে মানানসই।

Nfc-A (ISO/IEC 14443 type A) প্রোটোকল অ্যান্টি-কলিশন ও অ্যাক্টিভেশন

Nfc-A প্রোটোকল অ্যাক্টিভেশনের অংশ হিসেবে, একাধিক ফ্রেম এক্সচেঞ্জ করা হয়।

এক্সচেঞ্জের প্রথম অংশে, HCE ডিভাইস তার UID দেখায়; HCE ডিভাইসের UID র‍্যান্ডম বলে ধরে নেওয়া উচিত। এর অর্থ হল, প্রতিবার ট্যাপ করার সময়, পাঠককে যে UID দেখানো হয় সেটি র‍্যান্ডমভাবে জেনারেট করা UID। এই কারণে, NFC রিডারকে যাচাইকরণ বা শনাক্তকরণের জন্য HCE ডিভাইসের UID-এর উপর নির্ভর করা উচিত নয়।

NFC রিডার পরে SEL_REQ কমান্ড পাঠিয়ে HCE ডিভাইস বেছে নিতে পারে। HCE ডিভাইসের SEL_RES রেসপন্সে অন্তত ষষ্ঠ বিট (0x20) সেট করা থাকে, যা থেকে বোঝা যায় যে ডিভাইসটি ISO-DEP-এর সাথে কাজ করে। মনে রাখবেন, SEL_RES-এর অন্যান্য বিটও সেট করা থাকতে পারে, যা থেকে বোঝা যায় যে ডিভাইসটি NFC-DEP (p2p) প্রোটোকলের সাথে কাজ করে। অন্যান্য বিট সেট করা থাকতে পারে বলে, HCE ডিভাইসের সাথে ইন্টার‍্যাক্ট করতে চাওয়া পাঠকদের শুধুমাত্র ৬ষ্ঠ বিট চেক করতে হবে এবং সম্পূর্ণ SEL_RES-কে 0x20-এর মানের সাথে তুলনা করলে চলবে না।

ISO-DEP অ্যাক্টিভেশন

Nfc-A প্রোটোকল অ্যাক্টিভেট হওয়ার পরে, NFC রিডার ISO-DEP প্রোটোকল অ্যাক্টিভেশন শুরু করে। এটি RATS (Request for Answer To Select) কমান্ড পাঠায়। NFC কন্ট্রোলার RATS রেসপন্স, ATS জেনারেট করে; ATS, HCE পরিষেবার মাধ্যমে কনফিগার করা যায় না। তবে, HCE প্রয়োগের ক্ষেত্রে ATS রেসপন্সের জন্য NFC ফোরামের প্রয়োজনীয়তা পূরণ করতে হবে, যাতে NFC রিডার যেকোনও HCE ডিভাইসের জন্য NFC ফোরামের প্রয়োজনীয়তা অনুযায়ী সেট করা এইসব প্যারামিটার গণনা করতে পারে।

HCE ডিভাইসে NFC কন্ট্রোলারের মাধ্যমে প্রদান করা ATS রেসপন্সের স্বতন্ত্র বাইট সম্পর্কে নিচের বিভাগে আরও বিবরণ দেওয়া হয়েছে:

• TL: ATS উত্তরের দৈর্ঘ্য। দৈর্ঘ্য ২০ বাইটের বেশি হলে চলবে না।
• T0: বিট 5, 6 এবং 7 অবশ্যই সব HCE ডিভাইসে সেট করতে হবে, যা নির্দেশ করে যে TA(1), TB(1) এবং TC(1) ATS উত্তরে অন্তর্ভুক্ত। বিট ১ থেকে ৪ FSCI নির্দেশ করে, সর্বাধিক ফ্রেম সাইজ কোডিং করে। HCE ডিভাইসে FSCI-এর মান অবশ্যই 0h এবং 8h-এর মধ্যে হতে হবে।
• T(A)1: রিডার ও এমুলেটরের মধ্যে বিটরেট এবং সেগুলি অ্যাসিমেট্রিক হতে পারে কিনা তা নির্ধারণ করে। HCE ডিভাইসের জন্য কোনও বিটরেট সংক্রান্ত প্রয়োজনীয়তা বা গ্যারান্টি নেই।
• T(B)১: ১ থেকে ৪ বিট স্টার্ট-আপ ফ্রেম গার্ড টাইম ইন্টিজার (SFGI) নির্দেশ করে। HCE ডিভাইসে, SFGI অবশ্যই <= ৮ ঘণ্টা হতে হবে। বিট ৫ থেকে ৮ ফ্রেম ওয়েটিং টাইম ইন্টিজার (FWI) নির্দেশ করে এবং ফ্রেম ওয়েটিং টাইম (FWT) কোড করে। HCE ডিভাইসে, FWI অবশ্যই <= ৮ ঘণ্টা হতে হবে।
• T(C)1: বিট ৫ "উন্নত প্রোটোকল ফিচার" সংক্রান্ত সহায়তা নির্দেশ করে। HCE ডিভাইসে "উন্নত প্রোটোকল ফিচার" কাজ করতেও পারে, আবার নাও করতে পারে। বিট ২, DID-এর জন্য সহায়তা নির্দেশ করে। HCE ডিভাইসে DID কাজ করতেও পারে, আবার নাও করতে পারে। বিট ১ NAD-এর জন্য সহায়তা নির্দেশ করে। HCE ডিভাইসে NAD কাজ করলে চলবে না এবং বিট ১-কে শূন্যে সেট করতে হবে।
• ঐতিহাসিক বাইট: HCE ডিভাইস ১৫টি পর্যন্ত ঐতিহাসিক বাইট ফেরত দিতে পারে। HCE পরিষেবার সাথে ইন্টার‍্যাক্ট করতে ইচ্ছুক NFC রিডারদের হিস্টোরিক্যাল বাইটের কন্টেন্ট বা তাদের উপস্থিতি সম্পর্কে কোনও অনুমান করা উচিত নয়।

মনে রাখবেন, অনেক HCE ডিভাইস সম্ভবত প্রোটোকল সংক্রান্ত প্রয়োজনীয়তা মেনে চলে যা EMVCo-তে একত্রিত পেমেন্ট নেটওয়ার্ক তাদের "কন্ট্যাক্টলেস কমিউনিকেশন প্রোটোকল" স্পেসিফিকেশনে উল্লেখ করেছে। বিশেষ করে এতে:

• T0-তে FSCI অবশ্যই ২ ঘণ্টা থেকে ৮ ঘণ্টার মধ্যে হতে হবে।
• T(A)1 অবশ্যই 0x80-এ সেট করতে হবে, যা নির্দেশ করে যে শুধুমাত্র ১০৬ kbit/s বিটরেট কাজ করে এবং রিডার ও এমুলেটরের মধ্যে অ্যাসিমেট্রিক বিটরেট কাজ করে না।
• T(B)1-এ FWI অবশ্যই <= ৭ ঘণ্টা হতে হবে।

APDU ডেটা এক্সচেঞ্জ

আগে যেমন উল্লেখ করা হয়েছে, HCE প্রয়োগের ক্ষেত্রে শুধুমাত্র একটি লজিক্যাল চ্যানেল কাজ করে। HCE ডিভাইসে বিভিন্ন লজিক্যাল চ্যানেলে অ্যাপ্লিকেশন বেছে নেওয়ার চেষ্টা করলে তা কাজ করে না।