Muitos dispositivos com tecnologia Android que oferecem a funcionalidade NFC já são compatíveis com emulação de cartão NFC. Na maioria dos casos, o cartão é emulado por um chip separado no dispositivo, chamado de elemento de segurança. Muitos chips fornecidos por operadoras de celular também contêm um Elemento de segurança.
O Android 4.4 e versões mais recentes oferecem um método adicional de emulação de cartão que não envolve um elemento de segurança, chamado emulação de cartão com base no host. Dessa forma, qualquer app Android pode emular um cartão e se comunicar diretamente com o leitor de NFC. Este tópico descreve como a emulação de cartão com base em host (HCE, na sigla em inglês) funciona no Android e como você pode desenvolver um app que emula um cartão NFC usando essa técnica.
Emulação de cartão com um elemento de segurança
Quando a emulação de cartão NFC é fornecida usando um elemento de segurança, o cartão a ser emulado é provisionado no elemento de segurança no dispositivo por meio de um aplicativo para Android. Depois, quando o usuário segura o dispositivo sobre um terminal NFC, o controlador de NFC no dispositivo encaminha todos os dados do leitor diretamente para o elemento de segurança. A Figura 1 ilustra esse conceito:
O próprio elemento de segurança executa a comunicação com o terminal de NFC, e nenhum app Android está envolvido na transação. Após a conclusão da transação, um app Android pode consultar o elemento de segurança diretamente para conferir o status da transação e notificar o usuário.
Emulação de cartão com base no host
Quando um cartão NFC é emulado usando emulação de cartão com base em host, os dados são roteados diretamente para a CPU do host em vez de serem roteados para um elemento de segurança. A Figura 2 ilustra como funciona a emulação de cartão com base em host:
Cartões e protocolos de NFC compatíveis
Os padrões de NFC oferecem suporte a muitos protocolos diferentes, e há diferentes tipos de cartões que podem ser emulados.
O Android 4.4 e versões mais recentes oferecem suporte a vários protocolos comuns no mercado
hoje. Muitos cartões por aproximação atuais já são baseados nesses protocolos,
como cartões de pagamento por aproximação. Esses protocolos também são compatíveis com muitos
leitores de NFC no mercado atual, incluindo dispositivos Android NFC que funcionam como
leitores em si (consulte a classe
IsoDep
). Isso permite criar e implantar uma solução de NFC completa sobre
HCE usando apenas dispositivos com tecnologia Android.
Especificamente, o Android 4.4 e versões mais recentes oferecem suporte a emulação de cartões baseados na especificação ISO-DEP da NFC-Forum (com base na ISO/IEC 14443-4) e no processamento de unidades de dados de protocolo de aplicativo (APDUs, na sigla em inglês) conforme definido na especificação ISO/IEC 7816-4. O Android determina a emulação de ISO-DEP apenas com base na tecnologia Nfc-A (ISO/IEC 14443-3 Tipo A). O suporte para a tecnologia Nfc-B (ISO/IEC 14443-4 Tipo B) é opcional. A Figura 3 ilustra a criação de camadas de todas essas especificações.
Serviços de HCE
A arquitetura de HCE no Android é baseada em componentes
Service
do Android, conhecidos como serviços
de HCE. Uma das principais vantagens de um serviço é que ele pode ser executado em
segundo plano sem nenhuma interface do usuário. Essa é uma opção natural para muitos aplicativos de HCE, como cartões de fidelidade ou de transporte público, que o usuário não precisa
iniciar um app para usar. Em vez disso, tocar o dispositivo no leitor de NFC inicia o serviço correto se ele ainda não estiver em execução e executa a transação em segundo plano. Obviamente, você pode iniciar outra IU (como
notificações do usuário) no seu serviço quando apropriado.
Seleção de serviço
Quando o usuário toca em um dispositivo em um leitor de NFC, o sistema Android precisa saber com qual serviço de HCE o leitor de NFC quer se comunicar. A especificação ISO/IEC 7816-4 define uma maneira de selecionar aplicativos com base em um ID do aplicativo (AID, na sigla em inglês). Um AID consiste em até 16 bytes. Se você estiver emulando cartões para uma infraestrutura de leitor de NFC, os AIDs que esses leitores procuram geralmente são bem conhecidos e registrados publicamente (por exemplo, os AIDs de redes de pagamento como Visa e MasterCard).
Se você quiser implantar uma nova infraestrutura de leitor para seu próprio aplicativo, registre seus próprios AIDs. O procedimento de registro de AIDs é definido na especificação ISO/IEC 7816-5. Recomendamos o registro de um AID conforme o 7816-5 se você estiver implantando um aplicativo de HCE para Android, porque isso evita colisões com outros apps.
Grupos de AID
Em alguns casos, um serviço de HCE pode precisar registrar vários AIDs e ser definido como o gerenciador padrão de todos eles para implementar um determinado aplicativo. Não há suporte para alguns AIDs no grupo que vão para outro serviço.
Uma lista de AIDs que são mantidas juntas é chamada de grupo de AIDs. Para todos os AIDs em um grupo de AIDs, o Android garante um dos seguintes itens:
- Todos os AIDs no grupo são roteados para esse serviço de HCE.
- Nenhum AID no grupo é roteado para esse serviço de HCE (por exemplo, porque o usuário preferiu outro serviço que também solicitou um ou mais AIDs no seu grupo).
Em outras palavras, não há estado intermediário, em que alguns AIDs no grupo podem ser roteados para um serviço de HCE e outros para outro.
Categorias e grupos de AID
Você pode associar cada grupo de AID a uma categoria. Isso permite que o Android agrupe serviços de HCE por categoria, o que permite que o usuário defina padrões no nível da categoria em vez do nível do AID. Evite mencionar AIDs em qualquer parte do app voltada ao usuário, porque eles não significam nada para o usuário comum.
O Android 4.4 e versões mais recentes oferecem suporte a duas categorias:
CATEGORY_PAYMENT
(inclui apps de pagamento padrão do setor)CATEGORY_OTHER
(para todos os outros apps de HCE)
Implementar um serviço de HCE
Para emular um cartão NFC usando a emulação de cartão com base em host, você precisa criar um componente
Service
que processe as transações NFC.
Verificar a compatibilidade com HCE
O aplicativo pode conferir se um dispositivo é compatível com HCE, verificando o
recurso
FEATURE_NFC_HOST_CARD_EMULATION
. Use a tag <uses-feature>
no manifesto do aplicativo para declarar que ele usa o recurso
HCE e se ele é necessário para o app funcionar ou não.
Implementação do serviço
O Android 4.4 e versões mais recentes oferecem uma classe de conveniência Service
que pode ser usada
como base para a implementação de um serviço de HCE: a
classe HostApduService
.
A primeira etapa é estender HostApduService
, conforme mostrado no exemplo de
código abaixo:
Kotlin
class MyHostApduService : HostApduService() { override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray { ... } override fun onDeactivated(reason: Int) { ... } }
Java
public class MyHostApduService extends HostApduService { @Override public byte[] processCommandApdu(byte[] apdu, Bundle extras) { ... } @Override public void onDeactivated(int reason) { ... } }
HostApduService
declara dois métodos abstratos que você precisa substituir e
implementar. Um desses métodos, processCommandApdu()
, é chamado sempre que um leitor de NFC envia uma unidade de dados do protocolo de aplicativo (APDU, na sigla em inglês) ao seu serviço. As APDUs são definidas na especificação ISO/IEC 7816-4. As APDUs são os pacotes no nível do aplicativo trocados entre o leitor de NFC e seu serviço de HCE. Esse protocolo no nível do aplicativo é half-duplex: o leitor de NFC envia uma APDU de comando e espera que você envie uma APDU de resposta em resposta.
Como mencionado anteriormente, o Android usa o AID para determinar com qual serviço de HCE o
leitor quer falar. Normalmente, a primeira APDU que um leitor de NFC envia para seu dispositivo é uma APDU SELECT AID
. Essa APDU contém o AID com que o leitor quer se comunicar. O Android extrai esse AID da APDU, o resolve para um serviço de
HCE e, em seguida, encaminha essa APDU para o serviço resolvido.
É possível enviar uma APDU de resposta retornando os bytes da APDU de resposta de processCommandApdu()
. Esse método é chamado na linha de execução principal
do aplicativo, a qual não pode ser bloqueada. Se não for possível calcular e retornar
uma APDU de resposta imediatamente, retorne nulo. Você pode fazer o trabalho necessário em
outra linha de execução e usar o método
sendResponseApdu()
definido na classe HostApduService
para enviar a resposta quando
terminar.
O Android continua encaminhando novas APDUs do leitor para seu serviço até que uma das seguintes situações aconteça:
- O leitor de NFC envia outra APDU
SELECT AID
, que o SO resolve para um serviço diferente. - o link de NFC entre o leitor de NFC e seu dispositivo seja quebrado.
Em ambos os casos, a implementação de
onDeactivated()
da classe é chamada com um argumento indicando qual dos dois aconteceu.
Se você estiver trabalhando com a infraestrutura de leitor atual, será necessário implementar o protocolo existente no nível do aplicativo que os leitores esperam no serviço de HCE.
Se você estiver implantando uma nova infraestrutura de leitor que também controla, poderá definir seu próprio protocolo e sequência de APDU. Tente limitar a quantidade de APDUs e o tamanho dos dados a serem trocados. Isso garante que os usuários precisem manter o dispositivo sobre o leitor de NFC por um curto período. Um limite superior razoável tem cerca de 1 KB de dados, que geralmente pode ser trocado em até 300 ms.
Declaração de manifesto de serviço e registro de AID
É necessário declarar o serviço no manifesto como de costume, mas também é necessário adicionar mais algumas partes à declaração de serviço:
Para informar à plataforma que é um serviço de HCE que implementa uma interface
HostApduService
, adicione um filtro de intent para a açãoSERVICE_INTERFACE
à declaração de serviço.Para informar à plataforma quais grupos de AIDs são solicitados por esse serviço, inclua uma tag
<meta-data>
SERVICE_META_DATA
na declaração do serviço, apontando para um recurso XML com mais informações sobre o serviço de HCE.Defina o atributo
android:exported
comotrue
e exija a permissãoandroid.permission.BIND_NFC_SERVICE
na declaração de serviço. O primeiro garante que o serviço possa ser vinculado por apps externos. O segundo garante que apenas apps externos que têm a permissãoandroid.permission.BIND_NFC_SERVICE
podem se vincular ao serviço. Comoandroid.permission.BIND_NFC_SERVICE
é uma permissão do sistema, isso implementa efetivamente que apenas o SO Android pode se vincular ao serviço.
Confira a seguir um exemplo de declaração de manifesto HostApduService
:
<service android:name=".MyHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apduservice"/> </service>
Essa tag de metadados aponta para um arquivo apduservice.xml
. Confira a seguir um exemplo desse arquivo com uma única declaração de grupo de AIDs contendo dois AIDs reservados:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc" android:requireDeviceUnlock="false"> <aid-group android:description="@string/aiddescription" android:category="other"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </host-apdu-service>
A tag <host-apdu-service>
precisa conter um atributo <android:description>
com uma descrição fácil de usar do serviço que você pode mostrar na
interface do app. É possível usar o atributo requireDeviceUnlock
para especificar que o
dispositivo será desbloqueado antes de invocar esse serviço para processar as APDUs.
O <host-apdu-service>
precisa conter uma ou mais tags <aid-group>
. Cada
tag <aid-group>
é necessária para fazer o seguinte:
- conter um atributo
android:description
que contenha uma descrição fácil de usar do grupo de AIDs, adequados para exibição na interface; - Ter o atributo
android:category
definido para indicar a categoria a que o grupo de AID pertence, como as constantes de string definidas porCATEGORY_PAYMENT
ouCATEGORY_OTHER
. - conter uma ou mais tags
<aid-filter>
, cada uma com um único AID; Especifique o AID no formato hexadecimal e verifique se ele contém um número par de caracteres.
O app também precisa conter a permissão
NFC
para se registrar como um
serviço de HCE.
Resolução de conflitos de AID
Vários componentes HostApduService
podem ser instalados em um único dispositivo, e
o mesmo AID pode ser registrado por mais de um serviço. O Android resolve conflitos de AID de maneira diferente, dependendo da categoria a que um AID pertence. Cada
categoria pode ter uma política de resolução de conflitos diferente.
Para algumas categorias, como pagamento, o usuário pode selecionar um serviço
padrão na interface de configurações do Android. Para outras categorias, a política pode ser
sempre perguntar ao usuário qual serviço invocar em caso de conflito. Para mais informações
sobre como consultar a política de resolução de conflitos de uma determinada categoria, consulte
getSelectionModeForCategory()
.
Verificar se o serviço é o padrão
Os aplicativos podem verificar se o serviço de HCE é o padrão para uma
determinada categoria usando a
API
isDefaultServiceForCategory()
.
Se o serviço não for o padrão, solicite que ele se torne padrão
usando
ACTION_CHANGE_DEFAULT
.
Apps de pagamento
O Android considera serviços de HCE que declararam um grupo de AIDs com a categoria de pagamento como apps de pagamento. O Android 4.4 e versões mais recentes contêm uma entrada de menu Configurações de nível superior chamada Toque e pague, que enumera todos esses apps de pagamento. Neste menu de configurações, o usuário pode selecionar o aplicativo de pagamento padrão a ser invocado quando um terminal de pagamento for tocado.
Recursos obrigatórios para apps de pagamento
Para proporcionar uma experiência do usuário visualmente mais atraente, os apps de pagamento de HCE precisam fornecer um banner de serviço.
Android 13 e versões mais recentes
Para ajustar melhor a lista de seleção de pagamento padrão na interface de configurações, ajuste o requisito do banner para um ícone quadrado. O ideal é que ele seja idêntico ao design do ícone na tela de início do aplicativo. Esse ajuste cria mais consistência e uma aparência mais limpa.
Android 12 e versões anteriores
Defina o tamanho do banner de serviço como 260 x 96 dp. Em seguida, defina o tamanho do banner de serviço
no arquivo XML de metadados adicionando o atributo android:apduServiceBanner
à
tag <host-apdu-service>
, que aponta para o recurso drawable. Confira
um exemplo:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc" android:requireDeviceUnlock="false" android:apduServiceBanner="@drawable/my_banner"> <aid-group android:description="@string/aiddescription" android:category="payment"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </host-apdu-service>
Tela desativada e comportamento da tela de bloqueio
O comportamento dos serviços de HCE varia de acordo com a versão do Android em execução no dispositivo.
Android 12 e versões mais recentes
Em apps direcionados ao Android 12 (nível 31 da API) e versões mais recentes, é possível ativar pagamentos NFC
sem a tela do dispositivo ativada, definindo
requireDeviceScreenOn
como
false
.
Android 10 e versões mais recentes
Dispositivos com o Android 10 (API de nível 29) ou versões mais recentes são compatíveis com a
NFC
segura. Enquanto a NFC segura estiver ativada, todos os emuladores de cartão (aplicativos host e aplicativos fora do host) ficarão indisponíveis quando a tela do dispositivo estiver desativada. Enquanto a NFC segura estiver desativada, os aplicativos fora do host estarão disponíveis quando a tela do dispositivo estiver desativada. Você pode verificar o suporte a NFC segura usando isSecureNfcSupported()
.
Em dispositivos com Android 10 e versões mais recentes, a mesma funcionalidade para definir
android:requireDeviceUnlock
como true
se aplica aos dispositivos
com Android 9 e versões anteriores, mas apenas quando a NFC segura está desativada. Ou seja, se
a NFC segura estiver ativada, os serviços de HCE não poderão funcionar na tela de bloqueio,
independentemente da configuração de android:requireDeviceUnlock
.
Android 9 e versões anteriores
Em dispositivos com o Android 9 (nível 28 da API) e versões anteriores, o controlador de NFC e o processador do aplicativo são desligados completamente quando a tela do dispositivo é desligada. Portanto, os serviços de HCE não funcionam quando a tela está desligada.
Também no Android 9 e versões anteriores, os serviços de HCE podem funcionar na tela de bloqueio.
No entanto, isso é controlado pelo atributo android:requireDeviceUnlock
na
tag <host-apdu-service>
do serviço de HCE. Por padrão, o desbloqueio do dispositivo não
é obrigatório, e o serviço é invocado mesmo se o dispositivo estiver bloqueado.
Se você definir o atributo android:requireDeviceUnlock
como true
para seu serviço
de HCE, o Android vai solicitar que o usuário desbloqueie o dispositivo quando o seguinte
acontecer:
- o usuário toca em um leitor de NFC.
- o leitor de NFC seleciona um AID que é resolvido para o seu serviço.
Após o desbloqueio, o Android mostra uma caixa de diálogo solicitando que o usuário toque novamente para concluir a transação. Isso é necessário porque o usuário pode ter movido o dispositivo para longe do leitor de NFC para desbloqueá-lo.
Coexistência com cartões de elemento de segurança
Esta seção é interessante para desenvolvedores que implantaram um aplicativo que depende de um elemento de segurança para a emulação de cartão. A implementação de HCE do Android foi projetada para funcionar em paralelo com outros métodos de implementação de emulação de cartão, incluindo o uso de elementos de segurança.
Essa coexistência é baseada em um princípio chamado roteamento de AID. O controlador de NFC mantém uma tabela de roteamento que consiste em uma lista (finita) de regras de roteamento. Cada regra de roteamento contém um AID e um destino. O destino pode ser a CPU do host, em que os apps Android estão em execução, ou um elemento de segurança conectado.
Quando o leitor de NFC envia uma APDU com um SELECT AID
, o controlador de NFC a analisa e verifica se os AIDs correspondem a algum AID na sua tabela de roteamento. Se corresponder, essa APDU e todas as APDUs a seguir serão enviadas ao destino associado ao AID, até que outra APDU SELECT AID
seja recebida ou o link NFC seja corrompido.
A Figura 4 ilustra essa arquitetura:
O controlador de NFC normalmente também contém uma rota padrão para APDUs. Quando um AID não é encontrado na tabela de roteamento, a rota padrão é usada. Embora essa configuração possa ser diferente de dispositivo para dispositivo, os dispositivos Android precisam garantir que os AIDs registrados pelo app sejam roteados corretamente para o host.
Os aplicativos Android que implementam um serviço de HCE ou que usam um elemento de segurança não precisam se preocupar com a configuração da tabela de roteamento, que é processada pelo Android automaticamente. O Android só precisa saber quais AIDs podem ser processados pelos serviços de HCE e quais podem ser processados pelo elemento de segurança. A tabela de roteamento é configurada automaticamente com base nos serviços instalados e nos configurados como preferidos pelo usuário.
A seção a seguir explica como declarar AIDs para aplicativos que usam um elemento de segurança para emulação de cartão.
Registro do AID do elemento de segurança
Os aplicativos que usam um elemento de segurança para emulação de cartão podem declarar um serviço fora do host no manifesto. A declaração de tal serviço é quase idêntica à declaração de um serviço de HCE. As exceções são as seguintes:
- A ação usada no filtro de intent precisa ser definida como
SERVICE_INTERFACE
. - O atributo de nome de metadados precisa ser definido como
SERVICE_META_DATA
. O arquivo XML de metadados precisa usar a tag raiz
<offhost-apdu-service>
.<service android:name=".MyOffHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service" android:resource="@xml/apduservice"/> </service>
Confira a seguir um exemplo do arquivo apduservice.xml
correspondente
que registra dois AIDs:
<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc"> <aid-group android:description="@string/subscription" android:category="other"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </offhost-apdu-service>
O atributo android:requireDeviceUnlock
não se aplica a serviços fora do host,
porque a CPU do host não está envolvida na transação e, portanto, não pode
impedir que o elemento de segurança execute transações quando o dispositivo estiver
bloqueado.
O atributo android:apduServiceBanner
é necessário para serviços fora do host
que são apps de pagamento e podem ser selecionados como um app
de pagamento padrão.
Invocação de serviço fora do host
O Android nunca inicia ou se vincula a um serviço declarado como "fora do host" porque as transações reais são executadas pelo elemento de segurança, e não pelo serviço do Android. A declaração de serviço apenas permite que os aplicativos registrem os AIDs presentes no elemento de segurança.
HCE e segurança
A arquitetura HCE fornece uma parte principal de segurança: como seu
serviço é protegido pela permissão do sistema
BIND_NFC_SERVICE
, apenas o SO pode se vincular e se comunicar com o serviço.
Isso garante que qualquer APDU recebida seja, na verdade, uma APDU recebida pelo SO do controlador de NFC e que qualquer APDU enviada de volta só vá para o SO, que, por sua vez, encaminha diretamente as APDUs para o controlador de NFC.
A última preocupação é onde você recebe os dados que o app envia ao leitor de NFC. Isso é intencionalmente dissociado no design de HCE. Não importa de onde os dados vêm, apenas garante que eles sejam transportados com segurança para o controlador de NFC e para o leitor de NFC.
Para armazenar e extrair com segurança os dados que você quer enviar do serviço de HCE, pode, por exemplo, usar o sandbox do aplicativo Android, que isola os dados do seu app de outros. Para saber mais sobre a segurança do Android, leia Dicas de segurança.
Parâmetros de protocolo e detalhes
Esta seção é de interesse de desenvolvedores que querem entender quais parâmetros de protocolo os dispositivos HCE usam durante as fases de anticolisão e ativação dos protocolos NFC. Isso permite criar uma infraestrutura de leitor que é compatível com dispositivos Android HCE.
Anticolisão e ativação do protocolo Nfc-A (ISO/IEC 14443 tipo A)
Como parte da ativação do protocolo Nfc-A, vários frames são trocados.
Na primeira parte da troca, o dispositivo HCE apresenta o UID. Os dispositivos HCE precisam ter um UID aleatório. Isso significa que, a cada toque, o UID apresentado ao leitor é um UID gerado aleatoriamente. Por isso, os leitores de NFC não podem depender do UID de dispositivos HCE como forma de autenticação ou identificação.
Em seguida, o leitor de NFC pode selecionar o dispositivo HCE enviando um comando
SEL_REQ
. A resposta SEL_RES
do dispositivo HCE tem pelo menos o 6o bit
(0x20) definido, indicando que o dispositivo é compatível com ISO-DEP. Outros bits em
SEL_RES
também podem ser definidos, indicando, por exemplo, suporte para o protocolo NFC-DEP
(p2p). Como outros bits podem ser definidos, os leitores que quiserem interagir com
dispositivos HCE precisam verificar explicitamente apenas o 6o bit e não comparar
o SEL_RES
completo com um valor de 0x20.
Ativação de ISO-DEP
Depois que o protocolo Nfc-A é ativado, o leitor de NFC inicia a ativação do protocolo ISO-DEP. Ele envia um comando "Solicitação de resposta para seleção" (RATS, na sigla em inglês). O controlador de NFC gera a resposta RATS, o ATS. O ATS não é configurável pelos serviços de HCE. No entanto, as implementações de HCE precisam atender aos requisitos do NFC Forum para a resposta ATS. Assim, os leitores de NFC podem contar com esses parâmetros definidos de acordo com os requisitos do Fórum de NFC para qualquer dispositivo HCE.
A seção abaixo fornece mais detalhes sobre os bytes individuais da resposta ATS fornecida pelo controlador de NFC em um dispositivo HCE:
- TL: comprimento da resposta ATS. Não pode indicar um comprimento maior que 20 bytes.
- T0: os bits 5, 6 e 7 precisam ser definidos em todos os dispositivos HCE, indicando que TA(1), TB(1) e TC(1) são incluídos na resposta ATS. Os bits 1 a 4 indicam o FSCI, codificando o tamanho máximo do frame. Em dispositivos HCE, o valor de FSCI precisa estar entre 0h e 8h.
- T(A)1: define taxas de bits entre o leitor e o emulador, e se eles podem ser assimétricas. Não existem requisitos ou garantias de taxa de bits para dispositivos HCE.
- T(B) 1: os bits 1 a 4 indicam o inteiro de tempo de ativação do frame de inicialização (SFGI, na sigla em inglês). Em dispositivos HCE, o SFGI precisa ser <= 8h. Os bits 5 a 8 indicam o número inteiro de tempo de espera do frame (FWI, na sigla em inglês) e codificam o tempo de espera do frame (FWT, na sigla em inglês). Em dispositivos HCE, o FWI precisa ser <= 8h.
- T(C) 1: o bit 5 indica suporte para "Recursos avançados do protocolo". Os dispositivos HCE podem ou não oferecer suporte a "Recursos avançados do protocolo". O bit 2 indica suporte para DID. Os dispositivos HCE podem ou não ser compatíveis com DID. O bit 1 indica suporte para NAD. Dispositivos HCE não devem ser compatíveis com NAD e definir o bit 1 como zero.
- Bytes históricos: os dispositivos HCE podem retornar até 15 bytes históricos. Os leitores de NFC dispostos a interagir com serviços de HCE não devem fazer suposições sobre o conteúdo dos bytes históricos ou a presença deles.
Observe que muitos dispositivos HCE provavelmente são compatíveis com os requisitos de protocolo que as redes de pagamentos unidas no EMVCo especificaram na especificação do "Protocolo de comunicação por aproximação". Especificamente, as seguintes:
- O FSCI em T0 precisa estar entre 2h e 8h.
- T(A)1 precisa ser definido como 0x80, indicando que apenas a taxa de bits de 106 kbit/s é compatível e não há suporte a taxas de bits assimétricas entre o leitor e o emulador.
- O FWI em T(B)1 precisa ser <= 7h.
Troca de dados da APDU
Como observado anteriormente, as implementações de HCE oferecem suporte a apenas um único canal lógico. A tentativa de selecionar apps em canais lógicos diferentes não funciona em um dispositivo HCE.