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