HCE: The User Experience That Nobody Talks About

Host Card Emulation (HCE) is an incredibly enabling technology. For Android developers there are a few nuances to be aware of in the form of OS rules. Not understanding how these rules apply can have a negative impact and create an embarrassing or awkward customer experience if the system should render a 'payment failure'. Here are four scenarios to keep in mind to avoid point-of-sale issues.

Avoid The Embarrassment

The only limiting factor for the NFC radio in an Android device is whether or not the screen is lit up. What that means is that the NFC radio will turn on and could be ready for an HCE transaction is:

screen is dark:    NO
screen is lit:       YES

That rule alone is an Android rule, not an application rule, and so the application will have the ability to further limit this HCE experience if it wants to.

To support the best user experience, an application must be able to respond and complete an HCE transaction on demand if the screen is lit up. This should hold true even if:

1) application is running in the foreground
2) application is running in the background
3) application is NOT running at all because android has "repo'd" or removed it from running memory, or not started at all since a re-boot of the phone.
4) application is NOT running and a time based  Limited Use Key has expired since the application stopped running

The 1st and 2nd cases above are the easy ones as transaction data can be store in the running application memory space.

Here is how android works on the 3rd and 4th scenarios. When the phone antenna engages the terminal antenna and the terminal requests a particular AID, then the android OS looks at that AID request from the terminal and decides which Card Emulation Service to startup based on the "Tap and Pay" menu options.  That service is NOT your app, it is a component of your application that is expected to respond to APDU requests from the terminal. An APDU stands for Application Protocol Data Units.  The challenge is that the service will most likely not contain the APDU data to respond with as the rest of the application is not currently running at that time and the data required may not be loaded. It would require that the APDU data that the reader is asking for actually must be persistent in some way on the device so that the service could get access to it and answer the terminal properly with card data.

There are a few ways to store data locally, but the point is that it must happen in order to respond to the reader in time for a proper user experience. We have noted that simply expecting the application to be running on the phone at tap time is simply not reliable and that in a 24 hour window, it the app is not used, then Android has likely removed that application from memory.

This is just food for thought as you are thinking of designing your own HCE application or using a vendor like ST.  By the way, the SimplyTapp SDK supports all 4 scenarios listed above. The 4th is slightly more complicated, but i'll leave it up to you to noodle at.