Criar um aplicativo de cartão inteligente NFC
Importante
Este tópico aplica-se apenas ao Windows 10 Mobile.
Este tópico descreve como usar a Emulação de Cartão Host (HCE) para se comunicar diretamente com um leitor de cartão NFC (comunicação de campo próximo) e permitir que seus clientes acessem seus serviços por meio do telefone (em vez de um cartão físico) sem uma operadora de rede móvel (MNO).
O que você precisa para desenvolver um aplicativo HCE
Para desenvolver um aplicativo de emulação de cartão baseado em HCE, você precisa instalar o Microsoft Visual Studio 2015 (consulte a página de download do Visual Studio) (inclui as ferramentas para desenvolvedores do Windows) e o emulador do Windows 10 Mobile.
Para obter mais informações sobre como obter a instalação, consulte Testar com o emulador da Microsoft para Windows 10 Mobile.
Opcionalmente, se você quiser testar com um dispositivo Windows 10 Mobile real em vez do emulador do Windows 10 Mobile incluído, você também precisará dos seguintes itens.
- Um dispositivo Windows 10 Mobile com suporte a NFC HCE.
- Um terminal leitor que suporta os protocolos ISO/IEC 14443-4 e ISO/IEC 7816-4
O Windows 10 Mobile implementa um serviço HCE que fornece as seguintes funcionalidades.
- Os aplicativos podem registrar os identificadores de applet (AIDs) para os cartões que gostariam de emular.
- Resolução de conflitos e roteamento dos pares de comando e resposta APDU (Application Protocol Data Unit) para um dos aplicativos registrados com base na seleção do cartão leitor externo e na preferência do usuário.
- Tratamento de eventos e notificações para os aplicativos como resultado de ações do usuário.
O Windows 10 oferece suporte à emulação de cartões inteligentes baseados em ISO-DEP (ISO-IEC 14443-4) e se comunica usando APDUs, conforme definido na especificação ISO-IEC 7816-4. O Windows 10 oferece suporte à tecnologia ISO/IEC 14443-4 Tipo A para aplicativos HCE. As tecnologias tipo B, tipo F e não ISO-DEP (por exemplo, MIFARE) são roteadas para o SIM por padrão.
Somente dispositivos Windows 10 Mobile são habilitados com o recurso de emulação de cartão. A emulação de cartão baseada em SIM e HCE não está disponível em outras versões do Windows 10.
A arquitetura para suporte à emulação de cartão baseado em HCE e SIM é mostrada no diagrama abaixo.
Seleção de aplicativos e roteamento AID
Para desenvolver um aplicativo HCE, você deve entender como os dispositivos Windows 10 Mobile roteiam AIDs para um aplicativo específico, pois os usuários podem instalar vários aplicativos HCE diferentes. Cada aplicativo pode registrar vários cartões baseados em HCE e SIM.
Quando o usuário toca em seu dispositivo Windows 10 Mobile em um terminal, os dados são roteados automaticamente para o aplicativo adequado instalado no dispositivo. Esse roteamento é baseado no ID do applet (AID), que é um identificador de 5 a 16 bytes. Durante um toque, o terminal externo transmitirá uma APDU com comando SELECT para especificar o AID para o qual gostaria que todos os comandos APDU subsequentes fossem roteados. Os comandos SELECT subsequentes alterarão o roteamento novamente. Com base nos AIDs registrados pelos aplicativos e nas configurações do usuário, o tráfego APDU é roteado para um aplicativo específico, que enviará uma APDU como resposta. Esteja ciente de que um terminal pode querer se comunicar com vários aplicativos diferentes durante o mesmo toque. Portanto, você deve garantir que a tarefa em segundo plano do seu aplicativo seja encerrada o mais rápido possível quando desativada para abrir espaço para que a tarefa em segundo plano de outro aplicativo responda à APDU. Discutiremos as tarefas em segundo plano mais adiante neste tópico.
Os aplicativos HCE devem se registrar com AIDs específicos com os quais consigam lidar para que recebam APDUs para um AID. Os aplicativos declaram AIDs usando grupos AID. Um grupo AID é conceitualmente equivalente a um cartão físico individual. Por exemplo, um cartão de crédito é declarado com um grupo AID e um segundo cartão de crédito de um banco diferente é declarado com um segundo grupo AID diferente, mesmo que ambos possam ter o mesmo AID.
Resolução de conflitos para grupos AID de pagamento
Quando um aplicativo registra cartões físicos (grupos AID), ele pode declarar a categoria de grupo AID como "Pagamento" ou "Outro". Embora possa haver vários grupos AID de pagamento registrados a qualquer momento, apenas um desses grupos AID de pagamento pode ser habilitado para Tocar e pagar por vez, que é selecionado pelo usuário. Esse comportamento existe porque o usuário espera estar no controle de escolher conscientemente um único cartão de pagamento, crédito ou débito a ser usado para que não pague com um cartão não intencional diferente ao tocar em seu dispositivo em um terminal.
No entanto, vários grupos AID registrados como "Outros" podem ser habilitados ao mesmo tempo sem interação do usuário. Esse comportamento existe porque outros tipos de cartões, como fidelidade, cupons ou transporte público, devem funcionar sem qualquer esforço ou aviso sempre que tocarem no telefone.
Todos os grupos AID registrados como "Pagamento" aparecem na lista de cartões na página Configurações de NFC, em que o usuário pode selecionar seu cartão de pagamento padrão. Quando um cartão de pagamento padrão é selecionado, o aplicativo que registrou esse grupo AID de pagamento se torna o aplicativo de pagamento padrão. Os aplicativos de pagamento padrão podem habilitar ou desabilitar qualquer um de seus grupos AID sem a interação do usuário. Se o usuário recusar o prompt do aplicativo de pagamento padrão, o aplicativo de pagamento padrão atual (se houver) continuará como padrão. A seguinte captura de tela mostra a página Configurações de NFC.
Usando a captura de tela de exemplo acima, se o usuário alterar seu cartão de pagamento padrão para outro cartão que não esteja registrado por "Aplicativo HCE 1", o sistema criará um prompt de confirmação para o consentimento do usuário. No entanto, se o usuário alterar seu cartão de pagamento padrão para outro cartão registrado pelo "Aplicativo HCE 1", o sistema não criará um prompt de confirmação para o usuário, pois "Aplicativo HCE 1" já é o aplicativo de pagamento padrão.
Resolução de conflitos para grupos AID que não são de pagamento
Os cartões que não são de pagamento categorizados como "Outros" não aparecem na página de configurações de NFC.
Seu aplicativo pode criar, registrar e habilitar grupos AID que não são de pagamento da mesma maneira que grupos AID de pagamento. A principal diferença é que, para grupos AID que não são de pagamento, a categoria de emulação é definida como "Outros" em oposição a "Pagamento". Depois de registrar o grupo AID no sistema, você precisa habilitar o grupo AID para receber tráfego NFC. Quando você tenta habilitar um grupo AID que não é de pagamento para receber tráfego, o usuário não é solicitado a confirmar, a menos que haja um conflito com um dos AIDs já registrados no sistema por um aplicativo diferente. Se houver um conflito, o usuário verá informações sobre qual cartão e qual aplicativo associado serão desativados se o usuário optar por habilitar o grupo AID recém-registrado.
Coexistência com aplicativos NFC baseados em SIM
No Windows 10 Mobile, o sistema configura a tabela de roteamento do controlador NFC que é usada para tomar decisões de roteamento na camada do controlador. A tabela contém informações de roteamento para os itens a seguir.
- Rotas individuais de AID.
- Rota baseada em protocolo (ISO-DEP).
- Roteamento baseado em tecnologia (NFC-A/B/F).
Quando um leitor externo envia um comando "SELECT AID", o controlador NFC primeiro verifica as rotas do AID na tabela de roteamento para uma correspondência. Se não houver correspondência, ele usará a rota baseada em protocolo como a rota padrão para o tráfego ISO-DEP (14443-4-A). Para qualquer outro tráfego que não seja de ISO-DEP, ele usará o roteamento baseado em tecnologia.
O Windows 10 Mobile fornece uma opção de menu "Cartão SIM" na página Configurações de NFC para continuar a usar aplicativos herdados baseados em SIM do Windows Phone 8.1, que não registram seus AIDs no sistema. Se o usuário selecionar "cartão SIM" como seu cartão de pagamento padrão, a rota ISO-DEP será definida como UICC, para todas as outras seleções no menu suspenso, a rota ISO-DEP será para o host.
A rota ISO-DEP é definida como "Cartão SIM" para dispositivos que têm um cartão SIM habilitado para ES quando o dispositivo é inicializado pela primeira vez com o Windows 10 Mobile. Quando o usuário instala um aplicativo habilitado para HCE e esse aplicativo habilita qualquer registro de grupo HCE AID, a rota ISO-DEP será apontada para o host. Novos aplicativos baseados em SIM precisam registrar os AIDs no SIM para que as rotas específicas do AID sejam preenchidas na tabela de roteamento do controlador.
Criar um aplicativo baseado em HCE
Seu aplicativo HCE tem duas partes.
- O principal aplicativo em primeiro plano para a interação do usuário.
- Uma tarefa em segundo plano que é acionada pelo sistema para processar APDUs para um determinado AID.
Devido aos requisitos de desempenho extremamente rígidos para carregar sua tarefa em segundo plano em resposta a um toque NFC, recomendamos que toda a tarefa em segundo plano seja implementada em código nativo C++/CX (incluindo quaisquer dependências, referências ou bibliotecas das quais você dependa) em vez de C# ou código gerenciado. Embora o C# e o código gerenciado normalmente tenham um bom desempenho, há sobrecarga, como carregar o .NET CLR, que pode ser evitada gravando-o em C++/CX.
Criar e registrar uma tarefa em segundo plano
Você precisa criar uma tarefa em segundo plano em seu aplicativo HCE para processar e responder a APDUs roteadas para ele pelo sistema. Na primeira vez que seu aplicativo é iniciado, o primeiro plano registra uma tarefa em segundo plano HCE que implementa a interface IBackgroundTaskRegistration, conforme mostrado no código a seguir.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();
Observe que o gatilho da tarefa está definido como SmartCardTriggerType. EmulatorHostApplicationActivated. Isso significa que sempre que uma APDU com comando SELECT AID for recebida pelo sistema operacional resolvendo para seu aplicativo, sua tarefa em segundo plano será iniciada.
Receber e responder a APDUs
Quando houver uma APDU direcionada para seu aplicativo, o sistema iniciará sua tarefa em segundo plano. Sua tarefa em segundo plano recebe a APDU passada pela propriedade CommandApdu do objeto SmartCardEmulatorApduReceivedEventArgs e responde à APDU usando o método TryRespondAsync do mesmo objeto. Considere manter sua tarefa em segundo plano para operações leves por motivos de desempenho. Por exemplo, responda às APDUs imediatamente e saia da tarefa em segundo plano quando todo o processamento estiver concluído. Devido à natureza das transações NFC, os usuários tendem a manter seu dispositivo contra o leitor por apenas um período muito curto de tempo. Sua tarefa em segundo plano continuará a receber tráfego do leitor até que sua conexão seja desativada, caso em que você receberá um objeto SmartCardEmulatorConnectionDeactivatedEventArgs. Sua conexão pode ser desativada devido aos seguintes motivos, conforme indicado na propriedade SmartCardEmulatorConnectionDeactivatedEventArgs.Reason.
- Se a conexão for desativada com o valor ConnectionLost, isso significa que o usuário afastou seu dispositivo do leitor. Se o seu aplicativo precisar que o usuário toque no terminal por mais tempo, convém informar isso. Você deve encerrar sua tarefa em segundo plano rapidamente (concluindo seu adiamento) para garantir que, se ela for tocada novamente, ela não será adiada aguardando a tarefa em segundo plano anterior sair.
- Se a conexão for desativada com o ConnectionRedirected, isso significa que o terminal enviou um novo comando SELECT AID da APDU direcionado para um AID diferente. Nesse caso, seu aplicativo deve sair da tarefa em segundo plano imediatamente (concluindo o adiamento) para permitir que outra tarefa em segundo plano seja executada.
A tarefa em segundo plano também deve se registrar para o Evento cancelado em IBackgroundTaskInstance interface e, da mesma forma, sair rapidamente da tarefa em segundo plano (concluindo o adiamento) porque esse evento é acionado pelo sistema quando é encerrado com sua tarefa em segundo plano. Abaixo está o código que demonstra uma tarefa em segundo plano do aplicativo 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();
}
}
Criar e registrar grupos AID
Durante o primeiro lançamento do seu aplicativo, quando o cartão estiver sendo provisionado, você criará e registrará grupos AID no sistema. O sistema determina o aplicativo com o qual um leitor externo gostaria de se comunicar e roteia APDUs adequadamente com base nos AIDs registrados e nas configurações do usuário.
A maioria dos cartões de pagamento é registrada para o mesmo AID, ambiente de sistema de pagamento por proximidade (PPSE) e AIDs específicos de placa de rede de pagamento adicionais. Cada grupo AID representa um cartão e quando o usuário habilita o cartão, todos os AIDs no grupo são habilitados. Da mesma forma, quando o usuário desativa o cartão, todos os AIDs do grupo são desabilitados.
Para registrar um grupo AID, você precisa criar um objeto SmartCardAppletIdGroup e definir suas propriedades para refletir que este é um cartão de pagamento baseado em HCE. Seu nome de exibição deve ser descritivo para o usuário, pois ele aparecerá no menu de configurações de NFC, bem como nos prompts do usuário. Para cartões de pagamento HCE, a propriedade SmartCardEmulationCategory deve ser definida como Payment, e a propriedade SmartCardEmulationType deve ser definida 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 cartões HCE que não são de pagamento, a propriedade SmartCardEmulationCategory deve ser definida como Other, e a propriedade SmartCardEmulationType deve ser definida como 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);
Você pode incluir até 9 AIDs (de 5 a 16 bytes cada) por grupo AID.
Use o método RegisterAppletIdGroupAsync para registrar seu grupo AID no sistema, que retornará um objeto SmartCardAppletIdGroupRegistration. Por padrão, a propriedade ActivationPolicy do objeto de registro é definida como Disabled. Isso significa que, mesmo que seus AIDs estejam registrados no sistema, eles ainda não estão habilitados e não receberão tráfego.
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
Você pode habilitar seus cartões registrados (grupos AID) usando o método RequestActivationPolicyChangeAsync da classe SmartCardAppletIdGroupRegistration, conforme mostrado abaixo. Como apenas um único cartão de pagamento pode ser habilitado por vez no sistema, definir a ActivationPolicy de um grupo AID de pagamento como Habilitado é o mesmo que definir o cartão de pagamento padrão. O usuário será solicitado a permitir esse cartão como um cartão de pagamento padrão, independentemente de haver um cartão de pagamento padrão já selecionado ou não. Essa afirmação não é verdadeira se seu aplicativo já é o aplicativo de pagamento padrão e está apenas mudando entre seus próprios grupos AID. Você pode registrar até 10 grupos AID por aplicativo.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);
Você pode consultar os grupos AID registrados do seu aplicativo com o sistema operacional e verificar sua política de ativação usando o método GetAppletIdGroupRegistrationsAsync.
Os usuários serão avisados quando você alterar a política de ativação de um cartão de pagamento de Desabilitado para Habilitado, somente se seu aplicativo ainda não for o aplicativo de pagamento padrão. Os usuários só serão solicitados quando você alterar a política de ativação de um cartão que não é de pagamento de Desabilitado para Habilitado se houver um conflito de AID.
var registrations = await SmartCardEmulator.GetAppletIdGroupRegistrationsAsync();
foreach (var registration in registrations)
{
registration.RequestActivationPolicyChangeAsync (AppletIdGroupActivationPolicy.Enabled);
}
Notificação de eventos quando a política de ativação é alterada
Em sua tarefa em segundo plano, você pode se registrar para receber eventos quando a política de ativação de um dos registros de grupo AID for alterada fora do aplicativo. Por exemplo, o usuário pode alterar o aplicativo de pagamento padrão por meio do menu de configurações de NFC de um de seus cartões para outro cartão hospedado por outro aplicativo. Se seu aplicativo precisar saber sobre essa alteração para configuração interna, como atualizar blocos dinâmicos, você poderá receber notificações de eventos para essa alteração e executar ações em seu aplicativo adequadamente.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();
Comportamento de substituição em primeiro plano
Você pode alterar a ActivationPolicy de qualquer um dos seus registros de grupo AID para ForegroundOverride enquanto seu aplicativo estiver em primeiro plano sem avisar o usuário. Quando o usuário toca em seu dispositivo em um terminal enquanto seu aplicativo está em primeiro plano, o tráfego é roteado para seu aplicativo, mesmo que nenhum de seus cartões de pagamento tenha sido escolhido pelo usuário como seu cartão de pagamento padrão. Quando você altera a política de ativação de um cartão para ForegroundOverride, essa alteração é apenas temporária até que seu aplicativo saia do primeiro plano. Ela não altera o cartão de pagamento padrão atual definido pelo usuário. Você pode alterar a ActivationPolicy de seus cartões de pagamento ou que não são de pagamento do seu aplicativo em primeiro plano da seguinte maneira. Observe que o método RequestActivationPolicyChangeAsync só pode ser chamado de um aplicativo em primeiro plano e não pode ser chamado de uma tarefa em segundo plano.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);
Além disso, você pode registrar um grupo AID que consiste em um único AID de 0 comprimento que fará com que o sistema roteie todas as APDUs independentemente do AID e incluindo qualquer comando APDU enviado antes de um comando SELECT AID ser recebido. No entanto, esse grupo AID só funciona enquanto seu aplicativo está em primeiro plano porque ele só pode ser definido como ForegroundOverride e não pode ser habilitado permanentemente. Além disso, esse mecanismo funciona para valores Host e UICC da enumeração SmartCardEmulationType para rotear todo o tráfego para a tarefa em segundo plano de HCE ou para o cartão 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);
Verificar se há suporte para NFC e HCE
Seu aplicativo deve verificar se um dispositivo tem hardware NFC, suporta o recurso de emulação de cartão e oferece suporte à emulação de cartão host antes de oferecer esses recursos ao usuário.
O recurso de emulação de cartão inteligente NFC só está habilitado no Windows 10 Mobile, portanto, tentar usar as APIs do emulador de cartão inteligente em qualquer outra versão do Windows 10 causará erros. Você pode verificar se há suporte à API de cartão inteligente no trecho de código a seguir.
Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");
Além disso, você pode verificar se o dispositivo tem hardware NFC capaz de alguma forma de emulação de cartão verificando se o método SmartCardEmulator.GetDefaultAsync retorna nulo. Se isso acontecer, nenhuma emulação de cartão NFC será suportada no dispositivo.
var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<
O suporte para roteamento UICC baseado em HCE e AID só está disponível em dispositivos lançados recentemente, como o Lumia 730, 830, 640 e 640 XL. Todos os novos dispositivos compatíveis com NFC que executam o Windows 10 Mobile e versões posteriores devem oferecer suporte a HCE. Seu aplicativo pode verificar se há suporte para HCE da seguinte maneira.
Smartcardemulator.IsHostCardEmulationSupported();
Comportamento da tela de bloqueio e desligamento da tela
O Windows 10 Mobile tem configurações de emulação de cartão no nível do dispositivo, que podem ser definidas pela operadora móvel ou pelo fabricante do dispositivo. Por padrão, a alternância "tocar para pagar" está desabilitada, e a "política de ativação no nível do dispositivo" é definida como "Sempre", a menos que o MO ou o OEM substitua esses valores.
Seu aplicativo pode consultar o valor da EnablementPolicy no nível do dispositivo e executar ações para cada caso, dependendo do comportamento desejado do seu aplicativo em 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";
}
A tarefa em segundo plano do seu aplicativo será iniciada mesmo se o telefone estiver bloqueado e/ou a tela estiver desligada somente se o leitor externo selecionar um AID que resolva para seu aplicativo. Você pode responder aos comandos do leitor em sua tarefa em segundo plano, mas se precisar de qualquer entrada do usuário ou se quiser mostrar uma mensagem ao usuário, poderá iniciar seu aplicativo em primeiro plano com alguns argumentos. Sua tarefa em segundo plano pode iniciar seu aplicativo em primeiro plano com o seguinte comportamento.
- Na tela de bloqueio do dispositivo (o usuário verá seu aplicativo em primeiro plano somente depois que desbloquear o dispositivo)
- Acima da tela de bloqueio do dispositivo (depois que o usuário dispensar seu aplicativo, o dispositivo ainda ficará em 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 e outras atualizações para aplicativos baseados em SIM
Os aplicativos de emulação de cartão que usam o SIM como elemento seguro podem se registrar no serviço do Windows para declarar os AIDs com suporte no SIM. Esse registro é muito semelhante a um registro de aplicativo baseado em HCE. A única diferença é o SmartCardEmulationType, que deve ser definido como Uicc para aplicativos baseados em SIM. Como resultado do registro do cartão de pagamento, o nome de exibição do cartão também será preenchido no menu de configuração NFC.
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Uicc);
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de