| page.title=NFC Basics |
| @jd:body |
| |
| |
| <div id="qv-wrapper"> |
| <div id="qv"> |
| <h2>In this document</h2> |
| <ol> |
| <li><a href="#tag-dispatch">The Tag Dispatch System</a> |
| <ol> |
| <li><a href="#ndef">How NFC tags are mapped to MIME types and URIs</a></li> |
| <li><a href="#dispatching">How NFC Tags are Dispatched to Applications</a></li> |
| </ol> |
| </li> |
| <li><a href="#manifest">Requesting NFC Access in the Android Manifest</a></li> |
| <li><a href="#filtering-intents">Filtering for Intents</a> |
| <ol> |
| <li><a href="#ndef-disc">ACTION_NDEF_DISCOVERED</a></li> |
| <li><a href="#tech-disc">ACTION_TECH_DISCOVERED</a></li> |
| <li><a href="#tag-disc">ACTION_TAG_DISCOVERED</a></li> |
| <li><a href="#obtain-info">Obtaining information from intents</a></li> |
| </ol> |
| </li> |
| <li><a href="#creating-records">Creating Common Types of NDEF Records</a> |
| <ol> |
| <li><a href="#abs-uri">TNF_ABSOLUTE_URI</a></li> |
| <li><a href="#mime">TNF_MIME_MEDIA</a></li> |
| <li><a href="#well-known-text">TNF_WELL_KNOWN with RTD_TEXT</a></li> |
| <li><a href="#well-known-uri">TNF_WELL_KNOWN with RTD_URI</a></li> |
| <li><a href="#ext-type">TNF_EXTERNAL_TYPE</a></li> |
| <li><a href="#aar">Android Application Records</a></li> |
| </ol> |
| </li> |
| <li><a href="#p2p">Beaming NDEF Messages to Other Devices</a></li> |
| </ol> |
| </div> |
| </div> |
| |
| <p>This document describes the basic NFC tasks you perform in Android. It explains how to send and |
| receive NFC data in the form of NDEF messages and describes the Android framework APIs that support |
| these features. For more advanced topics, including a discussion of working with non-NDEF data, |
| see <a href="{@docRoot}guide/topics/nfc/advanced-nfc.html">Advanced NFC</a>.</p> |
| |
| |
| <p>There are two major uses cases when working with NDEF data and Android:</p> |
| |
| <ul> |
| <li>Reading NDEF data from an NFC tag</li> |
| <li>Beaming NDEF messages from one device to another with <a href="#p2p">Android |
| Beam™</a></li> |
| </ul> |
| |
| |
| <p>Reading NDEF data from an NFC tag is handled with the <a href="#tag-dispatch">tag dispatch |
| system</a>, which analyzes discovered NFC tags, appropriately categorizes the data, and starts |
| an application that is interested in the categorized data. An application that wants to handle the |
| scanned NFC tag can <a href="#filtering-intents">declare an intent filter</a> and |
| request to handle the data.</p> |
| |
| <p>The Android Beam™ feature allows a device to push an NDEF message onto |
| another device by physically tapping the devices together. This interaction provides an easier way |
| to send data than other wireless technologies like Bluetooth, because with NFC, no manual device |
| discovery or pairing is required. The connection is automatically started when two devices come |
| into range. Android Beam is available through a set of NFC APIs, so any application can transmit |
| information between devices. For example, the Contacts, Browser, and YouTube applications use |
| Android Beam to share contacts, web pages, and videos with other devices. |
| </p> |
| |
| |
| <h2 id="tag-dispatch">The Tag Dispatch System</h2> |
| |
| <p>Android-powered devices are usually looking for NFC tags when the screen |
| is unlocked, unless NFC is disabled in the device's Settings menu. |
| When an Android-powered device discovers an NFC tag, the desired behavior |
| is to have the most appropriate activity handle the intent without asking the user what application |
| to use. Because devices scan NFC tags at a very short range, it is likely that making users manually |
| select an activity would force them to move the device away from the tag and break the connection. |
| You should develop your activity to only handle the NFC tags that your activity cares about to |
| prevent the Activity Chooser from appearing.</p> |
| |
| <p>To help you with this goal, Android provides a special tag dispatch system that analyzes scanned |
| NFC tags, parses them, and tries to locate applications that are interested in the scanned data. It |
| does this by:</p> |
| |
| <ol> |
| <li>Parsing the NFC tag and figuring out the MIME type or a URI that identifies the data payload |
| in the tag.</li> |
| <li>Encapsulating the MIME type or URI and the payload into an intent. These first two |
| steps are described in <a href="#ndef">How NFC tags are mapped to MIME types and URIs</a>.</li> |
| <li>Starts an activity based on the intent. This is described in |
| <a href="#dispatching">How NFC Tags are Dispatched to Applications</a>.</li> |
| </ol> |
| |
| <h3 id="ndef">How NFC tags are mapped to MIME types and URIs</h3> |
| <p>Before you begin writing your NFC applications, it is important to understand the different |
| types of NFC tags, how the tag dispatch system parses NFC tags, and the special work that the tag |
| dispatch system does when it detects an NDEF message. NFC tags come in a |
| wide array of technologies and can also have data written to them in many different ways. |
| Android has the most support for the NDEF standard, which is defined by the <a |
| href="http://www.nfc-forum.org/home">NFC Forum</a>. |
| </p> |
| |
| <p>NDEF data is encapsulated inside a message ({@link android.nfc.NdefMessage}) that contains one |
| or more records ({@link android.nfc.NdefRecord}). Each NDEF record must be well-formed according to |
| the specification of the type of record that you want to create. Android |
| also supports other types of tags that do not contain NDEF data, which you can work with by using |
| the classes in the {@link android.nfc.tech} package. To learn more |
| about these technologies, see the <a href="{@docRoot}guide/topics/nfc/advanced-nfc.html">Advanced |
| NFC</a> topic. Working with these other types of tags involves |
| writing your own protocol stack to communicate with the tags, so we recommend using NDEF when |
| possible for ease of development and maximum support for Android-powered devices. |
| </p> |
| |
| <p class="note"><strong>Note:</strong> |
| To download complete NDEF specifications, go to the <a |
| href="http://www.nfc-forum.org/specs/spec_license">NFC Forum Specification Download</a> site and see |
| <a href="#creating-records">Creating common types of NDEF records</a> for examples of how to |
| construct NDEF records. </p> |
| |
| <p>Now that you have some background in NFC tags, the following sections describe in more detail how |
| Android handles NDEF formatted tags. When an Android-powered device scans an NFC tag containing NDEF |
| formatted data, it parses the message and tries to figure out the data's MIME type or identifying |
| URI. To do this, the system reads the first {@link android.nfc.NdefRecord} inside the {@link |
| android.nfc.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 {@link android.nfc.NdefRecord} |
| contains the following fields: |
| <dl> |
| <dt><strong>3-bit TNF (Type Name Format)</strong></dt> |
| <dd>Indicates how to interpret the variable length type field. Valid values are described in |
| described in <a href="#table1">Table 1</a>.</dd> |
| |
| <dt><strong>Variable length type</strong></dt> |
| <dd>Describes the type of the record. If using {@link android.nfc.NdefRecord#TNF_WELL_KNOWN}, use |
| this field to specify the Record Type Definition (RTD). Valid RTD values are described in <a |
| href="#table2">Table 2</a>.</dd> |
| |
| <dt><strong>Variable length ID</strong></dt> |
| <dd>A unique identifier for the record. This field is not used often, but |
| if you need to uniquely identify a tag, you can create an ID for it.</dd> |
| |
| <dt><strong>Variable length payload</strong></dt> |
| <dd>The actual data payload that you want to read or write. An NDEF |
| message can contain multiple NDEF records, so don't assume the full payload is in the first NDEF |
| record of the NDEF message.</dd> |
| |
| </dl> |
| |
| <p>The tag dispatch system uses the TNF and type fields to try to map a MIME type or URI to the |
| NDEF message. If successful, it encapsulates that information inside of a {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} intent along with the actual payload. However, there |
| are cases when the tag dispatch system cannot determine the type of data based on the first NDEF |
| record. This happens when the NDEF data cannot be mapped to a MIME type or URI, or when the |
| NFC tag does not contain NDEF data to begin with. In such cases, a {@link |
| android.nfc.Tag} object that has information about the tag's technologies and the payload are |
| encapsulated inside of a {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} intent instead.</p> |
| |
| <p> |
| <a href="#table1">Table 1.</a> describes how the tag dispatch system maps TNF and type |
| fields to MIME types or URIs. It also describes which TNFs cannot be mapped to a MIME type or URI. |
| In these cases, the tag dispatch system falls back to |
| {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}. |
| |
| <p>For example, if the tag dispatch system encounters a record of type {@link |
| android.nfc.NdefRecord#TNF_ABSOLUTE_URI}, it maps the variable length type field of that record |
| into a URI. The tag dispatch system encapsulates that URI in the data field of an {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} intent along with other information about the tag, |
| such as the payload. On the other hand, if it encounters a record of type {@link |
| android.nfc.NdefRecord#TNF_UNKNOWN}, it creates an intent that encapsulates the tag's technologies |
| instead.</p> |
| |
| |
| <p class="table-caption" id="table1"> |
| <strong>Table 1.</strong> Supported TNFs and their mappings</p> |
| <table id="mappings"> |
| <tr> |
| <th>Type Name Format (TNF)</th> |
| <th>Mapping</th> |
| </tr> |
| <tr> |
| <td>{@link android.nfc.NdefRecord#TNF_ABSOLUTE_URI}</td> |
| <td>URI based on the type field.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_EMPTY}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_EXTERNAL_TYPE}</td> |
| <td>URI based on the URN in the type field. The URN is encoded into the NDEF type field in |
| a shortened form: <code><em><domain_name>:<service_name></em></code>. |
| Android maps this to a URI in the form: |
| <code>vnd.android.nfc://ext/<em><domain_name>:<service_name></em></code>.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_MIME_MEDIA}</td> |
| <td>MIME type based on the type field.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_UNCHANGED}</td> |
| <td>Invalid in the first record, so falls back to |
| {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_UNKNOWN}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#TNF_WELL_KNOWN}</td> |
| <td>MIME type or URI depending on the Record Type Definition (RTD), which you set in the |
| type field. See <a href="#well_known">Table 2.</a> for more information on |
| available RTDs and their mappings.</td> |
| </tr> |
| </table> |
| |
| <p class="table-caption" id="table2"> |
| <strong>Table 2.</strong> Supported RTDs for TNF_WELL_KNOWN and their |
| mappings</p> |
| <table id="well-known"> |
| <tr> |
| <th>Record Type Definition (RTD)</th> |
| <th>Mapping</th> |
| </tr> |
| <tr> |
| <td>{@link android.nfc.NdefRecord#RTD_ALTERNATIVE_CARRIER}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_HANDOVER_CARRIER}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_HANDOVER_REQUEST}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_HANDOVER_SELECT}</td> |
| <td>Falls back to {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_SMART_POSTER}</td> |
| <td>URI based on parsing the payload.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_TEXT}</td> |
| <td>MIME type of <code>text/plain</code>.</td> |
| </tr> |
| <td>{@link android.nfc.NdefRecord#RTD_URI}</td> |
| <td>URI based on payload.</td> |
| </tr> |
| </table> |
| |
| <h3 id="dispatching">How NFC Tags are Dispatched to Applications</h3> |
| |
| <p>When the tag dispatch system is done creating an intent that encapsulates the NFC tag and its |
| identifying information, it sends the intent to an interested application that |
| filters for the intent. If more than one application can handle the intent, the Activity Chooser |
| is presented so the user can select the Activity. The tag dispatch system defines three intents, |
| which are listed in order of highest to lowest priority:</p> |
| |
| <ol> |
| <li> |
| {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED}: This intent is used to start an |
| Activity when a tag that contains an NDEF payload is scanned and is of a recognized type. This is |
| the highest priority intent, and the tag dispatch system tries to start an Activity with this |
| intent before any other intent, whenever possible. |
| </li> |
| |
| <li>{@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}: If no activities register to |
| handle the {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} |
| intent, the tag dispatch system tries to start an application with this intent. This |
| intent is also directly started (without starting {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} first) if the tag that is scanned |
| contains NDEF data that cannot be mapped to a MIME type or URI, or if the tag does not contain NDEF |
| data but is of a known tag technology. |
| </li> |
| |
| <li>{@link android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED}: This intent is started |
| if no activities handle the {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} or {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} |
| intents.</li> |
| </ol> |
| |
| <p>The basic way the tag dispatch system works is as follows:</p> |
| |
| <ol> |
| <li>Try to start an Activity with the intent that was created by the tag dispatch system |
| when parsing the NFC tag (either |
| {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} or {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}).</li> |
| <li>If no activities filter for that intent, try to start an Activity with the next |
| lowest priority intent (either {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} or {@link |
| android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED}) until an application filters for the |
| intent or until the tag dispatch system tries all possible intents.</li> |
| <li>If no applications filter for any of the intents, do nothing.</li> |
| </ol> |
| |
| <img src="{@docRoot}images/nfc_tag_dispatch.png" /> |
| |
| <p class="figure"><strong>Figure 1. </strong> Tag Dispatch System</p> |
| |
| |
| <p>Whenever possible, work with NDEF messages and the {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} intent, because it is the most specific out of |
| the three. This intent allows you to start your application at a more appropriate time than the |
| other two intents, giving the user a better experience.</p> |
| |
| <h2 id="manifest">Requesting NFC Access in the Android Manifest</h2> |
| |
| <p>Before you can access a device's NFC hardware and properly handle NFC intents, declare these |
| items in your <code>AndroidManifest.xml</code> file:</p> |
| |
| <ul> |
| <li>The NFC <code><uses-permission></code> element to access the NFC hardware: |
| <pre> |
| <uses-permission android:name="android.permission.NFC" /> |
| </pre> |
| </li> |
| |
| <li>The minimum SDK version that your application can support. API level 9 only supports |
| limited tag dispatch via {@link android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED}, and only gives |
| access to NDEF messages via the {@link android.nfc.NfcAdapter#EXTRA_NDEF_MESSAGES} extra. No |
| other tag properties or I/O operations are accessible. API level 10 |
| includes comprehensive reader/writer support as well as foreground NDEF pushing, and API level |
| 14 provides an easier way to push NDEF messages to other devices with Android Beam and extra |
| convenience methods to create NDEF records. |
| <pre class="pretty-print"> |
| <uses-sdk android:minSdkVersion="10"/> |
| </pre> |
| </li> |
| |
| <li>The <code>uses-feature</code> element so that your application shows up in Google |
| Play only for devices that have NFC hardware: |
| <pre> |
| <uses-feature android:name="android.hardware.nfc" android:required="true" /> |
| </pre> |
| <p>If your application uses NFC functionality, but that functionality is not crucial to your |
| application, you can omit the <code>uses-feature</code> element and check for NFC avalailbility at |
| runtime by checking to see if {@link android.nfc.NfcAdapter#getDefaultAdapter getDefaultAdapter()} |
| is <code>null</code>.</p> |
| </li> |
| </ul> |
| |
| <h2 id="filtering-intents">Filtering for NFC Intents</h2> |
| |
| <p>To start your application when an NFC tag that you want to handle is scanned, your application |
| can filter for one, two, or all three of the NFC intents in the Android manifest. However, you |
| usually want to filter for the {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} intent for the |
| most control of when your application starts. The {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} intent is a fallback for {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} when no applications filter for |
| {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} or for when the payload is not |
| NDEF. Filtering for {@link android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED} is usually too general of a |
| category to filter on. Many applications will filter for {@link |
| android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} or {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} before {@link |
| android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED}, so your application has a low probability of |
| starting. {@link android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED} is only available as a last resort |
| for applications to filter for in the cases where no other applications are installed to handle the |
| {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} or {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED}intent.</p> |
| |
| <p>Because NFC tag deployments vary and are many times not under your control, this is not always |
| possible, which is why you can fallback to the other two intents when necessary. When you have |
| control over the types of tags and data written, it is recommended that you use NDEF to format your |
| tags. The following sections describe how to filter for each type of intent.</p> |
| |
| |
| <h3 id="ndef-disc">ACTION_NDEF_DISCOVERED</h3> |
| <p> |
| To filter for {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} intents, declare the |
| intent filter along with the type of data that you want to filter for. The |
| following example filters for {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} |
| intents with a MIME type of <code>text/plain</code>: |
| </p> |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED"/> |
| <category android:name="android.intent.category.DEFAULT"/> |
| <data android:mimeType="text/plain" /> |
| </intent-filter> |
| </pre> |
| <p>The following example filters for a URI in the form of |
| <code>http://developer.android.com/index.html</code>. |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED"/> |
| <category android:name="android.intent.category.DEFAULT"/> |
| <data android:scheme="http" |
| android:host="developer.android.com" |
| android:pathPrefix="/index.html" /> |
| </intent-filter> |
| </pre> |
| |
| |
| <h3 id="tech-disc">ACTION_TECH_DISCOVERED</h3> |
| |
| <p>If your activity filters for the {@link android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} intent, |
| you must create an XML resource file that specifies the technologies that your activity supports |
| within a <code>tech-list</code> set. Your activity is |
| considered a match if a <code>tech-list</code> set is a subset of the technologies that are |
| supported by the tag, which you can obtain by calling {@link android.nfc.Tag#getTechList |
| getTechList()}.</p> |
| |
| <p>For example, if the tag that is scanned supports MifareClassic, NdefFormatable, and NfcA, your |
| <code>tech-list</code> set must specify all three, two, or one of the technologies (and nothing |
| else) in order for your activity to be matched.</p> |
| |
| <p>The following sample defines all of the technologies. You can remove the ones that you do not |
| need. Save this file (you can name it anything you wish) in the |
| <code><project-root>/res/xml</code> folder.</p> |
| <pre> |
| <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> |
| <tech-list> |
| <tech>android.nfc.tech.IsoDep</tech> |
| <tech>android.nfc.tech.NfcA</tech> |
| <tech>android.nfc.tech.NfcB</tech> |
| <tech>android.nfc.tech.NfcF</tech> |
| <tech>android.nfc.tech.NfcV</tech> |
| <tech>android.nfc.tech.Ndef</tech> |
| <tech>android.nfc.tech.NdefFormatable</tech> |
| <tech>android.nfc.tech.MifareClassic</tech> |
| <tech>android.nfc.tech.MifareUltralight</tech> |
| </tech-list> |
| </resources> |
| </pre> |
| |
| <p>You can also specify multiple <code>tech-list</code> sets. Each of the <code>tech-list</code> |
| sets is considered independently, and your activity is considered a match if any single |
| <code>tech-list</code> set is a subset of the technologies that are returned by {@link |
| android.nfc.Tag#getTechList getTechList()}. This provides <code>AND</code> and <code>OR</code> |
| semantics for matching technologies. The following example matches tags that can support the |
| NfcA and Ndef technologies or can support the NfcB and Ndef technologies:</p> |
| <pre> |
| <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> |
| <tech-list> |
| <tech>android.nfc.tech.NfcA</tech> |
| <tech>android.nfc.tech.Ndef</tech> |
| </tech-list> |
| </resources> |
| |
| <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"> |
| <tech-list> |
| <tech>android.nfc.tech.NfcB</tech> |
| <tech>android.nfc.tech.Ndef</tech> |
| </tech-list> |
| </resources> |
| </pre> |
| |
| <p>In your <code>AndroidManifest.xml</code> file, specify the resource file that you just created |
| in the <code><meta-data></code> element inside the <code><activity></code> |
| element like in the following example:</p> |
| <pre> |
| <activity> |
| ... |
| <intent-filter> |
| <action android:name="android.nfc.action.TECH_DISCOVERED"/> |
| </intent-filter> |
| |
| <meta-data android:name="android.nfc.action.TECH_DISCOVERED" |
| android:resource="@xml/nfc_tech_filter" /> |
| ... |
| </activity> |
| </pre> |
| |
| <p>For more information about working with tag technologies and the {@link |
| android.nfc.NfcAdapter#ACTION_TECH_DISCOVERED} intent, see <a |
| href="{@docRoot}guide/topics/nfc/advanced-nfc.html#tag-tech">Working with Supported Tag |
| Technologies</a> in the Advanced NFC document.</p> |
| <h3 id="tag-disc">ACTION_TAG_DISCOVERED</h3> |
| <p>To filter for {@link android.nfc.NfcAdapter#ACTION_TAG_DISCOVERED} use the following intent |
| filter:</p> |
| |
| |
| <pre><intent-filter> |
| <action android:name="android.nfc.action.TAG_DISCOVERED"/> |
| </intent-filter> |
| </pre> |
| |
| |
| |
| <h3 id="obtain-info">Obtaining information from intents</h3> |
| |
| <p>If an activity starts because of an NFC intent, you can obtain information about the scanned NFC |
| tag from the intent. Intents can contain the following extras depending on the tag that was scanned: |
| |
| <ul> |
| <li>{@link android.nfc.NfcAdapter#EXTRA_TAG} (required): A {@link android.nfc.Tag} object |
| representing the scanned tag.</li> |
| <li>{@link android.nfc.NfcAdapter#EXTRA_NDEF_MESSAGES} (optional): An array of NDEF messages |
| parsed from the tag. This extra is mandatory on {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED |
| intents.</li> |
| <li>{@link android.nfc.NfcAdapter#EXTRA_ID} (optional): The low-level ID of the tag.</li></ul> |
| |
| <p>To obtain these extras, check to see if your activity was launched with one of |
| the NFC intents to ensure that a tag was scanned, and then obtain the extras out of the |
| intent. The following example checks for the {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED} |
| intent and gets the NDEF messages from an intent extra.</p> |
| |
| <pre> |
| public void onResume() { |
| super.onResume(); |
| ... |
| if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) { |
| Parcelable[] rawMsgs = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES); |
| if (rawMsgs != null) { |
| msgs = new NdefMessage[rawMsgs.length]; |
| for (int i = 0; i < rawMsgs.length; i++) { |
| msgs[i] = (NdefMessage) rawMsgs[i]; |
| } |
| } |
| } |
| //process the msgs array |
| } |
| </pre> |
| |
| <p>Alternatively, you can obtain a {@link android.nfc.Tag} object from the intent, which will |
| contain the payload and allow you to enumerate the tag's technologies:</p> |
| |
| <pre>Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);</pre> |
| |
| |
| <h2 id="creating-records">Creating Common Types of NDEF Records</h2> |
| <p>This section describes how to create common types of NDEF records to help you when writing to |
| NFC tags or sending data with Android Beam. It also describes how to create the corresponding |
| intent filter for the record. All of these NDEF record examples should be in the first NDEF |
| record of the NDEF message that you are writing to a tag or beaming.</p> |
| |
| <h3 id="abs-uri">TNF_ABSOLUTE_URI</h3> |
| <p>Given the following {@link android.nfc.NdefRecord#TNF_ABSOLUTE_URI} NDEF record, which is |
| stored as the first record inside of an {@link android.nfc.NdefMessage}:</p> |
| |
| <pre> |
| NdefRecord uriRecord = new NdefRecord( |
| NdefRecord.TNF_ABSOLUTE_URI , |
| "http://developer.android.com/index.html".getBytes(Charset.forName("US-ASCII")), |
| new byte[0], new byte[0]); |
| </pre> |
| |
| <p>the intent filter would look like this:</p> |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| <data android:scheme="http" |
| android:host="developer.android.com" |
| android:pathPrefix="/index.html" /> |
| </intent-filter> |
| </pre> |
| |
| |
| <h3 id="mime">TNF_MIME_MEDIA</h3> |
| <p>Given the following {@link android.nfc.NdefRecord#TNF_MIME_MEDIA} NDEF record, which is stored as |
| the first record inside |
| of an {@link android.nfc.NdefMessage}:</p> |
| <pre> |
| NdefRecord mimeRecord = new NdefRecord( |
| NdefRecord.TNF_MIME_MEDIA , |
| "application/com.example.android.beam".getBytes(Charset.forName("US-ASCII")), |
| new byte[0], "Beam me up, Android!".getBytes(Charset.forName("US-ASCII"))); |
| </pre> |
| |
| <p>the intent filter would look like this:</p> |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| <data android:mimeType="application/com.example.android.beam" /> |
| </intent-filter> |
| </pre> |
| |
| |
| <h3 id="well-known-text">TNF_WELL_KNOWN with RTD_TEXT</h3> |
| |
| <p>Given the following {@link android.nfc.NdefRecord#TNF_WELL_KNOWN} NDEF record, which is stored as |
| the first record inside of an {@link android.nfc.NdefMessage}:</p> |
| <pre> |
| public NdefRecord createTextRecord(String payload, Locale locale, boolean encodeInUtf8) { |
| byte[] langBytes = locale.getLanguage().getBytes(Charset.forName("US-ASCII")); |
| Charset utfEncoding = encodeInUtf8 ? Charset.forName("UTF-8") : Charset.forName("UTF-16"); |
| byte[] textBytes = payload.getBytes(utfEncoding); |
| int utfBit = encodeInUtf8 ? 0 : (1 << 7); |
| char status = (char) (utfBit + langBytes.length); |
| byte[] data = new byte[1 + langBytes.length + textBytes.length]; |
| data[0] = (byte) status; |
| System.arraycopy(langBytes, 0, data, 1, langBytes.length); |
| System.arraycopy(textBytes, 0, data, 1 + langBytes.length, textBytes.length); |
| NdefRecord record = new NdefRecord(NdefRecord.TNF_WELL_KNOWN, |
| NdefRecord.RTD_TEXT, new byte[0], data); |
| return record; |
| } |
| </pre> |
| |
| <p>the intent filter would look like this:</p> |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| <data android:mimeType="text/plain" /> |
| </intent-filter> |
| </pre> |
| |
| |
| <h3 id="well-known-uri">TNF_WELL_KNOWN with RTD_URI</h3> |
| |
| <p>Given the following {@link android.nfc.NdefRecord#TNF_WELL_KNOWN} NDEF record, which is stored as |
| the first record inside of an {@link android.nfc.NdefMessage}:</p> |
| |
| <pre> |
| byte[] uriField = "example.com".getBytes(Charset.forName("US-ASCII")); |
| byte[] payload = new byte[uriField.length + 1]; //add 1 for the URI Prefix |
| byte payload[0] = 0x01; //prefixes http://www. to the URI |
| System.arraycopy(uriField, 0, payload, 1, uriField.length); //appends URI to payload |
| NdefRecord rtdUriRecord = new NdefRecord( |
| NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, new byte[0], payload); |
| </pre> |
| |
| <p>the intent filter would look like this:</p> |
| |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| <data android:scheme="http" |
| android:host="example.com" |
| android:pathPrefix="" /> |
| </intent-filter> |
| </pre> |
| |
| <h3 id="ext-type">TNF_EXTERNAL_TYPE</h3> |
| <p>Given the following {@link android.nfc.NdefRecord#TNF_EXTERNAL_TYPE} NDEF record, which is stored |
| as the first record inside of an {@link android.nfc.NdefMessage}:</p> |
| |
| <pre> |
| byte[] payload; |
| ... |
| NdefRecord mimeRecord = new NdefRecord( |
| NdefRecord.TNF_EXTERNAL_TYPE, "example.com:externalType", new byte[0], payload); |
| </pre> |
| |
| <p>the intent filter would look like this:</p> |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED" /> |
| <category android:name="android.intent.category.DEFAULT" /> |
| <data android:scheme="vnd.android.nfc" |
| android:host="ext" |
| android:pathPrefix="/example.com:externalType"/> |
| </intent-filter> |
| </pre> |
| |
| |
| <p>Use TNF_EXTERNAL_TYPE for more generic NFC tag deployments to better support both |
| Android-powered and non-Android-powered devices.</p> |
| |
| <p class="note"><strong>Note</strong>: URNs for {@link |
| android.nfc.NdefRecord#TNF_EXTERNAL_TYPE} have a canonical format of: |
| <code>urn:nfc:ext:example.com:externalType</code>, however the NFC Forum RTD specification |
| declares that the <code>urn:nfc:ext:</code> portion of the URN must be ommitted from the |
| NDEF record. So all you need to provide is the domain (<code>example.com</code> in the example) |
| and type (<code>externalType</code> in the example) separated by a colon. |
| When dispatching TNF_EXTERNAL_TYPE, Android converts the <code>urn:nfc:ext:example.com:externalType</code> URN to a |
| <code>vnd.android.nfc://ext/example.com:externalType</code> URI, which is what the intent filter in the example |
| declares.</p> |
| |
| <h3 id="aar">Android Application Records</h3> |
| |
| <p> |
| Introduced in Android 4.0 (API level 14), an Android Application Record (AAR) provides a stronger |
| certainty that your application is started when an NFC tag is scanned. An AAR has the package name |
| of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message, |
| because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based |
| on the package name inside the AAR. If the application is not present on the device, |
| Google Play is launched to download the application.</p> |
| |
| <p>AARs are useful if you want to prevent other applications from filtering for the same intent and |
| potentially handling specific tags that you have deployed. AARs are only supported at the |
| application level, because of the package name constraint, and not at the Activity level as with |
| intent filtering. If you want to handle an intent at the Activity level, <a |
| href="#filtering-intents">use intent filters</a>. |
| </p> |
| |
| |
| |
| <p>If a tag contains an AAR, the tag dispatch system dispatches in the following manner:</p> |
| <ol> |
| <li>Try to start an Activity using an intent filter as normal. If the Activity that matches |
| the intent also matches the AAR, start the Activity.</li> |
| <li>If the Activity that filters for the intent does not match the |
| AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the |
| application specified by the AAR.</li> |
| <li>If no application can start with the AAR, go to Google Play to download the |
| application based on the AAR.</li> |
| </ol> |
| |
| </p> |
| |
| <p class="note"><strong>Note:</strong> You can override AARs and the intent dispatch system with the <a |
| href="{@docRoot}guide/topics/nfc/advanced-nfc.html#foreground-dispatch">foreground dispatch |
| system</a>, which allows a foreground activity to have priority when an NFC tag is discovered. |
| With this method, the activity must be in the foreground to |
| override AARs and the intent dispatch system.</p> |
| |
| <p>If you still want to filter for scanned tags that do not contain an AAR, you can declare |
| intent filters as normal. This is useful if your application is interested in other tags |
| that do not contain an AAR. For example, maybe you want to guarantee that your application handles |
| proprietary tags that you deploy as well as general tags deployed by third parties. Keep in mind |
| that AARs are specific to Android 4.0 devices or later, so when deploying tags, you most likely want |
| to use a combination of AARs and MIME types/URIs to support the widest range of devices. In |
| addition, when you deploy NFC tags, think about how you want to write your NFC tags to enable |
| support for the most devices (Android-powered and other devices). You can do this by |
| defining a relatively unique MIME type or URI to make it easier for applications to distinguish. |
| </p> |
| |
| <p>Android provides a simple API to create an AAR, |
| {@link android.nfc.NdefRecord#createApplicationRecord createApplicationRecord()}. All you need to |
| do is embed the AAR anywhere in your {@link android.nfc.NdefMessage}. You do not want |
| to use the first record of your {@link android.nfc.NdefMessage}, unless the AAR is the only |
| record in the {@link android.nfc.NdefMessage}. This is because the Android |
| system checks the first record of an {@link android.nfc.NdefMessage} to determine the MIME type or |
| URI of the tag, which is used to create an intent for applications to filter. The following code |
| shows you how to create an AAR:</p> |
| |
| <pre> |
| NdefMessage msg = new NdefMessage( |
| new NdefRecord[] { |
| ..., |
| NdefRecord.createApplicationRecord("com.example.android.beam")} |
| </pre> |
| |
| |
| <h2 id="p2p">Beaming NDEF Messages to Other Devices</h2> |
| |
| <p>Android Beam allows simple peer-to-peer data exchange between two Android-powered devices. The |
| application that wants to beam data to another device must be in the foreground and the device |
| receiving the data must not be locked. When the beaming device comes in close enough contact with a |
| receiving device, the beaming device displays the "Touch to Beam" UI. The user can then choose |
| whether or not to beam the message to the receiving device.</p> |
| |
| <p class="note"><strong>Note:</strong> Foreground NDEF pushing was available at API level 10, |
| which provides similar functionality to Android Beam. These APIs have since been deprecated, but |
| are available to support older devices. See {@link android.nfc.NfcAdapter#enableForegroundNdefPush |
| enableForegroundNdefPush()} for more information.</p> |
| |
| <p>You can enable Android Beam for your application by calling one of the two methods:</p> |
| <ul> |
| <li>{@link android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()}: Accepts an |
| {@link android.nfc.NdefMessage} to set as the message to beam. Automatically beams the message |
| when two devices are in close enough proximity.</li> |
| <li>{@link android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback()}: |
| Accepts a callback that contains a |
| {@link android.nfc.NfcAdapter.CreateNdefMessageCallback#createNdefMessage createNdefMessage()} |
| which is called when a device is in range to beam data to. The callback lets you create |
| the NDEF message only when necessary.</li> |
| </ul> |
| |
| <p>An activity can only push one NDEF message at a time, so {@link |
| android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback()} takes precedence |
| over {@link android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()} if both are set. To use |
| Android Beam, the following general guidelines must be met: |
| </p> |
| |
| <ul> |
| <li>The activity that is beaming the data must be in the foreground. Both devices must have |
| their screens unlocked.</li> |
| |
| <li>You must encapsulate the data that you are beaming in an {@link android.nfc.NdefMessage} |
| object.</li> |
| |
| <li>The NFC device that is receiving the beamed data must support the |
| <code>com.android.npp</code> NDEF push protocol or NFC Forum's SNEP (Simple NDEF Exchange |
| Protocol). The <code>com.android.npp</code> protocol is required for devices on API level 9 (Android |
| 2.3) to API level 13 (Android 3.2). <code>com.android.npp</code> and SNEP are both required on |
| API level 14 (Android 4.0) and later.</li> |
| </li> |
| </ul> |
| |
| <p class="note"><strong>Note:</strong> If your activity enables Android Beam and is |
| in the foreground, the standard intent dispatch system is disabled. However, if your activity also |
| enables <a href="{@docRoot}guide/topics/nfc/advanced-nfc.html#foreground-dispatch">foreground |
| dispatching</a>, then it can still scan tags that match the intent filters set in the foreground |
| dispatching.</p> |
| |
| <p>To enable Android Beam:</p> |
| |
| <ol> |
| <li>Create an {@link android.nfc.NdefMessage} that contains the {@link android.nfc.NdefRecord}s |
| that you want to push onto the other device.</li> |
| |
| <li>Call {@link |
| android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()} with a {@link |
| android.nfc.NdefMessage} or call {@link |
| android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback} passing in a {@link |
| android.nfc.NfcAdapter.CreateNdefMessageCallback} object in the <code>onCreate()</code> method of |
| your activity. These methods require at least one activity that you want to enable with Android |
| Beam, along with an optional list of other activities to activate. |
| |
| <p>In general, you normally use {@link |
| android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()} if your Activity only needs to |
| push the same NDEF message at all times, when two devices are in range to communicate. You use |
| {@link android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback} when your |
| application cares about the current context of the application and wants to push an NDEF message |
| depending on what the user is doing in your application.</p> |
| </li> |
| </ol> |
| |
| <p>The following sample shows how a simple activity calls {@link |
| android.nfc.NfcAdapter.CreateNdefMessageCallback} in the <code>onCreate()</code> method of an |
| activity (see <a href="{@docRoot}resources/samples/AndroidBeamDemo/index.html">AndroidBeamDemo</a> |
| for the complete sample). This example also has methods to help you create a MIME record:</p> |
| |
| <pre id="code-example"> |
| package com.example.android.beam; |
| |
| import android.app.Activity; |
| import android.content.Intent; |
| import android.nfc.NdefMessage; |
| import android.nfc.NdefRecord; |
| import android.nfc.NfcAdapter; |
| import android.nfc.NfcAdapter.CreateNdefMessageCallback; |
| import android.nfc.NfcEvent; |
| import android.os.Bundle; |
| import android.os.Parcelable; |
| import android.widget.TextView; |
| import android.widget.Toast; |
| import java.nio.charset.Charset; |
| |
| |
| public class Beam extends Activity implements CreateNdefMessageCallback { |
| NfcAdapter mNfcAdapter; |
| TextView textView; |
| |
| @Override |
| public void onCreate(Bundle savedInstanceState) { |
| super.onCreate(savedInstanceState); |
| setContentView(R.layout.main); |
| TextView textView = (TextView) findViewById(R.id.textView); |
| // Check for available NFC Adapter |
| mNfcAdapter = NfcAdapter.getDefaultAdapter(this); |
| if (mNfcAdapter == null) { |
| Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show(); |
| finish(); |
| return; |
| } |
| // Register callback |
| mNfcAdapter.setNdefPushMessageCallback(this, this); |
| } |
| |
| @Override |
| public NdefMessage createNdefMessage(NfcEvent event) { |
| String text = ("Beam me up, Android!\n\n" + |
| "Beam Time: " + System.currentTimeMillis()); |
| NdefMessage msg = new NdefMessage( |
| new NdefRecord[] { createMimeRecord( |
| "application/com.example.android.beam", text.getBytes()) |
| /** |
| * The Android Application Record (AAR) is commented out. When a device |
| * receives a push with an AAR in it, the application specified in the AAR |
| * is guaranteed to run. The AAR overrides the tag dispatch system. |
| * You can add it back in to guarantee that this |
| * activity starts when receiving a beamed message. For now, this code |
| * uses the tag dispatch system. |
| */ |
| //,NdefRecord.createApplicationRecord("com.example.android.beam") |
| }); |
| return msg; |
| } |
| |
| @Override |
| public void onResume() { |
| super.onResume(); |
| // Check to see that the Activity started due to an Android Beam |
| if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) { |
| processIntent(getIntent()); |
| } |
| } |
| |
| @Override |
| public void onNewIntent(Intent intent) { |
| // onResume gets called after this to handle the intent |
| setIntent(intent); |
| } |
| |
| /** |
| * Parses the NDEF Message from the intent and prints to the TextView |
| */ |
| void processIntent(Intent intent) { |
| textView = (TextView) findViewById(R.id.textView); |
| Parcelable[] rawMsgs = intent.getParcelableArrayExtra( |
| NfcAdapter.EXTRA_NDEF_MESSAGES); |
| // only one message sent during the beam |
| NdefMessage msg = (NdefMessage) rawMsgs[0]; |
| // record 0 contains the MIME type, record 1 is the AAR, if present |
| textView.setText(new String(msg.getRecords()[0].getPayload())); |
| } |
| |
| /** |
| * Creates a custom MIME type encapsulated in an NDEF record |
| */ |
| public NdefRecord createMimeRecord(String mimeType, byte[] payload) { |
| byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII")); |
| NdefRecord mimeRecord = new NdefRecord( |
| NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload); |
| return mimeRecord; |
| } |
| } |
| </pre> |
| |
| <p>Note that this code comments out an AAR, which you can remove. If you enable the AAR, the |
| application specified in the AAR always receives the Android Beam message. If the application is not |
| present, Google Play launches to download the application. Therefore, the following intent |
| filter is not technically necessary for Android 4.0 devices or later if the AAR is used: |
| </p> |
| |
| <pre> |
| <intent-filter> |
| <action android:name="android.nfc.action.NDEF_DISCOVERED"/> |
| <category android:name="android.intent.category.DEFAULT"/> |
| <data android:mimeType="application/com.example.android.beam"/> |
| </intent-filter> |
| </pre> |
| <p>With this intent filter, the <code>com.example.android.beam</code> application now can be started |
| when it scans an NFC tag or receives an Android Beam with an AAR of |
| type <code>com.example.android.beam</code>, or when an NDEF formatted message contains a MIME record |
| of type <code>application/com.example.android.beam</code>.</p> |
| |
| <p>Even though AARs guarantee an application is started or downloaded, intent filters are |
| recommended, because they let you start an Activity of your choice in your |
| application instead of always starting the main Activity within the package specified by an AAR. |
| AARs do not have Activity level granularity. Also, because some Android-powered devices do not |
| support AARs, you should also embed identifying information in the first NDEF record of your NDEF |
| messages and filter for that as well, just in case. See <a href="#creating-records">Creating Common |
| Types of NDEF records</a> for more information on how to create records. |
| </p> |