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

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

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

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

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

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

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

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

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

الشكل 2: محاكاة بطاقة NFC بدون عنصر آمن

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

الشكل 3. حِزمة بروتوكول HCE في Android

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

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

على وجه التحديد، يتيح الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث محاكاة البطاقات التي تستند إلى مواصفة ISO-DEP الخاصة بمنتدى NFC (استنادًا إلى ISO/IEC 14443-4) ومعالجة وحدات بيانات بروتوكول التطبيقات (APDU) على النحو المحدّد في مواصفة 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. بالنسبة إلى جميع معرّفات AID في مجموعة معرّفات AID، يضمن Android إجراءً واحدًا مما يلي:

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

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

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

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

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

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

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

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

التحقّق من توفّر ميزة "محاكاة البطاقة المُضيفة"

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

تنفيذ الخدمة

يوفّر الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث فئة 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 للرد.

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

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

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

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

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

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

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

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

1. لإعلام النظام الأساسي بأنّها خدمة HCE تنفِّذ واجهة HostApduService، أضِف فلتر أهداف للإجراء SERVICE_INTERFACE إلى بيان الخدمة.

2. لإعلام المنصة بمجموعات معرّفات AID التي تطلبها هذه الخدمة، أدرِج علامة SERVICE_META_DATA <meta-data> في بيان الخدمة، مع الإشارة إلى مصدر XML يحتوي على معلومات إضافية عن خدمة HCE.

3. اضبط سمة 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 بالتنسيق السداسي عشري، وتأكَّد من أنّه يحتوي على عددٍ زوجي من الأحرف.

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

حلّ النزاعات في AID

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

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

الإعدادات المفضّلة للخدمة التي تعمل في المقدّمة

يمكن للتطبيقات التي تعمل في المقدّمة استدعاء setPreferredService لتحديد خدمة محاكاة البطاقات التي يجب تفضيلها عندما يكون أحد الأنشطة معيّنًا في المقدّمة. تلغي الإعدادات المفضّلة للتطبيق الذي يعمل في المقدّمة حلّ تعارض AID. يُنصح باتّباع هذه الممارسة عندما يتوقّع التطبيق أنّ المستخدم قد يستخدم محاكاة بطاقة NFC.

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

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

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

اضبط حجم بانر الخدمة على 260x96 dp، ثم اضبط حجم بانر الخدمة في ملف 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>

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

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

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

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

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

مواد العرض المطلوبة لتطبيقات المحفظة

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

الإعدادات المفضّلة للخدمة التي تعمل في المقدّمة

يمكن للتطبيقات التي تعمل في المقدّمة استدعاء setPreferredService لتحديد خدمة محاكاة البطاقات التي يجب تفضيلها عندما يكون أحد الأنشطة معيّنًا في المقدّمة. تلغي الإعدادات المفضّلة للتطبيق الذي يعمل في المقدّمة حالة وضع "المراقبة" للجهاز التي تتوافق مع قيمة shouldDefaultToObserveMode لخدمة معيّنة، ويمكن ضبطها بطريقتَين من الطريقتَين التاليتَين:

• ضبط حالة shouldDefaultToObserveMode في ملف البيان لتلك الخدمة
• استدعاء CardEmulation.setShouldDefaultToObserveModeForService() مع الخدمة والحالة المعنيّتَين

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

يختلف سلوك خدمات HCE حسب إصدار Android الذي يعمل عليه الجهاز.

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

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

ننصح المطوّرين بالعمل مع أجهزة القراءة لإصدار نماذج قابلة للتحديد لحلقة الاستطلاع والتسجيل للتعامل مع هذه الأشكال من تطبيقاتهم.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الشكل 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.