android nfc(官方翻译)

为了充分详细的学习nfc相关的知识，决定阅读官方英文文档，并翻译下来供大家阅读。

NFC Basics

There are two major uses cases when working with NDEF data and Android:

Reading NDEF data from an NFC tag

Beaming NDEF messages from one device to another with Android Beam?

The Tag Dispatch System

Parsing the NFC tag and figuring out the MIME type or a URI that identifies the data payload in the tag.

解析NFC标签，计算出MINE类型或者一个URI，用于标示数据负载的身份

Encapsulating the MIME type or URI and the payload into an intent. These first two steps are described in How NFC tags are mapped to MIME types and URIs.

封装MIME类型或者URI和负载放入intent对象，这两步由 How NFC tags are mapped to MIME types and URIs描述。

Starts an activity based on the intent. This is described in How NFC Tags are Dispatched to Applications.

启动一个activity根据这个intent对象，这部分由How NFC Tags are Dispatched to Applications.描述

How NFC tags are mapped to MIME types and URIs（NFC标签是如何映射到MINE类型和URI的？）

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 NFC Forum.

在你开始写NFC应用之前，理解不同类型的NFC标签，标签调度系统如何解析NFC标签，当标签调度系统检测到NDEC message所要做的特殊工作，NFC标签来着不同类型的技术，写入标签有不同的方式，Android推荐使用NDEF标准，它是由NFC社区发起的

NDEF data is encapsulated inside a message (NdefMessage) that contains one or more records (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 android.nfc.tech package. To learn more about these technologies, see the Advanced NFC 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.

NDEF数据封装在一个由多个NdefRecord组成的NdefMessage中，每一个NDEF记录必须是格式良好的根据你要创建的具体类型，Android也支持其他不包含NDEF数据的类型，你能够使用android.nfc.tech进行工作，为了学习这些技术，请看Advanced NFC topic，操作这些标签会牵涉到你自己的协议栈和标签进行交流，因此为了简化开发和最大化支持android设备，我们建议使用NDEF尽可能。

Note: To download complete NDEF specifications, go to the NFC Forum Specification Download site and see Creating common types of NDEF records for examples of how to construct NDEF records.

注意：为了下载完整的NDEF详情，去NFC社区下载然后阅读如何构建公共类型的NDEF记录的例子。

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 NdefRecord inside the 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 fields:

现在你要具有NFC标签的背景，如下部分描述如何如何处理NDEF格式标签的更多详情。当一个android支持的设别检测到NFC包含NDEF格式的标签后，解析里面的信息然后试图计算数据的MIME类型和URI身份，为了读取它，系统阅读NDEF信息的第一个记录然后说明整个NDEF信息（一个NDEF信息有多个NDEF记录），在一个格式良好的NDEF信息内，第一个NdefRecord包含如下字段：

3-bit TNF (Type Name Format)

Indicates how to interpret the variable length type field. Valid values are described in described in Table 1.

指明了如何解析可变长度字段，有效值被描述在表1.

Variable length type

Describes the type of the record. If using TNF_WELL_KNOWN, use this field to specify the Record Type Definition (RTD). Valid RTD values are described in Table 2.

详细record的类型，如有使用了TNF_WELL_KNOWN，使用这个字段具体得记录的类型，有效的RTD值被描述在表2。

Variable length ID

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.

record唯一的身份，这个字段不是经常使用的，除非你需要唯一确定一个标签，你可以为它创建一个ID

Variable length payload

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.

确切的你将要读写的数据的payload，一个DNEF message能包含大量的 NDEF records，所以不要假定所有的payload在NDEF message的第一个NDEF record。

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 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 Tag object that has information about the tag‘s technologies and the payload are encapsulated inside of a ACTION_TECH_DISCOVERED intent instead.

标签调度系统使用TNF和type字段尝试映射一个MIME类型或者URI到一个NDEF message。如果成功，它将封装信息进一个ACTION_NDEF_DISCOVERED的intent伴随了确切的payload，这儿关心当调度系统不能决定数据的类型根据第一个NDEF record，这个情况发生在当NDEF data不能映射到一个MIME类型或者一个URI或者当NFC标签不包含NDEF的头信息时，这些情况，一个标签对象的的信息技术和负载将由ACTION_TECH_DISCOVERED的intent取代

Table 1. 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 ACTION_TECH_DISCOVERED.

表1：描述标签调度系统映射TNF and type field到一个MIME类型或者URIs。它也描述了TNFs不能被映射的MIME类型和 URI，如果这样的话，标签调度系统将回落给ACTION_TECH_DISCOVERED

For example, if the tag dispatch system encounters a record of type 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 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 TNF_UNKNOWN, it creates an intent that encapsulates the tag‘s technologies instead.

例如：如果标签 调度系统检测到一个TNF_ABSOLUTE_URI类型的记录，它映射记录的the variable length type field到一个URI，标签调度系统封装URI数据和相应payload的到ACTION_NDEF_DISCOVEREDintent，另一个方面，如果遇到一个TNF_UNKNOWN的记录，它将创建一个tag‘s
technologies 封装取代（ACTION_TECH_DISCOVERED）。

Table 1. Supported TNFs and their mappings

Table 2. Supported RTDs for TNF_WELL_KNOWN and their mappings

How NFC Tags are Dispatched to Applications

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:

当标签调度系统完成创建一个封装了NFC标签和它的身份信息的Intent后，它将发送由过滤器过滤后的intent到对应的应用，如果一个intent有多个应用可以处理，用户根据Activity Chooser选择器选择启动的Activity，标签调度系统定义了三种intent类型，优先级由高到低。

Requesting NFC Access in the Android Manifest

Before you can access a device‘s NFC hardware and properly handle NFC intents, declare these items in your AndroidManifest.xml file:

The NFC <uses-permission> element to access the NFC hardware:

<uses-permission android:name="android.permission.NFC" />

The minimum SDK version that your application can support. API level 9 only supports limited tag dispatch via ACTION_TAG_DISCOVERED, and only gives access to NDEF messages via the 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.

api只包含有限的标签，需要通过ACTION_TAG_DISCOVERED调度，仅仅给了访问NDEF messages通过EXTRA_NDEF_MESSAGES 的extra，没有其他标签属性和I/O操作是可用的。api10包含了全部的读/写操作支持和前台NDEF推送
，api14包含了更简单的方式推送NDEF信息到其他的设备通过Android Beam和额外创建NDEF records便利的方法。

<uses-sdk android:minSdkVersion="10"/>

The uses-feature element so that your application shows up in Google Play only for devices that have NFC hardware:

声明该属性后Google Play将显示你的应用必须支持NFC设备：

<uses-feature android:name="android.hardware.nfc" android:required="true" />

If your application uses NFC functionality, but that functionality is not crucial to your application, you can omit the uses-feature element and check for NFC avalailbility at runtime by checking to see if getDefaultAdapter()
is null.

如果你的应用中的NFC功能不是主要的功能，可以忽略uses-feature元素，然后在代码中通过getDefaultAdapter()是否为null动态检测NFC的可用性。

Filtering for NFC Intents

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.

因为NFC标签部署变化的和很多时候不在你的控制之下，这个部署并不总是可用的所以你可以在必要时回调其他两种标签，当你拥有了以上几种类型标签的写操作时，建议使用NDEF格式化你的标签，以下部分描述如何过滤每种类型的intent

ACTION_NDEF_DISCOVERED：

To filter for 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 ACTION_NDEF_DISCOVERED intents with a MIME type of text/plain:

过滤ACTION_NDEF_DISCOVERED的intent，使用你想要过滤的数据类型的intent filter，如下使用text/plain类型的MIME进行过滤的ACTION_NDEF_DISCOVERED的intent：

<intent-filter>
    <action android:name="android.nfc.action.NDEF_DISCOVERED"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <data android:mimeType="text/plain" />
</intent-filter>

The following example filters for a URI in the form of http://developer.android.com/index.html

<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>

ACTION_TECH_DISCOVERED：

If your activity filters for the ACTION_TECH_DISCOVERED intent, you must create an XML resource file that specifies
the technologies that your activity supports within a tech-list set. Your activity is considered a match if a tech-list set is a subset of the technologies that are supported by the tag, which you can obtain by calling getTechList().

如果你的Activity过滤ACTION_TECH_DISCOVERED的intent，你必须创建一个XML资源文件，这个资源文件在一个tech-list集合中具体指定你的Activity支持的技术，你的Activity被认为是匹配的如果你的标签调用getTechList()返回的集合支持了tech-list集合中所列出的所有的技术。

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 <project-root>/res/xml folder.

如下例子定义了所有的技术，你可以移除你不需要的那些，保存这个文件在/res/xml文件夹下

<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>

You can also specify multiple tech-list sets. Each of the tech-list sets is considered independently, and your activity is considered a match if any single tech-list set is a subset of the technologies that are returned
by getTechList(). This provides AND and OR 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:

也可以指定多个 tech-list集合，每个 tech-list都是独立的，你的Activity调用getTechList()返回的技术同任何单一一个 tech-list
set中的技术全部匹配时才被认为是匹配的，两个文件是之间是OR关系，文件之内是AND关系。下面的例子匹配了支持NfcA and Ndef technologies的标签或者是NfcB and Ndef technologies技术的标签：

<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>

In your AndroidManifest.xml file, specify the resource file that you just created in the <meta-data> element inside the <activity> element like in the following example:

<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>

For more information about working with tag technologies and the ACTION_TECH_DISCOVERED intent, see Working with Supported Tag Technologies in the Advanced NFC document.

ACTION_TAG_DISCOVERED：

To filter for ACTION_TAG_DISCOVERED
use the following intent filter:

<intent-filter>

<action android:name="android.nfc.action.TAG_DISCOVERED"/>

</intent-filter>

Obtaining information
from intents

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:

如果由于一个NFC的Intent启动的Activity，你可以通过从被扫描到的intent获取信息，被扫描的intent可以包含如下extras：

EXTRA_TAG (required):
A Tag object representing the scanned tag.

EXTRA_NDEF_MESSAGES (optional): An array of NDEF messages parsed from the tag. This extra is mandatory on intents.

{@link android.nfc.NfcAdapter#EXTRA_ID (optional): The low-level ID of the tag.

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 ACTION_NDEF_DISCOVERED intent and gets the NDEF messages from an intent
extra.

为了获取这些extras，检测你的Activity通过一个NFC
intent被发起以确保一个标签被扫描到，然后从intent获取extras，如下例子检测ACTION_NDEF_DISCOVERED的intent然后从intent extra中获取NDEF messages。

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
}

Alternatively, you can obtain a Tag object from the intent, which will contain the payload and allow you to enumerate the tag‘s technologies:

另外，你可以获取一个标签对象，并从标签对象上可以获取payload并且允许你枚举出所有的tag‘s
technologies

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);

Creating Common Types of NDEF Records：

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. Starting with Android 4.0 (API level 14), the createUri() method is available to help you create URI records automatically. Starting in Android
4.1 (API level 16), createExternal() and createMime() are available to help you create MIME and external type NDEF records. Use these helper methods whenever possible to avoid mistakes when manually creating NDEF records.

这部分描述了创建公共的NDEF records当你需要写标签或发送数据到给一个Android Beam，从Android 4.0 (API level 14)起createUri()是可用的帮助你自动创建URI
records，从Android 4.1 (API level 16)起createExternal() and createMime()是可用的帮助你创建MIME and external type NDEF records，使用帮助方法尽可能来避免因为手动创建NDEF records时出现错误

This
section 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.

这部分描述了如何创建对应 intent
filter对应的record，所有这些NDEF record 例子都应该在你写标签或者beaming的NDEF message的第一个NDEF record

TNF_ABSOLUTE_URI：

Note:
We recommend that you use the RTD_URI type instead of TNF_ABSOLUTE_URI, because it is more efficient.

建议使用RTD_URI替代TNF_ABSOLUTE_URI

You
can create a TNF_ABSOLUTE_URI NDEF record in the following way:

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]);

The intent filter for the previous NDEF record would look like this:

<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>

TNF_MIME_MEDIA：

You
can create a TNF_MIME_MEDIA NDEF record in the following ways.

Using
the createMime() method:

NdefRecord mimeRecord = NdefRecord.createMime("application/vnd.com.example.android.beam",
    "Beam me up, Android".getBytes(Charset.forName("US-ASCII")));

Creating the NdefRecord manually:

NdefRecord mimeRecord = new NdefRecord(
    NdefRecord.TNF_MIME_MEDIA ,
    "application/vnd.com.example.android.beam".getBytes(Charset.forName("US-ASCII")),
    new byte[0], "Beam me up, Android!".getBytes(Charset.forName("US-ASCII")));

The intent filter for the previous NDEF records would look like this:

<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="application/vnd.com.example.android.beam" />
</intent-filter>

TNF_WELL_KNOWN with RTD_TEXT：

You
can create a TNF_WELL_KNOWN NDEF record in the following way:

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;
}

the intent filter would look like this:

<intent-filter>
    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="text/plain" />
</intent-filter>

TNF_WELL_KNOWN with RTD_URI：

You
can create a TNF_WELL_KNOWN NDEF record in the following ways.

Using
the createUri(String) method:

NdefRecord rtdUriRecord1 = NdefRecord.createUri("http://example.com");

Using the createUri(Uri) method:

Uri uri = new Uri("http://example.com");
NdefRecord rtdUriRecord2 = NdefRecord.createUri(uri);

Creating the NdefRecord manually:

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);

The intent filter for the previous NDEF records would look like this:

<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>

TNF_EXTERNAL_TYPE：

You
can create a TNF_EXTERNAL_TYPE NDEF record in the following ways:

Using
the createExternal() method:

byte[] payload; //assign to your data
String domain = "com.example"; //usually your app‘s package name
String type = "externalType";
NdefRecord extRecord = NdefRecord.createExternal(domain, type, payload);

Creating the NdefRecord manually:

byte[] payload;
...
NdefRecord extRecord = new NdefRecord(
    NdefRecord.TNF_EXTERNAL_TYPE, "com.example:externalType", new byte[0], payload);

The intent filter for the previous NDEF records would look like this:

<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="/com.example:externalType"/>
</intent-filter>

Use TNF_EXTERNAL_TYPE for more generic NFC tag deployments to better support both Android-powered and non-Android-powered devices.

Note:
URNs for TNF_EXTERNAL_TYPE have a canonical format of: urn:nfc:ext:example.com:externalType, however the NFC Forum RTD specification declares that the urn:nfc:ext: portion of the URN must be ommitted from the NDEF record. So all you need to provide is the
domain (example.com in the example) and type (externalType in the example) separated by a colon. When dispatching TNF_EXTERNAL_TYPE, Android converts the urn:nfc:ext:example.com:externalType URN to a vnd.android.nfc://ext/example.com:externalType URI, which
is what the intent filter in the example declares.

Android
Application Records

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.

Android
4.0 (API level 14)引进的，一个Android Application Record (AAR)提供了更强的功能，当你的NFC标签被扫描会启动你的应用，一个AAR由一个应用的包名被嵌入在NDEF record。你能增加一个AAR到NDEF里任何一个NDEF record因为Android搜索全部NDEF message中的AAR，如果找到了AAR，它就启动AAR中包名对应的应用，如果应用不存在你的设备中，Google Play会被发起来下载对应的应用。

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, use intent filters.

AAR是有用的对于你想防止其他应用过滤相同的intent，和其他应用处理你部署的具体的标签，因为AARs仅仅支持应用水平（由包名常量指定），不能被过滤由其他的应用通过intent
filtering，如果你想处理一个intent在Activity水平，使用intent filters。

If
a tag contains an AAR, the tag dispatch system dispatches in the following manner:

如果一个标签包含一个AAR，标签调度系统采用如下方式进行调度：

1.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.

试图使用intent
filter启动一个Activity正常情况下，如果由intent匹配的Activity也匹配AAR，启动Activity

2.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.

如果filter过滤的intent对应的Activity不匹配AAR，如果多个Activity能处理intent，或者没有应用能处理intent，启动由AAR具体指定的应用

3.If
no application can start with the AAR, go to Google Play to download the application based on the AAR.

如果没有AAR所指定的应用，将打开Google Play下载AAR指定的应用

Android provides a simple API to create an AAR, createApplicationRecord(). All you need to do is embed the AAR anywhere in your NdefMessage. You do not want to use the first record of your NdefMessage, unless the AAR is the only
record in the NdefMessage. This is because the Android system checks the first record of an 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:

android提供了一个简单的api，createApplicationRecord()创建AAR，你需要嵌入AAR在任何NdefMessage，你应该使用NdefMessage中的第一个record，除非NdefMessage只有一个record，因为android系统检查NdefMessage第一个record决定标签的MIME类型或者URI，那用来创建一个intent为应用来过滤，下面代码教你如何创建一个AAR：

NdefMessage msg = new NdefMessage(
        new NdefRecord[] {
            ...,
            NdefRecord.createApplicationRecord("com.example.android.beam")}

android nfc(官方翻译)