I am working on nfc based Identification System. I am storing data on android device and at the time of Identification The nfc reader reads the data from android device for this thing the android device should run in HOST based card emulation based on ISO/IEC 14443-3 and for the deployment the nfc reader send the Application ID to identify service as per Google Developer NFC documentation so how i get the application id for custom application
According to the documentation:
"Specifically, Android 4.4 supports emulating cards that are based on the NFC-Forum ISO-DEP specification (based on ISO/IEC 14443-4)" So you cannot do ISO 14443-3 based HCE using this.
If you are creating a proprietary application using HCE then it is up to you to create the AID used by the reader and registered by the app. You can choose any AID but see this Setting up host card emulation answer for more detail about how to choose the AID to avoid clashes with other apps.
Related
I have read the Android documentation about NFC and found that it could emulate an NFC tag. However it requires that you register which AID you serve.
Is it possible to create an application that handles communication if the NFC reader does not send a "SELECT AID" APDU? Either by creating an application where the AID in the manifest file is empty, or create some sort of default application.
I don't mind if the application has to be in the foreground, if that helps in any way.
Thank you in advance.
No, the Android API currently does not support this. Commands are only routed to applications upon reception of a SELECT (by AID/DF name) command that matches an AID registered to the system. As of Android 4.4.4 there is no mechanism to define a catch-all/default app.
It seems that Android devices currently only use the AID-based routing mechanism defined in the NFC Forum NCI specification. However, the NCI specification also defines protocol-based and technology-based routing. These routing mechanisms could instruct the NFC controller to forward all communication regardless of a SELECT (by AID/DF name) command to the application processor/Android system. Consequently, it might be possible to implement a modified Andoid system that permits default routing of all communication to an app, but it's unclear if the NFC controllers used in Android devices support protocol-based or technology-based routing mechanisms (support for them seems to be optional).
I have some questions about the communication between a NFC reader and an Android phone.
The first subject is the Android / NFC reader modus:
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device? ACR122U in peer-to-peer, card emulation, or reader/writer mode? Wich modus are possible? And what is the best mode if you want bi-directional communication?
The second subject is about the listener on the android device:
How can a Android reader trigger an Android application? When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
Many thanks.
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device?
That depends on what you want to achieve.
Using the ACR122U in reader/writer mode will basically limit you to using Android 4.4 and later (as Android HCE -- for putting the phone into host-based card emulation mode -- is only supported from 4.4 onwards).
Peer-to-peer mode will work but will effectively limit you to sending one data packet (or one message) into a single direction.
Using the ACR122U in card emulation mode will permit you to perform true bidirectional communication (i.e. to send multiple data packets into both direction).
See this answer for a list of further literature.
Which modes are possible?
All three modes are possible but give you different degrees of freedom.
And what is the best mode if you want bi-directional communication?
See above, using the ACR122U in card emulation mode and the phone in reader/writer mode will permit bi-directional communication on all Android versions. The phone has the role of the interrogator (in a command-response protocol) in this case.
If you only want/need to support Android 4.4 and later, you could just as well use the phone in HCE (host-based card emulation) mode and the ACR122U in reader/writer mode.
When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
If you are using Android HCE (phone as emulated card): In this case, the communication is handled by a background service. No user interface is needed on the device. If you want to start a user interface upon scanning the ACR122U with a phone, I suggest that you stick with using the Android in reader/writer or peer-to-peer mode (though you could start a UI through the HCE service too).
If you are using the Android in reader/writer mode: You need an app running in the foreground to communicate with an NFC tag/smartcard/emulated card. However, the
app can be started automatically upon detection of the tag. You would
use an intent filter that matches either the tag's technology or
(better yet) matches an NDEF record that is stored on the tag. See
this for further details.
Hi I am android developer. I already build android NFC reader and writer and beam. So using writer i can write simple data on NFC tags and with the help of reader I can read data from tag. Using beam I can transmit data between two NFC enabled devices. So till now everything works fine. Now I want to work on NFC payments. I am working on android platform. So my question is that how NFC readers works which are use for payments. Are they work on Beam or our device act as nfc tag for NFC readers and it simply reads data from device.Mean how on device side I conform that this reader is for payments or something else. I read about HCE of android it helps a lot for understanding concept. But I am bit confuse regarding readers concepts and there working scenarios. Is there any one can help me out to understand this things, Need Help. Thank you.
When you talk about payments I assume you refer to payments based on well-known credit card schemes like AmEx, Discover, JCB, MasterCard, VISA, etc. Their payment protocols are standardized in EMVCo. Note that there are other (not that wide-spread) payment schemes that use different approaches.
For the contactless protcols of EMV-based payment cards, they typically follow the following scheme:
ISO/IEC 14443 anti-collision and activation (either Type A or Type B)
ISO/IEC 14443-4 transport protocol
ISO/IEC 7816-4 APDUs
Payment scheme specific command-sets (the reader side for those command sets is standardized in EMVCo's EMV Contactless Specifications for Payment Systems, seperated in 5 different kernels for different credit/debit card schemes)
(In Android's reader/writer mode NFC API terminology, "ISO/IEC 14443 anti-collision and activation (either Type A or Type B)" would be NfcA or NfcB and the combination of "ISO/IEC 14443 anti-collision and activation (either Type A or Type B)" and "ISO/IEC 14443-4 transport protocol" would be IsoDep.)
So the payment terminal (e.g. POS) implements the reader side for the above protocol stack. The user-side payment device (e.g. plastic credit card, mobile phone with virtual credit card) implements the card-side of these protocols.
So to your questions:
Beam (or NFC's peer-to-peer mode) is not involved in these payment card schemes.
NFC's reader/writer mode (as implemented on Android devices) is mostly capable of implementing the payment terminal side of these schemes.
I don't like the term "act as NFC tags" in that context. NFC tags (as defined by the NFC Forum) are pure data containers with read (and optional write) access, where NDEF messages can be stored on. Payment cards, however, are (contactless) smartcards with processing capabilities (i.e. they execute program code), secure data storage and cryptographic capabilities. Besides freely readable static data, they typically also contain program logic that processes requests from the reader side and they also contain secret keys (that can never be read from the card by conventional means) used for signature generation over payment transactions, etc.
Android's HCE facility permits developers to implement the above protocol stack on an Android device. So with HCE and Android device can be put in a mode where it acts as a contactless smartcard and interprets ISO/IEC 7816-4 smartcard commands (APDUs).
Is it possible for an Android application to send a previously stored RFID card ID to a NFC reader? The aim would be to use an Android device to enable access to a room instead of a physical RFID card.
Having read a lot of other threads about NFC/RFID & card-emulation, I came to the conclusion it was not available for now in Android but I'm still kinda confused if it apply to this particular case. Can't the application simply send the card ID within a NDEF message or an APDU command or I'm just completely dreaming?
Well, strictly speaking. For what you want to do you don't need card emulation. You just need to send a token to the door lock that can be validated.
You could do this with Android beam by pushing an NDEF message to a device that is compatible, SNEP is the protocol you'll be looking for.
A solution I would prefer would be to get the door lock device to emulate a tag. Then you could have your Android app register a listener for that tag (Doesn't even need to be running). When the tag is detected that app will fire up and send your secure token to the lock by using the tag write NFC functions in the Android SDK.
Securing your token is another matter.
The android view:
Long story short: It's not possible.
Long story long:
It would be possible from a hardware and software point of view to do this. The NFC chips are perfectly capable to emulate most (not all) standard tags. The functionality to do this is even built in the lower level software but not exposed to applications.
Why: Emulating tags is what the entire mobile payment infrastructure is built upon. Allowing two card emulations of the same type at once is for most NFC chips not possible and will also shut off mobile payment as mobile payment readers only accept a single tag at once (for security reasons).
Things are a bit different for RIM based Blackberry phones, they allow card emulations (even have this feature out of the box) but they don't do any mobile payment at the moment as far as I know.
When somebody purchases something and pays with google's NFC payment system (google wallet) , is the phone sending information to the register (if yes, what?) or is it just receiving the cashier's ID code, and then completing the transaction online (like dwolla)?
-gk
during the payment the phone behaves exactly in a the same way as a contact-less payment plastic card (it is based on same ISO/IEC standards). Phone works in so called 'card-emulation' mode. The card is emulated in the secure element, which is highly protected chip. This chip can be so-far programmed only by Google or Samsung. Only those two manufacturers or possibly highly trusted 3rd party (currently I am not aware of any) companies have the possibility to use the build-in NXP SmartMX secure element. It means that nobody else can develop similar application like Google Wallet.
You can of course use other NFC HW for payment - the SIM card, but then you must deal with MNOs (Android SDK does not support the SWI officially), bluetooth NFC sticker or NFC SD card or SD card connected with NFC antenna via NFC-WI (S2C). Note that the last option is the best one, but is not supported by any phone.
You can also invent some proprietary payment system, which is less secure or which uses different schema like e.g. NFC PayPal application, which does not use the secure element, but the peer-to-peer mode for communication between phones. In this application the NFC is just the bearer to transport information - they can do the same over bluetooth or WiFi.
BR
STeN