Transfer from http://blog.csdn.net/think_soft/article/details/8169483
This article was translated from: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
This article describes the basic tasks that you can perform in the Android system. It explains how to send and receive NFC data in the NDEF message format, and describes the Android framework API that supports these features? For more advanced topics, including discussion of non-ndef format data, the situation "advanced NFC "
There are two main scenarios where NDEF data works with Android:
1. Read the Ndef data from the NFC tag;
2. Send ndef messages from one device to another?
Reading Ndef data from an NFC tag is handled using the label dispatch system, which analyzes the discovered NFC tags, classifies the data appropriately, and launches an application that is interested in the data. The application that is scanning to the NFC tag declares a intent filter and requests that the data be processed ?
Does the Android beam™ feature allow devices to push a NDEF message to another device that is physically listening to each other? This interaction provides a way to send data more easily than other wireless technologies, such as Bluetooth, because NFC does not require manual device discovery or pairing requirements? Will the two devices automatically connect when they are close to a certain range? Android beam is used by a set of NFC APIs so that applications can transfer information between devices? for example, a communications directory, a browser, and apps like YouTube use Android beam to share communications with other devices? Web pages and videos?
NFC Tag Scheduling system
In general, unless NFC is disabled in the device's Settings menu, the Android device searches for NFC in a non-lock screen state. When an Android device discovers an NFC tag, the desired behavior is to handle the intent with the most appropriate activity, Instead of asking the user what application to use? Because the device can only scan the NFC tag in a very short range, forcing the user to manually select an activity causes the device to leave the NFC tag, interrupting the connection? Should you develop your own activity to handle the NFC tag you care about, thereby blocking the operation of the selector?
To help you achieve this goal, Android provides a special label scheduling system to analyze the scanned NFC tag, by parsing the data and trying to find the application of interest in the data being scanned, as follows:
1. Resolve the NFC tag and figure out the MIME type or URI that identifies the data payload in the tag;
2. Encapsulate the MIME type or URI and the data payload into a intent?
3. Start activity based on intent?
How to map NFC tags to mime types and URIs
Before you start writing an NFC application, it is important to understand the different types of NFC tags. How does the label dispatch system parse the NFC tag? and the specific work done by the label dispatch system when the NDEF message is detected? NFC tags involve a wide range of technologies, and there are many different ways to write data to tags. Android supports the NDEF standard defined by NFC forum?
Ndef data is encapsulated in a message (Ndefmessage) that contains one or more records (Ndefrecord)? Each NDEF record must have a good format for the specification of the record type you want to create? Android also supports other tags that do not contain the NDEF data type, can you work with classes in the Android.nfc.tech package? To work with other types of labels, it involves writing your own protocol stack to communicate with that label, so we recommend that you use the ndef as much as possible, To reduce development difficulty and maximize support for Android devices?
Note: To download the full NDEF specification, please go to the "NFC Forum specification download" url to download?
Now that you have some background knowledge of NFC tags, how does android handle NDEF format tags? When an android device scans an NFC tag that contains ndef format data, it resolves the message, And try to figure out the MIME type or URI identifier of the data? First, the system reads the first Ndefrecord in the message (ndefmessage) to determine how to interpret the entire NDEF message (a NDEF message can have multiple Ndef records)? In well-formed NDEF messages , the first Ndefrecord contains the following field information:
3-bit TNF (type name format)
Indicates how variable-length type fields are interpreted, and the valid values are described in table 1 below?
Variable length type
Describe the type of record, and if you use Tnf_well_known, use this field to specify the type definition (RTD) for the record? The valid RTD values are defined in table 2 below?
Variable length ID
Uniquely identify the record? This field is not used frequently, but if you need to uniquely identify a tag, you can create an ID for that field?
Variable-Length load
Do you want to read/write the actual data load? A NDEF message can contain multiple NDEF records, so don't assume that all the load is included in the first ndef record of the NDEF message?
The tag dispatch system uses the TNF and type fields to attempt to map a MIME type or URI to a NDEF message? If successful, it encapsulates the information with the actual payload into the action_nedf_discovered type of intent? However, There will be a label dispatch system can not judge the data type according to the first ndef record, so that there will be ndef data can not be mapped to MIME type or URI, or the NFC tag does not contain ndef start data of the situation occurs? In this case, The tag object associated with a tagged technical information is replaced with the payload encapsulated within the Action_tech_discovered type intent object?
Table 1. Introduction to label scheduling system mapping How do I map TNF and type fields to MIME or URI? Also, it is explained that the type of TNF cannot be mapped to MIME type or URI? In this case, the label scheduling system will degenerate to Action_tech_ Discovered type of intent object?
For example, if the label dispatch system encounters a record of type Tnf_absolute_uri, it maps the variable-length type field of the record to a URI? The label dispatch system encapsulates this URI with information about other related tags, such as data payload, to Action_ndef _discovered Intent object? On the other hand, if you encounter a Tnf_unknown type, it creates a intent object that encapsulates the technical information of the tag instead?
Table 1. The supported TNF and their mappings
Type name format (TNF) |
Mapping |
Tnf_absolute_uri |
URI based on the Type field |
Tnf_empty |
Intent object that is degraded to the action_tech_discovered type |
Tnf_external_type |
Based on the URI of the urn in the Type field? Urn is the shortened format (<DOMAIN_NAME>:<SERVICE_NAME) encoded into the Ndef type? Android will map this urn into the following format Uri:vnd.android.nfc://ext/<domain_name>:<service_name> |
Tnf_mime_media |
MIME type based on Type field |
Tnf_unchanged |
Intent object that is degraded to the action_tech_discovered type |
Tnf_unknown |
Intent object that is degraded to the action_tech_discovered type |
Tnf_well_known |
Depending on the MIME type or URI of the record type definition (RTD) that you set in the Type field, |
Table 2. Tnf_well_known supported RTDs and their mappings
Record type definition (RTD) |
Mapping |
Rtd_alternative_carrier |
Intent object that is degraded to the action_tech_discovered type |
Rtd_handover_carrier |
Intent object that is degraded to the action_tech_discovered type |
Rtd_handover_request |
Intent object that is degraded to the action_tech_discovered type |
Rtd_handover_select |
Intent object that is degraded to the action_tech_discovered type |
Rtd_smart_poster |
URI based on load resolution |
Rtd_text |
MIME of the Text/plain type |
Rtd_uri |
Payload-based URI |
Android near Field Communication---NFC Basics (i) (RPM)