L'émulation de carte par l'hôte marche-t-elle écran éteint ?
Cela dépend de la version d'Android et d'un réglage de l'appareil. Jusqu'à Android 9 rien ne répond écran éteint. Depuis Android 12 un service peut poser requireDeviceScreenOn à faux. Et tant que Secure NFC est actif, depuis Android 10, tout émulateur de carte est indisponible écran éteint.
Version par version
Le guide de l'émulation de carte d'Android répond version par version, et les réponses diffèrent assez pour qu'une phrase unique soit fausse quelque part.
Sur Android 9 et antérieurs, le contrôleur et le processeur applicatif sont éteints quand l'écran l'est, donc aucun service ne répond ; depuis l'écran de verrouillage ils répondent, sauf si le service réclame un déverrouillage. Depuis Android 10, le réglage Secure NFC, que les réglages français nomment « Exiger le déverrouillage de l'appareil pour le NFC », change la question : tant qu'il est actif, tout émulateur de carte, hôte ou hors hôte, est indisponible écran éteint, et un service hôte ne peut pas fonctionner depuis l'écran de verrouillage quoi qu'il ait déclaré ; tant qu'il est inactif, les applications hors hôte restent disponibles écran éteint. isSecureNfcSupported dit si l'appareil possède seulement ce réglage.
Depuis Android 12, une application qui vise cette version ou une ultérieure peut poser requireDeviceScreenOn à faux et répondre écran éteint. Depuis Android 15, une application de portefeuille par défaut qui active le mode Observe renverse à la fois le comportement de déverrouillage et celui de l'écran éteint, parce que c'est elle qui décide quand une transaction peut avoir lieu.
Les deux déclarations
Toutes deux vivent dans le XML qui enregistre les identifiants, sur la balise host-apdu-service. requireDeviceUnlock vaut faux par défaut, ce qui veut dire que le service est invoqué même sur un téléphone verrouillé. Posée à vrai, un contact qui mène au service fait demander à l'utilisateur de déverrouiller, puis de taper à nouveau, puisque le téléphone a dû être bougé pour être déverrouillé.
requireDeviceScreenOn est la plus récente, et c'est faux qui laisse un paiement répondre écran éteint depuis Android 12. Ni l'un ni l'autre attribut ne s'applique à un service hors hôte : le processeur hôte ne participe pas à cet échange, donc il ne peut pas retenir l'élément sécurisé.
Ce que le mode Observe a changé
Le mode Observe, depuis Android 15, laisse l'appareil regarder les boucles d'interrogation sans autoriser de transaction. Un service l'active par setObserveModeEnabled(true), et la pile observe alors au lieu de transiger, ce qui permet à un portefeuille d'attendre l'utilisateur avant de répondre quoi que ce soit.
Ce que le service observe est filtré. Les filtres enregistrés pour un service apparient une trame d'interrogation exactement ou par motif, et les trames appariées atteignent processPollingFrames(), où l'application peut se préparer ou authentifier l'utilisateur ; les trames d'un lecteur qui interroge avec des trames standard vont au service de premier plan préféré, ou au détenteur du rôle de portefeuille. Une trame porte aussi une mesure propre au fabricant de la force du champ, lue par getVendorSpecificGain.
Quitter le mode Observe est le signal que l'application est prête : setObserveModeEnabled(false), ou autoTransact sur un filtre pour qu'une trame appariée le fasse. Un service peut demander à démarrer en mode Observe dès qu'il est le service de paiement préféré, par shouldDefaultToObserveMode au manifeste ou par setShouldDefaultToObserveModeForService.
Concevoir pour un téléphone verrouillé
Testez les états plutôt que les versions. Écran allumé et déverrouillé, écran allumé et verrouillé, écran éteint, chacun avec Secure NFC actif et inactif, est une matrice courte qui répond à ce qu'un utilisateur rencontrera, et le téléphone dans une poche est l'état que les démonstrations sautent le plus souvent. La page de l'écran éteint couvre la même frontière du côté de l'utilisateur.
Décidez ensuite à quoi ressemble l'échec. Un service qui ne peut pas répondre pendant le verrouillage laisse l'utilisateur devant un lecteur qui ne dit rien, donc l'application doit expliquer l'état quelque part où l'utilisateur regardera, ce que l'invite de déverrouillage du guide ne fait que si le service a réclamé ce déverrouillage.
Et si un lecteur peut être changé, changez-le avec le téléphone : le guide encourage à travailler avec les fournisseurs de lecteurs pour que leurs boucles d'interrogation portent un motif identifiable, ce qui est ce qui permet à un service de reconnaître son propre terminal avant de décider de transiger.
Questions fréquentes
Une carte émulée peut-elle répondre écran éteint ?
Depuis Android 12, si le service pose requireDeviceScreenOn à faux et que Secure NFC est inactif. Jusqu'à Android 9 le contrôleur s'éteint avec l'écran.
Que change Secure NFC ?
Tant qu'il est actif, tout émulateur de carte est indisponible écran éteint, et un service hôte ne peut pas fonctionner depuis l'écran de verrouillage quoi qu'il ait déclaré.
À quoi sert requireDeviceUnlock ?
Posée à vrai, un contact invite l'utilisateur à déverrouiller puis à taper à nouveau. La valeur par défaut est faux, donc le service répond sur un téléphone verrouillé.
Ces réglages s'appliquent-ils à un élément sécurisé ?
Non. Ni l'un ni l'autre attribut ne s'applique à un service hors hôte, le processeur hôte ne faisant pas partie de cet échange.