Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
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-Kartenleser (Near Field Communication) zu kommunizieren und Ihren Kunden den Zugriff auf Ihre Dienste über ihr Telefon (anstelle einer physischen Karte) ohne einen Mobilfunkanbieter (MNO) zu ermöglichen.
Was Sie zum Entwickeln einer HCE-App benötigen
Um eine HCE-basierte Kartenemulations-App zu entwickeln, müssen Sie Microsoft Visual Studio 2015 installieren (siehe Die Visual Studio-Downloadseite) (enthält die Windows-Entwicklertools) und den Windows 10 Mobile-Emulator.
Weitere Informationen zur Einrichtung finden Sie unter Test mit dem Microsoft Emulator für Windows 10 Mobile.
Wenn Sie optional ein echtes Windows 10 Mobile-Gerät anstelle des enthaltenen Windows 10 Mobile-Emulators testen möchten, benötigen Sie auch die folgenden Elemente.
- Ein Windows 10 Mobile-Gerät mit NFC HCE-Unterstützung.
- Ein Leseterminal, das protokolle ISO/IEC 14443-4 und ISO/IEC 7816-4 unterstützt
Windows 10 Mobile implementiert einen HCE-Dienst, der die folgenden Funktionen bereitstellt.
- Apps können die Applet-IDs (AIDs) für die Karten registrieren, die sie emulieren möchten.
- Konfliktlösung und Routing von APDU-Befehls- und Antwortpaaren (Application Protocol Data Unit) zu einer der registrierten Apps basierend auf der Auswahl eines externen Kartenlesegeräts und der Benutzervorliebe.
- Verarbeitung von Ereignissen und Benachrichtigungen an die Apps als Ergebnis von Benutzereingaben.
Windows 10 unterstützt die Emulation von Smartcards, die auf ISO-DEP (ISO-IEC 14443-4) basieren und mit APDUs kommunizieren, wie in der ISO-IEC 7816-4-Spezifikation definiert. Windows 10 unterstützt ISO/IEC 14443-4 Type A-Technologie für HCE-Apps. Typ B, Typ F und Nicht-ISO-DEP (z. B. MIFARE)-Technologien werden standardmäßig an die SIM-Karte weitergeleitet.
Nur Windows 10 Mobile-Geräte sind mit dem Kartenemulationsfeature aktiviert. SIM-basierte und HCE-basierte Kartenemulation ist in anderen Versionen von Windows 10 nicht verfügbar.
Die Architektur für hcE- und SIM-basierte Kartenemulationsunterstützung wird 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 hält, werden die Daten automatisch an die richtige, auf dem Gerät installierte App weitergeleitet. Dieses Routing basiert auf der Applet-ID (AID), bei der es sich um einen 5-16 Bytebezeichner handelt. Während eines Tippens überträgt das externe Terminal eine SELECT-Befehls-APDU, um die AID anzugeben, an die alle nachfolgenden APDU-Befehle weitergeleitet werden sollen. Nachfolgende SELECT-Befehle ändern das Routing erneut. Basierend auf den von Apps und Benutzereinstellungen registrierten AIDs wird der APDU-Datenverkehr an eine bestimmte App weitergeleitet, die eine Antwort-APDU sendet. Beachten Sie, dass ein Terminal während des gleichen Tippens möglicherweise mit mehreren verschiedenen Apps kommunizieren möchte. Daher müssen Sie sicherstellen, dass die Hintergrundaufgabe Ihrer App so schnell wie möglich beendet wird, wenn sie deaktiviert wird, um Platz für die Hintergrundaufgabe einer anderen App zu schaffen, die auf die APDU reagieren muss. Wir werden später in diesem Thema Hintergrundaufgaben besprechen.
HCE-Apps müssen sich mit bestimmten AIDs registrieren, die sie verarbeiten können, damit sie APDUs für diese AIDs erhalten. Apps deklarieren AIDs mithilfe von AID-Gruppen. Eine AID-Gruppe entspricht konzeptionell einer einzelnen physischen Karte. Beispielsweise wird eine Kreditkarte mit einer AID-Gruppe deklariert, und eine zweite Kreditkarte von einer anderen Bank wird mit einer anderen, zweiten AID-Gruppe deklariert, obwohl beide möglicherweise dieselbe AID haben.
Konfliktlösung für AID-Zahlungsgruppen
Wenn eine App physische Karten registriert (AID-Gruppen), kann sie die AID-Gruppenkategorie entweder als "Zahlung" oder "Sonstige" deklarieren. Es können zwar mehrere AID-Zahlungsgruppen gleichzeitig registriert werden, aber nur eine dieser AID-Zahlungsgruppen kann gleichzeitig für "Tippen und Bezahlen" aktiviert sein, die vom Benutzer ausgewählt wird. Dieses Verhalten ist vorhanden, da der Benutzer erwartet, bewusst eine einzelne Kredit- oder Debitkarte zu wählen, damit er nicht mit einer unbeabsichtigten Karte bezahlt, wenn er sein Gerät an ein Terminal hält.
Mehrere AID-Gruppen, die als "Andere" registriert sind, können jedoch ohne Benutzerinteraktion gleichzeitig aktiviert werden. Dieses Verhalten tritt auf, weil von anderen Arten von Karten wie Treuekarten, Gutscheinen oder Fahrkarten erwartet wird, dass sie ganz einfach funktionieren, ohne Aufwand oder Aufforderung, wann immer sie ihr Smartphone auflegen.
Alle AID-Gruppen, die als "Zahlung" registriert sind, werden in der Kartenliste der NFC-Einstellungen-Seite angezeigt, auf der der Benutzer seine Standardzahlungskarte auswählen kann. Wenn eine Standardzahlungskarte ausgewählt ist, wird die App, die diese Zahlungs-AID-Gruppe registriert hat, zur Standardzahlungs-App. Standardmäßige Zahlungs-Apps können eine ihrer AID-Gruppen ohne Benutzerinteraktion aktivieren oder deaktivieren. Wenn der Benutzer die Standardaufforderung der Zahlungs-App ablehnt, bleibt die aktuelle Standardzahlungs-App (falls vorhanden) weiterhin als Standard. Der folgende Screenshot zeigt die Seite mit den NFC-Einstellungen.
Anhand des obigen Beispiel-Screenshots, wenn der Benutzer seine Standardzahlungskarte auf eine andere Karte ändert, die nicht von "HCE Application 1" registriert ist, erstellt das System eine Bestätigungsanfrage für die Zustimmung des Benutzers. Wenn der Benutzer jedoch seine Standardzahlungskarte auf eine andere Karte ändert, die von "HCE Application 1" registriert ist, erstellt das System keine Bestätigungsaufforderung für den Benutzer, da "HCE Application1" bereits die Standard-Zahlungs-App ist.
Konfliktlösung für AID-Gruppen ohne Zahlung
Nicht bezahlte Karten, die als "Andere" kategorisiert sind, werden nicht auf der Seite mit den NFC-Einstellungen angezeigt.
Ihre App kann nicht-zahlungsbezogene AID-Gruppen ebenso wie Zahlungs-AID-Gruppen erstellen, registrieren und aktivieren. Der Hauptunterschied besteht darin, dass für AID-Gruppen ohne Zahlung die Emulationskategorie auf "Sonstige" statt auf "Zahlung" eingestellt wird. Nachdem Sie die AID-Gruppe beim System registriert haben, müssen Sie die AID-Gruppe aktivieren, um NFC-Datenverkehr zu empfangen. Wenn Sie versuchen, eine AID-Gruppe ohne Zahlungsfunktion zu aktivieren, um Verkehr zu empfangen, wird der Benutzer nicht zur Bestätigung aufgefordert, es sei denn, es besteht ein Konflikt mit einer der AIDs, die bereits von einer anderen App im System registriert wurden. Wenn ein Konflikt vorliegt, wird der Benutzer mit Informationen dazu aufgefordert, welche Karte und die zugeordnete App deaktiviert werden, wenn der Benutzer sich dafür entscheidet, die neu registrierte AID-Gruppe zu aktivieren.
Koexistenz mit SIM-basierten NFC-Anwendungen
In Windows 10 Mobile richtet das System die NFC-Controllerroutingtabelle ein, die zum Treffen von Routingentscheidungen auf Controllerebene verwendet wird. Die Tabelle enthält Routinginformationen für die folgenden Elemente.
- Einzelne AID-Routen.
- Protokollbasierte Route (ISO-DEP).
- Technologiebasiertes Routing (NFC-A/B/F).
Wenn ein externer Reader einen Befehl "SELECT AID" sendet, überprüft der NFC-Controller zunächst die AID-Routen in der Routing-Tabelle auf eine Übereinstimmung. Wenn keine Übereinstimmung vorhanden ist, wird die protokollbasierte Route als Standardroute für ISO-DEP (14443-4-A)-Datenverkehr verwendet. Für alle anderen nicht-ISO-DEP-Verkehrsarten wird es das technologiebasierte Routing verwenden.
Windows 10 Mobile bietet auf der Seite "NFC-Einstellungen" eine Menüoption "SIM-Karte", um weiterhin ältere SIM-basierte Windows Phone 8.1-Apps zu verwenden, die ihre AIDs nicht beim System registrieren. Wenn der Benutzer "SIM-Karte" als Standardzahlungskarte auswählt, wird die ISO-DEP Route auf UICC festgelegt, für alle anderen Auswahlen im Dropdown-Menü geht die ISO-DEP Route an den Host.
Wenn ein Gerät mit einer SIM-Karte mit aktivierter SE zum ersten Mal mit Windows 10 Mobile gestartet wird, ist die Routeneinstellung ISO-DEP auf "SIM-Karte" eingestellt. Wenn der Benutzer eine HCE-aktivierte App installiert und diese App HCE AID-Gruppenregistrierungen 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 der Controller-Routingtabelle ausgefüllt werden können.
Erstellen einer HCE-basierten App
Ihre HCE-App verfügt über zwei Teile.
- Die Haupt-Vordergrund-App für die Benutzerinteraktion.
- Eine vom System ausgelöste Hintergrundaufgabe, die APDUs für eine bestimmte AID verarbeitet.
Aufgrund der extrem engen Leistungsanforderungen für das Laden Ihrer Hintergrundaufgabe als Reaktion auf ein NFC-Antippen empfehlen wir, dass Ihre gesamte Hintergrundaufgabe in systemeigenem C++/CX-Code (einschließlich aller Abhängigkeiten, Verweise oder Bibliotheken, auf die Sie angewiesen sind) anstelle von C# oder verwaltetem Code implementiert wird. Während C# und verwalteter Code normalerweise gut funktionieren, gibt es Mehraufwand, z. B. das Laden der .NET-CLR, die durch Schreiben in C++/CX vermieden werden können.
Erstellen und Registrieren Sie Ihre Hintergrundaufgabe
Sie müssen eine Hintergrundaufgabe in Ihrer HCE-App erstellen, um apDUs zu verarbeiten und darauf zu reagieren, die vom System an sie weitergeleitet werden. Beim ersten Starten der App registriert der Vordergrund eine HCE-Hintergrundaufgabe, die die IBackgroundTaskRegistration Schnittstelle implementiert, wie im folgenden Code dargestellt.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();
Beachten Sie, dass der Tasktrigger auf SmartCardTriggerTypefestgelegt ist. EmulatorHostApplicationActivated. Dies bedeutet, dass Ihre Hintergrundaufgabe gestartet wird, sobald eine SELECT AID-Befehls-APDU vom Betriebssystem empfangen wird, die zu Ihrer App führt.
Empfangen und Beantworten von APDUs
Wenn eine für Ihre App bestimmte APDU vorliegt, startet das System Ihre Hintergrundaufgabe. Ihre Hintergrundaufgabe empfängt die APDU, die über die SmartCardEmulatorApduReceivedEventArgsCommandApdu-Eigenschaft des Objekts übergeben wird, und antwortet mithilfe der TryRespondAsync Methode desselben Objekts auf die APDU. Erwägen Sie, die Hintergrundaufgabe aus Leistungsgründen für leichte Vorgänge beizubehalten. Reagieren Sie beispielsweise sofort auf die APDUs und beenden Sie die Hintergrundaufgabe, wenn die gesamte Verarbeitung abgeschlossen ist. Aufgrund der Art von NFC-Transaktionen neigen Benutzer dazu, ihr Gerät nur sehr kurz an das Lesegerät zu halten. Ihre Hintergrundaufgabe empfängt weiterhin Verkehr vom Leser, bis die Verbindung deaktiviert ist. In diesem Fall erhalten Sie ein SmartCardEmulatorConnectionDeactivatedEventArgs-Objekt. Ihre Verbindung kann aus den folgenden Gründen deaktiviert werden, wie in der SmartCardEmulatorConnectionDeactivatedEventArgs.Reason-Eigenschaft angegeben.
- Wenn die Verbindung mit dem Wert ConnectionLost deaktiviert ist, bedeutet es, dass der Benutzer sein Gerät vom Lesegerät entfernt hat. Wenn Ihre App es erfordert, dass der Benutzer länger auf das Terminal tippt, sollten Sie ihm möglicherweise Feedback geben, um ihn darauf hinzuweisen. Sie sollten die Hintergrundaufgabe schnell beenden (indem Sie die Verzögerung abschließen), um sicherzustellen, dass sie erneut tippen, es wird nicht verzögert, bis die vorherige Hintergrundaufgabe beendet wird.
- Wenn die Verbindung mit dem ConnectionRedirecteddeaktiviert wird, bedeutet dies, dass das Terminal eine neue SELECT AID-Befehls-APDU gesendet hat, die an eine andere AID gerichtet ist. In diesem Fall sollte Ihre App die Hintergrundaufgabe sofort beenden (durch Abschließen der Verzögerung), damit eine andere Hintergrundaufgabe ausgeführt werden kann.
Die Hintergrundaufgabe sollte sich auch für das Canceled-Ereignis auf der IBackgroundTaskInstance-Schnittstelleregistrieren und die Hintergrundaufgabe ebenso schnell beenden (durch Beenden der Verzögerung), da dieses Ereignis vom System ausgelöst wird, wenn es mit der Hintergrundaufgabe fertig ist. Im Folgenden finden Sie Code, der eine HCE-App-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 deferral 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();
}
}
Erstellen und Registrieren von AID-Gruppen
Während des ersten Starts Ihrer Anwendung, wenn die Karte bereitgestellt wird, erstellen und registrieren Sie AID-Gruppen beim System. Das System bestimmt, mit welcher App ein externer Leser kommunizieren möchte, und leitet die APDUs entsprechend basierend auf den registrierten AIDs und Benutzereinstellungen weiter.
Die meisten Zahlungskarten melden sich für dieselbe AID im Proximity Payment System Environment (PPSE) an, zusammen mit zusätzlichen zahlungsnetzwerkspezifischen AIDs. Jede AID-Gruppe stellt eine Karte dar und wenn der Benutzer die Karte aktiviert, werden alle AIDs in der Gruppe aktiviert. Ebenso werden alle AIDs in der Gruppe deaktiviert, wenn der Benutzer die Karte deaktiviert.
Um eine AID-Gruppe zu registrieren, müssen Sie ein SmartCardAppletIdGroup-Objekt erstellen und dessen Eigenschaften so festlegen, dass es sich um eine HCE-basierte Zahlungskarte handelt. Ihr Anzeigename sollte für den Benutzer beschreibend sein, da er im Menü mit den NFC-Einstellungen sowie benutzeraufforderungen angezeigt wird. Bei HCE-Zahlungskarten sollte die SmartCardEmulationCategory--Eigenschaft auf Payment- festgelegt werden, und die SmartCardEmulationType--Eigenschaft sollte auf Host-festgelegt 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, die nicht für Zahlungen verwendet werden, sollte die Eigenschaft SmartCardEmulationCategory auf Other gesetzt werden und die Eigenschaft SmartCardEmulationType sollte auf Hostgesetzt 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 pro AID-Gruppe bis zu 9 AIDs (jeweils 5 bis 16 Byte lang) einfügen.
Verwenden Sie die RegisterAppletIdGroupAsync- Methode, um die AID-Gruppe mit dem System zu registrieren, wodurch ein SmartCardAppletIdGroupRegistration-Objekt zurückgegeben wird. Standardmäßig ist die ActivationPolicy-Eigenschaft des Registrierungsobjekts auf Disabledfestgelegt. Dies bedeutet, dass Ihre AIDs zwar im System registriert sind, sie aber noch nicht aktiviert sind und keinen Datenverkehr erhalten.
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
Sie können Ihre registrierten Karten (AID-Gruppen) mithilfe der RequestActivationPolicyChangeAsync- Methode derSmartCardAppletIdGroupRegistration Klasse aktivieren, wie unten dargestellt. Da nur eine einzelne Zahlungskarte gleichzeitig im System aktiviert werden kann, entspricht das Festlegen der ActivationPolicy- einer AID-Zahlungsgruppe auf Aktivierte dem Festlegen 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 gilt nicht, wenn Ihre App bereits als Standardzahlungsanwendung definiert ist und lediglich zwischen ihren eigenen AID-Gruppen wechselt. Sie können bis zu 10 AID-Gruppen pro App registrieren.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);
Sie können die registrierten AID-Gruppen Ihrer App mit dem Betriebssystem abfragen und deren Aktivierungsrichtlinie mithilfe der GetAppletIdGroupRegistrationsAsync-Methode überprüfen.
Benutzer werden benachrichtigt, wenn Sie die Aktivierungsrichtlinie einer Zahlungskarte von Disabled in Enabledändern, vorausgesetzt, Ihre App ist noch nicht die standardmäßige Zahlungs-App. Benutzer werden nur aufgefordert, wenn Sie die Aktivierungsrichtlinie einer Karte, die nicht für Zahlungen bestimmt ist, von Deaktiviert in Aktiviert ändern und ein AID-Konflikt vorliegt.
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 für eine Ihrer AID-Gruppenregistrierungen außerhalb Ihrer App ändert. Beispielsweise kann der Benutzer die Standardzahlungs-App über das NFC-Einstellungsmenü von einer Ihrer Karten in eine andere Karte ändern, die von einer anderen App gehostet wird. Wenn Ihre App über diese Änderung für interne Konfigurationen wie das Aktualisieren von Live-Kacheln informiert werden muss, können Sie Ereignisbenachrichtigungen für diese Änderung erhalten und rechtzeitig entsprechende Schritte in Ihrer App ergreifen.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();
Verhalten beim Außerkraftsetzen des Vordergrunds
Sie können die ActivationPolicy- ihrer AID-Gruppenregistrierungen zu ForegroundOverride- ändern, während sich Ihre App im Vordergrund befindet, ohne den Benutzer aufzufordern. Wenn der Benutzer auf sein Gerät auf ein Terminal tippt, während sich Ihre App im Vordergrund befindet, wird der Datenverkehr an Ihre App weitergeleitet, auch wenn keine Ihrer Zahlungskarten vom Benutzer als Standardzahlungskarte ausgewählt wurde. Wenn Sie die Aktivierungsrichtlinie einer Karte in ForegroundOverrideändern, ist diese Änderung nur vorübergehend, bis Ihre App 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 wie folgt aus der Vordergrund-App ändern. Beachten Sie, dass die RequestActivationPolicyChangeAsync- Methode nur von einer Vordergrundanwendung und nicht von einer Hintergrundaufgabe aufgerufen werden kann.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);
Darüber hinaus können Sie eine AID-Gruppe registrieren, die aus einer einzigen AID mit 0-Länge besteht und dazu führt, dass das System alle APDUs unabhängig von der AID weiterleitet, einschließlich aller Befehls-APDUs, die gesendet wurden, bevor ein SELECT-AID-Befehl empfangen wurde. Eine solche AID-Gruppe funktioniert jedoch nur, wenn sich Ihre App im Vordergrund befindet, da sie nur auf ForegroundOverride festgelegt 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 Enumeration, um entweder den gesamten Datenverkehr an Ihre HCE-Hintergrundaufgabe oder an die SIM-Karte weiterzuleiten.
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);
Überprüfung der NFC- und HCE-Unterstützung
Ihre App sollte überprüfen, ob ein Gerät ÜBER NFC-Hardware verfügt, das Kartenemulationsfeature unterstützt und die Hostkartenemulation unterstützt, bevor diese Features dem Benutzer angeboten werden.
Das NFC-Smartcardemulationsfeature ist nur unter Windows 10 Mobile aktiviert. Daher verursacht der Versuch, die Smartcard-Emulator-APIs in anderen Versionen von Windows 10 zu verwenden, Fehler. Sie können die Smartcard-API-Unterstützung im folgenden Codeausschnitt überprüfen.
Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");
Darüber hinaus können Sie überprüfen, ob das Gerät über NFC-Hardware verfügt, die eine Form der Kartenemulation hat, indem Sie überprüfen, ob die SmartCardEmulator.GetDefaultAsync-Methode NULL zurückgibt. Wenn dies der Fall ist, wird keine NFC-Kartenemulation auf dem Gerät unterstützt.
var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<
Unterstützung für HCE- und AID-basiertes UICC-Routing ist nur auf kürzlich eingeführten Geräten wie Lumia 730, 830, 640 und 640 XL verfügbar. Alle neuen NFC-fähigen Geräte unter Windows 10 Mobile und danach sollten HCE unterstützen. Ihre App kann die HCE-Unterstützung wie folgt überprüfen.
Smartcardemulator.IsHostCardEmulationSupported();
Verhalten des Sperrbildschirms und des Bildschirms bei Inaktivität
Windows 10 Mobile verfügt über Kartenemulationseinstellungen auf Geräteebene, die vom Mobilfunkanbieter oder hersteller des Geräts festgelegt werden können. Standardmäßig ist der Schalter "Zum Bezahlen tippen" deaktiviert, und die Option "Aktivierungsrichtlinie auf Geräteebene" ist auf "Immer" festgelegt, sofern der MO oder OEM diese Werte nicht überschreibt.
Ihre Anwendung kann den Wert der EnablementPolicy- auf Geräteebene abfragen und je nach gewünschtem Verhalten Ihrer App in jedem Zustand Maßnahmen ergreifen.
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 gestartet, auch wenn das Telefon gesperrt ist und/oder der Bildschirm ausgeschaltet ist, wenn der externe Leser eine AID auswählt, die Ihrer App zugeordnet ist. Sie können auf die Befehle des Lesers in Ihrer Hintergrundaufgabe reagieren. Wenn Sie jedoch Eingaben vom Benutzer benötigen oder dem Benutzer eine Meldung anzeigen möchten, können Sie Ihre Vordergrundanwendung mit bestimmten Argumenten starten. Ihre Hintergrundaufgabe kann ihre Vordergrund-App mit dem folgenden Verhalten starten.
- Unter dem Sperrbildschirm des Geräts (Ihre Vordergrund-App wird nur angezeigt, nachdem sie das Gerät entsperrt hat)
- Über dem Sperrbildschirm des Geräts (nachdem der Benutzer Ihre App geschlossen hat, befindet sich das Gerät weiterhin im gesperrten Zustand).
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 Apps
Kartenemulations-Apps, die die SIM als sicheres Element verwenden, können sich beim Windows-Dienst registrieren, um die auf der SIM-Karte unterstützten AIDs zu deklarieren. Diese Registrierung ähnelt einer HCE-basierten App-Registrierung. Der einzige Unterschied besteht im SmartCardEmulationType, der für SIM-basierte Apps auf "Uicc" festgelegt werden sollte. Als Ergebnis der Zahlungskartenregistrierung wird der Anzeigename der Karte auch im NFC-Einstellungsmenü ausgefüllt.
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Uicc);