Host Card Emulation limits on Android

Direct answer

Understand Android Host Card Emulation limits: ISO-DEP, APDUs, AID routing, random UID behavior, screen state, reader timing and secure credential boundaries.

Android 4.4 and the HCE model

Android 4.4 introduced host-based card emulation so an application service could process supported contactless commands without storing the application inside a secure element. The NFC controller routes reader traffic toward the host CPU and Android selects the responsible service.

Host path: Application logic and data live in the Android environment, so process scheduling and device state become part of transaction behavior.
Secure-element contrast: Off-host emulation routes supported traffic to tamper-resistant hardware and follows a different provisioning and ownership model.

Supported RF and protocol layers

Android HCE focuses on ISO-DEP based on ISO/IEC 14443-4 and exchanges APDUs defined by ISO/IEC 7816-4 conventions. It does not reproduce every low-level technology that Android can read through TagTechnology classes.

Required path: Android mandates ISO-DEP emulation over NFC-A; NFC-B support is optional at the platform level.
Reader contract: The external reader must intentionally speak the application protocol implemented by the HCE service.

AID routing and service selection

A reader commonly begins by sending SELECT AID. Android matches that Application Identifier to registered HostApduService declarations, resolves conflicts and forwards the command to the selected service.

Manifest: The service needs the NFC service interface, BIND_NFC_SERVICE permission and metadata listing valid AID groups.
Conflict: More than one installed service can register related AIDs, so wallet role, category and foreground preference influence selection.

APDU exchange and timing

processCommandApdu receives a command and returns a response, while sendResponseApdu supports asynchronous completion. The reader waits, so long network calls or main-thread work can exceed its transaction timeout even when the code is logically correct.

State machine: Validate CLA, INS, P1, P2 and Lc before processing, then return explicit status words for unsupported or malformed commands.
Performance: Keep the exchange compact and cache non-secret data needed by the transaction rather than depending on an unpredictable remote round trip.

Why HCE cannot guarantee a fixed UID

Android's official guidance says HCE devices should be assumed to present a random UID on each tap. The application service does not control anti-collision bytes generated before its APDU protocol is selected.

Reader design: Use an application-level identifier and cryptographic protocol instead of authenticating the phone from the RF UID.
Legacy mismatch: A reader that accepts only one fixed UID is not compatible with ordinary Android HCE without redesigning its trust model.

Screen, lock and Secure NFC behavior

HCE availability changes across Android versions and device settings. Secure NFC, screen-off policy, requireDeviceUnlock and wallet behavior can prevent or delay a service even when the app manifest is valid.

User-visible requirement: Explain when the phone must be awake or unlocked and never promise universal screen-off transactions.
Version test: Exercise supported OS versions because Android 9-and-lower, Android 10 Secure NFC and newer wallet behavior have different rules.

Emulating an NDEF Type 4 style profile

An application can implement the selection and file-reading behavior expected by a compatible NFC Forum Type 4 NDEF reader. The profile is an application protocol over APDUs, not a byte-for-byte reproduction of a physical Type 2 sticker.

File model: Expose the capability and NDEF files with correct lengths, access conditions and status responses.
Compatibility: Test with the intended readers because some products assume proprietary commands or timing beyond standard NDEF access.

Payment, transit and access boundaries

HCE is used in legitimate credential systems, but those deployments include issuer provisioning, keys, tokenization, certified readers and operating-system policy. A generic app cannot convert a protected physical card into an authorized mobile credential.

Issuer role: The system owner decides which AIDs, keys and lifecycle controls make a phone trusted.
No cloning claim: NFCMagic limits HCE to supported profiles and states clearly that fixed-UID or secret-key credentials are outside ordinary emulation.

Device and reader variability

Controller implementation, antenna, power policy and external reader timeout differ. Phone-to-phone tests are useful but cannot represent a kiosk, industrial terminal or embedded reader with another field strength and APDU sequence.

Matrix: Record phone, Android build, screen state, reader model, command trace, timing and deactivation reason.
Deactivation: Handle link loss and deselection explicitly, discard partial session state and prepare for a fresh SELECT on the next tap.

A production HCE checklist

Check HCE feature support, register the correct service, validate every APDU, bound response time, protect application data and provide a fallback. Physical acceptance testing remains required because an emulator cannot reproduce the complete contactless controller path.

Security: Keep credentials in protected storage, minimize exported components and require authentication when the use case demands it.
Observability: Log non-secret command categories and deactivation reasons locally without storing full credential exchanges.

Quick reference

HCE property	Android controls	App controls
RF UID	Generated before app protocol	Do not depend on it
AID routing	System resolves services	Declare supported AIDs
APDU response	Delivered through HostApduService	Validate and answer quickly
Screen policy	Version and Secure NFC dependent	Explain and test states

Related NFCMagic app screens

These screenshots connect this Android HCE limits guide to the related Android workflow in NFCMagic. They document interface states; radio behavior still requires a physical Android device and real tags.

The interface presents HCE as a bounded Type 4 style test and does not promise fixed-UID credential cloning.

NFCMagic developer settings for controlled NFC and backend test configuration — Reader interoperability should be reproduced with labelled test settings rather than hidden production overrides.

Frequently asked questions

Which Android version introduced HCE?

Android 4.4 introduced host-based card emulation through HostApduService.

Can an HCE app choose its NFC UID?

Ordinary Android HCE apps cannot rely on a fixed UID; readers should treat the presented UID as random.

Can HCE emulate a Type 2 sticker?

HCE implements supported ISO-DEP and APDU protocols. A Type 4 NDEF style profile is possible, but it is not low-level Type 2 emulation.

Why does HCE work with one reader but not another?

Readers can differ in protocol, AID, timing, field behavior and proprietary assumptions, so the actual target reader must be tested.

Primary technical sources

Android Developers: Host-based card emulation — Official HCE architecture, APDU routing, AID selection and UID limitations.
Android Developers: Android Keystore — Official key-storage model and hardware-backed protection guidance.