Partager via


Créer une application de carte à puce NFC

Important

Cette rubrique s’applique uniquement à Windows 10 Mobile.

Cette rubrique explique comment utiliser l’émulation de carte hôte (HCE) pour communiquer directement avec un lecteur de carte NFC (Near-Field Communication) et permettre à vos clients d’accéder à vos services via leur téléphone (au lieu d’une carte physique) sans opérateur de réseau mobile (MNO).

Ce dont vous avez besoin pour développer une application HCE

Pour développer une application d’émulation de carte basée sur HCE, vous devez installer Microsoft Visual Studio 2015 (voir la page de téléchargement Visual Studio) (inclut les outils de développement Windows) et l’émulateur Windows 10 Mobile .

Pour plus d’informations sur la configuration, consultez Test avec l’émulateur Microsoft pour Windows 10 Mobile.

Si vous souhaitez tester avec un appareil Windows 10 Mobile réel au lieu de l’émulateur Windows 10 Mobile inclus, vous aurez également besoin des éléments suivants.

  • Un appareil Windows 10 Mobile avec compatibilité NFC HCE.
  • Terminal lecteur qui prend en charge les protocoles ISO/IEC 14443-4 et ISO/IEC 7816-4

Windows 10 Mobile implémente un service HCE qui fournit les fonctionnalités suivantes.

  • Les applications peuvent inscrire les identificateurs d’applet (AID) pour les cartes qu’ils souhaitent émuler.
  • Résolution des conflits et routage des paires de commande et de réponse APDU (Application Protocol Data Unit) vers l’une des applications inscrites en fonction de la sélection de la carte de lecteur externe et de la préférence utilisateur.
  • Gestion des événements et des notifications aux applications à la suite d’actions utilisateur.

Windows 10 prend en charge l’émulation des cartes à puce basées sur ISO-DEP (ISO-IEC 14443-4) et communique à l’aide d’APDUs comme défini dans la spécification ISO-IEC 7816-4. Windows 10 prend en charge la technologie ISO/IEC 14443-4 type A pour les applications HCE. Les technologies type B, type F et non-ISO-DEP (par exemple MIFARE) sont routées vers la carte SIM par défaut.

Seuls les appareils Windows 10 Mobile sont activés avec la fonctionnalité d’émulation de carte. L’émulation de carte basée sur SIM et HCE n’est pas disponible sur d’autres versions de Windows 10.

L’architecture pour la prise en charge de l’émulation de carte basée sur HCE et SIM est illustrée dans le diagramme ci-dessous.

Architecture pour HCE et émulation de carte SIM

Sélection de l’application et routage AID

Pour développer une application HCE, vous devez comprendre comment les appareils Windows 10 Mobile routent les AID vers une application spécifique, car les utilisateurs peuvent installer plusieurs applications HCE différentes. Chaque application peut inscrire plusieurs cartes HCE et SIM.

Lorsque l’utilisateur appuie sur son appareil Windows 10 Mobile sur un terminal, les données sont automatiquement acheminées vers l’application appropriée installée sur l’appareil. Ce routage est basé sur l’ID d’applet (AID) qui est un identificateur de 5 à 16 octets. Pendant un appui, le terminal externe transmet une commande SELECT APDU pour spécifier l’AIDE vers laquelle toutes les commandes APDU suivantes doivent être routées. Les commandes SELECT suivantes modifient à nouveau le routage. En fonction des identifiants d'application inscrits par les applications et les paramètres utilisateur, le trafic APDU est acheminé vers une application spécifique, qui enverra une APDU de réponse. N’oubliez pas qu’un terminal peut vouloir communiquer avec plusieurs applications différentes pendant le même appui. Vous devez donc vous assurer que la tâche en arrière-plan de votre application s’arrête aussi rapidement que possible lorsqu’elle est désactivée pour permettre à une autre application de répondre à l’APIDU. Nous aborderons les tâches en arrière-plan plus loin dans cette rubrique.

Les applications HCE doivent s’inscrire auprès d'AID spécifiques qu'elles peuvent gérer afin de recevoir des APDU pour un AID. Les applications déclarent des AID à l’aide de groupes AID. Un groupe AID est conceptuellement équivalent à une carte physique individuelle. Par exemple, une carte de crédit est déclarée avec un groupe AID et une deuxième carte de crédit d’une autre banque est déclarée avec un autre groupe d’AIDE, même si les deux d’entre eux peuvent avoir la même AIDE.

Résolution des conflits pour les groupes d’AIDE de paiement

Lorsqu’une application inscrit des cartes physiques (groupes AID), elle peut déclarer la catégorie de groupe AID en tant que « Paiement » ou « Autre ». Bien qu’il puisse y avoir plusieurs groupes d’AIDES de paiement inscrits à un moment donné, un seul de ces groupes d’AIDES de paiement peut être activé pour tap and Pay à la fois, qui est sélectionné par l’utilisateur. Ce comportement existe parce que l'utilisateur s'attend à pouvoir choisir consciemment un seul moyen de paiement, carte de crédit ou de débit, afin de ne pas payer avec une autre carte non intentionnelle en approchant son appareil d'un terminal.

Toutefois, plusieurs groupes AID inscrits en tant que « Autre » peuvent être activés en même temps sans interaction utilisateur. Ce comportement existe parce que d’autres types de cartes comme la fidélité, les coupons ou le transit sont censés fonctionner simplement sans aucun effort ni invite chaque fois qu’ils appuient sur leur téléphone.

Tous les groupes d’AIDE inscrits en tant que « paiement » apparaissent dans la liste des cartes dans la page Paramètres NFC, où l’utilisateur peut sélectionner sa carte de paiement par défaut. Lorsqu’une carte de paiement par défaut est sélectionnée, l’application qui a inscrit ce groupe d’AIDES de paiement devient l’application de paiement par défaut. Les applications de paiement par défaut peuvent activer ou désactiver l’un de leurs groupes AID sans interaction utilisateur. Si l’utilisateur refuse l’invite d’application de paiement par défaut, l’application de paiement par défaut actuelle (le cas échéant) continue de rester comme valeur par défaut. La capture d’écran suivante montre la page Paramètres NFC.

Capture d’écran de la page des paramètres NFC

À l’aide de l’exemple de capture d’écran ci-dessus, si l’utilisateur remplace sa carte de paiement par défaut par une autre carte qui n’est pas inscrite par « Application HCE 1 », le système crée une invite de confirmation pour le consentement de l’utilisateur. Toutefois, si l’utilisateur remplace sa carte de paiement par défaut par une autre carte inscrite par « Application HCE 1 », le système ne crée pas d’invite de confirmation pour l’utilisateur en tant que « HCE Application1 » est déjà l’application de paiement par défaut.

Résolution des conflits pour les groupes d'aide avec impayés

Les cartes de non-paiement classées comme « Autres » n’apparaissent pas dans la page des paramètres NFC.

Votre application peut créer, inscrire et activer des groupes d’AIDE sans paiement de la même manière que les groupes d’AIDE de paiement. La principale différence est que pour les groupes AID non-paiement, la catégorie d’émulation est définie sur « Autre » contrairement à « Paiement ». Après avoir inscrit le groupe AID auprès du système, vous devez autoriser le groupe AID à recevoir le trafic NFC. Lorsque vous essayez d’activer un groupe AID non-payant pour recevoir du trafic, l’utilisateur n’est pas sollicité pour une confirmation, sauf s’il existe un conflit avec l’un des AIDs déjà enregistrés dans le système par une autre application. En cas de conflit, l'utilisateur recevra des informations sur la carte et l'application associée qui seront désactivées si l'utilisateur choisit d'activer le groupe AID nouvellement enregistré.

Coexistence avec des applications NFC basées sur SIM

Dans Windows 10 Mobile, le système configure la table de routage du contrôleur NFC utilisée pour prendre des décisions de routage au niveau de la couche contrôleur. Le tableau contient des informations de routage pour les éléments suivants.

  • Itinéraires d’AIDE individuels.
  • Itinéraire basé sur le protocole (ISO-DEP).
  • Routage basé sur la technologie (NFC-A/B/F).

Lorsqu’un lecteur externe envoie une commande « SELECT AID », le contrôleur NFC vérifie d’abord les itinéraires AID dans la table de routage pour trouver une correspondance. S’il n’existe aucune correspondance, il utilise l’itinéraire basé sur le protocole comme itinéraire par défaut pour le trafic ISO-DEP (14443-4-A). Pour tout autre trafic nonISO-DEP, il utilisera le routage basé sur la technologie.

Windows 10 Mobile fournit une option de menu « Carte SIM » dans la page Paramètres NFC pour continuer à utiliser les applications Windows Phone 8.1 héritées basées sur SIM, qui n’inscrivent pas leurs AID auprès du système. Si l’utilisateur sélectionne « Carte SIM » comme carte de paiement par défaut, l’itinéraire ISO-DEP est défini sur UICC, pour toutes les autres sélections du menu déroulant, l’itinéraire ISO-DEP est vers l’hôte.

L’itinéraire ISO-DEP est défini sur « Carte SIM » pour les appareils dotés d’une carte SIM activée par SE lorsque l’appareil est démarré pour la première fois avec Windows 10 Mobile. Lorsque l’utilisateur installe une application HCE activée et que cette application active toutes les inscriptions de groupe HCE AID, l’itinéraire ISO-DEP est pointé vers l’hôte. Les nouvelles applications basées sur SIM doivent inscrire les AID dans la carte SIM afin que les itinéraires AID spécifiques soient renseignés dans la table de routage du contrôleur.

Création d’une application basée sur HCE

Votre application HCE comporte deux parties.

  • Application de premier plan principale pour l’interaction utilisateur.
  • Tâche de fond déclenchée par le système pour traiter les APDUs pour un AID donné.

En raison des exigences de performances extrêmement strictes pour le chargement de votre tâche en arrière-plan en réponse à un appui NFC, nous vous recommandons d’implémenter toute votre tâche en arrière-plan dans le code natif C++/CX (y compris les dépendances, références ou bibliothèques dont vous dépendez) plutôt que le code C# ou managé. Bien que le code C# et le code managé fonctionnent normalement correctement, il existe une surcharge, comme le chargement du CLR .NET, qui peut être évité en l’écrivant en C++/CX.

Créer et enregistrer votre tâche en arrière-plan

Vous devez créer une tâche en arrière-plan dans votre application HCE pour le traitement et la réponse aux APDUs routées vers celle-ci par le système. La première fois que votre application est lancée, le premier plan enregistre une tâche d'arrière-plan HCE qui implémente l’interface IBackgroundTaskRegistration, comme indiqué dans le code suivant.

var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();

Notez que le déclencheur de tâche est défini sur SmartCardTriggerType. EmulatorHostApplicationActivated. Cela signifie que chaque fois qu’une commande SELECT AID APDU est reçue par le système d’exploitation et redirigée vers votre application, votre tâche en arrière-plan sera lancée.

Recevoir et répondre aux APDU

Lorsqu’il existe une APDU ciblée pour votre application, le système lance votre tâche en arrière-plan. Votre tâche en arrière-plan reçoit l’APDU transmise via l'objet SmartCardEmulatorApduReceivedEventArgs, propriété CommandApdu, et répond à l’APDU en utilisant la méthode TryRespondAsync du même objet. Envisagez de conserver votre tâche en arrière-plan pour les opérations légères pour des raisons de performances. Par exemple, répondez immédiatement aux APDUs et quittez votre tâche en arrière-plan lorsque tout le traitement est terminé. En raison de la nature des transactions NFC, les utilisateurs ont tendance à maintenir leur appareil sur le lecteur pendant une très courte durée. Votre tâche en arrière-plan continuera à recevoir le trafic du lecteur jusqu’à ce que votre connexion soit désactivée, auquel cas vous recevrez un SmartCardEmulatorConnectionDeactivatedEventArgs objet. Votre connexion peut être désactivée pour les raisons suivantes, comme indiqué dans la propriété SmartCardEmulatorConnectionDeactivatedEventArgs.Reason.

  • Si la connexion est désactivée avec la valeur ConnectionLost, cela signifie que l’utilisateur a retiré son appareil du lecteur. Si votre application a besoin de l’utilisateur pour appuyer sur le terminal plus longtemps, vous pouvez envisager de les inviter à recevoir des commentaires. Vous devez arrêter rapidement votre tâche en arrière-plan (en terminant votre report) pour vous assurer que, si l'utilisateur appuie à nouveau, son action ne sera pas retardée en attendant que la tâche en arrière-plan précédente se termine.
  • Si la connexion est désactivée avec le ConnectionRedirected, cela signifie que le terminal a envoyé une nouvelle commande SELECT AID APDU dirigée vers un autre AID. Dans ce cas, votre application doit quitter immédiatement la tâche en arrière-plan (en effectuant votre report) pour autoriser l’exécution d’une autre tâche en arrière-plan.

La tâche en arrière-plan doit également s’inscrire à l''événement Annulé sur 'interface IBackgroundTaskInstance, et quitter rapidement la tâche en arrière-plan (en terminant votre report), car cet événement est déclenché par le système lorsqu’il est terminé avec votre tâche en arrière-plan. Voici le code qui illustre une tâche en arrière-plan de l’application HCE.

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();
 }
}

Créer et inscrire des groupes AID

Au cours du premier lancement de votre application lorsque la carte est provisionnée, vous allez créer et inscrire des groupes d'AID auprès du système. Le système détermine l’application avec laquelle un lecteur externe veut communiquer et achemine les APDUs en conséquence en fonction des AIDs enregistrés et des paramètres utilisateur.

La plupart des cartes de paiement s'enregistrent pour le même identifiant d'application (AID), Proximity Payment System Environment (PPSE), ainsi que pour d'autres identifiants d'application spécifiques aux réseaux de paiement. Chaque groupe AID représente une carte et lorsque l’utilisateur active la carte, tous les AID du groupe sont activés. De même, lorsque l’utilisateur désactive la carte, tous les AID du groupe sont désactivés.

Pour inscrire un groupe AID, vous devez créer un objet SmartCardAppletIdGroup et définir ses propriétés pour refléter qu’il s’agit d’une carte de paiement basée sur HCE. Votre nom d’affichage doit être descriptif pour l’utilisateur, car il s’affiche dans le menu des paramètres NFC, ainsi que dans les invites de l’utilisateur. Pour les cartes de paiement HCE, la propriété SmartCardEmulationCategory doit être définie sur Paiement et la propriété SmartCardEmulationType doit être définie sur Hôte.

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);

Pour les cartes HCE sans paiement, la propriété SmartCardEmulationCategory doit être définie sur Autre et la propriété SmartCardEmulationType doit être définie sur hôte.

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);

Vous pouvez inclure jusqu’à 9 AID (de 5 à 16 octets de longueur chacun) par groupe AID.

Utilisez la méthode RegisterAppletIdGroupAsync pour inscrire votre groupe AID auprès du système, qui retourne un objet SmartCardAppletIdGroupRegistration. Par défaut, la propriété ActivationPolicy de l’objet d'enregistrement est définie sur désactivée. Cela signifie que même si vos AID sont inscrits auprès du système, ils ne sont pas encore activés et ne recevront pas de trafic.

reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);

Vous pouvez activer vos cartes inscrites (groupes AID) à l’aide de la méthode RequestActivationPolicyChangeAsync de la classeSmartCardAppletIdGroupRegistration comme indiqué ci-dessous. Étant donné qu'une unique carte de paiement peut être activée à la fois sur le système, la définition de l'ActivationPolicy d’un groupe d’AID de paiement sur Enabled est identique à la définition de la carte de paiement par défaut. L’utilisateur est invité à autoriser cette carte en tant que carte de paiement par défaut, qu’il existe une carte de paiement par défaut déjà sélectionnée ou non. Cette déclaration n’est pas vraie si votre application est déjà l’application de paiement par défaut et change simplement entre ses propres groupes d’AID. Vous pouvez inscrire jusqu’à 10 groupes d’AIDE par application.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);

Vous pouvez interroger les groupes d'AID enregistrés de votre application avec le système d'exploitation et vérifier leur stratégie d'activation à l'aide de la méthode GetAppletIdGroupRegistrationsAsync.

Les utilisateurs recevront un avertissement lorsque vous modifiez la stratégie d’activation d'une carte de paiement de Désactivée à Activée, uniquement si votre application n'est pas déjà l'application de paiement par défaut. Les utilisateurs ne reçoivent une notification que lorsqu’on modifie la politique d’activation d’une carte sans paiement de l’état Désactivée à l’état Activée en cas de conflit d'AID.

var registrations = await SmartCardEmulator.GetAppletIdGroupRegistrationsAsync();
    foreach (var registration in registrations)
    {
registration.RequestActivationPolicyChangeAsync (AppletIdGroupActivationPolicy.Enabled);
    }

Notification d’événement lorsque la stratégie d’activation change

Dans votre tâche en arrière-plan, vous pouvez vous inscrire pour recevoir des événements lorsque la stratégie d’activation de l’une de vos inscriptions de groupe AID change en dehors de votre application. Par exemple, l’utilisateur peut modifier l’application de paiement par défaut via le menu paramètres NFC de l’une de vos cartes vers une autre carte hébergée par une autre application. Si votre application doit connaître cette modification pour une configuration interne telle que la mise à jour des vignettes actives, vous pouvez recevoir des notifications d’événements pour cette modification et agir en conséquence dans votre application.

var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();

Comportement de remplacement au premier plan

Vous pouvez modifier l' ActivationPolicy de l’une de vos inscriptions de groupe AID en foregroundOverride pendant que votre application est au premier plan sans inviter l’utilisateur. Lorsque l’utilisateur appuie sur son appareil sur un terminal pendant que votre application est au premier plan, le trafic est acheminé vers votre application même si aucune de vos cartes de paiement n’a été choisie par l’utilisateur comme carte de paiement par défaut. Lorsque vous modifiez la stratégie d’activation d’une carte en ForegroundOverride, cette modification n’est temporaire que si votre application quitte le premier plan et qu’elle ne modifie pas la carte de paiement par défaut actuelle définie par l’utilisateur. Vous pouvez modifier la ActivationPolicy de vos cartes de paiement ou de non-paiement à partir de votre application de premier plan comme suit. Notez que la méthode RequestActivationPolicyChangeAsync ne peut être appelée qu’à partir d’une application de premier plan et ne peut pas être appelée à partir d’une tâche en arrière-plan.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);

En outre, vous pouvez inscrire un groupe d'AID composé d'un seul AID de longueur 0, ce qui amène le système à acheminer tous les APDU, indépendamment de l'AID, y compris tous les APDU de commande envoyés avant la réception d'une commande SELECT AID. Toutefois, un tel groupe AID fonctionne uniquement pendant que votre application est au premier plan, car elle ne peut être définie que sur foregroundOverride et ne peut pas être activée définitivement. En outre, ce mécanisme fonctionne à la fois pour hôte et valeurs DE l’UICC des valeurs SmartCardEmulationType énumération pour acheminer tout le trafic vers votre tâche en arrière-plan HCE ou vers la carte SIM.

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);

Vérifier la prise en charge NFC et HCE

Votre application doit vérifier si un appareil dispose d’un matériel NFC, prend en charge la fonctionnalité d’émulation de carte d’hôte et prend en charge l’émulation de carte hôte avant d’offrir ces fonctionnalités à l’utilisateur.

La fonctionnalité d’émulation de carte à puce NFC est activée uniquement sur Windows 10 Mobile. Par conséquent, la tentative d’utilisation des API de l’émulateur de carte à puce dans toutes les autres versions de Windows 10 entraîne des erreurs. Vous pouvez vérifier la prise en charge de l’API de carte à puce dans l’extrait de code suivant.

Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");

Vous pouvez également vérifier si l’appareil dispose d’un matériel NFC capable d’une forme d’émulation de carte en vérifiant si la méthode SmartCardEmulator.GetDefaultAsync retourne null. Si c’est le cas, aucune émulation de carte NFC n’est prise en charge sur l’appareil.

var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<

La prise en charge du routage UICC basé sur HCE et AID n’est disponible que sur les appareils récemment lancés, tels que le Lumia 730, 830, 640 et 640 XL. Tous les nouveaux appareils compatibles NFC exécutant Windows 10 Mobile et après doivent prendre en charge HCE. Votre application peut vérifier le support de HCE comme suit.

Smartcardemulator.IsHostCardEmulationSupported();

Verrouillage de l’écran et du comportement de désactivation de l’écran

Windows 10 Mobile a des paramètres d’émulation de carte au niveau de l’appareil, qui peuvent être définis par l’opérateur mobile ou le fabricant de l’appareil. Par défaut, le bouton bascule « appuyer pour payer » est désactivé et la stratégie d’activation au niveau de l’appareil est définie sur « Toujours », à moins que le MO ou l’OEM ne remplace ces valeurs.

Votre application peut interroger la valeur de l'EnablementPolicy au niveau de l’appareil et prendre des mesures pour chaque cas en fonction du comportement souhaité de votre application dans chaque état.

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";
}

La tâche en arrière-plan de votre application sera lancée même si le téléphone est verrouillé et/ou que l’écran est éteint, uniquement si le lecteur externe sélectionne un AID qui pointe vers votre application. Vous pouvez répondre aux commandes du lecteur dans votre tâche en arrière-plan, mais si vous avez besoin d’une entrée de l’utilisateur ou si vous souhaitez afficher un message à l’utilisateur, vous pouvez lancer votre application de premier plan avec certains arguments. Votre tâche en arrière-plan peut lancer votre application de premier plan avec le comportement suivant.

  • Sous l’écran de verrouillage de l’appareil (l’utilisateur voit votre application de premier plan uniquement après avoir déverrouillé l’appareil)
  • Au-dessus de l’écran de verrouillage de l’appareil (une fois que l’utilisateur a ignoré votre application, l’appareil est toujours en état verrouillé)
        if (Windows::Phone::System::SystemProtection::ScreenLocked)
        {
            // Launch above the lock with some arguments
            var result = await eventDetails.TryLaunchSelfAsync("app-specific arguments", SmartCardLaunchBehavior.AboveLock);
        }

Inscription d’AID et autres mises à jour pour les applications basées sur SIM

Les applications d’émulation de carte qui utilisent la carte SIM comme élément sécurisé peuvent s’inscrire auprès du service Windows pour déclarer les AID pris en charge sur la carte SIM. Cette inscription est très similaire à celle d'une application basée sur l'HCE. La seule différence est la SmartCardEmulationType, qui doit être définie sur Uicc pour les applications basées sur SIM. En conséquence de l’inscription de la carte de paiement, le nom complet de la carte est également renseigné dans le menu du paramètre NFC.

var appletIdGroup = new SmartCardAppletIdGroup(
                        "Example DisplayName",
                                new List<IBuffer> {AID_PPSE.AsBuffer()},
                                SmartCardEmulationCategory.Payment,
                                SmartCardEmulationType.Uicc);