Creare un’app smart card NFC
Importante
Questo argomento si applica solo a Windows 10 Mobile.
Questo argomento descrive come usare Host Card Emulation (HCE) per comunicare direttamente con un lettore di schede NFC (Near-Field Communication) e consentire ai clienti di accedere ai servizi tramite il telefono (anziché una scheda fisica) senza un operatore di rete mobile (MNO).
Elementi necessari per sviluppare un'app HCE
Per sviluppare un'app di emulazione schede basata su HCE, è necessario installare Microsoft Visual Studio 2015 (vedere la pagina Download di Visual Studio) (include gli strumenti di sviluppo di Windows) e l'emulatore di Windows 10 Mobile.
Per altre informazioni su come ottenere l'installazione, vedere Testare con l'Emulatore Microsoft per Windows 10 Mobile.
Facoltativamente, se si desidera eseguire il test con un dispositivo Windows 10 Mobile reale anziché l'emulatore di Windows 10 Mobile incluso, serviranno anche gli elementi seguenti.
- Un dispositivo Windows 10 Mobile con supporto NFC HCE.
- Un terminale di lettore che supporta i protocolli ISO/IEC 14443-4 e ISO/IEC 7816-4
Windows 10 Mobile implementa un servizio HCE che fornisce le funzionalità seguenti.
- Le app possono registrare gli identificatori applet (AID) per le schede da emulare.
- Risoluzione dei conflitti e routing del comando APDU (Application Protocol Data Unit) e delle coppie di risposta a una delle app registrate in base alla selezione della scheda lettore esterna e alla preferenza utente.
- Gestione di eventi e notifiche alle app in seguito alle azioni dell'utente.
Windows 10 supporta l'emulazione di smart card basate su ISO-DEP (ISO-IEC 14443-4) e comunica usando le APDU definite nella specifica ISO-IEC 7816-4. Windows 10 supporta la tecnologia ISO/IEC 14443-4 tipo A per le app HCE. Le tecnologie di tipo B, tipo F e non ISO-DEP (ad esempio MIFARE) vengono instradate alla SIM per impostazione predefinita.
Solo i dispositivi di Windows 10 Mobile sono abilitati con la funzionalità di emulazione delle schede. L'emulazione di schede basate su SIM e HCE non è disponibile in altre versioni di Windows 10.
L'architettura per il supporto dell'emulazione di schede basate su SIM e HCE è illustrata nel diagramma seguente.
Selezione dell'app e routing AID
Per sviluppare un'app HCE, è necessario comprendere in che modo i dispositivi Windows 10 Mobile instradano gli AID a un'app specifica, in quanto gli utenti possono installare più app HCE differenti. Ogni app può registrare più schede HCE e basate su SIM.
Quando l'utente collega il dispositivo Windows 10 Mobile a un terminale, i dati vengono indirizzati automaticamente all'apposita app installata nel dispositivo. Questo routing si basa sull'ID applet (AID) che è un identificatore di 5-16 byte. Durante la commutazione, il terminale esterno trasmetterà un APDU del comando SELECT per specificare l'AID a cui si desidera indirizzare tutti i comandi APDU successivi. I comandi SELECT successivi cambieranno di nuovo la pianificazione del percorso. In base agli AID registrati dalle app e dalle impostazioni utente, il traffico APDU viene instradato a un'app specifica, che invierà una risposta APDU. Tenere presente che un terminale può voler comunicare con diverse app durante la stessa commutazione. È quindi necessario assicurarsi che l'attività in background dell'app venga chiusa il più rapidamente possibile quando disattivata per fare spazio all'attività in background di un'altra app per rispondere all'APDU. Le attività in background verranno illustrate più avanti in questo argomento.
Le app HCE devono registrarsi con particolari AID che possono gestire in modo che ricevano unità APD per un AID. Le applicazioni dichiarano gli AID tramite i gruppi AID. Un gruppo AID equivale concettualmente a una singola scheda fisica. Ad esempio, una carta di credito viene dichiarata con un gruppo AID e una seconda carta di credito di una banca diversa viene dichiarata con un secondo gruppo AID diverso, anche se entrambi possono avere lo stesso AID.
Risoluzione dei conflitti per i gruppi AID di pagamento
Quando un'app registra schede fisiche (gruppi di AID), può dichiarare la categoria del gruppo AID come "Pagamento" o "Altro". Anche se in un determinato momento possono essere registrati più gruppi di AID di pagamento, è possibile abilitare solo uno di questi gruppi di AID di pagamento per ogni volta che l'utente seleziona l'opzione "Seleziona e paga". Questo comportamento avviene perché l'utente si aspetta di avere il controllo della scelta consapevole di un singolo pagamento, credito o carta di debito da usare in modo da non pagare con una carta diversa non intenzionale quando associa il dispositivo a un terminale.
Tuttavia, più gruppi di AID registrati come "Altro" possono essere abilitati contemporaneamente senza l'interazione dell'utente. Questo comportamento esiste perché altri tipi di schede come carte fedeltà, coupon o carte di transito dovrebbero funzionare solo senza alcun sforzo o richiedendo ogni volta che associano il telefono.
Tutti i gruppi AID registrati come "Pagamento" vengono visualizzati nell'elenco delle schede nella pagina Impostazioni NFC, in cui l'utente può selezionare la carta di pagamento predefinita. Quando si seleziona una carta di pagamento predefinita, l'app che ha registrato questo gruppo AID di pagamento diventa l'app di pagamento predefinita. Le app di pagamento predefinite possono abilitare o disabilitare uno dei gruppi AID senza l'interazione dell'utente. Se l'utente rifiuta il prompt dell'app di pagamento predefinita, l'app di pagamento predefinita corrente (se presente) continua a rimanere come predefinita. Lo screenshot seguente mostra la pagina impostazioni NFC.
Usando lo screenshot di esempio precedente, se l'utente modifica la carta di pagamento predefinita in un'altra scheda non registrata da "Applicazione HCE 1", il sistema crea una richiesta di conferma per il consenso dell'utente. Tuttavia, se l'utente modifica la carta di pagamento predefinita in un'altra scheda registrata da "Applicazione HCE 1", il sistema non crea una richiesta di conferma per l'utente poiché "HCE Application1" è già l'app di pagamento predefinita.
Risoluzione dei conflitti per i gruppi AID non di pagamento
Le carte non di pagamento classificate come "Altro" non vengono visualizzate nella pagina delle impostazioni NFC.
L'app può creare, registrare e abilitare gruppi di AID non di pagamento nello stesso modo dei gruppi AID di pagamento. La differenza principale è che per i gruppi aid non di pagamento la categoria di emulazione è impostata su "Altro" anziché su "Pagamento". Dopo aver registrato il gruppo AID con il sistema, è necessario abilitare il gruppo AID per ricevere il traffico NFC. Quando si tenta di abilitare un gruppo AID non di pagamento per ricevere il traffico, all'utente non viene richiesto di confermare, a meno che non si verifichi un conflitto con uno degli AID già registrati nel sistema da un'app diversa. Se si verifica un conflitto, all'utente verranno richieste informazioni sulla scheda e l'app associata verrà disabilitata se l'utente sceglie di abilitare il gruppo AID appena registrato.
Coesistenza con applicazioni NFC basate su SIM
In Windows 10 Mobile il sistema configura la tabella di pianificazione percorso del controller NFC usata per prendere decisioni di routing a livello di controller. La tabella contiene informazioni di pianificazione percorso per gli elementi seguenti.
- Percorsi di AID individuali.
- Percorso basato su protocollo (ISO-DEP).
- Pianificazione percorso basata sulla tecnologia (NFC-A/B/F).
Quando un lettore esterno invia un comando "SELECT AID", il controller NFC controlla innanzitutto i percorsi AID nella tabella di pianificazione percorso per una corrispondenza. Se non esiste alcuna corrispondenza, userà il percorso basato su protocollo come predefinito per il traffico ISO-DEP (14443-4-A). Per qualsiasi altro traffico non ISO-DEP, userà la pianificazione percorso basata sulla tecnologia.
Windows 10 Mobile offre un'opzione di menu "SIM Card" nella pagina NFC Impostazioni per continuare a usare le app legacy basate su SIM di Windows Phone 8.1, che non registrano i propri AID con il sistema. Se l'utente seleziona "carta SIM" come scheda di pagamento predefinita, il percorso ISO-DEP è impostato su UICC, mentre per tutte le altre selezioni nel menu a discesa il percorso ISO-DEP è verso l'host.
Il percorso ISO-DEP è impostato su "Scheda SIM" per i dispositivi con una scheda SIM abilitata SE quando il dispositivo viene avviato per la prima volta con Windows 10 Mobile. Quando l'utente installa un'app abilitata per HCE e tale app abilita tutte le registrazioni del gruppo di AID HCE, la route ISO-DEP verrà indicata all'host. Le nuove applicazioni basate su SIM devono registrare gli AID nella SIM affinché i percorsi AID specifici vengano popolate nella tabella di pianificazione percorso del controller.
Creazione di un'app basata su HCE
L'app HCE ha due parti.
- L'app principale in primo piano per l'interazione dell'utente.
- Un'attività in background attivata dal sistema per elaborare le APDU per un determinato AID.
A causa dei requisiti di prestazioni estremamente rigorosi per il caricamento dell'attività in background in risposta a un tocco NFC, è consigliabile implementare l'intera attività in background nel codice nativo C++/CX (incluse eventuali dipendenze, riferimenti o librerie da cui si dipende) piuttosto che C# o codice gestito. Anche se di solito codice C# e codice gestito funzionano correttamente, si verifica un sovraccarico, ad esempio il caricamento di CLR .NET, che può essere evitato scrivendolo in C++/CX.
Creare e registrare un'attività in background
È necessario creare un'attività in background nell'app HCE per l'elaborazione e la risposta alle APDU indirizzate dal sistema. Durante il primo avvio dell'app, il primo piano registra un'attività in background HCE che implementa l'interfaccia IBackgroundTaskRegistration , come illustrato nel codice seguente.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorHostApplicationActivated));
bgTask = taskBuilder.Register();
Si noti che il trigger dell'attività è impostato su SmartCardTriggerType. EmulatorHostApplicationActivated. Ciò significa che ogniqualvolta il sistema operativo riceve una APDU di comando SELECT AID che si riferisce all'applicazione, viene avviata l'attività in background.
Ricevere e rispondere alle APDU
Quando è presente un'APDU destinata all'app, il sistema avvierà l'attività in background. L'attività in background riceve l'APDU passata attraverso la proprietà CommandApdu dell'oggetto SmartCardEmulatorApduReceivedEventArgs e risponde all'APDU utilizzando il metodo TryRespondAsync dello stesso oggetto. Per motivi di prestazioni è consigliabile mantenere l'attività in background per le operazioni leggere. Ad esempio, rispondere immediatamente alle APDU e uscire dall'attività in background al termine di tutte le elaborazioni. A causa della natura delle transazioni NFC, gli utenti tendono a mantenere il dispositivo verso il lettore solo per un periodo di tempo molto breve. L'attività in background continuerà a ricevere traffico dal lettore fino alla disattivazione della connessione, nel qual caso si riceverà un oggetto SmartCardEmulatorConnectionDeactivatedEventArgs. La connessione può essere disattivata a causa dei motivi seguenti, come indicato nella proprietà SmartCardEmulatorConnectionDeactivatedEventArgs.Reason.
- Se la connessione viene disattivata con il valore ConnectionLost, significa che l'utente ha estratto il dispositivo dal lettore. Se l'app richiede che l'utente selezioni più a lungo il terminale, si potrebbe voler prendere in considerazione la richiesta di commenti e suggerimenti. È necessario terminare rapidamente l'attività in background (completando il differire) per assicurarsi che, se toccano di nuovo, l'attività in background non verrà posticipata in attesa della precedente chiusura di attività in background.
- Se la connessione viene disattivata con il ConnectionRedirected, significa che il terminale ha inviato un nuovo comando SELECT AID APDU diretto a un AID diverso. In questo caso, l'app deve uscire immediatamente dall'attività in background (completando il rinvio) per consentire l'esecuzione di un'altra attività in background.
L'attività in background deve anche registrarsi per l'evento cancellato on IBackgroundTaskInstance interface e, analogamente, uscire rapidamente dall'attività in background (completando il rinvio) perché questo evento viene generato dal sistema al termine dell'attività in background. Di seguito è riportato il codice che illustra un'attività in background dell'app 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();
}
}
Creare e registrare gruppi di AID
Durante il primo avvio dell'applicazione quando viene effettuato il provisioning della scheda, verranno creati e registrati gruppi di AID con il sistema. Il sistema determina l'app a cui un lettore esterno vuole comunicare e instradare di conseguenza le unità APDU in base alle impostazioni utente e agli AID registrati.
La maggior parte delle carte di pagamento si registra per lo stesso AID, Proximity Payment System Environment (PPSE), insieme ad altri AID specifici per la rete di pagamento. Ciascun gruppo di AID rappresenta una carta e quando l'utente abilita la carta, tutti gli AID nel gruppo vengono abilitati. Analogamente, quando l'utente disattiva la carta, tutti gli AID nel gruppo vengono disabilitati.
Per registrare un gruppo di AID, è necessario creare un oggetto SmartCardAppletIdGroup e impostarne le proprietà in modo da riflettere che si tratta di una carta di pagamento basata su HCE. Il nome visualizzato deve essere descrittivo per l'utente perché verrà visualizzato nel menu delle impostazioni NFC e nelle richieste degli utenti. Per le carte di pagamento HCE, la proprietà SmartCardEmulationCategory dovrebbe essere impostata su Pagamento, mentre la proprietà SmartCardEmulationType su 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);
Per le carte di pagamento HCE, la proprietà SmartCardEmulationCategory dovrebbe essere impostata su Altro mentre la proprietà SmartCardEmulationType su 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);
È possibile includere fino a 9 AID (di lunghezza da 5 a 16 byte ciascuno) per ogni gruppo di AID.
Utilizzare il metodo RegisterAppletIdGroupAsync per registrare il gruppo AID nel sistema, che restituirà un oggetto SmartCardAppletIdGroupRegistration. Per impostazione predefinita, la proprietà ActivationPolicy property dell'oggetto di registrazione è impostata su Disabilitato. Ciò significa che anche se gli AID sono registrati nel sistema, non sono ancora abilitati e non riceveranno traffico.
reg = await SmartCardEmulator.RegisterAppletIdGroupAsync(appletIdGroup);
È possibile abilitare le schede registrate (gruppi di AID) usando il metodo RequestActivationPolicyChangeAsync della classeSmartCardAppletIdGroupRegistration, come illustrato di seguito. Poiché è possibile abilitare solo una singola carta di pagamento alla volta nel sistema, l'impostazione di ActivationPolicy per un gruppo AID di pagamento su Abilitato equivale all'impostazione della carta di pagamento predefinita. All'utente verrà richiesto di consentire questa scheda come carta di pagamento predefinita, indipendentemente dal fatto che sia già selezionata o meno una carta di pagamento predefinita. Questa istruzione non è vera se l'app è già l'applicazione di pagamento predefinita e sta semplicemente cambiando tra i propri gruppi di AID. È possibile registrare fino a 10 gruppi di AID per ogni app.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.Enabled);
È possibile eseguire una query sui gruppi di AID registrati dell'app con il sistema operativo e controllarne i criteri di attivazione usando il metodo GetAppletIdGroupRegistrationsAsync.
Agli utenti verrà richiesto di modificare i criteri di attivazione di una carta di pagamento da Disabilitato a Abilitato, solo se l'app non è già quella di pagamento predefinita. Agli utenti verrà richiesto solo quando si modificano i criteri di attivazione di una carta non di pagamento da Disabilitato a Abilitato se si verifica un conflitto di AID.
var registrations = await SmartCardEmulator.GetAppletIdGroupRegistrationsAsync();
foreach (var registration in registrations)
{
registration.RequestActivationPolicyChangeAsync (AppletIdGroupActivationPolicy.Enabled);
}
Notifica degli eventi quando cambiano i criteri di attivazione
Nell'attività in background è possibile registrarsi per ricevere eventi quando i criteri di attivazione di una delle registrazioni del gruppo AID cambiano all'esterno dell'app. Ad esempio, l'utente può modificare l'app di pagamento predefinita tramite il menu delle impostazioni NFC da una delle proprie carte a un'altra carta ospitata da un'altra app. Se l'app deve essere a conoscenza di questa modifica per un'impostazione interna, come ad esempio l'aggiornamento dei riquadri animati, è possibile ricevere notifiche di eventi per questa modifica e agire di conseguenza nella propria applicazione.
var taskBuilder = new BackgroundTaskBuilder();
taskBuilder.Name = bgTaskName;
taskBuilder.TaskEntryPoint = taskEntryPoint;
taskBuilder.SetTrigger(new SmartCardTrigger(SmartCardTriggerType.EmulatorAppletIdGroupRegistrationChanged));
bgTask = taskBuilder.Register();
Comportamento di override in primo piano
È possibile modificare la ActivationPolicy di una delle registrazioni del gruppo AID in ForegroundOverride mentre l'app è in primo piano senza chiedere conferma all'utente. Quando l'utente tocca il dispositivo a un terminale mentre l'app è in primo piano, il traffico viene instradato all'app anche se nessuna delle carte di pagamento è stata scelta dall'utente come quella predefinita. Quando si modificano i criteri di attivazione di una carta in ForegroundOverride, tale modifica è temporanea solo finché l'app non lascia in primo piano e non modificherà l'attuale carta di pagamento predefinita impostata dall'utente. È possibile modificare la ActivationPolicy delle carte di pagamento o non di pagamento dall'app in primo piano come indicato di seguito. Si noti che il metodo RequestActivationPolicyChangeAsync può essere richiamato solo da un'app in primo piano e non può essere richiamato da un'attività in background.
reg.RequestActivationPolicyChangeAsync(AppletIdGroupActivationPolicy.ForegroundOverride);
Inoltre, è possibile registrare un gruppo AID costituito da un singolo AID di lunghezza 0, attraverso cui il sistema instrada tutti gli APDU indipendentemente dall'AID e includa qualsiasi comando APDU inviato prima che venga ricevuto un comando AID SELECT. Tuttavia, tale gruppo di AID funziona solo mentre l'app è in primo piano, in quanto può essere impostata solo su ForegroundOverride e non può essere abilitata in modo permanente. Inoltre, questo meccanismo funziona sia per i valori Host che UICC dell'enumerazione SmartCardEmulationType per instradare tutto il traffico all'attività in background HCE o alla scheda 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);
Verificare la presenza del supporto NFC e HCE
L'app deve verificare se un dispositivo dispone di hardware NFC, supporta la funzionalità di emulazione delle carte e supporta l'emulazione delle schede host prima di offrire tali funzionalità all'utente.
La funzionalità di emulazione di smart card NFC è abilitata solo in Windows 10 Mobile, quindi il tentativo di usare le API dell'emulatore di smart card in qualsiasi altra versione di Windows 10 causerà errori. È possibile verificare il supporto dell'API smart card nel frammento di codice seguente.
Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.SmartCards.SmartCardEmulator");
È anche possibile verificare se il dispositivo dispone di hardware NFC in grado di eseguire un'emulazione di carte controllando se il metodo SmartCardEmulator.GetDefaultAsync restituisce null. In caso affermativo, nel dispositivo non è supportata alcuna emulazione di carte NFC.
var smartcardemulator = await SmartCardEmulator.GetDefaultAsync();<
Il supporto per il routing UICC basato su HCE e AID è disponibile solo su dispositivi avviati di recente, ad esempio Lumia 730, 830, 640 e 640 XL. Tutti i nuovi dispositivi con supporto NFC che eseguono Windows 10 Mobile e successivi dovrebbero supportare HCE. L'app può verificare la disponibilità del supporto HCE come indicato di seguito.
Smartcardemulator.IsHostCardEmulationSupported();
Comportamento di blocco della schermata e dello schermo disattivato
Windows 10 Mobile include impostazioni di emulazione schede a livello di dispositivo, che possono essere impostate dall'operatore di telefonia mobile o dal produttore del dispositivo. Per impostazione predefinita, il commutatore "tocca per pagare" è disabilitato e il "criterio di abilitazione a livello di dispositivo" è impostato su "Sempre", a meno che l'MO o l'OEM non sovrascriva questi valori.
L'applicazione può eseguire query sul valore di EnablementPolicy a livello di dispositivo e intervenire per ogni caso a seconda del comportamento desiderato dell'app in ogni stato.
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";
}
L'attività in background dell'app verrà avviata anche se il telefono è bloccato e/o lo schermo è disattivato solo se il lettore esterno seleziona un AID che si risolve nell'app. È possibile rispondere ai comandi del lettore nell'attività in background, ma se è necessario un input dell'utente o se si vuole visualizzare un messaggio all'utente, è possibile avviare l'app in primo piano con alcuni argomenti. L'attività in background può avviare l'app in primo piano con il comportamento seguente.
- Nella schermata di blocco del dispositivo (l'utente visualizzerà l'app in primo piano solo dopo aver sbloccato il dispositivo)
- Sopra la schermata di blocco del dispositivo (dopo che l'utente chiude l'app, il dispositivo è ancora bloccato)
if (Windows::Phone::System::SystemProtection::ScreenLocked)
{
// Launch above the lock with some arguments
var result = await eventDetails.TryLaunchSelfAsync("app-specific arguments", SmartCardLaunchBehavior.AboveLock);
}
Registrazione AID e altri aggiornamenti per le app basate su SIM
Le app di emulazione delle carte che usano la SIM come elemento sicuro possono registrarsi con il servizio Windows per dichiarare gli AID supportati nella SIM. Questa registrazione è molto simile a una registrazione dell'app basata su HCE. L'unica differenza è la funzionalità SmartCardEmulationType, che deve essere impostata su Uicc per le app basate su SIM. Come risultato della registrazione della carta di pagamento, anche il nome visualizzato della carta verrà popolato nel menu delle impostazioni NFC.
var appletIdGroup = new SmartCardAppletIdGroup(
"Example DisplayName",
new List<IBuffer> {AID_PPSE.AsBuffer()},
SmartCardEmulationCategory.Payment,
SmartCardEmulationType.Uicc);
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per