Creación de una aplicación de tarjeta inteligente NFC

2024-04-26

Importante

Este tema solo se aplica a Windows 10 Mobile.

En este tema se describe cómo usar la emulación de tarjeta host (HCE) para comunicarse directamente con un lector de tarjetas de comunicación de campo cercano (NFC) y permitir que los clientes accedan a los servicios a través de su teléfono (en lugar de una tarjeta física) sin un operador de red móvil (MNO).

Lo que necesita para desarrollar una aplicación HCE

Para desarrollar una aplicación de emulación de tarjeta basada en HCE, debe instalar Microsoft Visual Studio 2015 (consulte la página de descarga de Visual Studio) (incluye las herramientas de desarrollo de Windows) y el emulador de Windows 10 Mobile .

Para obtener más información sobre cómo configurar, consulte Prueba con el emulador de Microsoft para Windows 10 Mobile.

Opcionalmente, si quieres probar con un dispositivo Windows 10 Mobile real en lugar del emulador de Windows 10 Mobile incluido, también necesitarás los siguientes elementos.

Un dispositivo Windows 10 Mobile con compatibilidad con NFC HCE.
Terminal lector que admite protocolos ISO/IEC 14443-4 e ISO/IEC 7816-4

Windows 10 Mobile implementa un servicio HCE que proporciona las siguientes funcionalidades.

Las aplicaciones pueden registrar los identificadores de applet (AID) para las tarjetas que les gustaría emular.
Resolución de conflictos y enrutamiento de los pares de comandos y respuestas de la unidad de datos del protocolo de aplicación (APDU) a una de las aplicaciones registradas en función de la selección de tarjetas de lector externas y la preferencia del usuario.
Control de eventos y notificaciones a las aplicaciones como resultado de las acciones del usuario.

Windows 10 admite la emulación de tarjetas inteligentes basadas en ISO-DEP (ISO-IEC 14443-4) y se comunica mediante APDUs tal como se define en la especificación ISO-IEC 7816-4. Windows 10 admite tecnología ISO/IEC 14443-4 type A para aplicaciones HCE. Las tecnologías de tipo B, tipo F y que no seanISO-DEP (por ejemplo, MIFARE) se enrutan a la SIM de forma predeterminada.

Solo los dispositivos Windows 10 Mobile están habilitados con la característica de emulación de tarjeta. La emulación de tarjetas basada en SIM y HCE no está disponible en otras versiones de Windows 10.

La arquitectura para la compatibilidad con emulación de tarjetas basadas en HCE y SIM se muestra en el diagrama siguiente.

arquitectura de para la emulación de tarjetas HCE y SIM

Selección de aplicaciones y enrutamiento de AID

Para desarrollar una aplicación HCE, debes comprender cómo los dispositivos Windows 10 Mobile enrutan los AID a una aplicación específica, ya que los usuarios pueden instalar varias aplicaciones HCE diferentes. Cada aplicación puede registrar varias tarjetas HCE y basadas en SIM.

Cuando el usuario pulsa su dispositivo Windows 10 Mobile en un terminal, los datos se enrutan automáticamente a la aplicación adecuada instalada en el dispositivo. Este enrutamiento se basa en el identificador de applet (AID), que es un identificador de 5 a 16 bytes. Durante una pulsación, el terminal externo transmitirá un comando SELECT APDU para especificar el AID al que desea que se enruten todos los comandos APDU posteriores. Los comandos SELECT posteriores cambiarán de nuevo el enrutamiento. En función de los AID registrados por aplicaciones y las configuraciones de usuario, el tráfico APDU se enruta a una aplicación específica, que enviará una respuesta APDU. Tenga en cuenta que un terminal puede querer comunicarse con varias aplicaciones diferentes durante la misma pulsación. Por lo tanto, debes asegurarte de que la tarea en segundo plano de la aplicación se cierre lo antes posible cuando se desactive para que la tarea en segundo plano de otra aplicación responda a la APDU. Analizaremos las tareas en segundo plano más adelante en este tema.

Las aplicaciones de HCE deben registrarse con determinados AIDs que puedan manejar para que reciban APDUs de un AID. Las aplicaciones declaran los AID mediante grupos de AID. Un grupo AID es conceptualmente equivalente a una tarjeta física individual. Por ejemplo, una tarjeta de crédito se declara con un grupo AID y una segunda tarjeta de crédito de otro banco se declara con un grupo AID diferente, aunque ambas puedan tener el mismo AID.

Resolución de conflictos para grupos de AID de pago

Cuando una aplicación registra tarjetas físicas (grupos aid), puede declarar la categoría del grupo AID como "Pago" o "Otro". Aunque puede haber varios grupos de AID de pago registrados en un momento dado, solo se puede habilitar uno de estos grupos de AID de pago para Tap y Pay a la vez, que es seleccionado por el usuario. Este comportamiento existe porque el usuario espera tener el control de elegir conscientemente una sola tarjeta de pago, crédito o débito para que no pague con una tarjeta no deseada diferente al pulsar su dispositivo en un terminal.

Sin embargo, se pueden habilitar varios grupos de AID registrados como "Otros" al mismo tiempo sin interacción del usuario. Este comportamiento existe porque se espera que otros tipos de tarjetas, como las de fidelización, los cupones o las de transporte, funcionen sin esfuerzo ni necesidad de activación cada vez que acercan su teléfono.

Todos los grupos AID registrados como "Pago" aparecen en la lista de tarjetas de la página la Configuración de NFC, donde el usuario puede seleccionar su tarjeta predeterminada de pago. Cuando se selecciona una tarjeta de pago predeterminada, la aplicación que registró este grupo de AID de pago se convierte en la aplicación de pago predeterminada. Las aplicaciones de pago predeterminadas pueden habilitar o deshabilitar cualquiera de sus grupos de AID sin interacción del usuario. Si el usuario rechaza el aviso de aplicación de pago predeterminado, la aplicación de pago predeterminada actual (si existe) sigue siendo predeterminada. En la captura de pantalla siguiente se muestra la página Configuración de NFC.

Captura de pantalla de la página de configuración de NFC

Con la captura de pantalla de ejemplo anterior, si el usuario cambia su tarjeta de pago predeterminada a otra tarjeta que no está registrada por "Aplicación HCE 1", el sistema crea una solicitud de confirmación para el consentimiento del usuario. Sin embargo, si el usuario cambia su tarjeta de pago predeterminada a otra tarjeta registrada por "Aplicación HCE 1", el sistema no crea una solicitud de confirmación para el usuario como "Aplicación HCE1" ya es la aplicación de pago predeterminada.

Resolución de conflictos para grupos de AID por impago

Las tarjetas de no pago clasificadas como "Otros" no aparecen en la página de configuración de NFC.

La aplicación puede crear, registrar y habilitar grupos de AID sin pago de la misma manera que los grupos de AID de pago. La principal diferencia es que para los grupos de AID que no son de pago, la categoría de emulación se establece en "Other" en lugar de "Pago". Después de registrar el grupo AID con el sistema, debe habilitar el grupo AID para recibir tráfico NFC. Cuando intenta permitir que un grupo de AID no de pago reciba tráfico, no se le pedirá al usuario una confirmación a menos que haya un conflicto con uno de los AID que ya se han registrado en el sistema mediante una aplicación diferente. Si hay un conflicto, se informará al usuario sobre qué tarjeta y su aplicación asociada se deshabilitarán si el usuario decide habilitar el grupo AID recién registrado.

Coexistencia con aplicaciones NFC basadas en SIM

En Windows 10 Mobile, el sistema configura la tabla de enrutamiento del controlador NFC que se usa para tomar decisiones de enrutamiento en la capa del controlador. La tabla contiene información de enrutamiento para los siguientes elementos.

Rutas de AID individuales.
Ruta basada en protocolo (ISO-DEP).
Enrutamiento basado en tecnología (NFC-A/B/F).

Cuando un lector externo envía un comando "SELECT AID", el controlador NFC comprueba primero las rutas AID en la tabla de enrutamiento para obtener una coincidencia. Si no hay ninguna coincidencia, usará la ruta basada en protocolo como ruta predeterminada para el tráfico de ISO-DEP (14443-4-A). Para cualquier otro tráfico que no sea deISO-DEP usará el enrutamiento basado en tecnología.

Windows 10 Mobile proporciona una opción de menú "Tarjeta SIM" en la página Configuración nfc para seguir usando aplicaciones heredadas basadas en SIM de Windows Phone 8.1, que no registran sus AID con el sistema. Si el usuario selecciona "tarjeta SIM" como su tarjeta de pago predeterminada, la ruta de ISO-DEP se establece en UICC, para todas las demás selecciones del menú desplegable la ruta ISO-DEP es para el host.

La ruta de ISO-DEP se establece en "Tarjeta SIM" para dispositivos que tienen una tarjeta SIM habilitada para SE cuando el dispositivo se arranca por primera vez con Windows 10 Mobile. Cuando el usuario instala una aplicación habilitada para HCE y esa aplicación habilita los registros de grupos de HCE AID, la ruta de ISO-DEP se apuntará al host. Las nuevas aplicaciones basadas en SIM deben registrar los AID en la SIM para que las rutas de AID específicas se rellenen en la tabla de enrutamiento del controlador.

Creación de una aplicación basada en HCE

La aplicación HCE tiene dos partes.

La aplicación principal en primer plano para la interacción del usuario.
Tarea en segundo plano desencadenada por el sistema para procesar las APDUs de un AID determinado.

Debido a los requisitos de rendimiento extremadamente estrictos para cargar la tarea en segundo plano en respuesta a una pulsación NFC, se recomienda implementar toda la tarea en segundo plano en el código nativo de C++/CX (incluidas las dependencias, referencias o bibliotecas que dependa) en lugar de código administrado o C#. Aunque C# y el código administrado normalmente funcionan bien, hay sobrecarga, como cargar .NET CLR, que se puede evitar escribiendo en C++/CX.

Cree y registre su tarea en segundo plano

Debe crear una tarea en segundo plano de tu aplicación HCE para procesar y responder a las APDUs enrutadas a ella por el sistema. Durante la primera vez que se inicia la aplicación, el primer plano registra una tarea en segundo plano de HCE que implementa la interfaz IBackgroundTaskRegistration tal como se muestra en el código siguiente.

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

Observe que el desencadenador de tareas está establecido en SmartCardTriggerType. EmulatorHostApplicationActivated. Esto significa que cada vez que el sistema operativo recibe un comando APDU SELECT AID que se dirige a tu aplicación, se iniciará la tarea en segundo plano.

Recepción y respuesta a las APDUs

Cuando hay una APDU destinada a la aplicación, el sistema iniciará la tarea en segundo plano. La tarea en segundo plano recibe la APDU que se pasa a través de la propiedad SmartCardEmulatorApduReceivedEventArgs del objeto CommandApdu y responde a la APDU mediante el método TryRespondAsync del mismo objeto. Considere la posibilidad de mantener la tarea en segundo plano para las operaciones ligeras por motivos de rendimiento. Por ejemplo, responda a los APDUs inmediatamente y salga de su tarea en segundo plano cuando se complete todo el procesamiento. Debido a la naturaleza de las transacciones NFC, los usuarios tienden a mantener su dispositivo en el lector durante una cantidad de tiempo muy corta. La tarea en segundo plano seguirá recibiendo tráfico del lector hasta que se desactive la conexión, en cuyo caso recibirá un objeto SmartCardEmulatorConnectionDeactivatedEventArgs. La conexión se puede desactivar debido a los siguientes motivos, como se indica en la propiedad SmartCardEmulatorConnectionDeactivatedEventArgs.Reason.

Si la conexión se desactiva con el valor de ConnectionLost, significa que el usuario alejó su dispositivo del lector. Si la aplicación requiere que el usuario mantenga pulsado en el terminal durante más tiempo, es posible que desee proporcionarles retroalimentación. Tienes que finalizar tu tarea en segundo plano rápidamente (completando tu acción diferida) para asegurarte de que, si los usuarios pulsan de nuevo, no haya retrasos mientras finaliza la tarea en segundo plano anterior.
Si la conexión se desactiva con el ConnectionRedirected, significa que el terminal envió un nuevo comando SELECT AID APDU dirigido a otro AID. En este caso, la aplicación debe salir de la tarea en segundo plano inmediatamente (completando el aplazamiento) para permitir que se ejecute otra tarea en segundo plano.

La tarea en segundo plano también debe registrarse para el evento canceled en interfaz IBackgroundTaskInstancey, del mismo modo, salir rápidamente de la tarea en segundo plano (completando el aplazamiento) porque el sistema desencadena este evento cuando finaliza con la tarea en segundo plano. A continuación se muestra el código que muestra una tarea en segundo plano de la aplicación 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();
 }
}

Crear y registrar grupos AID

Durante el primer inicio de la aplicación, cuando se aprovisione la tarjeta, creará y registrará grupos AID con el sistema. El sistema determina la aplicación con la que un lector externo quiere comunicarse y enrutar las APDUs según corresponda, basándose en los AIDs registrados y en las configuraciones del usuario.

La mayoría de las tarjetas de pago están registradas bajo el mismo AID, el entorno del sistema de pago por proximidad (PPSE), junto con AIDs adicionales específicos de la red de pago. Cada grupo aid representa una tarjeta y cuando el usuario habilita la tarjeta, todos los AID del grupo están habilitados. Del mismo modo, cuando el usuario desactiva la tarjeta, se deshabilitan todos los AID del grupo.

Para registrar un grupo AID, debe crear un objeto SmartCardAppletIdGroup y configurar sus propiedades para indicar que es una tarjeta de pago que utiliza HCE. El nombre para mostrar debe ser descriptivo para el usuario, ya que se mostrará en el menú de configuración de NFC, así como en las indicaciones del usuario. Para las tarjetas de pago HCE, la propiedad SmartCardEmulationCategory debe configurarse como Payment y la propiedad SmartCardEmulationType debe configurarse como Host.

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

Para las tarjetas HCE sin pago, la propiedad SmartCardEmulationCategory debe establecerse en Otro y la propiedad SmartCardEmulationType debe establecerse en Anfitrión.

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

Puede incluir hasta 9 AIDs (de longitud de 5 a 16 bytes cada uno) por grupo de AIDs.

Use el método RegisterAppletIdGroupAsync para registrar el grupo AID con el sistema, que devolverá un objeto SmartCardAppletIdGroupRegistration. De forma predeterminada, la propiedad ActivationPolicy del objeto de registro se establece en Deshabilitada. Esto significa que, aunque los AID están registrados con el sistema, aún no están habilitados y no recibirán tráfico.

reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);

Puede habilitar las tarjetas registradas (grupos AID) mediante el método RequestActivationPolicyChangeAsync de la claseSmartCardAppletIdGroupRegistration como sigue. Dado que solo se puede habilitar una sola tarjeta de pago a la vez en el sistema, establecer el ActivationPolicy de un grupo de AID de pago en Habilitado es igual que establecer la tarjeta de pago predeterminada. Se pedirá al usuario que permita esta tarjeta como una tarjeta de pago predeterminada, independientemente de si ya hay una tarjeta de pago predeterminada seleccionada o no. Esta declaración no es cierta si la aplicación ya es la aplicación de pago predeterminada y simplemente cambia entre grupos de AID propios. Puede registrar hasta 10 grupos AID por aplicación.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);

Puedes consultar los grupos de AID registrados de la aplicación con el sistema operativo y comprobar su directiva de activación mediante el método GetAppletIdGroupRegistrationsAsync.

Se notificará a los usuarios cuando se cambie la directiva de activación de una tarjeta de pago de Deshabilitado a Habilitado, solo si su aplicación no es ya la aplicación de pago predeterminada. A los usuarios solo se les pedirá cuando cambie la política de activación de una tarjeta que no es de pago de Deshabilitado a Habilitado si hay un conflicto de AID.

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

Notificación de eventos cuando cambia la directiva de activación

En tu tarea en segundo plano, puedes registrarte para recibir eventos cuando la política de activación de uno de los registros de tu grupo AID cambie fuera de tu aplicación. Por ejemplo, el usuario puede cambiar la aplicación de pago predeterminada a través del menú de configuración NFC de una de las tarjetas a otra tarjeta hospedada por otra aplicación. Si la aplicación necesita saber sobre este cambio para la configuración interna, como actualizar iconos dinámicos, puede recibir notificaciones de eventos para este cambio y tomar medidas en la aplicación en consecuencia.

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

Comportamiento de invalidación en primer plano

Puedes cambiar la PolíticaDeActivación de cualquiera de los registros de grupo AID a ForegroundOverride cuando tu aplicación está en primer plano sin preguntar al usuario. Cuando el usuario pulsa su dispositivo en un terminal mientras la aplicación está en primer plano, el tráfico se enruta a la aplicación incluso si el usuario no ha elegido ninguna de las tarjetas de pago como su tarjeta de pago predeterminada. Cuando cambias la directiva de activación de una tarjeta a ForegroundOverride, este cambio solo es temporal hasta que la aplicación deje el primer plano y no cambiará la tarjeta de pago predeterminada actual establecida por el usuario. Puede cambiar la política de activación de las tarjetas de pago o no pago desde tu aplicación en primer plano como se indica a continuación. Tenga en cuenta que el método RequestActivationPolicyChangeAsync solo se puede llamar desde una aplicación en primer plano y no se puede llamar desde una tarea en segundo plano.

reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);

Además, puede registrar un grupo de AID que consta de una sola AID de longitud 0, lo que hará que el sistema enrute todas las APDUs independientemente de la AID e incluya cualquier APDU de comando enviada antes de recibir un comando SELECT AID. Sin embargo, este grupo de AID solo funciona cuando tu aplicación está activa en primer plano, ya que solo puede establecerse en ForegroundOverride y no se puede habilitar de forma permanente. Además, este mecanismo funciona tanto para los valores Host y UICC de la enumeración SmartCardEmulationType, ya sea para enrutar todo el tráfico a tu tarea en segundo plano HCE o a la tarjeta 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);

Comprobación de la compatibilidad con NFC y HCE

La aplicación debe comprobar si un dispositivo tiene hardware NFC, admite la característica de emulación de tarjeta y admite la emulación de tarjeta host antes de ofrecer estas características al usuario.

La característica de emulación de tarjeta inteligente NFC solo está habilitada en Windows 10 Mobile, por lo que al intentar usar las API del emulador de tarjetas inteligentes en cualquier otra versión de Windows 10, se producirán errores. Puede comprobar si hay compatibilidad con la API de tarjeta inteligente en el siguiente fragmento de código.

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

Además, puede comprobar si el dispositivo tiene hardware NFC capaz de alguna forma de emulación de tarjeta comprobando si el método SmartCardEmulator.GetDefaultAsync devuelve null. Si lo hace, no se admite ninguna emulación de tarjeta NFC en el dispositivo.

var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<

La compatibilidad con el enrutamiento UICC basado en HCE y AID solo está disponible en dispositivos lanzados recientemente, como Lumia 730, 830, 640 y 640 XL. Cualquier nuevo dispositivo compatible con NFC que ejecute Windows 10 Mobile y después debe admitir HCE. La aplicación puede comprobar si hay compatibilidad con HCE como se indica a continuación.

Smartcardemulator.IsHostCardEmulationSupported();

Bloqueo de pantalla y comportamiento de desactivación de pantalla

Windows 10 Mobile tiene la configuración de emulación de tarjeta de nivel de dispositivo, que puede establecer el operador de telefonía móvil o el fabricante del dispositivo. De forma predeterminada, el interruptor "puntear para pagar" está deshabilitado y la "directiva de habilitación en el nivel de dispositivo" está establecida en "Siempre", a menos que el MO o el OEM sobrescriban estos valores.

Tu aplicación puede consultar el valor de la EnablementPolicy a nivel de dispositivo y tomar medidas para cada caso en función del comportamiento deseado de la aplicación en cada estado.

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 tarea en segundo plano de tu aplicación se iniciará incluso si el teléfono está bloqueado y/o la pantalla está apagada, solo si el lector externo selecciona un AID que se asocia a tu aplicación. Puede responder a los comandos del lector en la tarea en segundo plano, pero si necesita alguna entrada del usuario o si desea mostrar un mensaje al usuario, puede iniciar la aplicación en primer plano con algunos argumentos. La tarea en segundo plano puede iniciar la aplicación en primer plano con el siguiente comportamiento.

En la pantalla de bloqueo del dispositivo (el usuario verá la aplicación en primer plano solo después de desbloquear el dispositivo).
Encima de la pantalla de bloqueo del dispositivo (después de que el usuario descarte la aplicación, el dispositivo sigue en estado bloqueado)

        if (Windows::Phone::System::SystemProtection::ScreenLocked)
        {
            // Launch above the lock with some arguments
            var result = await eventDetails.TryLaunchSelfAsync("app-specific arguments", SmartCardLaunchBehavior.AboveLock);
        }

Registro de AID y otras actualizaciones para aplicaciones basadas en SIM

Las aplicaciones de emulación de tarjetas que usan la SIM como elemento seguro pueden registrarse con el servicio de Windows para declarar los AID admitidos en la SIM. Este registro es muy similar a un registro de aplicaciones basado en HCE. La única diferencia es el SmartCardEmulationType, que debe configurarse como Uicc para aplicaciones basadas en SIM. Como resultado del registro de la tarjeta de pago, el nombre para mostrar de la tarjeta también se rellenará en el menú de configuración NFC.

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

Compartir a través de