Does host card emulation work with the screen off?

Version by version

Android's card emulation guide answers this by version, and the answers differ enough that a single sentence would be wrong somewhere.

On Android 9 and lower, the controller and the application processor are off when the screen is off, so no service answers; from the lock screen they do answer, unless the service asks for an unlock. From Android 10, the Secure NFC setting changes the question: while it is on, every card emulator, host or off host, is unavailable with the screen off, and a host service cannot work from the lock screen whatever it declared; while it is off, off host applications remain available with the screen off. isSecureNfcSupported reports whether the device has the setting at all.

From Android 12, an app that targets that version or later can set requireDeviceScreenOn to false and answer with the screen off. From Android 15, a default wallet app that turns observe mode on overrides both the unlock and the screen off behaviour, because it decides when a transaction may proceed.

The two declarations

Both live in the XML that registers the identifiers, on the host-apdu-service tag. requireDeviceUnlock defaults to false, which means the service is invoked even on a locked phone. Set to true, a tap that resolves to the service makes Android ask the user to unlock, and then to tap again, since the phone had to be moved to be unlocked.

requireDeviceScreenOn is the newer one, and false is what lets a payment answer with the screen off from Android 12. Neither attribute applies to an off host service: the host processor is not involved in that exchange, so it cannot hold the secure element back.

What observe mode changed

Observe mode, from Android 15, lets the device watch polling loops without allowing a transaction. A service turns it on with setObserveModeEnabled(true), and the stack then observes rather than transacts, which is how a wallet can wait for the user before answering anything.

What the service observes is filtered. Filters registered for a service match a polling frame exactly or by pattern, and matching frames reach processPollingFrames(), where the app can prepare or authenticate the user; frames from a reader that polls with standard frames go to the preferred foreground service, or to the wallet role holder. A frame also carries a vendor specific measurement of field strength, read with getVendorSpecificGain.

Leaving observe mode is the signal that the app is ready: setObserveModeEnabled(false), or autoTransact on a filter so that a matching frame does it. A service can ask to start in observe mode whenever it is the preferred payment service, through shouldDefaultToObserveMode in the manifest or setShouldDefaultToObserveModeForService.

Designing for a locked phone

Test the states rather than the versions. Screen on and unlocked, screen on and locked, screen off, each with Secure NFC on and off, is a short matrix that answers what a user will meet, and the phone in a pocket is the state most demonstrations skip. The screen off page covers the same boundary from the user's side.

Then decide what the failure looks like. A service that cannot answer while locked leaves the user in front of a reader that says nothing, so the app has to explain the state somewhere the user will look, which the guide's unlock prompt does only when the service asked for the unlock.

And if a reader can be changed, change it with the phone: the guide encourages working with reader vendors so that their polling loops carry an identifiable pattern, which is what lets a service recognise its own terminal before deciding to transact.