This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Question about Android 4.4 Kitkat Host Card Emulation



Hi all~ This is Sungho.

I have a question about android`s new NFC function.

I heard that Android Kitkat will have NFC host card emulation(HCE) function. 

Is this mean that smart phone will be able to recognize an initiator(reader) without unlocking its sleep mode?? 

Until now to recognize a reader , handset user have to unlock their phone and turn on the android beam for bluetooth pairing.

I think it is so inconvenient way to use(Bluetooth pairing..etc..). I don`t know why I have to use SSP(Secure Simple Pairing)....I can do the same thing by touching the bluetooth icon on the smart phone....Of course I know at first pairing I have to do some settings.

I know that an initiator can give some power to NFC chip which resides in a handset.

And then NFC chip wake  and  It responses to  the Initiator~~~after some of their handshaking..NDEF data can be exchanged.

Am I wrong ?

Any replies will be welcome..

Thanks

-Sungho

  • Sungho - 

    its about simplicity and convenience. those of us who are very familiar with technical devices might overlook that the rest of the world is not and when BT will not connect and pair, its a frustrating thing for them. BLE and WiFi also fall in here, too.  

  • Hi Sungho,

    Just as Josh says, using SSP for pairing devices is a very convinient way of pairing two devices by just directly exchanging the bit of information that, otherwise, would require a full devices discovering execution plus additional mutual authentication and user PIN confirmation. It should be up-to the user using SSP or not.

    Usually the NFC analog front ends (AFE) support low power modes and wake-up on RF presence (at least the ones I've been looking at). Not all handsets use one independent IC for the NFC AFE as some very speciallized processors already include the AFE.

    The new HCE support in Android gives the host application the possibility to bind one (or more) service to one AID, so when the reader sends the command "SELECT AID" the service call and further executeAPDU() requests are dispatched according to registered services for that AID.

    Control for the possibility of being recognized without device unlock has also been introduced. It is controled at service manifest level with the attribute named <requireDeviceUnlock>. A few days ago a collegue pointed us to this page that introduces the term (among others) and gives some good and interesting background on the subject: https://developer.android.com/guide/topics/connectivity/nfc/hce.html.

    Regards,
    --Victor

  • Hi Victor.

    Thank you ~ I read the link you gave.

    According to the Supported NFC Cards and Protocols part in the link,

    Kitkat supports ISO/IEC 14443-4...and APDUs(ISO/IEC 7816-4).

    Is this mean NDEF exchange is available for Bluetooth Pairing?

    Thanks.

    -Sungho

  • Hi Sungho,

    To my limited knowledge, NDEF support is mandatory for Android devices supporting NFC, and from your application you have some API's for using collected NDEF data. That API partly isolates your application from the underlaying enumerated fare media or NFC device. I've not excersized this API before but you'll find info about it here: http://developer.android.com/reference/android/nfc/tech/Ndef.html. It seems to be supported from API levels 9/10.

    NDEF messages encapsulate many types of records, not only pairing information for Bluetooth or WiFi.

    Perhaps you'll find more precise information in dedicated forums from the Adroid developers community and in the documentation available from the NFC Forum.

    Regards,
    --Victor