Crear una aplicación de tarjeta NFC inteligente
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 configurarlo, consulte Prueba con el Emulador de Microsoft para Windows 10 Mobile.
Opcionalmente, si quiere probar con un dispositivo Windows 10 Mobile real en lugar del emulador de Windows 10 Mobile incluido, también necesitará los siguientes elementos.
- Un dispositivo Windows 10 Mobile con compatibilidad con NFC HCE.
- Un terminal lector que admita los 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 quieren 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 APDU tal como se define en la especificación ISO-IEC 7816-4. Windows 10 admite la tecnología ISO/IEC 14443-4 de tipo A para aplicaciones HCE. Las tecnologías de tipo B, tipo F y no ISO-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.
Selección de aplicaciones y enrutamiento de AID
Para desarrollar una aplicación HCE, debe 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 acerca su dispositivo Windows 10 Mobile a 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 un contacto, 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 la configuración de usuario, el tráfico APDU se enruta a una aplicación específica, que enviará una APDU de respuesta. Tenga en cuenta que un terminal puede querer comunicarse con varias aplicaciones diferentes durante la misma pulsación. Por lo tanto, debe asegurarse 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 HCE deben registrarse con determinados AID que puedan controlar para que reciban las APDU de un AID. Las aplicaciones declaran los AID mediante grupos de AID. Un grupo de AID es conceptualmente equivalente a una tarjeta física individual. Por ejemplo, una tarjeta de crédito se declara con un grupo de AID y una segunda tarjeta de crédito de otro banco se declara con un grupo de AID diferente, un segundo grupo de AID, aunque ambas pueden 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 de AID como "Pago" u "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 Tocar y pagar a la vez, que es seleccionado por el usuario. Este comportamiento existe porque el usuario espera tener el control y poder elegir conscientemente una sola tarjeta de pago, crédito o débito para no pagar con otra tarjeta no deseada al tocar un terminal con su dispositivo.
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 fidelidad, cupones o tránsito funcionen sin esfuerzo y sin preguntar cada vez que se toque un terminal con el teléfono.
Todos los grupos AID registrados como "Pago" aparecen en la lista de tarjetas de la página de Configuración NFC, donde el usuario puede seleccionar su tarjeta de pago predeterminada. 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 la aplicación de pago predeterminada, la aplicación de pago predeterminada actual (si existe) sigue siendo la predeterminada. En la captura de pantalla siguiente se muestra la página de Configuración 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 porque "Aplicación HCE1" ya es la aplicación de pago predeterminada.
Resolución de conflictos para grupos de AID no de pago
Las tarjetas no de 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 no de 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 "Otros" 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 intente permitir que un grupo de AID que no es 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 le pedirá al usuario información sobre la tarjeta que desea usar y se deshabilitará la aplicación asociada 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 ISO-DEP (14443-4-A). Para cualquier otro tráfico que no sea ISO-DEP, usará el enrutamiento basado en tecnología.
Windows 10 Mobile proporciona una opción de menú de "Tarjeta SIM" en la página Configuración de NFC para seguir usando aplicaciones basadas en SIM de Windows Phone 8.1 heredadas, que no registran sus AID con el sistema. Si el usuario selecciona "Tarjeta SIM" como tarjeta de pago predeterminada, la ruta 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 ISO-DEP se establece en "Tarjeta SIM" para dispositivos que tienen una tarjeta SIM habilitada para SE cuando el dispositivo se inicia 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 AID HCE, la ruta ISO-DEP 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.
- Una tarea en segundo plano desencadenada por el sistema para procesar las APDU 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 de las 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 escribiéndolo en C++/CX.
Creación y registro de la tarea en segundo plano
Debe crear una tarea en segundo plano en la aplicación HCE para procesar y responder a las APDU 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 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 tarea está establecido en SmartCardTriggerType. EmulatorHostApplicationActivated. Esto significa que cada vez que el sistema operativo que resuelve la aplicación reciba un comando SELECT AID, se iniciará la tarea en segundo plano.
Recepción y respuesta a APDU
Cuando haya 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 CommandApdu del objeto SmartCardEmulatorApduReceivedEventArgs 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 las APDU inmediatamente y salga de la 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 SmartCardEmulator Conectar ionDeactivatedEventArgs.Reason.
- Si la conexión se desactiva con el valor ConectionLost, significa que el usuario separó el dispositivo del lector. Si la aplicación necesita que el usuario lo mantenga sobre el terminal más tiempo, es posible que le interese mostrarle algún mensaje. Debe finalizar la tarea en segundo plano rápidamente (completando el aplazamiento) para asegurarse de que si lo acerca de nuevo no se retrasará mientras se espera que se cierre la tarea en segundo plano anterior.
- Si la conexión se desactiva con ConectionRedirected, significa que el terminal envió una nueva APDU de comando SELECT AID dirigida 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 Cancelado en la interfaz IBackgroundTaskInstance y, 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. El código siguiente 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 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();
}
}
Creación y registro de grupos de AID
Durante el primer inicio de la aplicación cuando se aprovisiona la tarjeta, creará y registrará grupos de AID con el sistema. El sistema determina la aplicación a la que un lector externo desea comunicarse y enrutar las APDU según corresponda en función de los AID registrados y la configuración del usuario.
La mayoría de las tarjetas de pago se registran para el mismo AID, entorno de sistema de pago por proximidad (PPSE), junto con AID específicos de tarjetas de red de pago adicionales. Cada grupo de AID representa una tarjeta y cuando el usuario habilita la tarjeta se habilitan todos los AID del grupo. Del mismo modo, cuando el usuario desactiva la tarjeta, se deshabilitan todos los AID del grupo.
Para registrar un grupo de AID, debe crear un objeto SmartCardAppletIdGroup y establecer sus propiedades para reflejar que se trata de una tarjeta de pago basada en 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 establecerse en Pago y la propiedad SmartCardEmulationType debe establecerse en 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 que no son de pago, la propiedad SmartCardEmulationCategory debe establecerse en Otros y la propiedad SmartCardEmulationType debe establecerse en Host.
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 AID (con una longitud de 5 a 16 bytes cada uno) por grupo de AID.
Use el método RegisterAppletIdGroupAsync para registrar el grupo de 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 en 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 de AID) mediante el método RequestActivationPolicyChangeAsync de la clase SmartCardAppletIdGroupRegistration, como se muestra a continuación. Dado que solo se puede habilitar una tarjeta de pago a la vez en el sistema, establecer la ActivationPolicy de un grupo de AID de pago en Habilitado es lo mismo que establecer la tarjeta de pago predeterminada. Se pedirá al usuario que permita esta tarjeta como tarjeta de pago predeterminada, independientemente de si ya hay una tarjeta de pago predeterminada seleccionada. Lo anterior no es cierto si la aplicación ya es la aplicación de pago predeterminada y simplemente está cambiando entre grupos de AID propios. Puede registrar hasta 10 grupos de AID por aplicación.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);
Puede 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 pedirá a los usuarios que cambien la directiva de activación de una tarjeta de pago de Deshabilitado a Habilitado solo si la aplicación aún no es la aplicación de pago predeterminada. Solo se pedirá a los usuarios cuando cambie la directiva 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 la tarea en segundo plano, puede registrarse para recibir eventos cuando la directiva de activación de uno de los registros de grupo de AID cambie fuera de la aplicación. Por ejemplo, el usuario puede cambiar la aplicación de pago predeterminada a través del menú de configuración de NFC de una de las tarjetas a otra tarjeta hospedada por otra aplicación. Si la aplicación necesita conocer 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
Puede cambiar la ActivationPolicy de cualquiera de los registros de grupos de AID a ForegroundOverride mientras la aplicación está en primer plano sin preguntar al usuario. Cuando el usuario acerca su dispositivo a 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 tarjeta de pago predeterminada. Cuando cambia la directiva de activación de una tarjeta a ForegroundOverride, este cambio solo es temporal hasta que la aplicación salga del primer plano y no cambiará la tarjeta de pago predeterminada actual establecida por el usuario. Puede cambiar la ActivationPolicy de sus tarjetas de pago o no de pago desde la aplicación en primer plano de la siguiente manera. 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 conste de un solo AID de longitud 0, lo que hará que el sistema enrute todas las APDU independientemente de la AID e incluir las APDU de comando enviadas antes de recibir un comando SELECT AID. Sin embargo, este tipo de grupo de AID solo funciona mientras la aplicación está en primer plano porque solo se puede establecer en ForegroundOverride y no se puede habilitar de forma permanente. Además, este mecanismo funciona para los valores Host y UICC de la enumeración SmartCardEmulationType para enrutar todo el tráfico a la tarea en segundo plano de 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 versiones posteriores 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 una 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 botón de alternancia "Tocar 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.
La aplicación puede consultar el valor de EnablementPolicy en el nivel del 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 la aplicación se iniciará cuando el teléfono está bloqueado o la pantalla está desactivada solo si el lector externo selecciona un AID que se resuelve en la 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 establecerse en 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 de NFC.
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Uicc);
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de