[android-developers] Re: NFC device identification
Hi Vasek, see ISO/IEC 18092 (or its freely available Ecma version ECMA-340) for a detailed description of the NFC protocol. During the link activation phase, NFC devices perform an anticollision mechanism. For active mode communication this is done by collision aviodance (i.e. the targets will answer with a random delay and only if there is no other target alredy answering. Thus the target with the shortest random delay will win the anticollision). For passive mode communication there are two strategies: For 106kbps a binary search anticollision is used (all targets will answer synchronously with a pseudo-unique identifier (NFCID1), the initiator will detect bit collisions in the received identifier and re-request only targets that have the colliding bit either set or cleared...). For 212kbps and 424kbps a time slot based anticollision is used (each target will randomly choose one of the available time slots to answer with its NFCID2). After the anticollision the initiator has has a list of targets available for communication. The initiator can choose to either communicate with only one target or even activate multiple targets which can then be addressed through a device ID (DID) field in the NFC Data Exchange Protocol commands. However, current Android implementations usually limit communication to one device (even if the chipset could handle multiple devices). Best regards, Michael -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] NFC Card Emulation on android
Hi Eliseo, so Nexus S, Galaxy Nexus and Galaxy S III have a fixed UID? These phones have an embedded secure element that has a fixed UID. it is due to the NFC NXP controller or to the secure element? Secure Element. The NFC controller uses random UIDs for all other cases. Which secure element they have? The embedded secure element on the Nexus S/Galaxy Nexus is a SmartMX from NXP. In a previous post, Nikolay say that You can't fix the UID, at least not with any of the standard NXP controllers.. Is it correct? For NXP's PN544 that's correct. For peer-to-peer mode and software card emulation, that NFC controller will use a random UID/NFCID1. Only in secure element based card emulation mode, the UID provided by the secure element is used. the fixed UID depends of the SE present on the phone? In case of random UID, what kind of SE is present? It not only depends on the SE being present. For the SE's UID to be used, the phone must also be in card emulation mode using that secure element. Which android phones can do software card emulation? is it made by the OS or by one custom application? The CyanogenMod 9.1 firmware contains patches to enable card emulation on phone's with NXP's NFC chipset (PN544). So any phone that you can put CyanogenMod on and that contains a PN544 should work. The standard Android OS on the phones is currently not capable of software card emulation. Best regards, Michael -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] NFC Card Emulation on android
Hi Eliseo, What I want to do is to use the UID received from the phone to read/write the tag emulated on the phone. Another application possible is to use the phone in access control applications, but a fixed UID is necessary. The UID is random for security reasons? How Card Emulation can be used if the UID is random? Typically, if you receive a random UID from the NFC phone you detected the phone's peer-to-peer mode (i.e. the phone listening in passive mode at 106kbps) or -- if the phone supports it -- software card emulation mode. If it's peer-to-peer mode, the random UID (btw. the first byte of a random UID is 0x08, except for some weird cards from NXP ;-) ) is actually an NFCID1. Most secure elements on the other hand provide a static UID. (At least the one that is embedded into the Nexus S/Galaxy Nexus/Galaxy SIII). You can determine if the detected target supports peer-to-peer mode or if it is in card emulation mode by the value of the SAK byte (in ISO 14443 language or SEL_RES in ISO 18092 language). If the bits of SAK are numbered from 7 downto 0 and bit 2 = 0: - Bit 6 = 1 denotes that the target supports NFC-DEP (i.e. peer-to-peer mode as defined in ISO 18092). - Bit 5 = 1 denotes that the target supports ISO-DEP (i.e. the smartcard transport protocol from ISO 14443-4). If none of those two bits is set then the target supports only some proprietary protocol. So if you detected that it's peer-to-peer mode, then there is NO tag to read/write from. However, you could use some library like ismb-snep-java to exchange data through Android Beam. Regarding fixed UIDs with Android NFC phones: At least phones based on the NXP chipset (i.e. PN544) can only have a fixed UID in combination with a secure element that has a fixed UID. For software card emulation mode, the NFC controller will always use a random UID. br, Michael -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi Harry, Im quite new to NFC, but I'm just wondering if emulation could possibly be done by bypassing the SE altogether and instead say simulating a peer to peer mode in order to create a tunnel through which an app could perform secure operations etc? With current Android and if you have no constraints on how to design the other end of the communication, I think the easiest option is to use reader/writer mode and have the other end use software card emulation (i.e. emulate a smartcard). Secure operations...that depends on what level of security you expect. On current Android it is difficult/impossible to store secret information within an app (one way or another an attacker may be able to access that information). While that may not be a problem with many applications, it might be with some (e.g. payment). br, Michael On Monday, April 4, 2011 9:37:52 PM UTC+9:30, Michael Roland wrote: Hallo JMC, I think there is a big misunderstanding out there of what card emulation is (and what it is not!). First of all, NFC has three different communication modes: * Reader/writer mode, * Peer-to-peer mode, and * Card-emulation mode *Reader/writer mode* is used to access NFC tag (i.e. tags that comply to the tag formats specified by the NFC Forum and contain NDEF data). Moreover, this modes provides compatibility to existing RFID (13.56MHz, inductive, proximity coupling) card infrastructures (i.e. you can interact with contactless smart (and memory) cards, like MIFARE, ePassports, ...) The Nexus S supports reader/writer mode for 3 (4) contactless standards: - ISO/IEC 14443 Type A (e.g. MIFARE) and Type B - JIS X 6319-4 (that's FeliCa) - ISO/IEC 15693 (that's vicinity coupling cards, which is not NFC but uses a similar communication technique also in 13.56 MHz) *Peer-to-peer mode* is used for direct communication between two NFC devices (e.g. two mobile phones, but an NFC device can be pretty much anything). This mode lifts the restrictions imposed by an active reader -- passive card system. Thus, in a classic RFID/smart card system there is a reader device that starts and controls the communication with one or multiple cards, and cards that process commands received by reader. Whereas, in a peer-to-peer system any device can start (and control) the communication with any other device. Peer-to-peer mode is used to exchange any data between NFC devices. This data can be as simple as NDEF messages, but it's even possible to tunnel other network protocols like IP over a peer-to-peer link. The Nexus S supports the peer-to-peer protocol (NFC-DEP, ISO/IEC 18092) with LLCP (NFC Logical Link Control Protocol) on top. With the current API level only a simple exchange of NDEF messages (with Android's proprietary protocol on top of LLCP) is possible. *Card-emulation mode* is used to emulate a contactless smart card with an NFC device. This mode provides compatibility to existing RFID (13.56MHz, inductive, proximity coupling) reader infrastructures. An NFC device in card-emulation mode acts the same as any real contactless smart card. With card emulation it is important to notice the difference between a _contactless smart card_ and an _NFC tag_: - An NFC tag is a contactless transponder that has a certain memory layout and contains standardized data elements (NDEF messages). Four such layouts are defined by the NFC Forum (tag types 1 to 4). Tag type 1 is based on Innovision's Jewel tags, tag type 2 is based on NXP's MIFARE Ultralight. So I would not consider these two smart cards (they are more like simple memory cards). Tag type 3 is based on FeliCa and tag type 4 is based on the ISO/IEC 7816-4 smart card standard. Therefore, the latter certainly are smart cards. Yet, in this case an NFC tag is a smart card with a specific file layout (i.e. a card that contains the NDEF application). Besides the standardized NFC tag formats, vendors like NXP have created guidelines for using their contactless card technologies (e.g. MIFARE Classic) as NFC tags. An NFC tag is only data storage and doesn't have (may have but not use) special security features like data encryption, ... - A smart card can be much more than an NFC tag. A smart card can contain, for instance, a credit/debit card application, a ticketing application for public transport ... These applications have even existed before NFC. They DO NOT use the NDEF format to exchange data. Instead they use their own protocols (e.g. EMV for payment cards). Often they use special security features of smart cards (high security execution
[android-developers] Re: can NFC read the RFID tag?
Hi, i have wonder on web to find the answer can android-NFC can read RFID tag data or not That depends on what type of RFID tag you want to read. NFC devices can read a subset of RFID tags. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi Nikolay, That is my understanding too, so I am not too far off :) I still don't get the intent when I send APDUs but that may be a problem with my libnfc setup. When I have a IsoPcdA activity in the foreground nfc_initiator_select_passive_target() return 0, i.e. no tags found, but this same code works with Google Wallet. Might be some sort of a catch 22 situation -- the reader expecting some response to detect it as a tag, and the tag expecting something from the reader to get activated. Well, the intent won't fire until the first APDU is sent. So as you didn't finish anti collision and activation, there is no APDUs yet. I believe I read a report about the phone not advertising NFCIP1 (in SAK byte) while the secure element is active, but I don't remember where I found that. Still, that shouldn't make any difference in this case. Unfortunately I didn't get a chance to investigate further. Additionally the ATR/ATS is different depending on whether Google Wallet is installed. Will try to look into it some more. Yeah, when Wallet is installed, it automatically activates the secure element for card emulation, so you will also see the SE's ATS (instead of the one generated by the PN544 for software card emulation/peer-to-peer). br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi Nikolay, Maybe Doug can give some more hints on how to properly use IsoPcd? Does he hang around here :) I don't know, but I had BCC'd him on that message, so here is what he wrote: || Sure guys, || ISOPCDA/B is just another tag type. || The only difference is that the intent won't fire unless the app || is in the foreground. This is on purpose to give default to || google wallet. The intent will fire only when the first APDU is || sent from reader to phone. At that point...the intent fires (so || rats, select, reset, etc 14443-3 commands don't fire the intent) || The emulation is a 14443-4 level emulation intended for APDU || exchange. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi Nikolay, Since you wrote the paper on this, any hints on how to activate software CE in CyanogneMod? Looking at the code, the app should get a notification for a IsoPcdA tag and be able to transceive() with it, but I don't get this when sending reset, select etc. with an external NFC reader. I have registered for IsoPcdA using foreground dispatch, and looking at the logs IsoPcdA seems to be enabled. Does the reader need to send any specific command to get this to work? I've tried with both CM9 (ICS) and CM10 (JB), but never get TECH_DISCOVERED intent. Unfortunately, I haven't tried software card emulation on Android yet. Have you confirmed that your reader actually sees the emulated card? What UID value and what SAK do you get on the reader side? Maybe Doug can give some more hints on how to properly use IsoPcd? br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi, Thanks for the series of fascinating posts and NFCTagInfo (I just installed it today!). :-) There's still a few things that are unclear to me about why card emulation isn't possible. I realize that applets within the secure element can't be modified without the vendor crypto key, but what is preventing a company or a (determined) developer from emulating the applet outside of the secure element? At the moment: There is no support for software card emulation in the standard Android system. You should be able to do this with CyanogenMod 9(? don't know exactly which in version the necessary patches were included, but the patches exist). Also when you emulate the smartcard in software on the application processor, you won't have the security of a dedicated smartcard chip of course. For more information on this issue, you might be interested in my recent paper Software Card Emulation in NFC-enabled Mobile Phones: Great Advantage or Security Nightmare? Available online: http://www.medien.ifi.lmu.de/iwssi2012/papers/iwssi-spmu2012-roland.pdf Is this how the SuicaMobile android application works? It was written by the company itself, but since it works with stock android, it doesn't have access to the WRITE_SECURE_SETTINGS permission. I didn't find any app by that name on Play Store. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hi, This just made the news :) http://www.cyanogenmod.com/blog/cyanogenmod9-1-and-simplytapp Thanks for the info. It is probably only visible from Japan, but here it is: https://play.google.com/store/apps/details?id=com.mobilesuica.msb.android Does it really work with stock Android? I always assumed that it uses some proprietary protocol and driver to talk to the FeliCa chip. The whole thing is proprietary and patented all over, but they do have web services that do their proprietary key derivation (iCAS), so it is possible that it's done online. The other alternative is a dedicated derivation chip, but those are expensive. Seems to be all Japanese ( Google translate didn't help much either). As it doesn't request NFC permisssion and works with Android 2.1+, I would assume that it works completely online. Or maybe there is some proprietary interface for FeliCa on Japanese Android smartphones? br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC P2P Samsung Galaxy SII and ACR122U
Hello, this is certainly not related to Android development, so you might be on the wrong list. However, I have an idea what could have gone wrong. Some versions of the ACR122U need to be activated from power-down mode before bringing them into initiator/target mode. You can try this by issuing a RfConfiguration command with parameter 0x01 0x03 before the TgInitAsTarget/InJumpForDep commands. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NDEF Message
Hello Shekhar, I am already aware of the fact that a NDEF message can have multiple NDEF records in it and payload data allowed is maximum of 2^32-1 bytes. If I have a payload data of 100 octets which is inside the range of default MIU, in that case should I send the data in one record or in a chunk of records. Which one is preferable and why? You should not bother about record chunks. Devices (or the operating system) are supposed to handle them automatically. So all you do in your app is put the record payload into an NDEF record and the NDEF record into an NDEF message. Suppose a remote device( which is not android ) send the NDEF message in the group of NDEF records then how to extract the payload from it. If a remote device splits the record into multiple chunks, the Android system should join the junks into full records before presenting them to the app. (Although, I have not thested if Android is capable of handling chunked records.) br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android NFC Options
Hi Alistair, I'm attempting to get into NFC on Android by communicating with a custom PN532 device, however I'm a little confused as to my options and the Android protocol. - NFCIP-1, is it possible to place my device as a target into this mode, for Android to automatically detect and communicate with to load an app Android's foreground NDEF push/beam is based on NFCIP-1 (+ LLCP), so you can exchange NDEF messages between an Android device and the PN532 in peer-to-peer mode. See http://code.google.com/p/ismb-snep-java/ (or the older http://code.google.com/p/ismb-npp-java/ ) for an example of how to communicate with Android apps in peer-to-peer mode. The ACR122U that is used in this examples contains a PN532, so it should be easy to adapt them to your custom PN532 device. - or can this only be done in card emulation mode (i.e. does NFCIP-1 have to be actively triggered)? You mean that you put your PN532 into card emulation mode and use the Android device as a card reader? This is also possible. You could then, for instance, emulate a type 4 NDEF tag or use your custom ISO-DEP based protocol. - What's the easiest to use card emulation mode for the sake of data format simplicity? (get an NDEF file over to the phone as simple and easy as possible that it will automatically act upon)? If you put the PN532 into card emulation mode and emulate a type 4 NDEF tag (see the NFC Forum website for the specification), the phone will recognize it as any other (real) tag. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: does NFC in gingerbread support card simulate?
Hi Shailen, I see that you created the NFCTagInfo App, available on the market. This app is, by far, the best Tag reader, because of all the little information it can give us, for example the HEX/ASCII values of the sectors. Thanks! Anyway, I just wanted to point out that it is possible to simulate an NFC Tag with card emulation. I was able to turn on card emulation on my Samsung Nexus S phone which sports a PN65 (=PN544+SmartMX) chip. The emulated card was a MIFARE 4K, which is a Type 4 NFC Tag. Using another Nexus S and the NXP TagWriter app, I was able to write a plain text message on the card-emulated Nexus S. First of all, you are partly right: The embedded secure element can be enabled with the latest device firmware (or is usually enabled by default to allow Google Wallet to work). Second, you are certainly wrong with MIFARE 4K beeing a Type 4 NFC tag! MIFARE 4K (and so does MIFARE 1K) use a proprietary protocol that is not specified as part of the NFC Forum's NDEF tag specifications. Still, once the embedded secure element is enabled for card emulation the MIFARE 4K area is readable and writable with the default keys. So it could probably be used with *some* NFC devices as NFC tag. Remember, however, that not all NFC devices support MIFARE 1K/4K. Also, this only allows external access to the MIFARE area. Internal access, i.e. through an app on the same phone, is still not easily doable. (It can be done with firmware modifications and it can be done through components installed as part of Google Wallet.) That said, full card-emulation is possible on the Nexus S!! I certainly would not call this *full* card emulation. Especially as you cannot modify the card content from within the phone. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: HID iCLASS
As far as I understand it, HID iClass does not use all ISO 15693 layers and is, thus, not compatible to the Nexus S's NFC hardware. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Is NFC card emulation possible on Galaxy Nexus and OS 4?
Hallo Roman, I have another question regarding card emulation. Do you know whether the UICC is physically connected to the NFC controller (SWP) on the Galaxy Nexus or not? Unfortunately, I don't know for sure. I would assume that the SWP pin is connected to the NFC controller (just as it is the case with the Nexus S) but I had no chance to test this yet. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Is NFC card emulation possible on Galaxy Nexus and OS 4?
Hallo Roman, Are you interest in investigating this assumption with me? Another option would be to ask Samsung. That reduces a lot of overhead regarding compiling, flashing, debugging etc. I assume that it will be easier to modify the firmware than to get a definitive answer from Samsung^^. However, testing if SWP is available should be rather easy (even without firmware modifications) if you have an SWP-enabled UICC. I expect that SWP will be initialized even if emulation mode is not switched to the UICC. So I guess you could just measure the voltage signal on the SWP pin (that's the communication from CLF to UICC) with an oscilloscope. SWP initialization should be performed during phone startup. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: is Card Emulation supported in Android with NFC?
Hallo Anatoly, I Suppose SE is Secure Element am i Right? Right. Is there any way to communicate with reader, without modyfing firmware? No. Android has no support for card emulation from software. From an external ISO 14443 reader you can only access the secure element. With a reader that supports peer-to-peer (ISO 18092) you could, however, communicate with the phone using NPP/SNEP (Android Beam). Or may be i can get access to secure element from native code (C) ? Access to the secure element is restricted in multiple ways: For one, Android applications need to have permission to access the secure element API (controlled through Android's permission system in 2.3.7 and controlled by a file in 4.0.3). A second barrier is the secure element itself. You would need to install your applet to the SE. But in order to do that, you would need to have the keys for GlobalPlatform card management. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Is NFC card emulation possible on Galaxy Nexus and OS 4?
Hallo Paul, card emulation is officially supported since Android 2.3.7 (?) and is used by Google Wallet. However, there is no way (unless you use a modified ROM) to access card emulation capabilities from your own applications. br Michael On Feb 15, 5:35 pm, Paul pabloisb...@gmail.com wrote: I know last year Google where not allowing NFC emulation mode with OS 2.3. But is NFC card emulation possible on Galaxy Nexus and OS 4? Thanks -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to write data in NFC smart poster
Hallo, How to write these information in smart poster programmatically? 1) URL of the discount offer That one is easy: use the smart poster's URI record. 2) Count value (like offer for first 200 entries) That depends on what you want to achieve: a) Should every smart poster should have a unique number between 1 and 200? In that case, you would simply add this number as a parameter to the URI. b) Should the counter be incremented on each read of the smart poster? That's a difficult task. There is no standard way to do that. In a production environment a smart poster would typically be read-only. You would therefore need tags that allow writing and you would need an app on the user's device that increments the counter on each read. However, that's not the user experience that is expected with smart posters. If you still want to take this approach, you could add the counter into a seperate NDEF record (e.g. your own external record type). This record can be either added after the smart poster record or inside the smart poster record's payload. Both variants are allowed by the NDEF RTD specifications. A different approach would be to use a dynamic tag. I.e. a tag that knows how many times it has been read. There's active tags from Sony that can be used to achive this task. You could even write your own NDEF Type 4 tag application on an ISO 14443-4 smart card. In this case you would again add the counter as a parameter to the URI. Whenever the tag is read, it would then increment the counter and create the new URI. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC detection of tag with NDEF URL always launch browser
Hallo, to get your app into the activity chooser for URLs you could possibly use an intent filter that matches the one that is used by the web browser: (I have no Android 4.0* at the moment, so I could not test if this works.) intent-filter android:priority=-101 action android:name=android.nfc.action.NDEF_DISCOVERED / category android:name=android.intent.category.DEFAULT / data android:scheme=http / data android:scheme=https / /intent-filter If you want your app to always handle certain more specific URLs you could use an intent filter like the following: intent-filter action android:name=android.nfc.action.NDEF_DISCOVERED / category android:name=android.intent.category.DEFAULT / data android:scheme=http android:host=test.com android:pathPrefix=/nfctest/ / /intent-filter br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo malls, I could listen to AID_SELECTED event from NfcService. I am trying to send data to SE. I get error that External RF Field detected, what does this mean. It means that you are trying to access the secure element from two sides simultaneously (from an external reader and from the application processor). You can only communicate through one interface at a time. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Saurabh, What is the significance of this : I just looked through my code and found that I also explicitly disabled ISO 14443-4 activation (before polling) using this command: FF0003D41224 See page 9 of the reader API manual: Some Type A Tags may support both ISO14443-3 Type A and ISO14443-4 Type A operating modes. For example, JCOP30 supports MIFARE 1K emulation (ISO14443-3) and ISO14443-4. If the reader sends a RATS command to the tag, the ISO14443-4 mode will be activated, or the tag remains in MIFARE 1K emulation mode (ISO14443-3). It is up to the application to decide which operating mode to be activated. By default, the reader will perform automatic ISO14443-4 activation if the tag supports ISO14443-4. * To disable automatic ISO14443-4 activation: FF 00 00 00 03 D4 12 24 * To Enable automatic ISO14443-4 activation: FF 00 00 00 03 D4 12 34 So you need to disable ISO 14443-4 activation *before* you start the anti-collision sequence. Once the RATS command is sent, the SmartMX will not accept raw MIFARE classic commands anymore. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NfcAdapter.enableForegroundNdefPush(Activity, NdefMessage message) and Serial Number
Hallo, When sharing a virtual tag using the enableForegroundNdefPush of an NfcAdapter instance object, i try to read the so-shared ndef message with my desktop reader (ID ISC CPR 40.30 USB). Well, it won't work. Correct. Foreground NDEF push Android Beam don't use tags to exchange data. What you call virtual tag is actually data exchange between two NFC devices over a peer-to-peer connection. On top of that P2P connection, the LLCP (NFC Logical Link Control Protocol, standardized by NFC Forum) is used and on top of this either Android's NPP (NDEF Push Protocol) or SNEP (Simple NDEF Exchange Protocol, standardized by NFC Forum) are used. As I got by debugging, my reader works in addressed mode. That is, I first run the inventory procedure, and get the Serial (something like FE7CE608) Correct. The anti-collision procedure of NFC is compatible to ISO 14443 proximity card protocol (for 106kbps) and JIS X 6319-4 FeliCa protocol (for 212kbps and 424kbps). Thus, ISO 14443 anti-collision will enumerate a card UID for the NFC device. Btw, the 0x08 gives you a hint that the UID is randomly generated for each session (which is mandated by NFC). and then, in addressed mode, i can read data blocks from a tag by addressing it with it serial number. No, you can't. Your virtual tag is not a memory card. Instead you need to speak NFC-DEP + LLCP + SNEP/NPP with it. I'd like to do the same with my android phone, but discovered that my android phone's serial number changes at every inventory!! See above. Is there a way to make it fixed ?? This wouldn't help as the NFC device doesn't respond to memory access commands. p.s: some one else out there is using Feig ID CPR40.30 USB ? I'm not sure if this reader is NFC-compatible. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Saurabh, You mean page 12 , section *5.3 Reading Binary Block*. I didn't find any section *5.3 Reading Binary Block* on that page. In fact, I mean have you tried the whole command sequence described for Card Access -- How to access MIFARE Classic Tags? on that page. You have to do the polling using these commands to access the card. The standard PC/SC commands will not work. I just looked through my code and found that I also explicitly disabled ISO 14443-4 activation (before polling) using this command: FF0003D41224 Can you tell me the name of card reader where we cant see this behavior (reader automatically performed protocol selection up to ISO 14443-4 / APDU layer) The ACR 122U was the only reader with which I successfully accessed the MIFARE area of the SmartMX so far. br, Michael On Thu, Jan 19, 2012 at 6:14 PM, Michael Roland mi.rol...@gmail.com mailto:mi.rol...@gmail.com wrote: Hallo Saurabh, I am getting This ATR now : *3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90* , which I have read in this group that it is for SmartMX. Correct, that's the PC/SC ATR for the SmartMX. I am looking into writing onto it but so far I am getting 63 00 response(which means error) I am trying to load., authenticate the keys and then read -write and then read back from the SmartMX (Secure Element). *_Here is my list of commands : _* FF82006006// load keys FF86050100026000// authenticate FFB210//read sector 2 FFD6000210// write sector 2 FFB210 // read sector 2 again I followed this -- http://www.nfc-reader.com/ NFC-smart-card-reader/ACR122-API-Manual/API_ACR122.pdf I would guess, that the reader automatically performed protocol selection up to ISO 14443-4 / APDU layer. In that state it is not possible to access the MIFARE part of the chip with reader-side MIFARE emulation. You could try the example on page 12ff of this document. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com mailto:android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com mailto:android-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Saurabh, I am getting This ATR now : *3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90* , which I have read in this group that it is for SmartMX. Correct, that's the PC/SC ATR for the SmartMX. I am looking into writing onto it but so far I am getting 63 00 response(which means error) I am trying to load., authenticate the keys and then read -write and then read back from the SmartMX (Secure Element). *_Here is my list of commands : _* FF82006006// load keys FF86050100026000// authenticate FFB210//read sector 2 FFD6000210// write sector 2 FFB210 // read sector 2 again I followed this -- http://www.nfc-reader.com/ NFC-smart-card-reader/ACR122-API-Manual/API_ACR122.pdf I would guess, that the reader automatically performed protocol selection up to ISO 14443-4 / APDU layer. In that state it is not possible to access the MIFARE part of the chip with reader-side MIFARE emulation. You could try the example on page 12ff of this document. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to configure a NFC tag in using the URI = text/x-vCard
Hallo Tarun,
NdefRecord textRecord = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,text/
x-vCard.getBytes(),new byte[] {}, textBytes);
Although MIME types are -- according to the RFC -- case-insensitive,
you should consider using only lower case letters, e.g. text/x-vcard.
intent-filter
action android:name=android.nfc.action.NDEF_DISCOVERED /
category android:name=android.intent.category.DEFAULT /
data android:mimeType=text/x-Vcard /
Be careul that Android's MIME type intent filter is case-sensitive,
e.g. text/x-Vcard is no the same as text/x-vCard and is not the
same as text/x-vcard.
br
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC App self-launched
Hallo, intent-filter action android:name=android.nfc.action.TECH_DISCOVERED/ /intent-filter meta-data android:name=android.nfc.action.TECH_DISCOVERED android:resource=@xml/tecnologia / /activity I thought that a TECH_DISCOVERED launch my application but it does not Have you correctly setup your tecnologia XML file? For instance if youz want to trigger on type A tags, your XML file would look like this: resources xmlns:xliff=urn:oasis:names:tc:xliff:document:1.2 tech-list techandroid.nfc.tech.NfcA/tech /tech-list /resources br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC support for ACR122u device
Hallo Sathish, see the nfcpy project at https://launchpad.net/nfcpy/ br Michael On Oct 20, 3:53 pm, Sathish Kumar sathishna...@gmail.com wrote: Hi Team, I need your help for the connection and exchange of Nexus S Device and ACR122U NFC card reader exchange through NFC, Is it possible to do I trying figure it out, but lagging. Can you Please help me... Thank a lot in advance... I LOVE ANDROID Google... Regards Sathish Kumar.C -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Re : NFC phone operated Mifare Classic
Hallo, Android provides an API for access to MIFARE Classic cards: http://developer.android.com/reference/android/nfc/tech/MifareClassic.html Use the readBlock, writeBlock, increment, decrement, transfer and restore methods to operate on value blocks. For more information on MIFARE commands and the format of data blocks see NXP's data sheet: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf Be careful that you have the correct permissions to use blocks as value blocks. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to display NDEF message ？
Hallo, as a start I would strongly suggest that you read the NFC Forum's specifications on the NDEF format and the record type definitions (RTDs). You can find them here: http://www.nfc-forum.org/specs/spec_dashboard/ Second I would suggest that you make use of the NDEF helper classes in Android (i.e. NdefMessage and NdefRecord) and avoid handling the whole NDEF message as a byte array. The NdefRecord class divides the record into its header fields (TNF, type, ID) and the payload field. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android SDK NFC Card Emulation
Hallo Eliseo, see this thread on more information regarding card emulation: http://groups.google.com/group/android-developers/browse_frm/thread/418c9b370f08a9f7 br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Tel: and SMS: URIs
Hallo Scott, My other question is with messaging, how can I get the sms: URI to attach the body with the message? I can get a href=sms:0123456789Request A Call/a to work but when I add the body a href=:sms:0123456789?body=Callback %20RequestRequest a Call/a returns Please correct the recipient(s) or they may not receive the message error See this bug report regarding the wrong interpretation of SMS URIs on Android: http://code.google.com/p/android/issues/detail?id=15866 br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Read NfcA card
Hallo,
byte[] commandAPDU= new byte[]{
(byte)0x00, (byte)0xA4, (byte)0x04, (byte)0x00, (byte)7,
(byte)0xAB, (byte)0xE5, (byte)0xBC, (byte)0x08, (byte)0x85,
(byte)0x01, (byte)0x00};
byte[] responseAPDU = tag.transceive(commandAPDU);
String m1=Hex.byteArrayToHex(responseAPDU);
But the result is wrong. It is :6A82. IS it meaning the file can't
found?
Correct. This error code means file or application not found.
Therefore, there is no applet (dedicated file) with the name
ABE5BC08850100h. Possibly you have mistyped the file name?
Have some wrongs in this commands ? What should I change my program?
Where the command APDU come from?
APDU commands are standardized in ISO/IEC 7816-4. What commands your
card understands depends on the card. (And in case of a JavaCard: on
what applets you have installed on that card.)
Anyways, as you received a response from the card (even if that response
is not what you expected) you successfully communicated with the card.
br
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to implement peer 2 peer application in android 2.3.3
Hallo Reddy, I am planning to write a full duplex peer 2 peer application in 2.3.3. Can any one please tell me how it can be possible. the P2P communication capabilities of Android on current devices (Nexus S, Galaxy SII) are limited to the NDEF Push Protocol (i.e. you can exchange a single message on each tap). I read that we can implement this using org.opennfc, integrate with 2.3.3. But this can be done by only device manufacturers. Please let me know is there any way that a user can integrate the open nfc with 2.3.3. OpenNFC is a software stack for Inside Secure's NFC controllers, while the NFC stack integrated into Android is for NXP's NFC controllers (NXP is the manufacturer of the PN544 integrated into Nexus S and Galaxy SII). br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Read NfcA card
Hallo,
I need to read and write ISO 14443-4 smart card .
In this case you won't need NfcA at all. You only need the IsoDep class.
In general you shouldn't care whether your IsoDep card uses NfcA or NfcB
as low-level technology.
I had used
mTechLists = new String[][] { new String[]
{ NfcA.class.getName() } }
NfcA tag=NfcA.get(tagFromIntent).How to use IsoDep?
Just replace NfcA with IsoDep.
Next, What I should do? Can give me some hints?
You can then connect to the IsoDep object:
tag.connect();
Then you can transmit ISO 7816-4 APDU commands with the transceive() method:
byte[] responseAPDU = tag.transceive(commandAPDU);
br,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Read NfcA card
Hallo, NfcA tag=NfcA.get(tagFromIntent); and i can get the ATQA,SAK,but i don't know how to use transceive(byte[] data),and how i can read the card?? There is no simple answer to that question. FIrst you need to know what card/tag technology you have. (E.g. Topaz/Jewel, MIFARE Ultralight, MIFARE CLassic, MIFARE DESfire, ISO 14443-4 smartcard, ...) If you are not sure about what technology your card is, usually, you should be able to derive this information from the ATQA/SAK values. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: How to read RFID tag using Nexus s device?
Hallo Adiga, http://developer.android.com/guide/topics/nfc/index.html Using this link , I can read MyFare Classic card , but unable to read RFID tags. MIFARE Classic *is* one type of RFID tag. Anyways, the refered API allows much more that accessing MIFARE Classic cards. It gives you high-level access to any type of NFC tag using the NDEF format, it allows easy access to MIFARE Ultralight cards and it provides classes for direct access to all NFC-compatible RFID tags: Low-level access through NfcA for ISO 14443 Type A, NfcB for ISO 14443 Type B, NfcF for FeliCa and NfcV for vicinity cards (although I haven't tried NfcB NfcF so far). And high-level access to APDU-based contactless smartcards through IsoDep. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: ISO 15693 card emulation
Hallo Sumit, So there is no way at present in Android by which one can perform card emulation from Nexus S? Watch out that this thread is about *ISO/IEC 15693* (vicinity) card emulation (as opposed to proximity card emulation). There is no way the PN544 NFC controller (which is used in the Nexus S) can do vicinity card emulation. Proximity card emulation is a whole different story (see the other threads on card emulation). br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NdefRecord(NdefMessage) extraction from the intent in a NFC design
Hallo Dominik,
What do you mean by all three NFC intents *have* three extras? I
ask, because the documentation at
http://developer.android.com/reference/android/nfc/NfcAdapter.html
states, that EXTRA_ID and EXTRA_NDEF_MESSAGES are optional (which is
obvious for the latter) and only EXTRA_TAG is mandatory.
Correct. Those intent extras are listed as optional. Still the current
implementation (or at least the one in Android 2.3.4) adds all three
extras to every intent. Though, some of the extras, especially
EXTRA_NDEF_MESSAGES, might be null.
Anyway, in which case is the ID field not available?
I don't think that there is any case where the ID field will be
empty/not available. For NFC/RFID tags there will always be an ID field.
Even for the NDEF push protocol a mock tag with an ID of
new byte[] { 0x00 }
is used.
br,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NdefRecord(NdefMessage) extraction from the intent in a NFC design
Hallo, first of all, the prefered method of receiving tag detection events is the android.nfc.action.TECH_DISCOVERED intent, the intent android.nfc.action.TAG_DISCOVERED is only used for fall-back tag detection. All three NFC intents (NDEF_DISCOVERED, TECH_DISCOVERED, TAG_DISCOVERED) have three extras: android.nfc.extra.ID: This is the UID (or whatever it's equivalent is called for that technology). android.nfc.extra.NDEF_MESSAGES: If the tag is an NDEF tag (or a dummy tag for NPP) this extra contains the received NDEF messages. android.nfc.extra.TAG: This is the Tag object for the detected tag. You can use it to get the tags technology and to create technology specific connections. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: enableForegroundNdefPush not working
Hallo Musfiq, it might help if you posted some of the relevant code. br, Michael On Aug 9, 3:46 am, musfiq musfiqu...@gmail.com wrote: Hi: I am trying to share a string between mobile phones using NFC. I want the same application to send the tag and another to receive the tag in two different role (Sender and receiver). I have tried to use enableForegroundNdefPush in the sender side and enableForegroundDispatch in the receiver side. But it is not working. Can anyone please help? /Musfiq -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to get the nfc card' UID?
Hallo, According to that, I use the API: byte[] uid = tagFromIntent.getId(); byte[] uid = intent.getByteArrayExtra(NfcAdapter.EXTRA_ID); Correct, both of them should return the same value. But the results appear in a bunch of strange number, not UID.For example: DISCOVERED TAG 1,THE DID IS:[B@40529388 DISCOVERED TAG 2,THE DID IS:[B@40529B10 ^^^ You should certainly start on learning the basics of the Java programming language first. The methods return a byte array. What you did now is to print out the byte array object as string. Java, however, does not know how the array object should be printed as string, so by default it prints the objects hash(?) value. What you need to do is parse the array into a proper string. Typically you would want to convert each byte in the array into a two digit hexadecimal string. br Michael On 8月5日, 下午4时25分, Michael Roland mi.rol...@gmail.com wrote: Hallo, the tag object's getId() method should work just fine for most cases[1]. I.e. byte[] uid = tagFromIntent.getId(); [1] Note that some tag platforms use random UIDs. For some others the method may return only a partial UID. LikeNFCForum Type 1 tags, where the method returns only 4 bytes of the 7 byte UID (which is correct as only those 4 bytes are used to reference the tag in the transmission protocol.) Besides getId(), this should also work (and give the same result as getId()): byte[] uid = intent.getByteArrayExtra(NfcAdapter.EXTRA_ID); br Michael On Aug 4, 11:32 am, xiaodai...@163.com zsbitxiao...@163.com wrote: Hi, I just started to research theNFCrelevant content. I can scan the card, but always don'treadthe card UID. I want to use getId(),but it cant'nread. And i see some demo ,using Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG); But it outputs a bunch of garbage characters. How it should bereadthe card UID? Can anyone help meThank you very much! Regards, Xiaoxiao- 隐藏被引用文字 - - 显示引用的文字 - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to get the nfc card' UID?
Hallo, the tag object's getId() method should work just fine for most cases[1]. I.e. byte[] uid = tagFromIntent.getId(); [1] Note that some tag platforms use random UIDs. For some others the method may return only a partial UID. Like NFC Forum Type 1 tags, where the method returns only 4 bytes of the 7 byte UID (which is correct as only those 4 bytes are used to reference the tag in the transmission protocol.) Besides getId(), this should also work (and give the same result as getId()): byte[] uid = intent.getByteArrayExtra(NfcAdapter.EXTRA_ID); br Michael On Aug 4, 11:32 am, xiaodai...@163.com zsbitxiao...@163.com wrote: Hi, I just started to research the NFC relevant content. I can scan the card, but always don't read the card UID. I want to use getId(),but it cant'n read. And i see some demo ,using Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG); But it outputs a bunch of garbage characters. How it should be read the card UID? Can anyone help meThank you very much! Regards, Xiaoxiao -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Fernando,
From what I've read in the PN544 User Manual, I don't think that there
is an equvalent for the wired mode with SWP/HCI (I would be happy to be
proven wrong).
Well, here is where the phHal4Nfc_Switch_Swp_Mode() comes. It is
analog to the phHal4Nfc_Switch_SMX_Mode() which is used to set the
wired mode to work with the SmartMX.
I modified the function to use phHal4Nfc_Switch_Swp_Mode() with
parameter eSWP_Switch_On (this parameter has an incorrect value by
default, it must be enabled by using nemik's patches).
If you are refering to this patch:
http://nemik.net/code/android-nfc/libnfc-nxp.diff
Then I don't see how it changes the value of eSWP_Switch_On
typedef enum phHal_eSWP_Mode{
eSWP_Switch_Off = 0x00U, /* SWP Link is Switched off */
+ //eSWP_Switch_Off, /* SWP Link is Switched off */
eSWP_Switch_Default, /* SWP is in Default Configuration Mode */
- eSWP_Switch_On /* SWP Link is Switched on */
+ eSWP_Switch_On /* SWP Link is Switched on */
+ //eSWP_Switch_On= 0x00U /* SWP Link is Switched on */
} phHal_eSWP_Mode_t;
After this patch eSWP_Switch_On still is 0x02. Which is in fact the
correct value according to PN544 user manual:
SWP Switch Mode Event Parameters:
-
Value Description
-
0x00Off (deactivated)
0x01Default mode
0x02On (activated)
others RFU
So there is no equivalent to the wired mode, but only options to
enable/disable external emulation.
When it comes to RIL issue. I patched the sources with SEEK diffs too
but rild daemon crashes. SEEK mantainers say it is due to baseband
processor not implementing required (AT+CSIM, AT+CCHO, AT+CCHC, AT+CGLA)
commands (http://code.google.com/p/seek-for-android/wiki/UICCSupport).
Correct.
Is there any way to reverse engineer baseband firmware or get access to
a modified version implementing those commands? Or has anyone discovered
whether Samsung has other propietary commands achieving the same results
(raw APDU exchange with SIM/UICC)?
I believe this would be the most promising direction. Unfortunately, I
haven't found much information on this.
br
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Ndef.get(tag) returns null
Hallo,
when i try to write to a mifare classic 1k card ,
Ndef.get(tag) returns null, upon searching, i find that tag is not
listed in tech list. but when i issue getTechList() command, i am able
to find
MifareClassic , NdefA and Ndefformatable are listed, so where am i
missing.
So you are missing quite the obvious:
You can only access technologies of a tag if the tag supports them.
Thus, as your MF1K tag supports MifareClassic, NfcA and
NdefFormatable, you can only access this tag using these three
technologies. Therefore, as Ndef is not listed you can also not use it
to access the tag.
Usually tags supporting Ndef provide either NdefFormatable (if the tag
supports NDEF but has not been initialized to the NDEF format) or Ndef
(if the tag is already prepared for NDEF data). So you need to check
which of these two technologies is supported and then use the proper
one to write your NDEF message to the tag.
MifareClassic mfc=MifareClassic.get(tagFromintent);
boolean auth=false;
try {
String[] ttype=tagFromintent.getTechList();
Ndef ndef1=Ndef.get(tagFromintent);
mfc.connect();
auth = mfc.authenticateSectorWithKeyA(0, MifareClassic.KEY_DEFAULT);
} catch (IOException e1) {
So here you got another (potential) problem. You should not mix using
different technologies. Either use MifareClassic for access to the
tags raw data or use Ndef/NdefFormatable to get high-level access to
NDEF data.
br
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NfcA timeout
Hallo, Does anyone know if there is a way to lengthen the time of a NfcA card timeout for receiving a response from the card after sending it a command? I saw that there was a way to do it with iso-dep type cards. Or does anyone know how long the timeout is on a NfcA type card? According to the standard (ISO/IEC 14443-3 -4) there is no standardized equvalent to a frame timeout with non ISO/IEC 14443-4 protocols (i.e. NfcA). br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: ISO 15693 card emulation
Hallo, My question is very simple: does Android v. 2.3.4 support ISO 15693 card emulation? No, the NFC hardware with current NFC phones (PN544 on Nexus S) does not support card emulation with ISO/IEC 16693 protocols. As a consequence this type of card emulation is not possible with current Android. I need to read at least the UID of an emulated tag on the Samsung Nexus S with an ISO 15693 reader. Not possible. (Unless your reader also supports ISO/IEC 14443.) I've foundhttp://www.open-nfc.org/opennfc_library/overview-summary.html but if I understantand (see also Reference), the possibility is limited to NDEF format tags (so not for ISO 15693). Is it right? Are there some last minute news? Thank you very much! Note that opennfc is not the library that is used on the Nexus S. Also opennfc is intended for Inside Secure's range of NFC chips and not for NXP's PN544. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC write error handling
Hallo,
first of all, there is no code in your catch statements. Second, for
instance the writeNdefMessage() would throw a TagLostException if the
tag is no longer available during write. None of your catch statements
handles this type of exception. You could use a try-catch block like
this to figure out what type of exception you get:
try {
...
} catch (Exception e) {
Log.d(MyApp, e.toString());
}
br
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC intent filters
Hallo Kev, However, when I return from the home screen I get the android.intent.action.MAIN action, which I think makes sense. When you launch your app through the launcher screen you should receive the intent action android.intent.action.MAIN with category android.intent.category.LAUNCHER. When your app is started by the NDEF discovery event, you should receive an intent action android.nfc.action.NDEF_DISCOVERED. For your foreground dispatch you should receive an intent action android.nfc.action.NDEF_DISCOVERED (or an intent action android.nfc.action.TECH_DISCOVERED). The OS has received an 'intent' from the NFC hardware, which one of my intent filters in the manifest matched, and then in order to launch my application uses the 'MAIN' action? No. The intent starts the app, so the action will not be changed by the OS. Which is then what I receive in my onResume code. This is where your error is. The onResume() method does not receive any intent at all. Once an activity was started (i.e. once its onCreate() method fired), the getIntent() method will return the same intent until setIntent() is explicitly called from your code. So to summarize this, onResume() might not be the place you want to respond to intents. For the initial intent that started your activity, the proper place would be onCreate(). For any following intent, onNewIntent() may be the proper place (as long as your activity meets the conditions for onNewIntent() to be fired.) br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Fernando, As far as I understand sending APDUs to the SmartMX SE element is possible because the NFC Controller (PN544) is told to enable the NFC-WI interface with SE. This is carried out by calling phHal4Nfc_Switch_SMX_Mode(), with parameter eSmartMx_Wired (function phLibNfc_SE_SetMode()). Correct, for the SE connected through NFC-WI/S2C, the NFC controller has three modes: off, wired and virtual mode. Off means that there is no communication with the secure element. Wired mode means that the secure element is visible to the application processor as if it was a (contactless) smartcard connected to the RF reader. Virtual mode means that the secure element is visible to external readers as if the phone were a contactless smartcard. Wouldn't it be possible to use the SWP channel to send APDUs to UICC SE through NFC Controller in an wired mode from an application the same way it is performed when sending APDUs to the SmartMX element? From what I've read in the PN544 User Manual, I don't think that there is an equvalent for the wired mode with SWP/HCI (I would be happy to be proven wrong). Usually for the wired mode, the contact interface of the UICC would be used so it wouldn't really make sense if the NFC controller allowed for an additional* channel between the UICC and the application processor. *) Additional once the RIL supported APDU exchange with the UICC. Or is SWP only supposed for raw RF Communication and has no such equivalent capabilities used by NFC-WI? In fact it is quite the opposite. NFC-WI is the protocol for raw RF communication. SWP has several more capabilities. There is three protocols used on top of SWP: ACT, CLT and SHDLC. ACT is used for interface activation. CLT is a tunneling protocol for raw frames of the contactless protocol (used for e.g. MIFARE protocol). SHDLC is the high level data link protocol. On top of this HCI (Host Controller Interface) is used for communication between the UICC and the NFC controller. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC intent filters
Hallo Kev, I wouldn't call that odd behavior but rather an exact match what you have written in your code. NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction()) will not return true if the intent received from getIntent() does not contain that action. So if your app is started for the first time by the NDEF_DISCOVERED intent, the condition will be true. Then you use setIntent(new Intent()). So the next call to getIntent() will return that new (empty) intent. Now you send your app into the background by pressing the home key. Note that the activity is still paused in background. When the app is triggered by a new NDEF_DISCOVERED intent, onResume() is called on the existing activity. Therefore, getIntent() will still return the intent you set with setIntent(...). br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo, Did you get it tweaking the code by yourself as described above or you used SEEK patches? I am currently trying to get some results myself but I am new to Android platform development and I am a little bit lost. I tweaked the code by myself. The SEEK patches won't enable card emulation through NFC. They enable secure element access from within Android apps. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo, I managed to write and read a block (4) to the Mifare 4K with default keys. Next thing will be investigating wheter 2.3.4 adds support by means of nxp-nfc library to directly send APDUs to the SE. You and Michael Roland already confirmed it was not possible with prior gingerbread versions. Just to be clear on that: From within Android apps it *is* possible to send APDUs to the internal secure element (SmartMX). But it *is not* possible to send APDus to an SWP-UICC. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo, Do you mean you could enable card emulation mode from UICC? Could you read the contents of a smartcard through an external reader and also from an android application? Yes, I managed to enable card emulation mode with a SWP-UICC as secure element. As the NFC controller allows only external card emulation for secure elements connected through SWP, I could only access the smartcard from an external reader but not through an Android app. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC card emulation, NXP PN544 and S2C (NFC-WI)
Hallo, I was thinking S2C is an NXP implementation (e.g. the commercial name) of the NFC-WI. Both,S2C and NFC-WI, looks pretty similar. So in fact, even they using similar approach, we are talking about two different technologies? No, same technology. S2C was there *before* NFC-WI was standardized. So NFC-WI is inspired by S2C. I didn't find any difference between the two so far. So having the NFC controller, e.g. Samsung S3FHRN2 (http://www.samsung.com/global/business/semiconductor/support/ brochures/downloads/systemlsi/S3FHRN2.pdf), which declared the NFC-WI support we are talking about 2 different, probably not compatible solutions? So theoretical SD card supporting S2C might not be compatible with ECMA NFC-WI standard and vice verse? See above. Should be compatible. When talking about PN532 and its card emulation capabilities, are you sure the controller emulates the smart card even without having attached the SmartMX secure element? I'm very sure that this NFC controller has card emulation capabilities even without a dedicate SE chip. Emulation of the low-level protocol (up to ISO 14443-4) is handled by the PN532 and the high-level APDU protocol (ISO 7816-4) is handled by the application processor. NXP delivers to Samsung, SonyEricssion, Nokia, etc. the S2C might be pretty widespread, right? At least everything that uses a SmartMX as secure element uses the S2C/NFC-WI. But since S2C is NXP proprietary do you know if other NFC IC manufacturers are going to support NFC-WI? No, I don't. It can, for example, act as a router and its powerful command set allows all elements of the chosen architecture to interact in a controlled manner (SIM, SE, SD card, Application Processor and NFC interfaces).This allows for implementation of various business models by mobile operators and third parties.. Do you know anything about that? No. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC card emulation, NXP PN544 and S2C (NFC-WI)
Hallo, On the enhanced SD card is then besides the normal flash storage also the secure element (smart card). To access the smart card the file I/O based interface is re-used, i.e. if you write something and it starts with 'magics' in header and it is valid APDU command it is send to the smart card instead of being saved to the flash memory - this is handled by the on-card enhanced controller, which inspects the content of the passed data (http://www.ctst.com/CTST08/pdf/Poitner.pdf, http://www.gi-de.com/en/products_and_solutions/products/secure_microsd/product_details_4992.jsp). Note that you would need an SD card that supports NFC-WI to be able to connect it to that interface. The products you mentioned above use a differnet approach (access trough direct APDU commands). As for the moment I don't know of any SD card that supports NFC-WI. Now having the standard SD card slot in which is inserted the microSD card with the secure element, which can be accessed by two above mentioned ways - how this can be connected with the NXP 544 s2c interface? Not at all. The secure element you described above can be accessed from the phone (trough some library like SEEK). It's not supposed to be connected to the NFC controller. According to my understanding in the mode you are describing as an 'internal' the NFC controller emits the same data like if it communicates with the smart card over the radio, but instead of using the RF antenna to send the data they are redirected over the wired s2c bus to the SD card pins Right, if you have an NFC-WI enabled SD card this is pretty much how the internal mode works. - so 2 selected SD card pins must be used for that. An SD card that supports NFC-WI would have that interface of course. This also means the phone (Andorid) SD card driver be modified to allow to send other than file I/O data and those data must be understand by the controller on the SD card? No, if the SD card can be accessed through the NFC-WI, the two NFC-WI pins of the SD card would need to be connected to the two NFC-WI pins of the PN544 (i.e. hardware modifications, not software). This has nothing to do with the SD card driver. The SD card driver would handle the SD card's memory interface as usual. Since the s2c is built on the top of the ISO 18092 (right?) this protocol must be understand by the on-card enhanced controller? Not ISO 18092 but the contactless protocol that is used by the secure element. In Europe this would typically be ISO 14443. So the NXP 544 s2c bus must be somehow physically connected to the SD card slot? Is that right? Yes. Since the Nexus S already has the built-in SmartMX family (BTW – do you know which chip is exactly used?) secure element how the SD card secure element is selected? How the system understands to which secure element it should talk, e.g. to embedded SmartMX or SD card? Or it is not possible to use SD card when there is already embedded secure element? Regarding the SD cards you linked above: These cards are completely independent from the NFC controller. Regarding a (teoretical) NFC-WI-enabled SD card: As NFC-WI is not really a bus but an interface between two endpoints, it would be difficult to have two secure elements connected to it. Possibly this could be done with some external multiplexing circuit. In general if a device contains multiple secure elements it would be the software's (or in the end the user's) decision which secure element to enable. But in general it is expected that only one secure element can be enabled at a time. I know there is too much questions, but I try to understand if it is at all possible to use the SD card or not and if it is possible, what can be changed even in OS source code and if some HW changes in the phones are necessary regarding the internal connection between NXP 544 and SD card slot – you said it will need some special hardware support: To use SD card that support the NFC-WI, the SIGIN and SIGOUT signal lines of the NFC-WI would need to be connected to the NFC chip.. If true, is it already in the Google Nexus S, will this be in the Galaxy SII? As I don't know of any SD cards that would actually support NFC-WI, I don't see why any manufacturer would integrate this into a device. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC card emulation, NXP PN544 and S2C (NFC-WI)
Hallo, I understand that there are no NFC-WI enabled microSD cards on the market. Anyway I think the SD Card Association has some standards, which specify two additional 13.56Mhz RF antenna pins complaint with ISO 10373-6 (check here http://wenku.baidu.com/view/2799ef0f4a7302768e993975.html). Do you think this can be possibly used for S2C? Sorry, but I couldn't check that document as it causes my webbrowser to freeze. If such microSD will be available it will need compatible microSD card slot. I understand that the legacy SD interface remains untouched (i.e. SD card with antenna slot can be used as a flash storage in legacy SD card slot), to interconnect two new connectors will be added to the SD card slot. Possibly, unless there are already some unused pins. Another option would be to multiplex the signal with signals on existing pins. Do you have some lnks, documents, specification, simply anything related to the S2C interface? Not to NXP's S2C but to NFC-WI, which is standardized in ECMA-373 (you'll find that on Google). You said two interesting facts: - It is not expected to have more than one secure element per device. Why? That is not what I said. I said that only one secure element could be active at the same time. The device itself could contain multiple secure elements. See the Nexus S which has an internal secure element and the possibility to use the UICC as SE. Both could be present at the same time, but only one of them could use the analog frontend for external card emulation. And also for APDUs routed from an application to the secure element, those APDUs could only be directed to one specific secure element. (Theoretically, options exist to aggregate multiple secure elements to one logical secure element but those seem not to be accepted by the industry for now. See Management of Multiple Cards in NFC-Devices, http://dx.doi.org/10.1007/978-3-540-85893-5_11) Do you know if SmartMX uses S2C to connect with PN544 – due to the PN544 data sheet it is the only way how it can be connected, but there can be something proprietary... Yes, the SmartMX and the PN544 are connected through the NFC-WI/S2C. Infact S2C *was* NXP's *proprietary* way to connect NFC controller and secure element. The most important – you have mentioned SEEK – can this be used for accessing the secure element on the SD card I have mentioned (e.g. GD APDU file I/O based interface). Do you think I can somehow use the RF antenna of the phone to get the information from e.g. POS terminal and forward those information using SEEK to the secure element on this SD card, then pickup the answer and send it back over the NFC controller and antenna to the POS terminal? The short easy, but not completely true, answer: no. The longer answer: At least the PN532 could be put into a software card emulation mode, where the PN532 acted like a passive card and the software stack could handle the APDU commands on top of ISO14443-4. I expect this same mode is available with the PN544. Yet, this would require large modifications of Android's NFC stack. (And don't expect too much documentation on this.) Also from a security point of view routing the APDUs through the application processor wouldn't be the best scenario. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: android nfc tech API help
Hallo Sumit, Can you please tell me how can read data from this type of card? Also, is there any way to find the type of card from coding? Well, that depends on what type of card you have. Knowing that the card is ISO 14443 Type B is certainly not enough to figure out how this card's data can be accessed. You definitely need to know further details of the card (e.g. does it support NDEF?, does it support IsoDep?, what memory structures are used? what communication protocols are used? what chip does it contain? ...) As Dominik pointed out, a starting point is the tags tech-list. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC card emulation, NXP PN544 and S2C (NFC-WI)
Hallo, the Nexus S device NXP PN544 NFC controller supports not only SWP for UICC based SE, but also the S2C (aka NFC-WI) Correct. for the external, e.g. micro SD card SE. Does anybody know how this can be enabled and what it means for the SD card? Well, as you mentioned yourself there is no SD card slot with the Nexus S. That is not relevant for the Google Nexus S (there is not SD card slot), but the NFC version of the Samsung Galaxy S II comes already with the SD card slot and here this will be a question. For the NFC version of the Galaxy S2 it won't change anything either (see below). I have tried to search for that and even the S2C standard seems to be relatively old (I think ECMA, 2006) I did not any related materials. What it means supporting S2C? The NXP544 has the built-in support, but what about the phone? Should the device have some hardware support like, e.g. antenna connectors in the slot and on the SD card to be connected directly to the RF interface? I think you misunderstood the concept of the NFC-WI here. A secure element that uses the NFC wired interface can support two modes: internal and external mode. In external mode, the SE uses the NFC chips (PN544) analog frontend + antenna for communication with RFID readers. In internal mode, the NFC chip accessed the SE as if it were an external contactless smartcard connected to the NFC chip. In either way the NFC-WI is used to transmit a digitized version of the signals that are normally transmitted over the contactless air interface. Thus, the SD card slot would not need some special features like antenna connectors, but it will need some special hardware support: To use SD card that support the NFC-WI, the SIGIN and SIGOUT signal lines of the NFC-WI would need to be connected to the NFC chip. But (yes, there's ofthen a but ;-) with the Nexus S (and I expect with the Galaxy S2 too) there is already a secure element connected to the NFC-WI. The Nexus S contains the PN65N (which is a combination of a PN544 and a SmartMX secure element chip). Those two chips are connected through the NFC-WI. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC send Url p2p
Hallo, Stringurl= http://example.com;; byte[] payload =url.getBytes(); NdefRecord ndefRecord = new NdefRecord(NdefRecord.TNF_ABSOLUTE_URI, NdefRecord.RTD_URI, new byte[0], payload); this works, however I am not sure whether it completely follows the NDEF spec. You are correct. This does not follow the NDEF spec. For TNF_ABSOLUTE_URI, the type name field needs to be an absolute URI. The constant NdefRecord.RTD_URI equals to U, so this is no absolute URI. RTD_URI is a well-known type (U) for record type definitions (RTDs), but in this case I would have expected WELL_KNOWN as TNF, i.e. new NdefRecord( NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, new byte[0], http://example.com.getBytes()) The payload lacks the identifier code byte in this example. If TNF = TNF_ABSOLUTE_URI, i thought that this means that the type descriptor is a complete URI (as we know it from XML schema, for example). Can someone confirm this (and give an example on when to use TNF_ABSOLUTE_URI)? Correct. TNF_ABSOLUTE_URI means that the type name is an absolute URI. That URI defines the format of the payload. An example would be the definition of custom record types for use with Android. Android currently implements automatic application launching only for the well-known URI type, the well-known smart poster type, MIME types and absolute URI types. The NFC Forum's external type is not (yet) supported for application triggering. Thus, you could use an absolute URI type as a replacement for external types. new NdefRecord( NdefRecord.TNF_ABSOLUTE_URI, http://nfc-research.at/my-record-scheme.getBytes(), new byte[0], payload) The contents of payload would be defined by the URI http://nfc-research.at/my-record-scheme. Note however that, as opposed to an XML schema's URL, the URI http://nfc-research.at/my-record-scheme; is just a *name* for that type. The resource behind the URI does not necessarily need to carry any information about the type. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo Dominik, What would be the use-case which requires access to the emulated Mifare card from within an android application? Or asked another way round: What could be done additionally compared to NDEF Push? Have a look at my reply a while ago in this thread: https://groups.google.com/group/android-developers/tree/browse_frm/thread/418c9b370f08a9f7/f1d824274a797adf?rnum=1#doc_55a8c6f6ba10f98c br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC: NDEF messages
Hallo Dominik, In the definition of the intent-filter I cannot use the android:path part as this one matches only if it is an exact match, i.e. in the above example only if the tag contains the URL http://commonsware.com/nfctest. It is not possible to add wildcards in the path part. But somewhere I have to add the tag specific data! Have you tried using android:pathPattern or android:pathPrefix? I haven't tested, but I would have expected these attributes to work with NFC intent filters too... br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Markus, You are sure its not possible to access it [SWP-UICC] from an android application? In Madlmayers Blog he wrote, its possible because of the additional AT Commands in RIL since 2.3.2. Where did you find this information in Gerald's blog? I only found When Android switched from 2.3.1 to 2.3.2, Google made some changes in the telephony API, which are required by GD's smartcard stack., which referes to the Telephony API and not to the RIL itself. According to the information in the SEEK project (http://code.google.com/p/seek-for-android/) the RIL itself is still not able to handle the additional AT commands. Have somebody activate the Card Emulation with UICC? Yes. I tryed it, with SmartMX SE it was no problem Card Emulation was running. When I tried the ID of my UICC in the Method doSelectSecureElement from NFC Service, then the Card Emulation was not running, Reader dont detect a Tag. Somebody knows why doSelectSecureElement Method dont working with UICC? If the UICC supports SWP, the doSelectSecureElement method works just fine here. (ID is 11259376 for UICC) br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Markus, But by loading the Key, occurs an error: /send FF82201A06 = FF 82 20 1A 06 FF FF FF FF FF FF .. (407461 nsec) = 69 86 i. Status: Command not allowed (no current EF) Actually this response means Volatile memory is not available according to the PC/SC standard. This suggests that the key number 0x1A is not usable with your reader. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo, Opening a connection with it - using doOpenSecureElementConnection, like you can with the Smart-MX - will most definitely not work for a UICC SE though. As the NativeNfcSecureElement will only open a connection with the Smart-MX SE - completely ignoring a UICC even if it is detected. Perhaps you could tweak this code to force a connection with a UICC if it's detected, but I doubt that will work (correctly). No, unfortunately this will not work. Neither the libnfc-nxp nor the PN544 NFC chip support internal access to the UICC through this method. Therefore, we will have to wait until UICC access gets available through the Telephony API. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Nexus S,how to exchange ndef data via p2p.
Hallo Tommy,
1. i send the ndef data by the enableForegroundNdefPush(this,
mMessage)function in onResume,but how can i known that the mMessage is
send over,can i got the notification or Intent?
You don't. Even if another device's NPP server picks up the NDEF
message from the NPP client, The NDEF push protocol provides no means
of acknowledgement that the message was actually received and
processed.
2. As i know,in p2p module there have two parts,the initiator
and the target.I think int the question one activity called
enableForegroundNdefPush(this, mMessage) , it's initiator ,am is think
right?
No. The NPP happens on a higher layer of abstraction than the NFC-DEP.
(The NFC-DEP is the NFC peer-to-peer data exchange protocol that knows
initiators and targets.) The NPP sits on top of the LLCP and the
LLCP sits on top of NFC-DEP. LLCP removes the restricition that the
initiator always starts a connection. In fact both, initiators and
targets, are equal on the LLCP layer. Both can listen on sockets and
create new sockets.
For NPP, the NPP server creates a listening LLCP socket and waits for
pushed NDEF messages. The NPP client is invoked by the foreground NDEF
push and sends NDEF messages to NPP servers.
3. If in question tow i'm right,the target(another Nexus S
phone,or a nfc reader in my desktop) received the ndef data
mMessage,and send a response to initiator,how can i got the ndef
response.
The NPP is one-way. You can't send a response to a received NDEF
message.
4. In target terminal such as another Nexus s phone,how can i get
the p2p inittiator pushed ndef data.
Ndef myTag=Ndef.get(tag);
myTag.connect();
if (myTag.isConnected())
{
myTag.getNdefMessage();
}
On the receiving device, the NDEF data should be delivered in an
NDEF_DISCOVERED intent (or through the respective foreground
dispatch).
br,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Need a NFC compatible Desktop NFC-Reader
Hallo Ferit, i'm working on some simple NFC-Applications and i want to realize a simple scenario, where the Nexus S sends some Text / URI / SmartPoster to a desktop NFC-Reader. Have a look at nfcpy ( https://launchpad.net/nfcpy ) and which readers it supports. For the moment, nfcpy is the only known LLCP implementation for desktops that also supports the NPP. - Is it possible to set the nexus s as a passive nfc tag? So the usb nfc reader thinks that it is reading a simple tag / sticker. Possibly you could abuse the secure element/card emulation to do this, but you would need to modify the phone's firmware to get the required access. Therefore, it is best to stick with peer-to-peer mode for exchange of NDEF messages between NFC devices. Also note that card emulation is intended for secure applications -- that require the high security standards of a (contactless) smartcard -- and *not* for emulating NFC tags with NDEF data. I'm using a usb hid(human interface device) reader which outputs some cryptic ID's if a passive tag(sticker) is scanned but if i want to write a tag with the nexus s nothing happens. There is no new intent started at the ddms. You can't access the Nexus S as if it were a *NFC tag*. (Don't confuse _NFC tag_ with _card emulation_, see note above.) br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Reading PayWave (ISO14443-B format) track information using Android 2.3.3 NFC API
Hallo Shekhar, if the card supports ISO 14443-4 (which every EMV card should do) you can access this card with APDU commands through ISO-DEP. (* Except for some cards that seem to require a higher magnetic field strength than the Nexus S provides.) Using APUD commands you can then access whatever information the EMV standards allow you to access. br, Michael On 14.06.2011 08:37 Shekhar wrote: Hi Michael, I have a doubt.You mean to say that if the EMV card supports ISO 14443 standard then we can be able to read the payment details of the credit cards using APDU commands? Thanks, Shekhar On Apr 25, 5:09 pm, Michael Roland mi.rol...@gmail.com wrote: Hallo lal, I'm trying to Read Track data for Payment cards (PayWave, PayPass). As per my understanding they follow ISO 14443 B. With new NFC API, byte[] b1 = myTag.getHiLayerResponse(); //b1 is not null, but length == 0 [...] result = myTag.transceive(b1); It will certainly not help if you send the bytes retrieved from getHiLayerResponse() back to the card. Especially if you say they are zero length anyways. These payment cards implement theEMVstandards. Application-to- application communication is done on the level of APDUs. Therefore, it should not matter if this card is ISO 14443 Type A or Type B. What matters is that IsoDep (= ISO 14443-4) is supported. Through the IsoDep interface you directly transmit APDU commands. Have a look at the ISO/IEC 7816-4 standard on how APDU command-response pairs are formatted. Regarding theEMVprotocol the specifications are available from EMVCo's website:http://www.emvco.com/ br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Nexus S,how to exchange ndef data via p2p.
Hallo Tommy, For NPP, the NPP server creates a listening LLCP socket and waits for pushed NDEF messages. The NPP client is invoked by the foreground NDEF push and sends NDEF messages to NPP servers. From your replys,i has some doubt about NPP.You mean the NPP server and NPP client both on the same NEXUS S phone?The NPP server get the NPP client pushed NDEF messages and then NPP server send the messages to anthor NEXUS S phone, can i think so? No, the NPP server is *always* the recipient of NDEF messages. I.e. each Nexus S has a NPP server running in the background that listens for incoming NDEF messages from *other phones*. As soon as an NDEF message is received, this message is dispatched through the NFC intent dispatching architecture. The NPP client is *always* the sender of NDEF messages. Thus, whenever you invoke enableForegroundNdefPush(), you feed the client with an NDEF message. As soon as another phone supporting LLCP/NPP comes into range, the NPP client sends its current NDEF message to the *other phone* across the NFC peer-to-peer link. Can i first delivered in one Nexus S phone NDEF_DISCOVERED intent,and received the NDEF messages.Then use the enableForegroundNdefPush to throw the messages back. Can i use this to alternate the questions how to get reponses above? Sorry, I didn't quite understand what you tried to ask with these questions. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Foreground Dispatch System
Hallo Ferit,
as an alternative you could use a pending intent like this:
PendingIntent pi =
caller.createPendingResult(PENDING_INTENT_NFC_TECH_DETECTED, new
Intent(), 0);
nfcAdapter.enableForegroundDispatch(caller, pi, intentFilters,
techLists);
(where caller is the calling *activity*, nfcAdapter is an instance of
the NfcAdapter, and PENDING_INTENT_NFC_TECH_DETECTED is some random
constant)
Then you can receive the intent with onActivityResult:
protected void onActivityResult(int requestCode, int resultCode,
Intent data) {
switch (requestCode) {
case PENDING_INTENT_NFC_TECH_DETECTED:
//YOUR INTENT HANDLING CODE GOES HERE
break;
}
}
br,
Michael
On Jun 14, 3:05 pm, Ferit Topcu fokus.fe...@googlemail.com wrote:
Thanks.
Perhaps it has something to do with my PendingIntent, again. All
nfc-logic, reading a tag etc. is realized in an external class. After
that every Activity is only invoking the method of this external
class. The enableForegroundDispatch() invoke is realized in this class
and the activity methods onResume(), onPause(), onNewIntent() are
calling the external methods.
Perhaps if i'm using a PendingIntent:
mPendingIntent =
PendingIntent.getActivity(con.getApplicationContext(), 0, new
Intent(con.getApplicationContext(),
getClass()).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0)
is it important which class is used? I mean the Context / Activity is
given to the external class and in the Intent there is the Information
about the context and the external class. Perhaps the dispatching
system has a problem with this procedure where an Intent refers to
non-acitivity class and the onNewIntent()-method is a activity class.
At the current this the point where a inconsistency is possible for
me.
kd,
ft
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo Marcus, At time, I'm able to put my devices into emulation mode. I'm getting ATR and UID throuth my OMNIKEY CardMan 5321 : - ATR: 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90 Correct, this is the ATR generated for the SmartMX. - The ID of the emulated card is constant even if i start a new power cycle . Correct, the UID of the SmartMX is static (by default). My question is how can I found my UID on the NXP chip ? What do you mean by find? - Do you want to read the UID value from Android? This can be done through some hidden/internal NFC APIs. Can you give me more information about the 0x key? I don't understant how to use it ... This is the authentication key to the MIFARE Classic area of the SmartMX. You can use this key to read write data to the 4K MIFARE area on the SmartMX. You would use this key with your reader's MIFARE access methods (either reader specific or compliant to the PC/SC standard for access to contactless memory cards). With your Omnikey reader it will be quite difficult to use the MIFARE area as it automatically activates the SmartMX up to its highest protocol level (APDU-based access to the JavaCard). So the MIFARE protocol will not work on this activation level. (As far as I remember you might be able to disable the automatic protocol activation with some registry tweaks.) br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo Steve, I can confirm the ATR's as Michael pointed and add an interesting follow on. When I do scardconnect and then scardsttus to get uid I get the 5 byte (4 byte dynamic first by 08 static e.g. 080A97A6) from the phone whenever the NFC service is running. The UID (or actually the NFCID1) you get should be 4 bytes in total, starting with 0x08 to mark that bytes 1 to 3 are randomly generated. if I leave the connection open and run multiple commands the uid stays the same but if i disconnect and reconnect the uid dynamically changes. Correct. A random UID/NFCID1 must stay constant during one power cycle (i.e. whenever the magnetic field of the reader switches from POWER-OFF state to the IDLE state.) As the UID is used for anti-collision of multiple transponders in the field of the reader it needs to be constant during the communication phase. Is there a way to capture this uid as it is being created/sent from the phone? Is this uid generated by the secure element? At least with the 3 phones I tried so far, the UID of the secure element was static. Only the NFCID1 generated for peer-to-peer mode was dynamic (as required by the standard). For the UID of the secure element: Yes it can be captured through the phone. For the NFCID1 in peer-to-peer mode: I guess there could be some way to capture the current NFCID1 through libnfc-nxp but I haven't tried. Best regards, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Secure Element
Hallo JMC, Are you guys sure it's a MIFARE 4k card it's emulating? Yes, I'm very sure it is emulating a MIFARE Classic 4K card and an APDU based smart card (depending on the protocol activation level). When I put the device in emulation mode and read its ATR, I'm getting: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 00 00 00 00 00 6B Decoding this PC/SC ATR gives this: 3B ... Contactless card 8F ... Number of historical bytes: 0xF (15) 80 01 80 ... Category indicator: A status indicator may be present in an optional COMPACT-TLV data object. 4F ... Application identifier Presence indicator 0C ... Length of application identifier: 0x0C (12) Application identifier: A0 00 00 03 06 ... RID: PC/SC Working Group 03 ... Byte for Standard: ISO 14443 A, part 3 00 00 ... Bytes for Card Name: not in standard 00 00 00 00 ... RFU (Shall be set to zero) 6B ... Checksum This is a typical ATR if the card emulation mode is not activated. I receive that ATR if I put the phone in peer-to-peer communication mode (which is the default if card emulation is disabled). While I'm actually expecting: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 02 00 00 00 00 69 With the phone you would not normally receive such an ATR for the card emulation mode either. Usually a contactless smart card reader (like the Omnikey 5321) activates the contactless smart card up to its highest supported protocol layer. For the SmartMX, this means that ISO 14443-4 protocol layer is activated for APDU based communication with the JavaCard. Thus, the ATR generated by the smart card reader would reflect the properties of the APDU-based JavaCard and not those of the MIFARE 4K area. This is the value I recieve when card emulation is on: 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90 Best regards, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Martin,
it seems you are right. Obviously, my tests were too superficial.
I tested with an Omnikey 5321, but that reader automatically activated
the SMX up to the ISO 14443-4 layer, so it was not possible to transmit
any MIFARE Commands.
I, therefore, switched to an ACR122U. I followed the instructions in
that reader's manual to stop activation after ISO 14443-3 (the layer
were MIFARE Classic kicks in). This seemed to work, but regardless of
what commands I sent to the reader my program told me that the commands
were successful. Yet, when I tried to read back any previously written
data it did not work.
It took me a while to figure out what was going wrong: I misinterpreted
the steps required to stop ISO 14443-4 activation.
I can now confirm that reading writing the MIFARE Classic area of the
SmartMX works with the default keys (0x). (Tested with a
properly initialized ACR122U and an NXP Pegoda reader.)
Actually, I'm still a bit surprised that the default keys were used
here. In fact I would have expected that the MIFARE area was locked with
some non-standard keys to be protected against modification by anyone
except Google (or whoever will get access to te rest of the secure element).
So now we would only need to find a way to access the MIFARE area from
within an application on the phone.
I'm currently testing with a modified version of the 2.3.4 firmware. But
as with the smart card readers, the SmartMX is automatically activated
up to the ISO 14443-4/APDU layer. So far I was unable to use any MIFARE
Classic commands to access the secure element.
br
Michael
On 20.05.2011 13:32 Martin wrote:
Hello Michael,
here are the information I promised you yesterday.
Reader: Omnikey 55x3
Software: HID Reader Utility Version 4.0.0.0
Key: it works for each sector.
This is what we found in the api:
// The well-known default MIFARE read key. All keys are set to this at
the factory.
// Using this key will effectively make the payload in the sector
public.
public static final byte[] KEY_DEFAULT =
{(byte)0xFF,(byte)0xFF,(byte)0xFF,(byte)0xFF,
(byte)0xFF,(byte)0xFF};
I checked the UID of the SecureElement, which I can get by calling the
getSecureElementUid() of the NfcSecureElement class via reflection.
And I also checked the sector 00 block 00 of the emulated MiFare card
with our external NFC reader to get the UID. They match!
Do you think it is possible to read/write data with APDU commands?
There is a hidden method in the NfcSecureElement class called
exchangeAPDU.
public byte [] exchangeAPDU(int handle,byte [] data){...}
I have tried some commands, which I found on page eleven at the
following pdf document:
http://www.nfc-reader.com/NFC-smart-card-reader/ACR122-API-Manual/API_ACR122.pdf
But I always get back 6E 00.
Best wishes!
Martin
On 19 Mai, 20:18, Michael Roland mi.rol...@gmail.com wrote:
Hallo Martin,
After enabling the card emulation mode on the Nexus S, I am able to
read and write data to the emulated MiFare Classic 4k card by an
external NFC reader. I would like to do that within an android app.
Have you verified that you actually wrote data to the MIFARE Classic? I
really doubt that you did. What MIFARE keys did you use? In my tests
authentication passed regardless of the keys I used. In fact every
command seemed to return successfully, but in fact no data was ever
written to the card.
You have
spoken about the access keys, but aren't they the same for internal
and external access?
Yes, they would be the same for internal and external access.
br,
Michael
On 19 Mai, 00:59, Michael Roland mi.rol...@gmail.com wrote:
Hallo,
I more or less understand how to do it but I don't understand if after
is possible to build application on card emulation.
Regarding the internalsecureelement(SmartMX): No. Even if you
activate this chip as thesecureelement, you could only use its UID for
your application. To edit data on it/install applications into it you
would need to have the access keys for thatsecureelement.
Regarding an externalsecureelementon the UICC (SIM card): Partly
yes. You can activate an SWP-UICC assecureelement. But access is
limited to external readers for the moment. Until now, there is no known
way to get access to application on the UICC from a phone application.
Moreover some of you speak about authentication, and about a password
that is not possible to have? (What are you talking about when you
speak about this stuff).
The SmartMX in the Nexus S contains a JavaCard operating system that is
compliant to GlobalPlatform. GlobalPlatform defines methods to manage
multiple applications on this JavaCard. A central component of this card
management is the Card Manager, which itself is one application on
thesecureelement. The card manager provides an interface to load, install,
... delete applications on thesecureelement
[android-developers] Re: NFC: Android Samsung nexus as Smart Cart Reader
Hallo bebenza, yes, you can use the Nexus S to communicate with various types of contactless smart cards. Besides MIFARE, FeliCa and some other memory card protocols, the Nexus S also supports IsoDep (APDU based communication on top of ISO 14443-4). If you can use the Nexus S to communicate with the secure element of another phone also depends on the antenna parameters of the other phone. Not all phones work well together. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: ISO 15693 UID inversed
Hallo Johannes, the byte-order in the UID array exactly matches the byte-order defined in ISO/IEC 15693-3: MSB LSB +--+--+--+--+--+--+--+--+ |64 57|56 49|48 1| +--+--+--+--+--+--+--+--+ | 'E0' | MFG | SERIAL NUMBER | +--+--+--+--+--+--+--+--+ Figure 1 — UID format br, Michael On May 18, 7:47 pm, Johannes johannes-b...@gmx.net wrote: I'm not entirely sure whether this is an Android issue, but the byte array Tag.getId() returns on an ISO 15693 tag seems to return the actual UID bytes in inversed order. Any ideas on this? Johannes -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo Martin, After enabling the card emulation mode on the Nexus S, I am able to read and write data to the emulated MiFare Classic 4k card by an external NFC reader. I would like to do that within an android app. Have you verified that you actually wrote data to the MIFARE Classic? I really doubt that you did. What MIFARE keys did you use? In my tests authentication passed regardless of the keys I used. In fact every command seemed to return successfully, but in fact no data was ever written to the card. You have spoken about the access keys, but aren't they the same for internal and external access? Yes, they would be the same for internal and external access. br, Michael On 19 Mai, 00:59, Michael Roland mi.rol...@gmail.com wrote: Hallo, I more or less understand how to do it but I don't understand if after is possible to build application on card emulation. Regarding the internalsecureelement(SmartMX): No. Even if you activate this chip as thesecureelement, you could only use its UID for your application. To edit data on it/install applications into it you would need to have the access keys for thatsecureelement. Regarding an externalsecureelementon the UICC (SIM card): Partly yes. You can activate an SWP-UICC assecureelement. But access is limited to external readers for the moment. Until now, there is no known way to get access to application on the UICC from a phone application. Moreover some of you speak about authentication, and about a password that is not possible to have? (What are you talking about when you speak about this stuff). The SmartMX in the Nexus S contains a JavaCard operating system that is compliant to GlobalPlatform. GlobalPlatform defines methods to manage multiple applications on this JavaCard. A central component of this card management is the Card Manager, which itself is one application on thesecureelement. The card manager provides an interface to load, install, ... delete applications on thesecureelement. Additionally it controls access to these methods. To establish asecurechannel with the card manager (i.e. a connection that provides authenticity, integrity and possibly confidentiality) both, the entity that wants to manage the card and the card manager need to know one or more shared secrets, the authentication keys. Anyway some news aboutNFCcard emulation [nearfieldcommunicationworld] it seems that Google dev will not give use api about that in the next future. Still there is some developments towards card emulation going on (cf.http://www.nfctimes.com/news/android-card-emulation-expected-despite-... ) Moreover, what does it mean And if you improperly authenticate yourself a certain number of times, there aresecureelements out there that will physically destroy themselves and can never be recovered? Is related to the password of my previous questions? While the card manager is protected by access keys, there still exist some methods to find such keys. One of these methods would be brute forces (i.e. trying each possible key value). While such methods are usually very inefficient (if the key has an appropriate length) there might be some methods that could significantly speed up this process. As a safety mechanism the card manager usually implements an additional protection against such an attack: After ten consecutive authentication failures, the card manager locks itself and refuses any further commands. (Other applications that were previously installed on that card will continue to function as usual.) Once this lockdown has happened, there is *NO* way of reversing this. THerefore, once in lockdown no applications can be installed on, removed from, ... thesecureelement. br Michael On May 16, 3:48 pm, Goo_Goo danny.w.s...@gmail.com wrote: Could someone please post the the image withcardemulationenabled for Nexus S? On May 13, 5:08 am, Markus markus.tau...@gmail.com wrote: mtk you wrote after call phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeWired,nfc_jni_se_set_mode_callb ack, (void *)nat); your nexus s was incardemulation I called it with mode default phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeDefault,nfc_jni_se_set_mode_cal lback, (void *)nat); and get following log 5-12 22:08:54.421: DEBUG/NFCJNI(303):NFCcapabilities: HAL = 8150100, FW = a70414, HW = 620003, Model = 0, HCI = 1, Full_FW = 104, FW Update Info = 0 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_GetSecureElementList() 05-12 22:08:54.769: DEBUG/NFCJNI(303): Number ofSecure Element(s) : 1 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING] 05-12 22:08:54.828: INFO/NFCJNI(303):NFCInitialized 05-12 22:08:54.828: DEBUG/NfcService(303):NFC-EE routing OFF 05-12 22:08:54.847: DEBUG/NfcService(303):NFC-C discovery ON BUT reader
[android-developers] Re: NFC Tags
Hallo Shekhar, NDEF is a data exchange format for NFC (NDEF = NFC Data Exchange Format). It can be used with NFC tags (reader-writer mode) and in peer- to-peer mode. The NFC Forum Type tag formats specify a standardized way to store NDEF data (and possibly other data) onto certain tags. So these specifications define the tags' data structures and commands to access the data. The four tag types are based on previously existing vendor specific RFID tag types: NFC Forum Tag Type 1 is based on Innovision Topaz/Jewel NFC Forum Tag Type 2 is based on NXP MIFARE Ultralight NFC Forum Tag Type 3 is based on Sony FeliCa NFC Forum Tag Type 4 is based on APDU-based smart cards Besides these standard tag types NXP released application notes that define ways to store NDEF formatted data onto other RFID tag types (application notes are available for MIFARE Classic and for ICODE). As the tag types are based on existing RFID tag technologies, they also correspond to certain RFID/smartcard standards: NFC Forum Tag Type 1 sits on top of ISO/IEC 14443-3 Type A (but without anti-collision!) NFC Forum Tag Type 2 sits on top of ISO/IEC 14443-3 Type A NFC Forum Tag Type 3 sits on top of JIS X 6319-4 NFC Forum Tag Type 4 sits on top of ISO/IEC 14443-4 and ISO/IEC 7816-4 Corresponding to the ISO NFC standards (ISO/IEC 18092, ...), the NFC Forum combined certain RFID standards to the NFC Digital Protocol. The digital protocol has three RFID technologies named NFC-A, NFC-B and NFC-F: NFC-A matches the RFID standard ISO/IEC 14443-3 Type A NFC-B matches the RFID standard ISO/IEC 14443-3 Type B NFC-F matches the RFID standard FeliCa JIS X 6319-4 (or rather those parts of that standard that were incorporated by ISO/IEC 18092) Additionally, the Nexus S (or the NXP chip thats inside it) understands a forth RFID technology that uses the same frequency as NFC but is that not really related to NFC: ISO/IEC 15693 (called NFC-V in the Android API, where V stands for Vicinity as the ISO standard refers to this technology as vicinity cards). ISO-DEP is the data exchange protocol on top of ISO/IEC 14443-4. It is based on the same command exchange protocol that is used with contact smartcards: ISO/IEC 7816-4. ISO/IEC 14443-4 joins the two low-level protocols defined in ISO/IEC 14443-3 into one common high-level protocol. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Tags
Hallo Shekhar,
Really appreciate for the enlightment.Now as per my understanding, in
the Android system NDEF class can be used for the NFC Forum Tag Type
1,2,3,4 and NFC P2P
communication.
NDEF is an abstraction of the actual data structures on an NFC tag or
for peer-to-peer communication. Thus, with NDEF you don't need to care
about what technology is used below that data format.
NDEF can be used for peer-to-peer and on NFC tags (1 to 4) and, with the
Nexus S and some other phones, on certain vendor specific tag types like
MIFARE Classic and ICODE.
While we have to make use of the specific Android
Classes for:-
1.ISODEP - IsoDep Class
2.MIFARECLASSIC - MifareClassic class
3.NFCA - NfcA class
4.NFCB - NfcB class
5.NFCF - NfcF class
6.NFCV - NfcV class
If you want to use specific features of these technologies outside the
comfort of NDEF you would have to use these technology specific classes.
// Check which type of tags was discovered
switch(tagtype)
{
// do operation as per your need using the [specific] Class
Apis
break;
...
}
Am I correct?
Correct.
br
Michael
On 18 May 2011 10:10, Michael Roland mi.rol...@gmail.com wrote:
Hallo Shekhar,
NDEF is a data exchange format for NFC (NDEF = NFC Data Exchange
Format). It can be used with NFC tags (reader-writer mode) and in peer-
to-peer mode.
The NFC Forum Type tag formats specify a standardized way to store
NDEF data (and possibly other data) onto certain tags. So these
specifications define the tags' data structures and commands to access
the data. The four tag types are based on previously existing vendor
specific RFID tag types:
NFC Forum Tag Type 1 is based on Innovision Topaz/Jewel
NFC Forum Tag Type 2 is based on NXP MIFARE Ultralight
NFC Forum Tag Type 3 is based on Sony FeliCa
NFC Forum Tag Type 4 is based on APDU-based smart cards
Besides these standard tag types NXP released application notes that
define ways to store NDEF formatted data onto other RFID tag types
(application notes are available for MIFARE Classic and for ICODE).
As the tag types are based on existing RFID tag technologies, they
also correspond to certain RFID/smartcard standards:
NFC Forum Tag Type 1 sits on top of ISO/IEC 14443-3 Type A (but
without anti-collision!)
NFC Forum Tag Type 2 sits on top of ISO/IEC 14443-3 Type A
NFC Forum Tag Type 3 sits on top of JIS X 6319-4
NFC Forum Tag Type 4 sits on top of ISO/IEC 14443-4 and ISO/IEC 7816-4
Corresponding to the ISO NFC standards (ISO/IEC 18092, ...), the NFC
Forum combined certain RFID standards to the NFC Digital Protocol. The
digital protocol has three RFID technologies named NFC-A, NFC-B and
NFC-F:
NFC-A matches the RFID standard ISO/IEC 14443-3 Type A
NFC-B matches the RFID standard ISO/IEC 14443-3 Type B
NFC-F matches the RFID standard FeliCa JIS X 6319-4 (or rather those
parts of that standard that were incorporated by ISO/IEC 18092)
Additionally, the Nexus S (or the NXP chip thats inside it)
understands a forth RFID technology that uses the same frequency as
NFC but is that not really related to NFC: ISO/IEC 15693 (called NFC-V
in the Android API, where V stands for Vicinity as the ISO standard
refers to this technology as vicinity cards).
ISO-DEP is the data exchange protocol on top of ISO/IEC 14443-4. It is
based on the same command exchange protocol that is used with contact
smartcards: ISO/IEC 7816-4. ISO/IEC 14443-4 joins the two low-level
protocols defined in ISO/IEC 14443-3 into one common high-level
protocol.
br,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: NFC Secure Element
Hallo, I more or less understand how to do it but I don't understand if after is possible to build application on card emulation. Regarding the internal secure element (SmartMX): No. Even if you activate this chip as the secure element, you could only use its UID for your application. To edit data on it/install applications into it you would need to have the access keys for that secure element. Regarding an external secure element on the UICC (SIM card): Partly yes. You can activate an SWP-UICC as secure element. But access is limited to external readers for the moment. Until now, there is no known way to get access to application on the UICC from a phone application. Moreover some of you speak about authentication, and about a password that is not possible to have? (What are you talking about when you speak about this stuff). The SmartMX in the Nexus S contains a JavaCard operating system that is compliant to GlobalPlatform. GlobalPlatform defines methods to manage multiple applications on this JavaCard. A central component of this card management is the Card Manager, which itself is one application on the secure element. The card manager provides an interface to load, install, ... delete applications on the secure element. Additionally it controls access to these methods. To establish a secure channel with the card manager (i.e. a connection that provides authenticity, integrity and possibly confidentiality) both, the entity that wants to manage the card and the card manager need to know one or more shared secrets, the authentication keys. Anyway some news about NFC card emulation [nearfieldcommunicationworld] it seems that Google dev will not give use api about that in the next future. Still there is some developments towards card emulation going on (cf. http://www.nfctimes.com/news/android-card-emulation-expected-despite-doubts-google-engineers ) Moreover, what does it mean And if you improperly authenticate yourself a certain number of times, there are secure elements out there that will physically destroy themselves and can never be recovered? Is related to the password of my previous questions? While the card manager is protected by access keys, there still exist some methods to find such keys. One of these methods would be brute forces (i.e. trying each possible key value). While such methods are usually very inefficient (if the key has an appropriate length) there might be some methods that could significantly speed up this process. As a safety mechanism the card manager usually implements an additional protection against such an attack: After ten consecutive authentication failures, the card manager locks itself and refuses any further commands. (Other applications that were previously installed on that card will continue to function as usual.) Once this lockdown has happened, there is *NO* way of reversing this. THerefore, once in lockdown no applications can be installed on, removed from, ... the secure element. br Michael On May 16, 3:48 pm, Goo_Goo danny.w.s...@gmail.com wrote: Could someone please post the the image withcardemulationenabled for Nexus S? On May 13, 5:08 am, Markus markus.tau...@gmail.com wrote: mtk you wrote after call phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeWired,nfc_jni_se_set_mode_callb ack, (void *)nat); your nexus s was incardemulation I called it with mode default phLibNfc_SE_SetMode(seID,phLibNfc_SE_ActModeDefault,nfc_jni_se_set_mode_cal lback, (void *)nat); and get following log 5-12 22:08:54.421: DEBUG/NFCJNI(303):NFCcapabilities: HAL = 8150100, FW = a70414, HW = 620003, Model = 0, HCI = 1, Full_FW = 104, FW Update Info = 0 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_GetSecureElementList() 05-12 22:08:54.769: DEBUG/NFCJNI(303): Number of Secure Element(s) : 1 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef 05-12 22:08:54.769: DEBUG/NFCJNI(303): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING] 05-12 22:08:54.828: INFO/NFCJNI(303):NFCInitialized 05-12 22:08:54.828: DEBUG/NfcService(303):NFC-EE routing OFF 05-12 22:08:54.847: DEBUG/NfcService(303):NFC-C discovery ON BUT reader is not detecting a Tag on my phone Is there maybe a problem to setting the mode returned 0x000d[NFCSTATUS_PENDING] sounds not so great I am working with CyanogenMod 7 (Android 2.3.4) regards Markus- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC Dispatch
Hallo, And Tech_Discovered: intent-filter action android:name=android.nfc.action.TECH_DISCOVERED meta-data android:name=android.nfc.action.TECH_DISCOVERED android:resource=@xml/nfc_tech_filter / /action/intent-filter This intent filter seems to be wrong. The meta-data should be placed as a subelement of the activity (just on the same level as the intent filter). This also seems to be a bug in the documentation. (Actually there are more mistakes on that page.) So the correct intent-filter would look like this: activity ... !-- Catch tag detection events for specific technologies -- intent-filter action android:name=android.nfc.action.TECH_DISCOVERED / /intent-filter meta-data android:name=android.nfc.action.TECH_DISCOVERED android:resource=@xml/filter_nfc / /activity My first question is: Are this definitions enough to get the App shown in the TechListOverView? To get your activity in the activity chooser, you must also correctly setup your @xml/nfc_tech_filter xml resource. If you want to be sensitive to the NfcA technology, your tech-filter would look like this: resources xmlns:xliff=urn:oasis:names:tc:xliff:document:1.2 tech-list techandroid.nfc.tech.NfcA/tech /tech-list /resources If you want to be sensitive to all Mifare Ultralight tags that are also NfcA technology, your filter would look like this: resources xmlns:xliff=urn:oasis:names:tc:xliff:document:1.2 tech-list techandroid.nfc.tech.NfcA/tech techandroid.nfc.tech.MifareUltralight/tech /tech-list /resources Btw, in this case it would have been enough to use the MifareUltralight tech filter alone, as *all* Mifare Ultralights are NfcA anyways. If you want to be sensitive to all NfcA tags and all NfcB tags, your tech-filter would look like this: resources xmlns:xliff=urn:oasis:names:tc:xliff:document:1.2 tech-list techandroid.nfc.tech.NfcA/tech /tech-list tech-list techandroid.nfc.tech.NfcB/tech /tech-list /resources Notice two things here: 1. The documentation is wrong in saying that each tech-list is to be surrounded with resources tags. (The compiler will throw an error on this.) 2. Putting multiple techs inside one tech-list give the logical AND between the techs and putting mutiple tech-lists inside the filter xml-file gives the logical OR between the tech-lists. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Filtering NFC intents, NDEF message external type
Hallo Gorka, for the moment Android provides no means to directly dispatch your application based on an NFC Forum External Type (btw, your external type name does not follow the RTD specification, The External Type Name MUST be formed by taking the domain name of the issuing organization, adding a colon, and then adding the type name as managed by the organization.) By the way, I cannot filter smartposter and URI NDEF message types. Could someone tell me how to do this?? Filtering should work based on the data of the URI record (both for the URI record itself and the SmartPoster's embedded URI record). You can do this with data ... /. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: android nfc tech API help
Hallo,
which variant did you use, the low-level access or the IsoDep acccess?
The low-level example will only work with MIFARE Ultralight cards (these
are always NfcA). Sorry, I don't know any example for low-level access
to NfcB cards. The IsoDep example will certainly only give a useful
result if the card contains the ICAO electronic passport application...
br
Michael
On 30.04.2011 00:58 priti - wrote:
Hi Michael,
Thanks! that worked with my nfcA cards!
But when I use it with my nfcB cards, I am getting a 67 00 (protocol
error?)
Appreciate your help,
Priti
On Thu, Apr 28, 2011 at 8:50 AM, Michael Roland mi.rol...@gmail.com
mailto:mi.rol...@gmail.com wrote:
Hallo,
What exactly is low level access?
With low-level access (as compared to APDU based access) I mean some
vendor specific (proprietary) protocol according to the ISO/IEC 14443-3
standard. Thus, instead of sending high-level APDU commands a more
simple protocol is used (such a protocol is for example the MIFARE
Ultralight and the MIFARE Classic command-set).
How do I send/receive nfcA/nfcB commands then?
For NfcA (e.g. MIFARE Ultralight) you would simply retrieve an NfcA
object:
NfcA myTag = NfcA.getTag(tag);
And then transceive low-level commands with transceive() method. E.g.
byte[] data = myTag.transceive(new byte[]{ (byte)0x30, (byte)0x00 });
would retrieve the first 16 bytes of data from an MIFARE Ultralight tag.
But as you suggested you want to transfer APDUs, instead of getting an
NfcA object you would want to get an IsoDep object for the tag. This
object wraps an APDU-based (ISO/IEC 14443-4 ISO/IEC 7816-4)
connection:
IsoDep myCard = IsoDep.getTag(tag);
The transceive() method then allows you to directly transmit command
APDUs to the contactless smart card and returns the response APDU:
byte[] response = myCard.transceive(command);
Where command could be, for instance, a SELECT(file by DF name) command.
The following command would select the ICAO electronic passport
application (AID A002471001):
byte[] command = new byte[]{
(byte)0x00, /* CLA = 00 (first interindustry command set) */
(byte)0xA4, /* INS = A4 (SELECT) */
(byte)0x04, /* P1 = 04 (select file by DF name) */
(byte)0x0C, /* P2 = 0C (first or only file; no FCI) */
(byte)0x07, /* Lc = 7 (data/AID has 7 bytes) */
/* AID = A002471001: */
(byte)0xA0, (byte)0x00, (byte)0x00, (byte)0x02,
(byte)0x47, (byte)0x10, (byte)0x01
};
As a response you would get e.g. status code 9000 if the applet was
found on the card.
Best regards,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: nfc read not working
Hallo John,
the manifest file have the following filters:
intent-filter
action android:name=android.nfc.action.TECH_DISCOVERED/
/intent-filter
The program can't go through reading process because the follwoing condition
is always false:
if (NfcAdapter.ACTION_TAG_DISCOVERED.equals(intent.getAction())){}
Right, if you look at the intent filter you will realize that you are
sensitive to a different intent. Consequently, the condition sould
check for NfcAdapter.ACTION_TECH_DISCOVERED instead of
NfcAdapter.ACTION_TAG_DISCOVERED.
br,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: android nfc tech API help
Hallo,
What exactly is low level access?
With low-level access (as compared to APDU based access) I mean some
vendor specific (proprietary) protocol according to the ISO/IEC 14443-3
standard. Thus, instead of sending high-level APDU commands a more
simple protocol is used (such a protocol is for example the MIFARE
Ultralight and the MIFARE Classic command-set).
How do I send/receive nfcA/nfcB commands then?
For NfcA (e.g. MIFARE Ultralight) you would simply retrieve an NfcA object:
NfcA myTag = NfcA.getTag(tag);
And then transceive low-level commands with transceive() method. E.g.
byte[] data = myTag.transceive(new byte[]{ (byte)0x30, (byte)0x00 });
would retrieve the first 16 bytes of data from an MIFARE Ultralight tag.
But as you suggested you want to transfer APDUs, instead of getting an
NfcA object you would want to get an IsoDep object for the tag. This
object wraps an APDU-based (ISO/IEC 14443-4 ISO/IEC 7816-4) connection:
IsoDep myCard = IsoDep.getTag(tag);
The transceive() method then allows you to directly transmit command
APDUs to the contactless smart card and returns the response APDU:
byte[] response = myCard.transceive(command);
Where command could be, for instance, a SELECT(file by DF name) command.
The following command would select the ICAO electronic passport
application (AID A002471001):
byte[] command = new byte[]{
(byte)0x00, /* CLA = 00 (first interindustry command set) */
(byte)0xA4, /* INS = A4 (SELECT) */
(byte)0x04, /* P1 = 04 (select file by DF name) */
(byte)0x0C, /* P2 = 0C (first or only file; no FCI) */
(byte)0x07, /* Lc = 7 (data/AID has 7 bytes) */
/* AID = A002471001: */
(byte)0xA0, (byte)0x00, (byte)0x00, (byte)0x02,
(byte)0x47, (byte)0x10, (byte)0x01
};
As a response you would get e.g. status code 9000 if the applet was
found on the card.
Best regards,
Michael
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Sending data continuously over NFC in mode P2P
Hallo Azahara, thanks for your answer. So that means Android 2.3.3 does not provide the possibility to send many messages per connection established, however internally it uses a more complex scheme to communicate in p2p mode that is not available yet?. Right. Actually it is internally it uses a lower level of abstraction. Do you know if there exists any alternative to accomplish the objective of sending data continuously in p2p mode in only one tap? If you only need communication into one direction, you could of course pack as many NDEF records into the NDEF message as you want. Other than that, you could possibly try to access the classes/methods for LLCP communication through reflection, but I don't have any experiences with that. Alternatively you could re-compile the Android system and include the LLCP part into the public API. I have done this for my Nexus S but I did not yet have the time to test this. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Reading PayWave (ISO14443-B format) track information using Android 2.3.3 NFC API
Hallo lal, I'm trying to Read Track data for Payment cards (PayWave, PayPass). As per my understanding they follow ISO 14443 B. With new NFC API, byte[] b1 = myTag.getHiLayerResponse(); //b1 is not null, but length == 0 [...] result = myTag.transceive(b1); It will certainly not help if you send the bytes retrieved from getHiLayerResponse() back to the card. Especially if you say they are zero length anyways. These payment cards implement the EMV standards. Application-to- application communication is done on the level of APDUs. Therefore, it should not matter if this card is ISO 14443 Type A or Type B. What matters is that IsoDep (= ISO 14443-4) is supported. Through the IsoDep interface you directly transmit APDU commands. Have a look at the ISO/IEC 7816-4 standard on how APDU command-response pairs are formatted. Regarding the EMV protocol the specifications are available from EMVCo's website: http://www.emvco.com/ br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC: convert MIME type to byte[]?
Hallo Johannes, Unfortunately, I can't make a lot out of the RFC 2046 specification (http://www.ietf.org/rfc/rfc2046.txt). a MIME type is basically a string in the format top-level-type/ subtypeoptions (all 7bit US-ASCII). Typical values for top-evel- type are text, image, video, audio or application (a full list is given in section 3 of RFC 2046). subtype further describes the format of the content. For example if the payload of your NDEF record is some plain text in US-ASCII you would use the MIME type text/plain. If the payload was an image in JPEG format the MIME type would be image/jpeg. options specifies additional options for the MIME type. For example the text/plain MIME type could also use ISO-8859-1 instead of US-ASCII as character encoding by appending ; charset=iso-8859-1. The Wikipedia article http://en.wikipedia.org/wiki/Internet_media_type gives a introduction to registered MIME types and also explains how you would define your own application specific non-standard MIME type. So, how do I correctly parse a MIME type string into said byte[] array? The MIME type specifier itself is 7bit US-ASCII encoded. Sou you would use something like this: byte[] mimeType = text/plain.getBytes(US-ASCII); br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to communicate with SmartCard such as e-ID, e-Passport using ISO14443 APDU format???
Hallo, take a look at the IsoDep class. It allows you to exchange APDU command-response pairs with contactless smartcards. br, Michael On Apr 21, 6:59 am, comsta6 ms...@komsco.com wrote: I am a new about android phone. Especially,,,I am a smartcard developer such as e-Passport, e-ID card. I am interested in android nfc phone as a reader communicating with real e-Passport. I would like to read all data in e-Passport with android's nfc functions. Is it possible to develop a terminal program in android phone to communicate general smartcard?? Please,,Let me know some information about this? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Sending APDU Command from Nexus S
Hallo Perumal, I am having Nexus S and a Mifare Tag. Using TagWriter application I am write and read from the Tag. Now I want to try sending an APDU command to the Tag. if you tag is a MIFARE Classic or MIFARE Ultralight tag, you won't be able to communicate with it using APDU commands. These two technologies use their own proprietary command sets. Use the MifareClassic (or MifareUltralight) objects exposed by such tags. These classes already provide the necessary read/write/ authenticate/... commands to communicate with these tags. You won't need to prepare and transceive() your own commands. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Sending APDU Command from Nexus S
Hallo Wilson, I am facing an issue with a Mifare Classic card (this is a dual interface smart card; contact and contactless). Alright, then it is most likely not a MIFARE Classic card but a contactless (dual interface) smart card (with ISO 14443-4 interface) that additionally provides a MIFARE Classic emulation. When I use transceive() to send apdu corresponding to select AID, it always return null. Right, as you write here: 2) Create MifareClassic object using you create a MifareClassic but what you really want to do is open an APDU connection to the card. If your card is a real dual-interface smart card(*) it should also expose an IsoDep interface (ISO 14443-4 / ISO 7816-4). This is the interface you would want to use for APDU communication. br, Michael (*) There could also exist some hybrid cards that have a MIFARE Classic _contactless_ card and an APDU-based _contact_ smart card joined into the same plastic card. In that case the contact and contactless parts would be independent chips and no communication between them would be possible. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Sending data continuously over NFC in mode P2P
Hallo Azahara, Does anybody know why should I have to tap many times the phones in order to send continuously data in p2p mode?. This is because the current Android NFC API does not provide any furhter P2P (LLCP) communication features. Internally, Android already uses more sophisticated LLCP communication sockets, but in the public API they are not available yet. I would expect them to become available with one of the next releases. This behavior corresponds to a feature of NFC, that only allows to send one message per tap, or a problem concerned with the management of the intent sent to the application when a NdefMessage is received more than once? Neither. This is simply a matter of the API that is available to the programmer in Android 2.3.3. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: NFC p2p with NFC Reader
Hallo, have a look at the thread: http://groups.google.com/group/android-developers/browse_frm/thread/fe9956bb2a6529ca For the moment Sony's nfcpy project ( https://launchpad.net/nfcpy/ ) seems to be the only freely available open-source LLCP implementation for the desktop platform. You might want to try to port this to the ACR122U reader. On top of LLCP the NDEF Push Protocol should be pretty easy to implement. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: (Full) NFC support for Android (on a Nexus S, specifically)
Hallo, Only open LLCP implementation I know of is NFCPy, https://launchpad.net/nfcpy.. heard they've established some communication with an Android device, but it only works for one type of reader. Sony had a pretty impressive demo of their nfcpy at WIMA this week. As the python module is their reference implementation of the LLCP it should work with the Android phones too. It should be pretty easy to implement the NPP on top of this library. So it seems we only need someone to port it to other reader platforms like the ACR122U. Also SCM Microsystems showcased their peer-to-peer development kit which is supposed to support LLCP, although I didn't find it on their website. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: does NFC in gingerbread support card simulate?
Hallo Nick, Understood. There was no choice but to create a new protocol, since the rules of the NFC Forum are that you cannot implement a protocol until it is ratified. And SNEP is not yet ratified. Rather than wait for ever, we want to put it in the hands of users and application developers right now :) Oh, I didn't know of this rule, although it makes sense ;-) * The specification says that the service name is com.android.npp. The LLCP specification mandates well-known service names to be URIs in the form urn:nfc:sn:servicename and external service names to be URIs in the form urn:nfc:xsn:domain:servicename. The NPP is an external service, therefore, in my opinion this service name is not compatible with the LLCP specification. Or did I miss something? Well the LLCP spec is not super clear here, note language like External service names MAY be formatted as uniform resource names (URN). However, we have heard this feedback and are considering changes. You are right :-) I didn't read the MAY. In fact it only mandates the name to be a URI reference (which, as I just learned, could be pretty much anything as it's not required to be an absolute URI). * The specification refers to NFC-DEP. This seems to be in conflict with the LLCP specification which does not mandate the binding to a specific underlying protocol. Thus, LLCP could be used on top of other protocols than NFC-DEP too. This is on purpose. We require that an Android compatible device that claims NFC hardware support must do NPP, and it must do so on top of NFC-DEP. Alright. br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: MiFare Classic detection
Hallo Domnic, could you show the complete AndroidManifest? And are you sure that your tag is MIFARE Classic? br Michael On 13.04.2011 12:29 androidom wrote: Hello Michael, I tried this with the intend filter. I am not getting my app triggered. somehow it is still landing on the Tags app. and I am not able to de.install the tags app. do you have a working source which can just detect a tag and show up the ID of the tag.. a Mifare classic one perhaps..? thanks Domnic -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: MiFare Classic detection
Hallo, Just another question, I would like to start scanning for a tag inside an activity on press of a button say - Start Scanning. In which case, the scanning of the tag must be triggered after that button press. Once a tag is scanned, then it must get the ID of the tag back to the activity that started the scanning. You should take a look at the foreground activity dispatch: http://developer.android.com/reference/android/nfc/Tag.html br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: MiFare Classic detection
Hallo Domnic, Strange, the manifest looks good to me. uses-sdk android:minSdkVersion=9 / Your phone is Android 2.3.3 (i.e. API version 10, right?). Otherwise, the TECH_DETECTED intent is not available. activity android:name=verifytagscanact android:permission=android.permission.NFC ^^^ I'm not sure why you request the calling app to have the NFC permission. You might want to try to remove this requirement, eventhough I would expect the NFC Service to have this permission. br, Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: MiFare Classic detection
Hallo Domnic, I've just re-read through the code you posted before and found another problem: Did you place the action inside an intent-filter? Like this: intent-filter action android:name=android.nfc.action.TECH_DISCOVERED / /intent-filter meta-data android:name=android.nfc.action.TECH_DISCOVERED android:resource=@xml/filter_nfc / br Michael -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
