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

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

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

একটি সুরক্ষিত উপাদান সহ কার্ড অনুকরণ

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

চিত্র 1. একটি সুরক্ষিত উপাদান সহ NFC কার্ড এমুলেশন।

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

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

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

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

সমর্থিত NFC কার্ড এবং প্রোটোকল

চিত্র 3. অ্যান্ড্রয়েডের HCE প্রোটোকল স্ট্যাক।

এনএফসি স্ট্যান্ডার্ডগুলি বিভিন্ন প্রোটোকলের জন্য সমর্থন প্রদান করে এবং বিভিন্ন ধরণের কার্ড রয়েছে যা আপনি অনুকরণ করতে পারেন।

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

বিশেষত, Android 4.4 এবং উচ্চতর এনএফসি-ফোরাম ISO-DEP স্পেসিফিকেশন (ISO/IEC 14443-4-এর উপর ভিত্তি করে) এবং ISO/IEC 7816-4 এ সংজ্ঞায়িত অ্যাপ্লিকেশন প্রোটোকল ডেটা ইউনিট (APDUs) এর উপর ভিত্তি করে অনুকরণীয় কার্ডগুলিকে সমর্থন করে। স্পেসিফিকেশন Android শুধুমাত্র Nfc-A (ISO/IEC 14443-3 Type A) প্রযুক্তির উপরে ISO-DEP অনুকরণ করে। Nfc-B (ISO/IEC 14443-4 Type B) প্রযুক্তির জন্য সমর্থন ঐচ্ছিক। চিত্র 3 এই সমস্ত বৈশিষ্ট্যগুলির স্তরবিন্যাসকে চিত্রিত করে৷

HCE পরিষেবা

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

পরিষেবা নির্বাচন

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

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

এইড গ্রুপ

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

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

• গ্রুপের সমস্ত এইডগুলি এই HCE পরিষেবাতে পাঠানো হয়৷
• এই এইচসিই পরিষেবাতে গ্রুপের কোনও এআইডি রাউট করা হয় না (উদাহরণস্বরূপ, কারণ ব্যবহারকারী অন্য কোনও পরিষেবা পছন্দ করেছেন যা আপনার গোষ্ঠীতেও এক বা একাধিক এআইডি অনুরোধ করেছে)।

অন্য কথায়, এর মধ্যে কোনো রাজ্য নেই, যেখানে গ্রুপের কিছু এইডগুলি একটি HCE পরিষেবাতে এবং কিছুকে অন্য পরিষেবাতে পাঠানো যেতে পারে।

এইড গ্রুপ এবং বিভাগ

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

অ্যান্ড্রয়েড 4.4 এবং উচ্চতর দুটি বিভাগ সমর্থন করে:

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

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

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

একটি HCE পরিষেবা বাস্তবায়ন করুন

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

HCE সমর্থন জন্য পরীক্ষা করুন

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

সেবা বাস্তবায়ন

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

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

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

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

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

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

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

আপনি যদি বিদ্যমান পাঠক পরিকাঠামো নিয়ে কাজ করেন, তাহলে আপনাকে অবশ্যই বিদ্যমান অ্যাপ্লিকেশন-স্তরের প্রোটোকল বাস্তবায়ন করতে হবে যা পাঠকরা আপনার HCE পরিষেবাতে আশা করে।

আপনি যদি নতুন পাঠক পরিকাঠামো স্থাপন করেন যা আপনি নিয়ন্ত্রণ করেন, আপনি আপনার নিজস্ব প্রোটোকল এবং APDU ক্রম সংজ্ঞায়িত করতে পারেন। বিনিময় করার জন্য APDU-এর পরিমাণ এবং ডেটার আকার সীমিত করার চেষ্টা করুন: এটি নিশ্চিত করে যে আপনার ব্যবহারকারীদের শুধুমাত্র অল্প সময়ের জন্য NFC রিডারে তাদের ডিভাইস ধরে রাখতে হবে। একটি যুক্তিসঙ্গত উপরের সীমা হল প্রায় 1 KB ডেটা, যা সাধারণত 300 ms এর মধ্যে বিনিময় করা যেতে পারে।

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

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

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

2. এই পরিষেবার দ্বারা কোন AIDs গোষ্ঠীগুলিকে অনুরোধ করা হয়েছে তা প্ল্যাটফর্মকে জানাতে, পরিষেবার ঘোষণায় একটি 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-তে দেখাতে পারেন। আপনি APDU গুলি পরিচালনা করার জন্য এই পরিষেবাটি চালু করার আগে ডিভাইসটি আনলক করা হয়েছে তা নির্দিষ্ট করতে আপনি requireDeviceUnlock বৈশিষ্ট্যটি ব্যবহার করতে পারেন৷

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

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

HCE পরিষেবা হিসাবে নিবন্ধন করার জন্য আপনার আবেদনের NFC অনুমতিও থাকতে হবে।

এআইডি দ্বন্দ্ব সমাধান

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

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

ফোরগ্রাউন্ড পরিষেবা পছন্দ

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

Android 13 এবং উচ্চতর

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

অ্যান্ড্রয়েড 12 এবং তার নিচের

পরিষেবা ব্যানারের আকার 260x96 dp তে সেট করুন, তারপরে <host-apdu-service> ট্যাগে android:apduServiceBanner অ্যাট্রিবিউট যোগ করে আপনার মেটাডেটা XML ফাইলে পরিষেবা ব্যানারের আকার সেট করুন, যা অঙ্কনযোগ্য সম্পদের দিকে নির্দেশ করে। নিম্নলিখিত একটি উদাহরণ:

<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 এবং উচ্চতর একটি ডিফল্ট ওয়ালেট অ্যাপ ভূমিকা অন্তর্ভুক্ত করে যা ব্যবহারকারী সেটিংস > অ্যাপস > ডিফল্ট অ্যাপে নেভিগেট করে নির্বাচন করতে পারেন। এটি একটি পেমেন্ট টার্মিনাল ট্যাপ করা হলে আহ্বান করার জন্য ডিফল্ট ওয়ালেট অ্যাপ্লিকেশনটিকে সংজ্ঞায়িত করে৷ অ্যান্ড্রয়েড এইচসিই পরিষেবাগুলিকে বিবেচনা করে যেগুলি অর্থপ্রদানের বিভাগ সহ একটি এআইডি গ্রুপকে ওয়ালেট অ্যাপ্লিকেশন হিসাবে ঘোষণা করেছে৷

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

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

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

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

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

পর্যবেক্ষণ মোড

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

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

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

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

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

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

পোলিং লুপগুলিতে সাড়া দিন এবং পর্যবেক্ষণ মোড থেকে স্থানান্তর করুন৷

পরিষেবাটি লেনদেনের জন্য প্রস্তুত হলে, এটি setObserveModeEnabled() এ false পাস করে অবজারভ মোড থেকে প্রস্থান করতে পারে। 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 স্তর 31) এবং উচ্চতরকে লক্ষ্য করে, আপনি ডিভাইসের স্ক্রীন ছাড়া NFC অর্থপ্রদান চালু করতে পারেন requireDeviceScreenOn কে false সেট করে।

Android 10 এবং উচ্চতর

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

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

অ্যান্ড্রয়েড 9 এবং তার নিচের

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

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

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

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

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

সুরক্ষিত উপাদান কার্ডের সাথে সহাবস্থান

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

দ্রষ্টব্য: Android একটি নিরাপদ উপাদানের সাথে সরাসরি যোগাযোগের জন্য API অফার করে না।

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

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

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

চিত্র 4 এই স্থাপত্যটি চিত্রিত করে:

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

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

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

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

নিরাপদ উপাদান AID নিবন্ধন

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

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

• মেটা-ডেটা XML ফাইলটিকে অবশ্যই <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 অ্যাট্রিবিউট অফ-হোস্ট পরিষেবাগুলিতে প্রযোজ্য নয়, কারণ হোস্ট CPU লেনদেনের সাথে জড়িত নয় এবং তাই ডিভাইসটি লক থাকা অবস্থায় নিরাপদ উপাদানটিকে লেনদেন সম্পাদন করা থেকে আটকাতে পারে না৷

android:apduServiceBanner বৈশিষ্ট্যটি অফ-হোস্ট পরিষেবাগুলির জন্য প্রয়োজন যা অর্থপ্রদানের অ্যাপ্লিকেশন এবং একটি ডিফল্ট অর্থপ্রদানের অ্যাপ্লিকেশন হিসাবে নির্বাচনযোগ্য।

অফ-হোস্ট পরিষেবা আহ্বান

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

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

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

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

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

প্রোটোকল পরামিতি এবং বিবরণ

এই বিভাগটি সেই বিকাশকারীদের জন্য আগ্রহের বিষয় যারা NFC প্রোটোকলের অ্যান্টি-কলিশন এবং অ্যাক্টিভেশন পর্যায়গুলির সময় HCE ডিভাইসগুলি কোন প্রোটোকল প্যারামিটারগুলি ব্যবহার করে তা বুঝতে চান৷ এটি একটি পাঠক পরিকাঠামো তৈরি করতে দেয় যা Android HCE ডিভাইসের সাথে সামঞ্জস্যপূর্ণ।

এনএফসি-এ (আইএসও/আইইসি 14443 টাইপ এ) প্রোটোকল অ্যান্টি-কলিশন এবং অ্যাক্টিভেশন

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

বিনিময়ের প্রথম অংশে, HCE ডিভাইসটি তার UID উপস্থাপন করে; HCE ডিভাইসগুলির একটি এলোমেলো UID আছে বলে ধরে নেওয়া উচিত। এর মানে হল যে প্রতিটি ট্যাপে, পাঠকের কাছে যে UID উপস্থাপিত হয় তা একটি এলোমেলোভাবে তৈরি করা UID। এই কারণে, NFC পাঠকদের প্রমাণীকরণ বা শনাক্তকরণের ফর্ম হিসাবে HCE ডিভাইসগুলির UID-এর উপর নির্ভর করা উচিত নয়।

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

ISO-DEP সক্রিয়করণ

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

নীচের বিভাগটি HCE ডিভাইসে NFC কন্ট্রোলার দ্বারা প্রদত্ত ATS প্রতিক্রিয়ার পৃথক বাইটের বিষয়ে আরও বিশদ প্রদান করে:

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

মনে রাখবেন যে অনেক HCE ডিভাইস সম্ভবত প্রোটোকল প্রয়োজনীয়তাগুলির সাথে সঙ্গতিপূর্ণ করা হয়েছে যা EMVCo-তে একত্রিত পেমেন্ট নেটওয়ার্কগুলি তাদের "যোগাযোগহীন যোগাযোগ প্রোটোকল" স্পেসিফিকেশনে নির্দিষ্ট করেছে। বিশেষ করে:

• T0 তে FSCI 2h এবং 8h এর মধ্যে হতে হবে।
• T(A)1 অবশ্যই 0x80 এ সেট করতে হবে, এটি নির্দেশ করে যে শুধুমাত্র 106 kbit/s বিটরেট সমর্থিত, এবং রিডার এবং এমুলেটরের মধ্যে অসমমিত বিটরেট সমর্থিত নয়।
• T(B)1 এ FWI অবশ্যই <= 7h হতে হবে।

APDU ডেটা বিনিময়

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