This article translated from: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
This article describes the basic tasks you can perform in Android. It explains how to use the ndef Message format to send and receive NFC data, android framework APIs that support these features are also introduced. More advanced topics, including discussions on non-ndef format data
NFC"
Ndef data works with Android in two main scenarios:
1. Read ndef data from NFC tags;
2. Send the ndef message from one device to another 。
The tag scheduling system is used to read ndef data from NFC tags. It analyzes the detected NFC tags and classifies the data as appropriate, and start the application that is interested in this type of data. The application that wants to process the NFC tag scanned will declare an intent filter and request to process the data 。
Android
Beam allows devices to push an ndef message to another device that listens to each other physically. This type of interaction provides other wireless technologies (such as Bluetooth) it is easier to send data because NFC does not require manual device discovery or pairing. Two devices are automatically connected when they are close to a certain range. Android beam uses a group of NFC APIs. to use, this allows applications to transmit information between devices. For example, applications such as communication records, browsers, and YouTube use Android beam to share communication records, webpages, and videos with other devices 。
NFC tag Scheduling System
Generally, an Android device searches for NFC in a non-lock status unless NFC is disabled in the device settings menu. When an Android device discovers an NFC tag, the expected behavior is to use the most appropriate activity to process the intent, rather than asking the user what application to use, because the device can only scan NFC tags within a very short range, force the user to manually select an activity, which will cause the device to leave the NFC tag and interrupt the connection. You should develop your own activity to process the NFC tag you are concerned about and block it.
Selector operation 。
To help you achieve this goal, Android provides a special tag scheduling system to analyze the scanned NFC tags and parse the data, try to find the application that you are interested in the scanned data as follows:
1. parse the NFC tag and identify the MIME type or Uri of the data load in the tag;
2. encapsulate the MIME type, Uri, and data load into an intent 。
3. Start the activity based on intent 。
How to map NFC tags to MIME types and Uris
Before writing NFC applications, it is important to understand how different NFC tags, tag scheduling systems parse NFC tags, and when detecting ndef messages, the tag scheduling system performs specific work. NFC tags involve a wide range of technologies and there are many different ways to write data to tags. Android supports NFC
The ndef standard defined by Forum 。
Ndef data is encapsulated in a message (ndefmessage), which contains one or more records (ndefrecord) each ndef record must have a standard format of the record type you want to create. Android also supports other labels that do not contain the ndef data type. You can use android. NFC. the classes in the tech package work. To use other types of tags to work, it involves writing your own protocol stack for communicating with the tag. Therefore, we recommend that you use ndef as much as possible, to reduce development difficulty and maximize support for Android devices 。
Note: To download the complete ndef specification, go to the "NFC Forum specification download" URL to download it 。
Now you have some background knowledge about NFC tags, next, we will introduce in detail how Android processes tags in ndef format. When an Android device scans an NFC tag containing ndef format data, it will parse the message, and try to figure out the MIME type or Uri identifier of the data. First, the system will read the first ndefrecord in the message (ndefmessage, to determine how to interpret the entire ndef message (an ndef message can have multiple ndef records). In a well-formed ndef message, the first ndefrecord contains the following field information:
3-bit TNF (type name format)
Describes how to interpret fields of the variable length type. The valid values are described in table 1 。
Variable Length type
Description of the record type. If tnf_well_known is used, this field is used to specify the record type definition (RTD). A valid RTD value is defined in Table 2 below 。
Variable Length ID
This field is not frequently used. However, if you need a unique identifier, you can create an ID for this field 。
Variable Length Load
The actual data load you want to read/write. An ndef message can contain multiple ndef records, so do not assume that the first ndef record of the ndef message contains all the loads 。
The tag scheduling system uses the TNF and type fields to map the MIME type or URI to the ndef message. If yes, it encapsulates the information with the actual load into the intent of the action_nedf_discovered type. However, the tag scheduling system cannot judge the data type based on the first ndef record, in this case, the ndef data cannot be mapped to the MIME type or Uri, or the NFC tag does not contain the ndef start data. In this case, instead of using a tag object related to tag technology and loads encapsulated in the action_tech_discovered intent object 。
Table 1. this section describes how to map the TNF and type fields to mime-type or URI in the tag scheduling system ing. It also describes that the type of TNF cannot be mapped to the MIME type or Uri., the tag scheduling system degrades to the intent object of the action_tech_discovered type 。
For example, if the tag scheduling system encounters a tnf_absolute_uri record, it maps the variable-length field of the record to a URI. The tag scheduling system will map the URI with other related tag information (such as data load) encapsulated together into the intent object of action_ndef_discovered. On the other hand, if the tnf_unknown type is encountered, it will create an intent object that encapsulates the tag technical information to replace 。
Table 1. Supported mappings between TNF and them
|
Type name format (TNF) |
Ing |
|
Tnf_absolute_uri |
Type field-based URI |
|
Tnf_empty |
Degraded to intent object of action_tech_discovered type |
|
Tnf_external_type |
Based on the urn URI in the Type field. Urn is a shortened format (<domain_name >:< SERVICE_NAME) encoded into the ndef type. Android maps this urn to the URI in the following format: vnd. android. NFC: // EXT/<domain_name >:< SERVICE_NAME> 。 |
|
Tnf_mime_media |
MIME type based on type fields |
|
Tnf_unchanged |
Degraded to intent object of action_tech_discovered type |
|
Tnf_unknown |
Degraded to intent object of action_tech_discovered type |
|
Tnf_well_known |
Depends on the MIME type or Uri of the record type definition (RTD) you set in the Type field, |
Table 2. RTD and Their ing supported by tnf_well_known
|
Record type definition (RTD) |
Ing |
|
Rtd_alternative_carrier |
Degraded to intent object of action_tech_discovered type |
|
Rtd_handover_carrier |
Degraded to intent object of action_tech_discovered type |
|
Rtd_handover_request |
Degraded to intent object of action_tech_discovered type |
|
Rtd_handover_select |
Degraded to intent object of action_tech_discovered type |
|
Rtd_smart_poster |
Server Load balancer-based URI |
|
Rtd_text |
Text/plain mime |
|
Rtd_uri |
Payload-based URI |