تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

نظرة عامة على محاكاة البطاقة المستنِدة إلى المضيف

إنّ العديد من أجهزة Android التي تتيح استخدام تقنية NFC تتيح أيضًا محاكاة بطاقات NFC. في معظم الحالات، تتم محاكاة البطاقة بواسطة شريحة منفصلة في الجهاز تُسمى العنصر الآمن. تحتوي العديد من شرائح SIM التي يوفّرها مشغّلو شبكات الجوّال أيضًا على عنصر آمن.

يقدّم نظام التشغيل Android 4.4 والإصدارات الأحدث طريقة إضافية لمحاكاة البطاقة لا تتضمّن عنصرًا آمنًا، وتُعرف باسم محاكاة البطاقة المستندة إلى المضيف. يتيح ذلك لأي تطبيق Android محاكاة بطاقة والتواصل مباشرةً مع قارئ تقنية NFC. يصف هذا الموضوع طريقة عمل ميزة "محاكاة البطاقة المستندة إلى المضيف" (HCE) على نظام التشغيل Android وكيفية تطوير تطبيق يحاكي بطاقة NFC باستخدام هذه التقنية.

محاكاة البطاقة باستخدام عنصر آمن

عند توفير محاكاة بطاقة NFC باستخدام عنصر آمن، يتم توفير البطاقة التي سيتم محاكاتها في العنصر الآمن على الجهاز من خلال أحد تطبيقات Android. بعد ذلك، عندما يضع المستخدم الجهاز فوق محطة NFC، يوجّه عنصر التحكّم في تكنولوجيا NFC في الجهاز جميع البيانات من القارئ مباشرةً إلى العنصر المأمون. يوضّح الشكل 1 هذا المفهوم:

مخطّط بياني يعرض قارئ NFC يمر عبر وحدة تحكّم في NFC لاسترداد المعلومات من عنصر آمن
الشكل 1. محاكاة بطاقة NFC باستخدام عنصر آمن

يُجري العنصر الآمن نفسه عملية التواصل مع محطة NFC، ولا يشارك أي تطبيق Android في المعاملة. بعد اكتمال المعاملة، يمكن لتطبيق Android طلب معلومات من العنصر الآمن مباشرةً عن حالة المعاملة وإرسال إشعار إلى المستخدم.

محاكاة البطاقة المستندة إلى المضيف

عند محاكاة بطاقة NFC باستخدام محاكاة البطاقة المستندة إلى المضيف، يتم توجيه البيانات مباشرةً إلى وحدة المعالجة المركزية للمضيف بدلاً من توجيهها إلى عنصر آمن. يوضِّح الشكل 2 طريقة عمل ميزة محاكاة البطاقة المستندة إلى المضيف:

مخطّط بياني يعرض قارئ NFC يمر عبر وحدة تحكّم في NFC لاسترداد المعلومات من وحدة المعالجة المركزية
الشكل 2: محاكاة بطاقة NFC بدون عنصر آمن

بطاقات NFC والبروتوكولات المتوافقة

مخطّط بياني يعرض حِزمة بروتوكول HCE
الشكل 3. حِزمة بروتوكول HCE في Android

تدعم معايير NFC العديد من البروتوكولات المختلفة، وهناك أنواع مختلفة من البطاقات التي يمكنك محاكاتها.

يتوافق الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث مع العديد من البروتوكولات الشائعة في السوق اليوم. تستند العديد من البطاقات الحالية التي تعمل بدون تلامس الأجهزة إلى هذه البروتوكولات، مثل بطاقات الدفع بدون تلامس الأجهزة. تتوفّر هذه البروتوكولات أيضًا في العديد من قارئات NFC المتوفّرة في السوق حاليًا، بما في ذلك أجهزة Android NFC التي تعمل بدورها كهي قارئات (راجِع فئة IsoDep ). يتيح لك ذلك إنشاء ونشر حلّ NFC شامل حول HCE باستخدام أجهزة Android فقط.

على وجه التحديد، يتيح الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث محاكاة البطاقات التي تستند إلى مواصفة ISO-DEP الخاصة بمنتدى NFC (استنادًا إلى ISO/IEC 14443-4) ومعالجة وحدات بيانات بروتوكول التطبيقات (APDUs) على النحو المحدّد في مواصفة ISO/IEC 7816-4. يفرض Android محاكاة بروتوكول ISO-DEP فقط على تقنية Nfc-A (ISO/IEC 14443-3 Type A). إنّ إتاحة تقنية Nfc-B (المعيار ISO/IEC 14443-4، النوع B) هو أمر اختياري. يوضّح الشكل 3 تداخل كل هذه المواصفات.

خدمات محاكاة البطاقة المُضيفة (HCE)

تستند بنية HCE في Android إلى مكوّنات Android Service (المعروفة باسم خدمات HCE). من بين المزايا الرئيسية لأي خدمة إمكانية تشغيلها في الخلفية بدون أي واجهة مستخدم. وهذا مناسب بشكلٍ طبيعي للعديد من تطبيقات HCE ، مثل بطاقات الولاء أو بطاقات النقل العام، والتي لا يحتاج المستخدم إلى تشغيل تطبيق لاستخدامها. بدلاً من ذلك، يؤدي النقر على الجهاز مقابل قارئ NFC إلى بدء الخدمة الصحيحة إذا لم تكن قيد التشغيل، وتنفيذ المعاملة في الخلفية. وبإمكانك بالطبع إطلاق واجهة مستخدم إضافية (مثل إشعارات المستخدمين) من خدمتك عند الاقتضاء.

اختيار الخدمة

عندما ينقر المستخدم على جهاز مع قارئ NFC، يجب أن يعرف نظام Android خدمة HCE التي يريد قارئ NFC التواصل معها. تحدِّد مواصفة ISO/IEC 7816-4 طريقة اختيار التطبيقات، والتي تركّز على معرّف التطبيق (AID). يتكوّن معرّف AID من 16 بايت كحدّ أقصى. إذا كنت تحاكي البطاقات لبنية أساسية حالية لقارئ NFC، تكون معرّفات AID التي يبحث عنها هؤلاء القرّاء عادةً معروفة ومسجّلة بشكل علني (على سبيل المثال، معرّفات AID لشبكات الدفع مثل Visa وMasterCard).

إذا كنت تريد نشر بنية أساسية جديدة للقارئ لتطبيقك، عليك تسجيل معرّفات AID الخاصة بك. يتم تحديد إجراء التسجيل الخاص بفيروسات AID في مواصفات ISO/IEC 7816-5. ننصح بتسجيل رقم AID وفقًا للرقم 7816-5 إذا كنت تنشر تطبيق HCE على نظام Android، لأنّ ذلك يتجنّب التعارضات مع التطبيقات الأخرى.

مجموعات تحسين الأداء من خلال الإعلان

في بعض الحالات، قد تحتاج خدمة HCE إلى تسجيل معرّفات AID متعددة وضبطها على أنّها المعالج التلقائي لجميع معرّفات AID من أجل تنفيذ تطبيق معيّن. لا يتم دعم بعض أنواع الإيدز في المجموعة التي تنتقل إلى خدمة أخرى.

تسمى قائمة AID المحفوظة معًا بمجموعة AID. بالنسبة إلى جميع أنواع الإيدز في مجموعة المساعدات AID، يضمن Android واحدًا مما يلي:

يتم توجيه جميع معرّفات AID في المجموعة إلى خدمة HCE هذه.
لا يتم توجيه أي معرّفات خاصة بـ AID في المجموعة إلى خدمة HCE هذه (على سبيل المثال، لأن المستخدم فضّل خدمة أخرى طلبت معرّفًا واحدًا أو أكثر من معرّفات AID في مجموعتك أيضًا).

بعبارة أخرى، لا تتوفّر حالة وسيطة يمكن فيها توجيه بعض معرّفات AID في المجموعة إلى خدمة HCE واحدة وبعضها إلى خدمة أخرى.

مجموعات وفئات ميزة "المساعدة في التسويق"

يمكنك ربط كل مجموعة من مجموعات ميزة تحديد المصدر بالاستناد إلى البيانات بفئة. ويسمح ذلك لنظام التشغيل Android بتجميع خدمات HCE معًا حسب الفئة، ويتيح للمستخدم ضبط الإعدادات التلقائية على مستوى الفئة بدلاً من مستوى AID. تجنَّب الإشارة إلى معرّفات AID في أي أجزاء من تطبيقك موجّهة للمستخدمين، لأنّها لا تعني أيّ شيء للمستخدم العادي.

يتيح الإصدار 4.4 من نظام التشغيل Android فئتين:

CATEGORY_PAYMENT (تغطي تطبيقات الدفع وفقًا للمعايير المتّبعة في المجال)
CATEGORY_OTHER (لجميع تطبيقات HCE الأخرى)

ملاحظة: يمكن تفعيل مجموعة واحدة فقط من مجموعات AID في فئة CATEGORY_PAYMENT في النظام في أي وقت. وعادةً ما يتمكّن هذا التطبيق من فهم بروتوكولات الدفع الرئيسية ببطاقة الائتمان ويمكن استخدامه لدى أي تاجر.

بالنسبة إلى تطبيقات الدفع ذات الحلقات المغلقة التي لا تعمل إلا لدى تاجر واحد (مثل البطاقات ذات القيمة المخزّنة)، استخدِم CATEGORY_OTHER. يمكن أن تكون مجموعات معرّفات AID في هذه الفئة نشطة دائمًا، ويمكن أن تمنح أدوات قراءة NFC الأولوية لها أثناء اختيار معرّف AID إذا لزم الأمر.

تنفيذ خدمة محاكاة البطاقة المضيفة (HCE)

لمحاكاة بطاقة NFC باستخدام ميزة "محاكاة البطاقة المستندة إلى المضيف"، عليك إنشاء عنصر Service يعالج معاملات NFC.

التحقّق من توفّر وظيفة HCE

يمكن لتطبيقك التحقّق مما إذا كان الجهاز متوافقًا مع معيار HCE من خلال التحقّق من توفّر ميزة FEATURE_NFC_HOST_CARD_EMULATION. استخدِم العلامة <uses-feature> في ملف بيان تطبيقك للإشارة إلى أنّ تطبيقك يستخدم ميزة HCE وما إذا كانت هذه الميزة مطلوبة لكي يعمل التطبيق أم لا.

تنفيذ الخدمة

يوفّر الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث فئة Service سهلة الاستخدام يمكنك استخدامها كأساس لتنفيذ خدمة HCE: فئة 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()، عندما يرسل قارئ NFC وحدة بيانات بروتوكول التطبيق (APDU) إلى خدمتك. يتم تحديد وحدات APDU في مواصفة ISO/IEC 7816-4. ‫APDU هي الحِزم على مستوى التطبيق التي يتم تبادلها بين قارئ NFC وخدمات HCE. هذا البروتوكول على مستوى التطبيق هو نصف مزدوج: يُرسِل قارئ NFC إليك APDU للطلب، وينتظر منك إرسال APDU للرد.

كما ذكرنا سابقًا، يستخدم Android معرّف الجهاز لتحديد خدمة HCE التي يريد القارئ التواصل معها. عادةً ما يكون أول APDU يرسله قارئ NFC إلى جهازك هو APDU من النوع SELECT AID، ويحتوي هذا APDU على معرّف AID الذي يريد قارئ البطاقة التفاعل معه. يستخرج Android معرّف AID هذا من APDU، ويحلّه إلى خدمة HCE ، ثم يعيد توجيه APDU إلى الخدمة التي تم حلّها.

يمكنك إرسال APDU للرد من خلال عرض وحدات البايت الخاصة بـ APDU للرد من processCommandApdu(). يُرجى العِلم أنّ هذه الطريقة يتمّ استدعاؤها في سلسلة المهام الرئيسية لتطبيقك، والتي يجب عدم حظرها. إذا لم تتمكّن من احتساب APDU للردّ وإعادته على الفور، أعِد القيمة null. يمكنك بعد ذلك تنفيذ العمل اللازم في سلسلت محادثات أخرى واستخدام الأسلوب sendResponseApdu() المحدّد في فئة HostApduService لإرسال الردّ عند الانتهاء من المعالجة.

يواصل Android إعادة توجيه رسائل APDU الجديدة من القارئ إلى خدمتك إلى أن يحدث أحد يليه:

يُرسِل قارئ NFC SELECT AID APDU آخر، والذي يحلّ نظام التشغيل برمجه للخدمة المختلفة.
رابط NFC بين قارئ NFC وجهازك لا يعمل.

في كلتا الحالتَين، يتمّ استدعاء تنفيذ onDeactivated() صفّك باستخدام وسيطة تشير إلى أيّ من الاثنين حدث.

إذا كنت تعمل مع البنية الأساسية الحالية للقارئ، يجب تنفيذ البروتوكول الحالي على مستوى التطبيق الذي يتوقّعه القرّاء في خدمة HCE.

إذا كنت بصدد نشر بنية أساسية جديدة للقارئ تتحكم فيها أيضًا، يمكنك تحديد بروتوكولك وتسلسل APDU. حاوِل الحد من عدد رسائل APDU وحجم البيانات المطلوب تبادلها: يضمن ذلك أنّه على المستخدمين سوى إمساك أجهزتهم فوق قارئ NFC لفترة قصيرة. يبلغ الحد الأقصى المعقول حوالي 1 كيلوبايت من البيانات، والتي يمكن عادةً تبادلها في غضون 300 ملي ثانية.

بيان بيان الخدمة وتسجيل معرّف AID

يجب الإفصاح عن خدمتك في البيان كالمعتاد، ولكن عليك أيضًا إضافة بعض العناصر الإضافية إلى بيان الخدمة:

لإعلام المنصة بأنّها خدمة HCE تنفّذ واجهة HostApduService، أضِف فلتر أهداف للإجراء SERVICE_INTERFACE إلى بيان الخدمة.
لإعلام المنصة بمجموعات AID التي تطلبها هذه الخدمة، يجب تضمين علامة SERVICE_META_DATA <meta-data> في إعلان الخدمة للإشارة إلى مورد XML الذي يتضمن معلومات إضافية حول خدمة HCE.
اضبط سمة android:exported على true، واطلب إذن android.permission.BIND_NFC_SERVICE في بيان الخدمة. يضمن الخيار الأول إمكانية ربط الخدمة بتطبيقات خارجية. ويفرض هذا الأخير بعد ذلك أنّه لا يمكن للتطبيقات الخارجية التي تمتلك إذن android.permission.BIND_NFC_SERVICE فقط الربط بخدمتك. بما أنّ android.permission.BIND_NFC_SERVICE هو إذن نظام، يؤدي ذلك إلى فرض ربط نظام التشغيل Android فقط بخدمتك.

في ما يلي مثال على بيان بيان 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> تتضمّن وصفًا بسيطًا للمستخدم عن الخدمة التي يمكنك عرضها في واجهة مستخدم التطبيق. يمكنك استخدام السمة requireDeviceUnlock لتحديد أنّه تم فتح قفل الجهاز قبل استدعاء هذه الخدمة لمعالجة عمليات APDU.

يجب أن يحتوي <host-apdu-service> على علامة <aid-group> واحدة أو أكثر. يجب استخدام علامة <aid-group> لتنفيذ ما يلي:

أن تتضمّن سمة android:description تشمل وصفًا سهل الاستخدام لمجموعة AID وملائمًا للعرض في واجهة المستخدم
يتم ضبط السمة android:category الخاصة بها للإشارة إلى الفئة التي تنتمي إليها مجموعة AID، مثل ثوابت السلسلة المحدَّدة من خلال CATEGORY_PAYMENT أو CATEGORY_OTHER.
تحتوي على علامة <aid-filter> واحدة أو أكثر، كل منها يحتوي على معرّف AID واحد. حدِّد معرّف AID بالتنسيق السداسي عشري، وتأكَّد من أنّه يحتوي على عددٍ زوجي من الأحرف.

يجب أن يحصل تطبيقك أيضًا على إذن NFC للتسجيل كأحد خدمات HCE.

حل النزاعات في مجال AID

يمكن تثبيت عدة مكونات HostApduService على جهاز واحد، ويمكن تسجيل معرّف AID نفسه من خلال أكثر من خدمة واحدة. يحدِّد نظام التشغيل Android الخدمة التي سيتمّ استدعاؤها باستخدام الخطوات التالية:

إذا سجّل تطبيق المحفظة التلقائي الذي اختاره المستخدم معرّف AID، سيتم استدعاء هذا التطبيق.
إذا لم يسجِّل تطبيق المحفظة التلقائي معرّف AID، يتمّ استدعاء الخدمة التي سجّلت معرّف AID.
إذا سجّلت أكثر من خدمة واحدة معرّف AID، يسأل Android المستخدم عن الخدمة التي يريد استدعاؤها.

التحقّق مما إذا كان تطبيقك هو تطبيق المحفظة التلقائي

يمكن للتطبيقات التحقّق مما إذا كانت هي تطبيق المحفظة التلقائي من خلال إرسال رمز RoleManager.ROLE_WALLET إلى RoleManager.isRoleHeld().

إذا لم يكن تطبيقك هو التطبيق التلقائي، يمكنك طلب دور المحفظة التلقائي من خلال إرسال RoleManager.ROLE_WALLET إلى RoleManager.createRequestRoleIntent().

تطبيقات "محفظة Google"

تصنِّف نظام التشغيل Android خدمات HCE التي أعلنت عن مجموعة AID ضمن فئة الدفع على أنّها تطبيقات محفظة. يشمل نظام Android 15 والإصدارات الأحدث دورًا تلقائيًا في تطبيق المحفظة يمكن للمستخدم اختياره من خلال الانتقال إلى الإعدادات > التطبيقات > التطبيقات التلقائية. يحدِّد هذا العنصر تطبيق المحفظة التلقائي الذي سيتم تشغيله عند النقر على محطّة دفع.

الأصول المطلوبة لتطبيقات "محفظة Google"

لتوفير تجربة استخدام أكثر جاذبية من الناحية المرئية، يجب أن تشمل تطبيقات محفظة HCE إعلان بانر للخدمة.

الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث

لكي تلائم قائمة اختيار الدفع التلقائية في واجهة مستخدم "الإعدادات" بشكلٍ أفضل، عدِّل متطلبات الباننر لتكون رمزًا مربّعًا. من الأفضل أن يكون مطابقًا لتصميم رمز مشغّل التطبيقات. يوفر هذا التعديل مزيدًا من الاتساق ومظهر أكثر وضوحًا.

الإصدار 12 من نظام التشغيل Android والإصدارات الأقدم

اضبط حجم بانر الخدمة على 260x96 بكسل مستقل الكثافة، ثم اضبط حجم بانر الخدمة في ملف XML الخاص بالبيانات الوصفية من خلال إضافة سمة android:apduServiceBanner إلى العلامة <host-apdu-service> التي تشير إلى المورد القابل للرسم. فيما يلي مثال:

<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 ميزة وضع المراقبة. عند تفعيل وضع "الملاحظة"، يسمح للجهاز بملاحظة دورات الاستطلاع 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 أيضًا إلى أنّه ينبغي أن يؤدي فلاتر حلقة الاستطلاع التي تتطابق مع إطارات حلقة الاستطلاع المستلَمة إلى إيقاف وضع "الملاحظة" تلقائيًا والسماح بمواصلة المعاملات من خلال ضبط autoTransact على true في بيان PollingLoopFilter في البيان.

سلوك الشاشة المُطفأة وشاشة القفل

يختلف سلوك خدمات HCE بناءً على إصدار Android المثبَّت على الجهاز.

الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث

في التطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك تفعيل الدفعات عبر NFC بدون تفعيل شاشة الجهاز من خلال ضبط السمة requireDeviceScreenOn على false.

الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث

الأجهزة التي تعمل بنظام التشغيل Android 10 (المستوى 29 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث تتوافق مع تقنية الاتصال القصير المدى (NFC) الآمنة. عندما تكون ميزة "NFC الآمنة" مفعّلة، لا تتوفّر جميع محاكيات البطاقات (التطبيقات المضيفّة والتطبيقات غير المضيفّة) عند إطفاء شاشة الجهاز. وعندما تكون هذه الميزة غير مفعّلة، تتوفّر التطبيقات غير المضيفّة عند إطفاء شاشة الجهاز. يمكنك التحقّق من توفّر ميزة "NFC الآمنة" باستخدام رمز isSecureNfcSupported().

على الأجهزة التي تعمل بالإصدار 10 من نظام التشغيل Android والإصدارات الأحدث، تنطبق الوظيفة نفسها لضبط قيمة android:requireDeviceUnlock على true كما هو الحال مع الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android والإصدارات الأقدم، ولكن فقط عند إيقاف ميزة "الاتصال الآمن عبر NFC". وهذا يعني أنّه إذا كانت ميزة "الاتصال الآمن عبر NFC" مفعّلة، لا يمكن لخدمات HCE العمل من شاشة القفل بغض النظر عن قيمة android:requireDeviceUnlock.

الإصدار 9 من نظام Android والإصدارات الأقدم

على الأجهزة التي تعمل بنظام التشغيل Android 9 (المستوى 28 من واجهة برمجة التطبيقات) والإصدارات الأقدم، يتم إيقاف وحدة التحكّم في تقنية NFC ومعالج التطبيقات بالكامل عند إيقاف شاشة الجهاز. وبالتالي، لا تعمل خدمات HCE عندما تكون الشاشة مُطفأة.

على الإصدار 9 من نظام Android والإصدارات الأقدم، يمكن أن تعمل خدمات HCE من شاشة القفل. في المقابل، تتحكَّم السمة android:requireDeviceUnlock في العلامة <host-apdu-service> في خدمة HCE. بشكلٍ تلقائي، ليس مطلوبًا فتح قفل الجهاز، ويتمّ استدعاء خدمتك حتى إذا كان الجهاز مقفلاً.

في حال ضبط سمة android:requireDeviceUnlock على true لخدمة HCE ، يطلب Android من المستخدم فتح قفل الجهاز عند حدوث ما يلي:

ينقر المستخدم على قارئ NFC.
يختار قارئ NFC معرّف AID الذي يتمّ حلّه لخدمتك.

بعد فتح القفل، يعرض Android مربّع حوار يطلب من المستخدم النقر مرة أخرى لإتمام المعاملة. وهذا أمر ضروري لأن المستخدم ربما أزال الجهاز بعيدًا عن قارئ NFC لإلغاء قفله.

التوافق مع البطاقات التي تتضمّن عنصرًا آمنًا

يهتم هذا القسم بالمطوّرين الذين نشروا تطبيقًا يعتمد على عنصر آمن لمحاكاة البطاقات. تم تصميم عملية تنفيذ تقنية HCE في Android لتعمل بالتوازي مع طرق أخرى لتنفيذ emulatior البطاقة، بما في ذلك استخدام العناصر الآمنة.

يستند هذا التعايش إلى مبدأ يُعرف باسم توجيه AID. تحتفظ وحدة التحكم NFC بجدول توجيه يتكون من قائمة (محدودة) من قواعد التوجيه. تحتوي كل قاعدة توجيه على معرّف AID ووجهة. يمكن أن يكون الوجهة إما وحدة المعالجة المركزية للمضيف، حيث يتم تشغيل تطبيقات Android، أو عنصر آمن مرتبط.

عندما يرسل قارئ NFC معرّف APDU مع SELECT AID، تحلِّله وحدة التحكّم في تقنية NFC وتتحقّق مما إذا كانت هذه البيانات متطابقة مع أي معرّف آخر في جدول التوجيه الخاص به. إذا كانت متطابقة، يتم إرسال APDU هذا وجميع APDU التي تليه إلى الوجهة المرتبطة بمعرّف AID، إلى أن يتم استلام APDU آخر من النوع SELECT AID أو يتم قطع رابط NFC.

يوضّح الشكل 4 هذه البنية:

رسم بياني يعرض قارئ NFC يتواصل مع عنصر آمن ووحدة المعالجة المركزية
الشكل 4. يعمل نظام التشغيل Android مع العناصر الآمنة ومحاكاة البطاقة المضيفة.

يحتوي جهاز التحكّم في NFC عادةً أيضًا على مسار تلقائي لرسائل APDU. عند عدم العثور على ملف IDE في جدول التوجيه، يتم استخدام المسار التلقائي. وعلى الرغم من أنّ هذا الإعداد قد يختلف من جهاز إلى آخر، فإنّه يجب استخدام أجهزة Android للتأكّد من أنّ مؤشرات AID التي يسجّلها تطبيقك يتم توجيهها بشكل صحيح إلى المضيف.

لا داعي للقلق بشأن ضبط جدول التوجيه في تطبيقات Android التي تُنفِّذ خدمة HCE أو التي تستخدِم عنصرًا آمنًا، لأنّه يتم التعامل مع ذلك تلقائيًا من خلال Android. ما على نظام التشغيل Android سوى معرفة معرّفات AID التي يمكن لخدمات HCE التعامل معها ومعرّفات AID التي يمكن للعنصر الآمن التعامل معها. يتم ضبط جدول التوجيه تلقائيًا استنادًا إلى الخدمات المثبَّتة والتي أعدّها المستخدم على أنّها مفضّلة.

يوضّح القسم التالي كيفية الإفصاح عن معرّفات 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>

في ما يلي مثال على ملف apduservice.xml المقابل الذي يسجّل نوعَي تعريف AID:

<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. لا يسمح بيان الخدمة للتطبيقات إلا بتسجيل معرّفات AID المتوفّرة على العنصر الآمن.

وظيفة محاكاة البطاقة المُضيفة (HCE) والأمان

توفّر بنية HCE جزءًا أساسيًا واحدًا من الأمان: بما أنّ خدمتك محمية بإذن نظام BIND_NFC_SERVICE، لا يمكن إلا لنظام التشغيل الربط بالخدمة والتواصل معها. يضمن ذلك أنّ أي APDU تتلقّاها هو في الواقع APDU تلقّاه نظام التشغيل من وحدة تحكّم NFC، وأنّ أي APDU ترسلها مرة أخرى لا تنتقل إلا إلى نظام التشغيل، الذي بدوره يعيد توجيه APDUs مباشرةً إلى وحدة تحكّم NFC.

المشكلة الأخيرة المتبقية هي المكان الذي تحصل فيه على البيانات التي يرسلها تطبيقك إلى قارئ NFC. يتم فصل هذا العنصر عن بعضها عمدًا في تصميم HCE، ولا يهتم بمصدر البيانات، بل يحرص فقط على نقلها بأمان إلى وحدة التحكّم في NFC وإلى قارئ NFC.

لتخزين البيانات التي تريد إرسالها من خدمة HCE بأمان واستردادها، يمكنك مثلاً الاعتماد على "منطقة التطبيق المحمية" في Android، التي تُعزل بيانات تطبيقك عن التطبيقات الأخرى. لمزيد من التفاصيل حول أمان Android، يُرجى الاطّلاع على نصائح حول الأمان.

مَعلمات البروتوكول وتفاصيله

يهمّ هذا القسم المطوِّرين الذين يريدون التعرّف على معلَمات البروتوكولات التي تستخدمها أجهزة HCE أثناء مرحلتي مكافحة الاصطدام والتفعيل لبروتوكولات NFC. يتيح ذلك إنشاء بنية أساسية للقارئين متوافقة مع أجهزة Android HCE.

بروتوكول Nfc-A (المعيار ISO/IEC 14443 من النوع A) لمنع الاصطدام وتفعيل الاتصال

كجزء من تفعيل بروتوكول Nfc-A، يتم تبادل لقطات متعددة.

في الجزء الأول من عملية التبادل، يعرض جهاز HCE معرّف مستخدم فريدًا. ومن المفترض أن يكون لدى أجهزة HCE معرّف مستخدم فريدًا. وهذا يعني أنّه عند كل نقرة، يتم عرض معرّف فريد للجهاز يتم إنشاؤه عشوائيًا للقارئ. ولهذا السبب، ينبغي ألا تعتمد تطبيقات قراءة بطاقات NFC على معرّف المستخدم الفريد لأجهزة HCE كطريقة مصادقة أو إثبات هوية.

يمكن لقارئ NFC بعد ذلك اختيار جهاز HCE من خلال إرسال SEL_REQ command. تتضمّن استجابة SEL_RES لجهاز HCE مجموعة البت السادسة على الأقل (0x20)، ما يشير إلى أنّ الجهاز يتوافق مع ISO-DEP. ويُرجى العِلم أنّه قد يتم أيضًا ضبط وحدات بت أخرى في SEL_RES، ما يشير على سبيل المثال إلى توافق الجهاز مع بروتوكول NFC-DEP (p2p). بما أنّه قد يتم ضبط بتات أخرى، على أدوات القراءة التي تريد التفاعل مع أجهزة HCE التحقّق صراحةً من البت السادس فقط، وعدم مقارنة SEL_RES الكامل بقيمة 0x20.

تفعيل ISO-DEP

بعد تفعيل بروتوكول Nfc-A، يبدأ قارئ NFC في تفعيل بروتوكول ISO-DEP. ويُرسِل الأمر "طلب إجابة لاختيار" (RATS). ينشئ وحدة التحكّم في NFC استجابة RATS، وهي ATS، ولا يمكن لخدمات HCE تعديل ATS. ومع ذلك، يجب أن تستوفي عمليات تنفيذ HCE متطلبات منتدى NFC لردّ ATS، حتى يمكن لأجهزة قراءة NFC الاعتماد على ضبط هذه المَعلمات وفقًا لمتطلبات منتدى NFC لأي جهاز HCE.

يوفّر القسم أدناه مزيدًا من التفاصيل حول البايتات الفردية لردّ ATS الذي يوفّره وحدة التحكّم في NFC على جهاز HCE:

TL: طول ردّ ATS يجب ألا يشير إلى طول أكبر من 20 بايت.
‫T0: يجب ضبط الأرقام الثنائيّة 5 و6 و7 على جميع أجهزة HCE، ما يشير إلى أنّه تم تضمين TA(1) وTB(1) وTC(1) في استجابة ATS. تشير الأرقام الثنائيّة من 1 إلى 4 إلى معرّف FSCI، وهو رمز الحد الأقصى لحجم اللقطة. على أجهزة HCE، يجب أن تكون قيمة FSCI بين 0 و8 ساعات.
‫T(A)1: لتحديد معدلات نقل البيانات بين القارئ والمحاكي، وما إذا كان يمكن أن تكون غير متماثلة. لا تتوفّر متطلبات أو ضمانات لمعدّل نقل البيانات لأجهزة HCE.
‫T(B)1: تشير الأرقام الثنائيّة من 1 إلى 4 إلى عدد صحيح لوقت حماية إطار البدء (SFGI). على أجهزة HCE، يجب أن تكون مدة صلاحية مفتاح الجلسة قصيرة، أي أقل من أو تساوي 8 ساعات. تشير الأرقام الثنائيّة من 5 إلى 8 إلى عدد اللقطات الصحيح لوقت انتظار اللقطة (FWI) وتُشفِّر وقت انتظار اللقطة (FWT). على أجهزة HCE، يجب أن تكون قيمة FWI أقل من أو تساوي 8 ساعات.
‫T(C)1: يشير الرمز 5 إلى توفُّر "ميزات البروتوكول المتقدّمة". قد تتيح أجهزة HCE "ميزات البروتوكول المتقدّمة" أو لا تتيحها. يشير الرقّم الثنائي 2 إلى توفّر ميزة DID. قد تتوافق أجهزة HCE مع ميزة DID أو لا تتوافق معها. يشير العنصر البتي 1 إلى توفُّر ميزة NAD. يجب ألا تتوافق أجهزة HCE مع ميزة "الوصول بدون إنترنت" وأن يتم ضبط القيمة 1 على القيمة 0.
وحدات البايت السابقة: قد تعرض أجهزة HCE ما يصل إلى 15 وحدة بايت سابقة. على تطبيقات قراءة NFC التي تريد التفاعل مع خدمات HCE عدم افتراض أي شيء بشأن محتويات البايتات السابقة أو وجودها.

يُرجى العِلم أنّه من المرجّح أن تكون العديد من أجهزة HCE متوافقة مع متطلبات البروتوكول التي حدّدتها شبكات الدفع المتحدة في EMVCo في مواصفات "بروتوكول التواصل بدون تلامس الأجهزة". ويشمل ذلك على وجه الخصوص:

يجب أن تتراوح فترة FSCI في T0 بين ساعتَين و8 ساعات.
يجب ضبط T(A)1 على 0x80، ما يشير إلى أنّ معدل نقل البيانات 106 كيلوبت في الثانية هو فقط متوافق، ولا يمكن استخدام معدلات نقل البيانات غير المتماثلة بين القارئ والمحاكي.
يجب أن تكون مدة FWI في T(B)1 أقل من أو تساوي 7 ساعات.

تبادل بيانات APDU

كما أشرنا سابقًا، لا تتيح عمليات تنفيذ وظيفة HCE إلا قناة منطقية واحدة. لن تنجح محاولة اختيار تطبيقات على قنوات منطقية مختلفة على جهاز HCE.