Erstellen einer NFC-Smartcard-App
Wichtig
Dieses Thema gilt nur für Windows 10 Mobile.
In diesem Thema wird beschrieben, wie Sie die Host Card Emulation (HCE) verwenden, um direkt mit einem NFC-Kartenlesegerät (Near Field Communication) zu kommunizieren und Ihren Kunden den Zugang zu Ihren Diensten über ihr Telefon (anstelle einer physischen Karte) zu ermöglichen, ohne dass sie einen Mobilfunknetzbetreiber (MNO) benötigen.
Was Sie für die Entwicklung einer HCE-Anwendung benötigen
Um eine HCE-basierte Kartenemulations-App zu entwickeln, müssen Sie Microsoft Visual Studio 2015 (siehe Visual Studio Download-Seite) (einschließlich der Windows-Entwickler-Tools) und den Windows 10 Mobile-Emulator installieren.
Weitere Informationen zur Einrichtung finden Sie unter Test mit dem Microsoft Emulator für Windows 10 Mobile.
Wenn Sie mit einem echten Windows 10 Mobile-Gerät anstelle des mitgelieferten Windows 10 Mobile-Emulators testen möchten, benötigen Sie zusätzlich die folgenden Elemente.
- Ein Windows 10 Mobile-Gerät mit NFC HCE-Unterstützung.
- Ein Leseterminal, das die Protokolle ISO/IEC 14443-4 und ISO/IEC 7816-4 unterstützt
Windows 10 Mobile implementiert einen HCE-Dienst, der die folgenden Funktionalitäten bietet.
- Apps können die Applet Identifier (AIDs) für die Karten registrieren, die sie emulieren möchten.
- Konfliktlösung und Weiterleitung der APDU-Befehls- und Antwortpaare (Application Protocol Data Unit) an eine der registrierten Anwendungen auf der Grundlage der Auswahl der externen Lesekarte und der Benutzerpräferenz.
- Behandlung von Ereignissen und Benachrichtigungen an die Anwendungen als Folge von Benutzeraktionen.
Windows 10 unterstützt die Emulation von Smartcards, die auf ISO-DEP (ISO-IEC 14443-4) basieren und über APDUs kommunizieren, wie in der ISO-IEC 7816-4-Spezifikation definiert. Windows 10 unterstützt die ISO/IEC 14443-4 Typ A-Technologie für HCE-Anwendungen. Typ B, Typ F und Nicht-ISO-DEP-Technologien (z. B. MIFARE) werden standardmäßig an die SIM-Karte weitergeleitet.
Nur Windows 10 Mobile-Geräte verfügen über die Kartenemulationsfunktion. Die SIM- und HCE-basierte Kartenemulation ist in anderen Versionen von Windows 10 nicht verfügbar.
Die Architektur für die Unterstützung von HCE- und SIM-basierter Kartenemulation ist im folgenden Diagramm dargestellt.
App-Auswahl und AID-Routing
Um eine HCE-App zu entwickeln, müssen Sie verstehen, wie Windows 10 Mobile-Geräte AIDs an eine bestimmte App weiterleiten, da Benutzer mehrere verschiedene HCE-Apps installieren können. Jede App kann mehrere HCE- und SIM-basierte Karten registrieren.
Wenn der Benutzer sein Windows 10 Mobile-Gerät an ein Terminal anschließt, werden die Daten automatisch an die entsprechende auf dem Gerät installierte App weitergeleitet. Dieses Routing basiert auf der Applet-ID (AID), einer 5-16 Byte langen Kennung. Während einer Anzapfung sendet das externe Terminal ein SELECT-Befehls-APDU, um die AID anzugeben, an die alle nachfolgenden APDU-Befehle weitergeleitet werden sollen. Nachfolgende SELECT-Befehle ändern das Routing erneut. Auf der Grundlage der von den Anwendungen registrierten AIDs und der Benutzereinstellungen wird der APDU-Verkehr an eine bestimmte Anwendung weitergeleitet, die dann eine Antwort-APDU sendet. Beachten Sie, dass ein Endgerät möglicherweise mit mehreren verschiedenen Anwendungen während desselben Abgriffs kommunizieren möchte. Sie müssen also sicherstellen, dass die Hintergrundaufgabe Ihrer Anwendung so schnell wie möglich beendet wird, wenn sie deaktiviert wird, um Platz für die Hintergrundaufgabe einer anderen Anwendung zu schaffen, die auf die APDU reagieren kann. Wir werden später in diesem Thema auf Hintergrundaufgaben eingehen.
HCE-Anwendungen müssen sich bei bestimmten AIDs, die sie verarbeiten können, registrieren, damit sie APDUs für eine AID empfangen können. Apps deklarieren AIDs mit Hilfe von AID-Gruppen. Eine AID-Gruppe ist konzeptionell gleichwertig mit einer einzelnen physischen Karte. So wird beispielsweise eine Kreditkarte mit einer AID-Gruppe und eine zweite Kreditkarte einer anderen Bank mit einer anderen, zweiten AID-Gruppe angegeben, obwohl beide dieselbe AID haben können.
Konfliktlösung für AID-Zahlungsgruppen
Wenn eine App physische Karten (AID-Gruppen) registriert, kann sie die AID-Gruppen-Kategorie entweder als „Zahlung" oder "Sonstige“ deklarieren Es können zwar mehrere AID-Zahlungsgruppen zu einem bestimmten Zeitpunkt registriert werden, aber es kann jeweils nur eine dieser AID-Zahlungsgruppen für Tap and Pay aktiviert werden, die vom Benutzer ausgewählt wird. Dieses Verhalten besteht, weil der Benutzer erwartet, dass er sich bewusst für eine einzige Zahlungs-, Kredit- oder Debitkarte entscheidet, damit er nicht mit einer anderen Karte bezahlt, wenn er sein Gerät an ein Terminal hält.
Es können jedoch mehrere als „Sonstige“ registrierte AID-Gruppen gleichzeitig aktiviert werden, ohne dass der Benutzer eingreifen muss. Dieses Verhalten ist darauf zurückzuführen, dass von anderen Kartenarten wie Treuekarten, Coupons oder Transitkarten erwartet wird, dass sie einfach funktionieren, ohne dass der Benutzer etwas dafür tun muss oder dazu aufgefordert wird, wenn er sein Telefon antippt.
Alle AID-Gruppen, die als „Zahlung“ registriert sind, erscheinen in der Liste der Karten auf der Seite NFC-Einstellungen, wo der Benutzer seine Standardzahlungskarte auswählen kann. Wenn eine Standard-Zahlungskarte ausgewählt wird, wird die App, die diese Zahlungs-AID-Gruppe registriert hat, zur Standard-Zahlungs-App. Standardmäßige Zahlungsanwendungen können jede ihrer AID-Gruppen ohne Benutzerinteraktion aktivieren oder deaktivieren. Wenn der Benutzer die Aufforderung zur Standard-Zahlungsanwendung ablehnt, bleibt die aktuelle Standard-Zahlungsanwendung (falls vorhanden) als Standard erhalten. Der folgende Screenshot zeigt die Seite NFC-Einstellungen.
Wenn der Benutzer seine Standard-Zahlungskarte in eine andere Karte ändert, die nicht von „HCE-Anwendung 1“ registriert ist, erstellt das System eine Bestätigungsaufforderung für die Zustimmung des Benutzers. Ändert der Benutzer jedoch seine Standardzahlungskarte in eine andere Karte, die von „HCE-Anwendung 1" registriert wird, erstellt das System keine Bestätigungsaufforderung für den Benutzer, da "HCE-Anwendung 1“ bereits die Standardzahlungsanwendung ist.
Konfliktlösung für nicht zahlende AID-Gruppen
Karten, die nicht als „Sonstige“ kategorisiert sind, erscheinen nicht auf der NFC-Einstellungsseite.
Ihre Anwendung kann AID-Gruppen für Nicht-Zahlungen auf dieselbe Weise erstellen, registrieren und aktivieren wie AID-Gruppen für Zahlungen. Der Hauptunterschied besteht darin, dass für AID-Gruppen ohne Zahlung die Emulationskategorie auf „Sonstige" und nicht auf "Zahlung“ gesetzt wird. Nachdem Sie die AID-Gruppe im System registriert haben, müssen Sie die AID-Gruppe für den Empfang von NFC-Datenverkehr aktivieren. Wenn Sie versuchen, eine Nicht-Zahlungs-AID-Gruppe für den Empfang von Datenverkehr zu aktivieren, wird der Benutzer nicht zu einer Bestätigung aufgefordert, es sei denn, es besteht ein Konflikt mit einer der AIDs, die bereits von einer anderen Anwendung im System registriert wurden. Im Falle eines Konflikts wird der Benutzer darüber informiert, welche Karte und die zugehörige Anwendung deaktiviert werden, wenn der Benutzer die neu registrierte AID-Gruppe aktiviert.
Koexistenz mit SIM-basierten NFC-Anwendungen
In Windows 10 Mobile richtet das System die NFC-Controller-Routing-Tabelle ein, die verwendet wird, um Routing-Entscheidungen auf der Controller-Ebene zu treffen. Die Tabelle enthält Routing-Informationen für die folgenden Elemente.
- Einzelne AID-Routen.
- Protokollbasierte Route (ISO-DEP).
- Technologiebasiertes Routing (NFC-A/B/F).
Wenn ein externer Leser einen „SELECT AID“-Befehl sendet, prüft der NFC-Controller zunächst die AID-Routen in der Routing-Tabelle auf Übereinstimmung. Gibt es keine Übereinstimmung, wird die protokollbasierte Route als Standardroute für den ISO-DEP (14443-4-A) Verkehr verwendet. Für jeden anderen Nicht-ISO-DEP-Verkehr wird das technologiebasierte Routing verwendet.
Windows 10 Mobile bietet eine Menüoption „SIM-Karte“ auf der NFC-Einstellungsseite, um ältere Windows Phone 8.1 SIM-basierte Apps, die ihre AIDs nicht im System registrieren, weiterhin nutzen zu können. Wenn der Benutzer „SIM-Karte“ als Standard-Zahlungskarte auswählt, wird die ISO-DEP-Route auf UICC gesetzt, bei allen anderen Auswahlen im Dropdown-Menü geht die ISO-DEP-Route zum Host.
Die ISO-DEP-Route ist für Geräte mit einer SE-fähigen SIM-Karte auf „SIM-Karte“ eingestellt, wenn das Gerät zum ersten Mal mit Windows 10 Mobile gestartet wird. Wenn der Benutzer eine HCE-fähige Anwendung installiert und diese Anwendung eine HCE-AID-Gruppenregistrierung aktiviert, wird die ISO-DEP-Route auf den Host verwiesen. Neue SIM-basierte Anwendungen müssen die AIDs in der SIM registrieren, damit die spezifischen AID-Routen in die Routing-Tabelle des Controllers eingetragen werden können.
Erstellen einer HCE-basierten Anwendung
Ihre HCE-Anwendung besteht aus zwei Teilen.
- Die Hauptanwendung für die Benutzerinteraktion im Vordergrund.
- Eine Hintergrundaufgabe, die vom System ausgelöst wird, um APDUs für eine bestimmte AID zu verarbeiten.
Aufgrund der extrem hohen Leistungsanforderungen für das Laden Ihrer Hintergrundaufgabe als Reaktion auf einen NFC-Tap empfehlen wir, dass Ihre gesamte Hintergrundaufgabe in nativem C++/CX-Code (einschließlich aller Abhängigkeiten, Referenzen oder Bibliotheken, von denen Sie abhängig sind) und nicht in C# oder verwaltetem Code implementiert wird. Während C# und verwalteter Code normalerweise gut funktionieren, gibt es Overhead, wie das Laden der .NET CLR, der durch das Schreiben in C++/CX vermieden werden kann.
Erstellen und registrieren Sie Ihre Hintergrundaufgabe
Sie müssen in Ihrer HCE-Anwendung eine Hintergrundaufgabe erstellen, um APDUs, die vom System an sie weitergeleitet werden, zu verarbeiten und darauf zu reagieren. Wenn Ihre Anwendung zum ersten Mal gestartet wird, registriert der Vordergrund eine HCE-Hintergrundaufgabe, die die Schnittstelle IBackgroundTaskRegistration implementiert, wie im folgenden Code gezeigt.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();
Beachten Sie, dass der Aufgabenauslöser auf SmartCardTriggerType eingestellt ist. EmulatorHostApplicationActivated. Das bedeutet, dass immer dann, wenn das Betriebssystem eine SELECT AID-Befehls-APDU empfängt, die Ihre Anwendung auflöst, Ihre Hintergrundaufgabe gestartet wird.
Empfang und Beantwortung von APDUs
Wenn es eine APDU für Ihre Anwendung gibt, wird das System Ihre Hintergrundaufgabe starten. Ihre Hintergrundaufgabe empfängt die APDU, die über die Eigenschaft CommandApdu des Objekts SmartCardEmulatorApduReceivedEventArgs übergeben wurde, und antwortet auf die APDU mit der Methode TryRespondAsync desselben Objekts. Ziehen Sie in Erwägung, Ihre Hintergrundaufgabe aus Leistungsgründen auf leichte Operationen zu beschränken. Reagieren Sie z. B. sofort auf die APDUs und beenden Sie Ihre Hintergrundaufgabe, wenn die Verarbeitung abgeschlossen ist. Es liegt in der Natur von NFC-Transaktionen, dass die Benutzer ihr Gerät nur für eine sehr kurze Zeit an das Lesegerät halten. Ihre Hintergrundaufgabe wird weiterhin Datenverkehr vom Lesegerät empfangen, bis Ihre Verbindung deaktiviert wird. In diesem Fall erhalten Sie ein SmartCardEmulatorConnectionDeactivatedEventArgs-Objekt. Ihre Verbindung kann aus den folgenden Gründen deaktiviert werden, die in der Eigenschaft SmartCardEmulatorConnectionDeactivatedEventArgs.Reason angegeben sind.
- Wenn die Verbindung mit dem Wert ConnectionLost deaktiviert wird, bedeutet dies, dass der Benutzer sein Gerät vom Lesegerät entfernt hat. Wenn Ihre App den Benutzer dazu zwingt, länger auf das Terminal zu tippen, sollten Sie in Erwägung ziehen, ihn mit einer Rückmeldung aufzufordern. Sie sollten Ihre Hintergrundaufgabe schnell beenden (indem Sie die Aufschiebung abschließen), um sicherzustellen, dass bei einem erneuten Tippen nicht auf das Ende der vorherigen Hintergrundaufgabe gewartet wird.
- Wenn die Verbindung mit ConnectionRedirected deaktiviert wird, bedeutet dies, dass das Terminal eine neue SELECT AID command APDU an eine andere AID gesendet hat. In diesem Fall sollte Ihre Anwendung die Hintergrundaufgabe sofort beenden (indem Sie die Aufschiebung abschließen), damit eine andere Hintergrundaufgabe ausgeführt werden kann.
Die Hintergrundaufgabe sollte sich auch für das Canceled-Ereignis auf der IBackgroundTaskInstance-Schnittstelle registrieren und die Hintergrundaufgabe ebenfalls schnell beenden (indem Sie Ihre Aufschiebung abschließen), da dieses Ereignis vom System ausgelöst wird, wenn es mit Ihrer Hintergrundaufgabe fertig ist. Nachstehend finden Sie einen Code, der eine HCE-Hintergrundaufgabe veranschaulicht.
void BgTask::Run(
IBackgroundTaskInstance^ taskInstance)
{
m_triggerDetails = static_cast<SmartCardTriggerDetails^>(taskInstance->TriggerDetails);
if (m_triggerDetails == nullptr)
{
// May be not a smart card event that triggered us
return;
}
m_emulator = m_triggerDetails->Emulator;
m_taskInstance = taskInstance;
switch (m_triggerDetails->TriggerType)
{
case SmartCardTriggerType::EmulatorHostApplicationActivated:
HandleHceActivation();
break;
case SmartCardTriggerType::EmulatorAppletIdGroupRegistrationChanged:
HandleRegistrationChange();
break;
default:
break;
}
}
void BgTask::HandleHceActivation()
{
try
{
auto lock = m_srwLock.LockShared();
// Take a deferral to keep this background task alive even after this "Run" method returns
// You must complete this deferal immediately after you have done processing the current transaction
m_deferral = m_taskInstance->GetDeferral();
DebugLog(L"*** HCE Activation Background Task Started ***");
// Set up a handler for if the background task is cancelled, we must immediately complete our deferral
m_taskInstance->Canceled += ref new Windows::ApplicationModel::Background::BackgroundTaskCanceledEventHandler(
[this](
IBackgroundTaskInstance^ sender,
BackgroundTaskCancellationReason reason)
{
DebugLog(L"Cancelled");
DebugLog(reason.ToString()->Data());
EndTask();
});
if (Windows::Phone::System::SystemProtection::ScreenLocked)
{
auto denyIfLocked = Windows::Storage::ApplicationData::Current->RoamingSettings->Values->Lookup("DenyIfPhoneLocked");
if (denyIfLocked != nullptr && (bool)denyIfLocked == true)
{
// The phone is locked, and our current user setting is to deny transactions while locked so let the user know
// Denied
DoLaunch(Denied, L"Phone was locked at the time of tap");
// We still need to respond to APDUs in a timely manner, even though we will just return failure
m_fDenyTransactions = true;
}
}
else
{
m_fDenyTransactions = false;
}
m_emulator->ApduReceived += ref new TypedEventHandler<SmartCardEmulator^, SmartCardEmulatorApduReceivedEventArgs^>(
this, &BgTask::ApduReceived);
m_emulator->ConnectionDeactivated += ref new TypedEventHandler<SmartCardEmulator^, SmartCardEmulatorConnectionDeactivatedEventArgs^>(
[this](
SmartCardEmulator^ emulator,
SmartCardEmulatorConnectionDeactivatedEventArgs^ eventArgs)
{
DebugLog(L"Connection deactivated");
EndTask();
});
m_emulator->Start();
DebugLog(L"Emulator started");
}
catch (Exception^ e)
{
DebugLog(("Exception in Run: " + e->ToString())->Data());
EndTask();
}
}
AID-Gruppen erstellen und registrieren
Beim ersten Start Ihrer Anwendung, wenn die Karte bereitgestellt wird, erstellen und registrieren Sie AID-Gruppen im System. Das System bestimmt die App, mit der ein externes Lesegerät kommunizieren möchte, und leitet APDUs entsprechend auf der Grundlage der registrierten AIDs und Benutzereinstellungen weiter.
Die meisten Zahlungskarten registrieren sich für dieselbe AID, Proximity Payment System Environment (PPSE), zusammen mit zusätzlichen, für die Karten des Zahlungsnetzes spezifischen AIDs. Jede AID-Gruppe steht für eine Karte, und wenn der Benutzer die Karte aktiviert, werden alle AIDs in der Gruppe aktiviert. Wenn der Benutzer die Karte deaktiviert, werden auch alle AIDs in der Gruppe deaktiviert.
Um eine AID-Gruppe zu registrieren, müssen Sie ein SmartCardAppletIdGroup-Objekt erstellen und seine Eigenschaften so einstellen, dass sie widerspiegeln, dass es sich um eine HCE-basierte Zahlungskarte handelt. Ihr Anzeigename sollte für den Benutzer aussagekräftig sein, da er im NFC-Einstellungsmenü und in den Benutzeraufforderungen angezeigt wird. Für HCE-Zahlungskarten sollte die Eigenschaft SmartCardEmulationCategory auf Payment und die Eigenschaft SmartCardEmulationType auf Host gesetzt werden.
public static byte[] AID_PPSE =
{
// File name "2PAY.SYS.DDF01" (14 bytes)
(byte)'2', (byte)'P', (byte)'A', (byte)'Y',
(byte)'.', (byte)'S', (byte)'Y', (byte)'S',
(byte)'.', (byte)'D', (byte)'D', (byte)'F', (byte)'0', (byte)'1'
};
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Host);
Für HCE-Karten ohne Bezahlfunktion sollte die Eigenschaft SmartCardEmulationCategory auf Other und die Eigenschaft SmartCardEmulationType auf Host gesetzt werden.
public static byte[] AID_OTHER =
{
(byte)'1', (byte)'2', (byte)'3', (byte)'4',
(byte)'5', (byte)'6', (byte)'7', (byte)'8',
(byte)'O', (byte)'T', (byte)'H', (byte)'E', (byte)'R'
};
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_OTHER.AsBuffer()},
SmartCardEmulationCategory.Other,
SmartCardEmulationType.Host);
Sie können bis zu 9 AIDs (mit einer Länge von jeweils 5-16 Bytes) pro AID-Gruppe aufnehmen.
Verwenden Sie die Methode RegisterAppletIdGroupAsync, um Ihre AID-Gruppe beim System zu registrieren, das ein SmartCardAppletIdGroupRegistration-Objekt zurückgibt. Standardmäßig ist die Eigenschaft ActivationPolicy des Registrierungsobjekts auf Disabled eingestellt. Das bedeutet, dass Ihre AIDs zwar im System registriert sind, aber noch nicht aktiviert sind und keinen Datenverkehr empfangen können.
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
Sie können Ihre registrierten Karten (AID-Gruppen) aktivieren, indem Sie die Methode RequestActivationPolicyChangeAsync der KlasseSmartCardAppletIdGroupRegistration wie unten dargestellt verwenden. Da im System immer nur eine einzige Zahlungskarte aktiviert werden kann, ist das Einstellen der ActivationPolicy einer Zahlungs-AID-Gruppe auf Enabled dasselbe wie das Einstellen der Standardzahlungskarte. Der Benutzer wird aufgefordert, diese Karte als Standardzahlungskarte zuzulassen, unabhängig davon, ob bereits eine Standardzahlungskarte ausgewählt ist oder nicht. Diese Aussage trifft nicht zu, wenn Ihre Anwendung bereits die Standardzahlungsanwendung ist und lediglich zwischen ihren eigenen AID-Gruppen wechselt. Sie können bis zu 10 AID-Gruppen pro Anwendung registrieren.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);
Mit der Methode GetAppletIdGroupRegistrationsAsync können Sie die registrierten AID-Gruppen Ihrer App beim Betriebssystem abfragen und ihre Aktivierungsrichtlinie überprüfen.
Wenn Sie die Aktivierungsrichtlinie einer Zahlungskarte von Deaktiviert in Aktiviert ändern, werden die Benutzer nur dann dazu aufgefordert, wenn Ihre App nicht bereits die Standard-Zahlungs-App ist. Benutzer werden nur aufgefordert, wenn Sie die Aktivierungsrichtlinie einer Nichtzahlungskarte von Deaktiviert in Aktiviert ändern, wenn ein AID-Konflikt besteht.
var registrations = await SmartCardEmulator.GetAppletIdGroupRegistrationsAsync();
foreach (var registration in registrations)
{
registration.RequestActivationPolicyChangeAsync (AppletIdGroupActivationPolicy.Enabled);
}
Ereignisbenachrichtigung bei Änderung der Aktivierungsrichtlinie
In Ihrer Hintergrundaufgabe können Sie sich registrieren, um Ereignisse zu empfangen, wenn sich die Aktivierungsrichtlinie einer Ihrer AID-Gruppenregistrierungen außerhalb Ihrer Anwendung ändert. So kann der Benutzer beispielsweise über das NFC-Einstellungsmenü die Standard-Zahlungsanwendung von einer Ihrer Karten auf eine andere Karte ändern, die von einer anderen Anwendung bereitgestellt wird. Wenn Ihre Anwendung über diese Änderung für die interne Einrichtung, z. B. die Aktualisierung von Live-Kacheln, informiert werden muss, können Sie Ereignisbenachrichtigungen für diese Änderung empfangen und in Ihrer Anwendung entsprechende Maßnahmen ergreifen.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();
Verhalten bei Überlagerung des Vordergrunds
Sie können die ActivationPolicy jeder Ihrer AID-Gruppenregistrierungen in ForegroundOverride ändern, während sich Ihre Anwendung im Vordergrund befindet, ohne den Benutzer aufzufordern. Wenn der Benutzer sein Gerät an ein Terminal hält, während Ihre App im Vordergrund ist, wird der Datenverkehr an Ihre App weitergeleitet, auch wenn der Benutzer keine Ihrer Zahlungskarten als Standardzahlungskarte ausgewählt hat. Wenn Sie die Aktivierungsrichtlinie einer Karte in ForegroundOverride ändern, ist diese Änderung nur vorübergehend, bis Ihre Anwendung den Vordergrund verlässt, und sie ändert nicht die aktuelle Standardzahlungskarte, die vom Benutzer festgelegt wurde. Sie können die ActivationPolicy Ihrer Zahlungs- oder Nichtzahlungskarten von Ihrer Vordergrund-App aus wie folgt ändern. Beachten Sie, dass die Methode RequestActivationPolicyChangeAsync nur von einer Vordergrund-App aufgerufen werden kann und nicht von einer Hintergrundaufgabe.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);
Sie können auch eine AID-Gruppe registrieren, die aus einer einzigen AID der Länge 0 besteht, die das System veranlasst, alle APDUs unabhängig von der AID weiterzuleiten, einschließlich aller Befehls-APDUs, die vor dem Empfang eines SELECT AID-Befehls gesendet wurden. Eine solche AID-Gruppe funktioniert jedoch nur, während sich Ihre Anwendung im Vordergrund befindet, da sie nur auf ForegroundOverride gesetzt werden kann und nicht dauerhaft aktiviert werden kann. Außerdem funktioniert dieser Mechanismus sowohl für Host als auch für UICC Werte der SmartCardEmulationType Aufzählung, um den gesamten Datenverkehr entweder an Ihre HCE-Hintergrundaufgabe oder an die SIM-Karte zu leiten.
public static byte[] AID_Foreground =
{};
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_Foreground.AsBuffer()},
SmartCardEmulationCategory.Other,
SmartCardEmulationType.Host);
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);
Prüfen Sie auf NFC- und HCE-Unterstützung
Ihre App sollte prüfen, ob ein Gerät über NFC-Hardware verfügt, die Kartenemulationsfunktion unterstützt und die Host-Kartenemulation unterstützt, bevor sie dem Benutzer diese Funktionen anbietet.
Die NFC-Smartcard-Emulationsfunktion ist nur in Windows 10 Mobile aktiviert. Der Versuch, die Smartcard-Emulator-APIs in anderen Versionen von Windows 10 zu verwenden, führt zu Fehlern. Im folgenden Codeausschnitt können Sie prüfen, ob die Smartcard-API unterstützt wird.
Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");
Sie können zusätzlich prüfen, ob das Gerät über NFC-Hardware verfügt, die eine Form der Kartenemulation unterstützt, indem Sie prüfen, ob die Methode SmartCardEmulator.GetDefaultAsync null zurückgibt. Wenn dies der Fall ist, wird die NFC-Kartenemulation von dem Gerät nicht unterstützt.
var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<
Die Unterstützung für HCE und AID-basiertes UICC-Routing ist nur auf kürzlich eingeführten Geräten wie dem Lumia 730, 830, 640 und 640 XL verfügbar. Alle neuen NFC-fähigen Geräte mit Windows 10 Mobile und höher sollten HCE unterstützen. Ihre Anwendung kann wie folgt auf HCE-Unterstützung prüfen.
Smartcardemulator.IsHostCardEmulationSupported();
Verhalten beim Sperren und Ausschalten des Bildschirms
Windows 10 Mobile verfügt über Kartenemulationseinstellungen auf Geräteebene, die vom Mobilfunkbetreiber oder dem Hersteller des Geräts festgelegt werden können. Standardmäßig ist die Umschaltfunktion „Tap to Pay" deaktiviert und die "Aktivierungsrichtlinie auf Geräteebene" ist auf "Immer“ eingestellt, es sei denn, der Mobilfunkbetreiber oder OEM überschreibt diese Werte.
Ihre Anwendung kann den Wert der EnablementPolicy auf Geräteebene abfragen und für jeden Fall Maßnahmen ergreifen, die vom gewünschten Verhalten Ihrer Anwendung in jedem Zustand abhängen.
SmartCardEmulator emulator = await SmartCardEmulator.GetDefaultAsync();
switch (emulator.EnablementPolicy)
{
case Never:
// you can take the user to the NFC settings to turn "tap and pay" on
await Windows.System.Launcher.LaunchUriAsync(new Uri("ms-settings-nfctransactions:"));
break;
case Always:
return "Card emulation always on";
case ScreenOn:
return "Card emulation on only when screen is on";
case ScreenUnlocked:
return "Card emulation on only when screen unlocked";
}
Die Hintergrundaufgabe Ihrer App wird auch bei gesperrtem Telefon und/oder ausgeschaltetem Bildschirm nur dann gestartet, wenn der externe Leser eine AID auswählt, die zu Ihrer App passt. Sie können auf die Befehle des Lesers in Ihrer Hintergrundaufgabe reagieren, aber wenn Sie eine Eingabe vom Benutzer benötigen oder dem Benutzer eine Nachricht anzeigen möchten, können Sie Ihre Vordergrundanwendung mit einigen Argumenten starten. Ihre Hintergrundaufgabe kann Ihre Vordergrundanwendung mit dem folgenden Verhalten starten.
- Unter dem Sperrbildschirm des Geräts (der Benutzer sieht Ihre Vordergrund-App erst, nachdem er das Gerät entsperrt hat)
- Über dem Sperrbildschirm des Geräts (nachdem der Benutzer Ihre Anwendung beendet hat, ist das Gerät immer noch gesperrt)
if (Windows::Phone::System::SystemProtection::ScreenLocked)
{
// Launch above the lock with some arguments
var result = await eventDetails.TryLaunchSelfAsync("app-specific arguments", SmartCardLaunchBehavior.AboveLock);
}
AID-Registrierung und andere Updates für SIM-basierte Anwendungen
Kartenemulationsanwendungen, die die SIM-Karte als sicheres Element verwenden, können sich beim Windows-Dienst registrieren, um die auf der SIM-Karte unterstützten AIDs zu deklarieren. Diese Registrierung ist einer HCE-basierten App-Registrierung sehr ähnlich. Der einzige Unterschied ist der SmartCardEmulationType, der für SIM-basierte Anwendungen auf Uicc gesetzt werden sollte. Als Ergebnis der Registrierung der Zahlungskarte wird der Anzeigename der Karte auch im NFC-Einstellungsmenü angezeigt.
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Uicc);
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für