• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1page.title=Host-based Card Emulation
2page.tags="host card emulation", "hce","HostApduService","OffHostApduService","tap and pay"
3
4@jd:body
5
6
7<div id="qv-wrapper">
8<div id="qv">
9
10<h2>In this document</h2>
11<ol>
12  <li><a href="#SecureElement">Card Emulation with a Secure Element</a></li>
13  <li><a href="#HCE">Host-based Card Emulation</a></li>
14  <li><a href="#SupportedProtocols">Supported NFC Cards and Protocols</a></li>
15  <li><a href="#HceServices">HCE Services</a>
16  </li>
17  <li><a href="#ImplementingService">Implementing an HCE Service</a>
18  </li>
19  <li><a href="#AidConflicts">AID Conflict Resolution</a>
20  </li>
21  <li><a href="#PaymentApps">Payment Applications</a>
22  </li>
23  <li><a href="#ScreenOffBehavior">Screen Off and Lock-screen Behavior</a></li>
24  <li><a href="#Coexistence">Coexistence with Secure Element Cards</a>
25  </li>
26  <li><a href="#HceSecurity">HCE and Security</a></li>
27  <li><a href="#ProtocolParams">Protocol parameters and details</a>
28  </li>
29</ol>
30
31</div>
32</div>
33
34
35
36<p>Many Android-powered devices that offer NFC functionality already support NFC card
37emulation. In most cases, the card is emulated by a separate
38chip in the device, called a <em>secure element</em>. Many SIM cards provided by
39wireless carriers also contain a secure element.</p>
40
41<p>Android 4.4 introduces an additional method of card emulation that does not
42involve a secure element, called <em>host-based card emulation</em>. This allows any
43Android application to emulate a card and talk directly to the NFC reader. This
44document describes how host-based card emulation (HCE) works on Android and how you
45can develop an app that emulates an NFC card using this technique.</p>
46
47
48<h2 id="SecureElement">Card Emulation with a Secure Element</h2>
49
50<p>When NFC card emulation is provided using a secure element, the card to be emulated
51is provisioned into the secure element on
52the device through an Android application. Then, when the user holds the
53device over an NFC terminal, the NFC controller in the device routes all data
54from the reader directly to the secure element. Figure 1 illustrates this concept.</p>
55
56<img src="{@docRoot}images/nfc/secure-element.png" />
57<p class="img-caption"><strong>Figure 1.</strong> NFC card emulation with a secure element.</p>
58
59<p>The secure element itself performs the communication with the NFC terminal,
60and no Android application is involved in the transaction at all. After the
61transaction is complete, an Android application can query the secure element
62directly for the transaction status and notify the user.</p>
63
64
65<h2 id="HCE">Host-based Card Emulation</h2>
66
67<p>When an NFC card is emulated using host-based card emulation, the data is routed to
68the host CPU on which Android applications are running directly, instead of routing the NFC
69protocol frames to a secure element. Figure 2 illustrates how host-based card emulation
70works.</p>
71
72<img src="{@docRoot}images/nfc/host-based-card.png" />
73<p class="img-caption"><strong>Figure 2.</strong> NFC card emulation with a secure element.</p>
74
75
76<h2 id="SupportedProtocols">Supported NFC Cards and Protocols</h2>
77
78<div class="figure" style="width:147px">
79<img src="{@docRoot}images/nfc/protocol-stack.png"/>
80<p class="img-caption"><strong>Figure 3.</strong> Android's HCE protocol stack.</p>
81</div>
82
83<p>The NFC standards offer support for many different protocols, and there are
84different types of cards that can be emulated.</p>
85
86<p>Android 4.4 supports several protocols that are common in the
87market today. Many existing contactless cards are already based on these
88protocols, such as contactless payment cards. These protocols are also
89supported by many NFC readers in the market today, including Android NFC
90devices functioning as readers themselves (see the {@link android.nfc.tech.IsoDep} class).
91This allows you to build and deploy an end-to-end NFC solution
92around HCE using only Android-powered devices.</p>
93
94<p>Specifically, Android 4.4 supports emulating cards that are based on the
95NFC-Forum ISO-DEP specification (based on ISO/IEC 14443-4) and process
96Application Protocol Data Units (APDUs) as defined in the ISO/IEC 7816-4
97specification. Android mandates emulating ISO-DEP only on top of the
98Nfc-A (ISO/IEC 14443-3 Type A) technology. Support for Nfc-B (ISO/IEC 14443-4
99Type B) technology is optional. The layering of all these specifications is
100shown in the figure 3.</p>
101
102
103
104<h2 id="HceServices">HCE Services</h2>
105
106<p>The HCE architecture in Android is based around Android {@link android.app.Service} components
107(known as "HCE services").
108One of the key advantages of a service is that it can run in the background without
109any user interface. This is a natural fit for many HCE applications like loyalty or transit cards,
110with which the user shouldn't need to launch the app to use it.
111Instead, tapping the device against the NFC reader starts the correct service (if not already
112running) and executes the transaction in the background. Of course, you are free
113to launch additional UI (such as user notifications) from your service if that makes
114sense.</p>
115
116
117
118<h3 id="ServiceSelection">Service selection</h3>
119
120<p>When the user taps a device to an NFC reader, the Android system needs to
121	know which HCE service the NFC reader actually wants to talk to.
122This is where the ISO/IEC 7816-4 specification comes in: it defines a way to
123select applications, centered around an Application ID (AID). An AID
124consists of up to 16 bytes. If you are emulating cards for an existing NFC reader
125infrastructure, the AIDs that those readers are looking for are typically
126well-known and publicly registered (for example, the AIDs of payment networks
127such as Visa and MasterCard).</p>
128
129<p>If you want to deploy new reader infrastructure for your own application, you
130will need to register your own AID(s). The registration procedure for AIDs is
131defined in the ISO/IEC 7816-5 specification. Google recommends registering an
132AID as per 7816-5 if you are deploying a HCE application for Android, as it will avoid
133collisions with other applications.</p>
134
135
136<h3 id="AidGroups">AID groups</h3>
137
138<p>In some cases, an HCE service may need to register multiple AIDs to implement a
139certain application, and it needs to be sure that it is the default handler for
140all of these AIDs (as opposed to some AIDs in the group going to another
141service).</p>
142
143<p>An AID group is a list of AIDs that should be considered as belonging together
144by the OS. For all AIDs in an AID group, Android guarantees one of the
145following:</p>
146
147<ul>
148<li>All AIDs in the group are routed to this HCE service</li>
149<li>No AIDs in the group are routed to this HCE service (for example, because the user
150preferred another service which requested one or more AIDs in your group as
151well)</li>
152</ul>
153
154<p>In other words, there is no in-between state, where some AIDs in the group can
155be routed to one HCE service, and some to another.</p>
156
157<h3 id="GroupsCategories">AID groups and categories</h3>
158
159<p>Each AID group can be associated with a category. This allows Android to group
160HCE services together by category, and that in turn allows the user to set
161defaults at the category level instead of the AID level. In general, avoid
162mentioning AIDs in any user-facing parts of your application: they do not mean
163anything to the average user.</p>
164
165<p>Android 4.4 supports two categories: {@link
166	android.nfc.cardemulation.CardEmulation#CATEGORY_PAYMENT} (covering payment
167apps) and {@link android.nfc.cardemulation.CardEmulation#CATEGORY_OTHER}
168(for all other HCE apps).</p>
169
170
171
172<h2 id="ImplementingService">Implementing an HCE Service</h2>
173
174<p>To emulate an NFC card using host-based card emulation, you need to create
175	a {@link android.app.Service} component that handles the NFC transactions.
176
177<h3 id="CheckingforSupport">Checking for HCE support</h3>
178
179<p>Your application can check whether a device supports HCE by checking for the
180{@link android.content.pm.PackageManager#FEATURE_NFC_HOST_CARD_EMULATION} feature. You should use the
181{@code &lt;uses-feature>} tag in the manifest of your application to declare that your app
182uses the HCE feature, and whether it is required for the app to function or not.</p>
183
184<h3 id="ServiceImplementation">Service implementation</h3>
185
186<p>Android 4.4 comes with a convenience {@link android.app.Service} class that can be used as a
187basis for implementing a HCE service: the {@link android.nfc.cardemulation.HostApduService} class.</p>
188
189<p>The first step is therefore to extend {@link android.nfc.cardemulation.HostApduService}.</p>
190
191<pre>
192public class MyHostApduService extends HostApduService {
193    &#64;Override
194    public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
195       ...
196    }
197    &#64;Override
198    public void onDeactivated(int reason) {
199       ...
200    }
201}
202</pre>
203
204<p>{@link android.nfc.cardemulation.HostApduService}
205declares two abstract methods that need to be overridden and implemented.</p>
206
207<p>{@link android.nfc.cardemulation.HostApduService#processCommandApdu processCommandApdu()}
208	 is called whenever a NFC reader sends an Application
209Protocol Data Unit (APDU) to your service. APDUs are defined in the ISO/IEC
2107816-4 specification as well. APDUs are the application-level packets being
211exchanged between the NFC reader and your HCE service. That application-level
212protocol is half-duplex: the NFC reader will send you a command APDU, and it
213will wait for you to send a response APDU in return.</p>
214
215<p class="note"><strong>Note:</strong>
216	The ISO/IEC 7816-4 specification also defines the concept of multiple logical channels,
217	where you can have multiple parallel APDU exchanges on separate logical channels. Android’s
218	 HCE implementation however only supports a single logical channel, so there’s only a
219	single-threaded exchange of APDUs.</p>
220
221
222<p>As mentioned previously, Android uses the AID to determine which HCE service the
223reader wants to talk to. Typically, the first APDU an NFC reader sends to your
224device is a "SELECT AID" APDU; this APDU contains the AID that the reader wants
225to talk to. Android extracts that AID from the APDU, resolves it to an HCE service,
226then forwards that APDU to the resolved service.</p>
227
228<p>You can send a response APDU by returning the bytes of the response APDU from
229{@link android.nfc.cardemulation.HostApduService#processCommandApdu processCommandApdu()}.
230 Note that this method will be called on the main thread of
231your application, which shouldn't be blocked. So if you can't compute and return
232a response APDU immediately, return null. You can then do the necessary work on
233another thread, and use the {@link android.nfc.cardemulation.HostApduService#sendResponseApdu
234	sendResponseApdu()} method defined
235in the {@link android.nfc.cardemulation.HostApduService} class to send the response when you are done.</p>
236
237<p>Android will keep forwarding new APDUs from the reader to your service, until
238either:</p>
239
240<ol>
241<li>The NFC reader sends another "SELECT AID" APDU, which the OS resolves to a
242different service;</li>
243<li>The NFC link between the NFC reader and your device is broken.</li>
244</ol>
245
246<p>In both of these cases, your class's
247	{@link android.nfc.cardemulation.HostApduService#onDeactivated onDeactivated()}
248	 implementation is
249called with an argument indicating which of the two happened.</p>
250
251<p>If you are working with existing reader infrastructure, you need to
252implement the existing application-level protocol that the readers expect in
253your HCE service.</p>
254
255<p>If you are deploying new reader infrastructure which you control as well, you
256can define your own protocol and APDU sequence. In general try to limit the
257amount of APDUs and the size of the data that needs to be exchanged: this makes
258sure that your users will only have to hold their device over the NFC reader for
259a short amount of time. A sane upper bound is about 1KB of data, which can
260usually be exchanged within 300ms.</p>
261
262
263
264<h3 id="ManifestDeclaration">Service manifest declaration and AID registration</h3>
265
266<p>Your service must be declared in the manifest as usual, but some additional
267pieces must be added to the service declaration as well.</p>
268
269<p>First, to tell the platform that it is a HCE service implementing a
270{@link android.nfc.cardemulation.HostApduService} interface, your service declaration must contain an
271intent filter for the {@link android.nfc.cardemulation.HostApduService#SERVICE_INTERFACE} action.</p>
272
273<p>Additionally, to tell the platform which AIDs groups are requested by this
274service, a {@link android.nfc.cardemulation.HostApduService#SERVICE_META_DATA}
275<code>&lt;meta-data></code> tag must be included in
276the declaration of the service, pointing to an XML resource with additional
277information about the HCE service.</p>
278
279<p>Finally, you must set the {@code android:exported} attribute to true, and require the
280{@code "android.permission.BIND_NFC_SERVICE"} permission in your service declaration.
281The former ensures that the service can be bound to by external applications.
282The latter then enforces that only external applications that hold the
283{@code ""android.permission.BIND_NFC_SERVICE"} permission can bind to your service. Since
284{@code ""android.permission.BIND_NFC_SERVICE"} is a system permission, this effectively
285enforces that only the Android OS can bind to your service. </p>
286
287<p>Here's an example of a {@link android.nfc.cardemulation.HostApduService} manifest declaration:</p>
288
289<pre>
290&lt;service android:name=".MyHostApduService" android:exported="true"
291        android:permission="android.permission.BIND_NFC_SERVICE">
292    &lt;intent-filter>
293        &lt;action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
294    &lt;/intent-filter>
295    &lt;meta-data android:name="android.nfc.cardemulation.host_apdu_service"
296        android:resource="@xml/apduservice"/>
297&lt;/service>
298</pre>
299
300<p>This meta-data tag points to an {@code apduservice.xml} file. An example of such a file
301with a single AID group declaration containing two proprietary AIDs is shown
302below:</p>
303
304<pre>
305&lt;host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
306           android:description="@string/servicedesc"
307           android:requireDeviceUnlock="false">
308    &lt;aid-group android:description="@string/aiddescription"
309                android:category="other">
310        &lt;aid-filter android:name="F0010203040506"/>
311        &lt;aid-filter android:name="F0394148148100"/>
312    &lt;/aid-group>
313&lt;/host-apdu-service>
314</pre>
315
316<p>The <code>&lt;host-apdu-service></code> tag is required to contain a <code>&lt;android:description></code>
317attribute that contains a user-friendly description of the service that may be
318shown in UI. The <code>&lt;requireDeviceUnlock></code> attribute can be used to specify that the
319device must be unlocked before this service can be invoked to handle APDUs.</p>
320
321<p>The <code>&lt;host-apdu-service></code> must contain one or more <code>&lt;aid-group></code> tags. Each
322<code>&lt;aid-group></code> tag is required to contain a <code>android:description</code> attribute that
323contains a user-friendly description of the AID group that may be shown in UI.
324Each <code>&lt;aid-group></code> tag must also have the android:category attribute set to
325indicate the category the AID group belongs to, e.g. the string constants
326defined by CardEmulation.CATEGORY_PAYMENT or CardEmulation.CATEGORY_OTHER. Each
327<code>&lt;aid-group></code> must contain one or more <code>&lt;aid-filter></code> tags, each of which contains a
328single AID. The AID must be specified in hexadecimal format, and contain an even
329number of characters.</p>
330
331<p>As a final note, your application also needs to hold the NFC permission,
332	{@link android.Manifest.permission#NFC} to be able to register as a HCE service.</p>
333
334
335
336
337<h2 id="AidConflicts">AID Conflict Resolution</h2>
338
339<p>Multiple {@link android.nfc.cardemulation.HostApduService} components
340	 may be installed on a single device, and the same AID
341can be registered by more than one service. The Android platform resolves AID
342conflicts depending on which category an AID belongs to. Each category may have
343a different conflict resolution policy. </p>
344
345<p>For example, for some categories (like payment) the user may be able to select a
346default service in the Android settings UI. For other categories, the policy may
347be to always ask the user which service is to be invoked in case of conflict. To
348query the conflict resolution policy for a certain category, see
349{@link android.nfc.cardemulation.CardEmulation#getSelectionModeForCategory
350	getSelectionModeForCategory()}.</p>
351
352<h3 id="CheckingIfDefault">Checking if your service is the default</h3>
353
354<p>Applications can check whether their HCE service is the default service for a
355certain category by using the
356{@link android.nfc.cardemulation.CardEmulation#isDefaultServiceForCategory} API.</p>
357
358<p>If your service is not the default, you can request it to be made the default.
359See {@link android.nfc.cardemulation.CardEmulation#ACTION_CHANGE_DEFAULT}.</p>
360
361
362
363<h2 id="PaymentApps">Payment Applications</h2>
364
365<p>Android considers HCE services that have declared an AID group with the
366"payment" category as payment applications. The Android 4.4 release contains a
367top-level Settings menu entry called "tap &amp; pay", which enumerates all such
368payment applications. In this settings menu, the user can select the default
369payment application that will be invoked when a payment terminal is tapped.</p>
370
371<h3 id="RequiredAssets">Required assets for payment applications</h3>
372
373<p>To provide a more visually attractive user experience, HCE payment applications
374are required to provide an additional asset for their service: a so-called
375service banner.</p>
376
377<p>This asset should be sized 260x96 dp, and can be specified in your meta-data XML
378file by adding the <code>android:apduServiceBanner</code> attribute to the
379<code>&lt;host-apdu-service></code> tag, which points to the drawable resource. An example is
380shown below:</p>
381
382<pre>
383&lt;host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
384           android:description="@string/servicedesc"
385           android:requireDeviceUnlock="false"
386           android:apduServiceBanner="@drawable/my_banner">
387       &lt;aid-group android:description="@string/aiddescription"
388                  android:category="payment">
389           &lt;aid-filter android:name="F0010203040506"/>
390           &lt;aid-filter android:name="F0394148148100"/>
391       &lt;/aid-group>
392&lt;/host-apdu-service>
393</pre>
394
395
396
397<h2 id="ScreenOffBehavior">Screen Off and Lock-screen Behavior</h2>
398
399<p>Current Android implementations turn the NFC controller and the application
400processor off completely when the screen of the device is turned off. HCE
401services will therefore not work when the screen is off.</p>
402
403<p>HCE services can function from the lock-screen however: this is controlled by
404the <code>android:requireDeviceUnlock</code> attribute in the <code>&lt;host-apdu-service></code> tag of your
405HCE service. By default, device unlock is not required, and your service will be
406invoked even if the device is locked.</p>
407
408<p>If you set the <code>&lt;android:requireDeviceUnlock</code> attribute to "true" for your HCE
409service, Android will prompt the user to unlock the device when you tap an NFC
410reader that selects an AID that is resolved to your service. After unlocking,
411Android will show a dialog prompting the user to tap again to complete the
412transaction. This is necessary because the user may have moved the device away
413from the NFC reader in order to unlock it.</p>
414
415
416<h2 id="Coexistence">Coexistence with Secure Element Cards</h2>
417
418<p>This section is of interest for developers that have deployed an application
419that relies on a secure element for card emulation. Android's HCE implementation
420is designed to work in parallel with other methods of implementing card
421emulation, including the use of secure elements.</p>
422
423<p class="note"><strong>Note:</strong> Android does not offer APIs for directly communicating with a secure element itself.</p>
424
425<p>This coexistence is based on a principle called "AID routing": the NFC
426controller keeps a routing table that consists of a (finite) list of routing
427rules. Each routing rule contains an AID and a destination. The destination can
428either be the host CPU (where Android apps are running), or a connected secure
429element.</p>
430
431<p>When the NFC reader sends an APDU with a "SELECT AID", the NFC controller parses
432it and checks whether the AIDs matchesNo converter for: FOOTNOTE with any AID in
433its routing table. If it matches, that APDU and all APDUs following it will be
434sent to the destination associated with the AID, until another "SELECT AID" APDU
435is received or the NFC link is broken.</p>
436
437<p class="note"><strong>Note:</strong>
438	While ISO/IEC 7816-4 defines the concept of “partial matches” as well, this is currently not supported by Android HCE devices.</p>
439
440<p>This architecture is illustrated in figure 4.</p>
441
442
443<img src="{@docRoot}images/nfc/dual-mode.png" />
444<p class="img-caption"><strong>Figure 4.</strong> Android operating with both secure element
445and host-card emulation.</p>
446
447
448<p>The NFC controller typically also contains a default route for APDUs. When an
449AID is not found in the routing table, the default route is used. Beginning with Android
4504.4, the default route is required to be set to the host CPU. This
451means that the routing table typically only contains entries for AIDs that need
452to go to a secure element.</p>
453
454<p>Android applications that implement a HCE service or that use a secure element
455don't have to worry about configuring the routing table - that is taking care of
456by Android automatically. Android merely needs to know which AIDs can be handled
457by HCE services and which ones can be handled by the secure element. Based on
458which services are installed and which the user has configured as preferred, the
459routing table is configured automatically.</p>
460
461<p>We've already described how to declare AIDs for HCE services. The following
462section explains how to declare AIDs for applications that use a secure element
463for card emulation.</p>
464
465
466<h3 id="SecureElementReg">Secure element AID registration</h3>
467
468<p>Applications using a secure element for card emulation can declare a so-called
469"off host service" in their manifest. The declaration of such a service is
470almost identical to the declaration of a HCE service. The exceptions are:</p>
471
472<ul>
473<li>The action used in the intent-filter must be set to
474{@link android.nfc.cardemulation.OffHostApduService#SERVICE_INTERFACE}</li>
475<li>The meta-data name attribute must be set to
476{@link android.nfc.cardemulation.OffHostApduService#SERVICE_META_DATA}</li>
477<li><p>The meta-data XML file must use the <code>&lt;offhost-apdu-service></code> root tag</p>
478
479<pre>
480&lt;service android:name=".MyOffHostApduService" android:exported="true"
481     android:permission="android.permission.BIND_NFC_SERVICE">
482    &lt;intent-filter>
483        &lt;action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/>
484    &lt;/intent-filter>
485    &lt;meta-data android:name="android.nfc.cardemulation.off_host_apdu_ervice"
486         android:resource="@xml/apduservice"/>
487&lt;/service>
488</pre>
489</li>
490</ul>
491
492<p>An example of the corresponding {@code apduservice.xml} file registering two AIDs:</p>
493
494<pre>
495&lt;offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
496           android:description="@string/servicedesc">
497    &lt;aid-group android:description="@string/subscription" android:category="other">
498        &lt;aid-filter android:name="F0010203040506"/>
499        &lt;aid-filter android:name="F0394148148100"/>
500    &lt;/aid-group>
501&lt;/offhost-apdu-service>
502</pre>
503
504<p>The <code>android:requireDeviceUnlock</code> attribute does not apply to off host services,
505because the host CPU is not involved in the transaction and therefore cannot
506prevent the secure element from executing transactions when the device is
507locked.</p>
508
509<p>The <code>android:apduServiceBanner</code> attribute must be used for off host services that
510are payment applications as well in order to be selectable as a default payment
511application.</p>
512
513<h3 id="OffHostInvocation">Off host service invocation</h3>
514
515<p>Android itself will never start or bind to a service that is declared as "off
516host". This is because the actual transactions are executed by the secure
517element and not by the Android service itself. The service declaration merely
518allows applications to register AIDs present on the secure element.</p>
519
520<h2 id="HceSecurity">HCE and Security</h2>
521
522<p>The HCE architecture itself provides one core piece of security: because your
523service is protected by the {@link android.Manifest.permission#BIND_NFC_SERVICE}
524 system permission, only the OS can
525bind to and communicate with your service. This ensures that any APDU you
526receive is actually an APDU that was received by the OS from the NFC controller,
527and that any APDU you send back will only go to the OS, which in turn directly
528forwards the APDUs to the NFC controller.</p>
529
530<p>The core remaining piece is where you get the data from that you're sending back
531to the NFC reader. This is intentionally decoupled in the HCE design: it does
532not care where the data comes from, it just makes sure that it is safely
533transported to the NFC controller and out to the NFC reader.</p>
534
535<p>For securely storing and retrieving the data that you want to send from your HCE
536service, you can for example rely on the Android Application Sandbox, which
537isolates your app's data from other apps. For more details on Android security,
538read
539<a href="{@docRoot}training/articles/security-tips.html">Security Tips</a>
540.</p>
541
542<h2 id="ProtocolParams">Protocol parameters and details</h2>
543
544<p>This section is of interest for developers that want to understand what protocol
545parameters HCE devices use during the anti-collision and activations phases of
546the NFC protocols. This allows them to build a reader infrastructure that is
547compatible with Android HCE devices.</p>
548
549<h3 id="AntiCollisionAct">Nfc-A (ISO/IEC 14443 type A) protocol anti-collision and activation</h3>
550
551<p>As part of the Nfc-A protocol activation, multiple frames are exchanged.</p>
552
553<p>In the first part of the exchange the HCE device will present its UID; HCE
554devices should be assumed to have a random UID. This means that on every tap,
555the UID that is presented to the reader will be a randomly generated UID.
556Because of this, NFC readers should not depend on the UID of HCE devices as a
557form of authentication or identification.</p>
558
559<p>The NFC reader can subsequently select the HCE device by sending a SEL_REQ
560command. The SEL_RES response of the HCE device will at least have the 6th bit
561(0x20) set, indicating that the device supports ISO-DEP. Note that other bits in
562the SEL_RES may be set as well, indicating for example support for the NFC-DEP
563(p2p) protocol. Since other bits may be set, readers wanting to interact with
564HCE devices should explicitly check for the 6th bit only, and <stront>not</strong> compare the
565complete SEL_RES with a value of 0x20.</p>
566
567<h3 id="IsoDepAct">ISO-DEP activation</h3>
568
569<p>After the Nfc-A protocol is activated, the ISO-DEP protocol activation is
570initiated by the NFC reader. It sends a "RATS" (Request for Answer To Select)
571command. The RATS response, the ATS, is completely generated by the NFC
572controller and not configurable by HCE services. However, HCE implementations
573are required to meet NFC Forum requirements for the ATS response, so NFC readers
574can count on these parameters being set in accordance with NFC Forum
575requirements for any HCE device.</p>
576
577<p>The section below provides more details on the individual bytes of the ATS
578response provided by the NFC controller on a HCE device:</p>
579
580<ul>
581<li>TL: length of the ATS response. Must not indicate a length greater than 20
582bytes.</li>
583<li>T0: bits 5, 6 and 7 must be set on all HCE devices, indicating TA(1), TB(1)
584and TC(1) are included in the ATS response. Bits 1 to 4 indicate the FSCI,
585coding the maximum frame size. On HCE devices the value of FSCI must be
586between 0h and 8h.</li>
587<li>T(A)1: defines bitrates between reader and emulator, and whether they can be
588asymmetric. There are no bitrate requirements or guarantees for HCE devices.</li>
589<li>T(B)1: bits 1 to 4 indicate the Start-up Frame Guard time Integer (SFGI). On
590HCE devices, SFGI must be &lt;= 8h. Bits 5 to 8 indicate the Frame Waiting time
591Integer (FWI) and codes the Frame Waiting Time (FWT). On HCE devices, FWI must
592be &lt;= 8h.</li>
593<li>T(C)1: bit 5 indicates support for "Advanced Protocol features". HCE devices
594may or may not support "Advanced Protocol features". Bit 2 indicates support
595for DID. HCE devices may or may not support DID. Bit 1 indicates support for
596NAD. HCE devices must not support NAD and set bit 1 to zero.</li>
597<li>Historical bytes: HCE devices may return up to 15 historical bytes. NFC
598readers willing to interact with HCE services should make no assumptions about
599the contents of the historical bytes or their presence.</li>
600</ul>
601
602<p>Note that many HCE devices are likely made compliant with protocol requirements
603that the payment networks united in EMVCo have specified in their "Contactless
604Communication Protocol" specification. In particular:</p>
605
606<ul>
607<li>FSCI in T0 must be between 2h and 8h.</li>
608<li>T(A)1 must be set to 0x80, indicating only the 106 kbit/s bitrate is
609supported, and asymmetric bitrates between reader and emulator are not
610supported.</li>
611<li>FWI in T(B)1 must be &lt;= 7h.</li>
612</ul>
613
614<h3 id="ApduExchange">APDU data exchange</h3>
615
616<p>As noted earlier, HCE implementations only support a single logical channel.
617Attempting to select applications on different logical channels will not work on
618a HCE device.</p>
619