Эта страница переведена с помощью Cloud Translation API.

Основы NFC

В этом документе описываются основные задачи NFC, выполняемые в Android. В нём объясняется, как отправлять и получать данные NFC в виде сообщений NDEF, а также описываются API-интерфейсы Android, поддерживающие эти функции. Более сложные темы, включая обсуждение работы с данными, отличными от NDEF, см. в разделе Advanced NFC .

Считывание данных NDEF с NFC-метки осуществляется системой распределения меток , которая анализирует обнаруженные NFC-метки, соответствующим образом классифицирует данные и запускает приложение, заинтересованное в этих данных. Приложение, желающее обработать отсканированную NFC-метку, может объявить фильтр намерений и запросить обработку данных.

Система отправки тегов

Устройства на базе Android обычно ищут NFC-метки при разблокированном экране, если только NFC не отключено в меню настроек устройства. Когда устройство на базе Android обнаруживает NFC-метку, желаемое поведение — это чтобы наиболее подходящее действие обрабатывало намерение, не спрашивая пользователя, какое приложение использовать. Поскольку устройства сканируют NFC-метки на очень коротком расстоянии, вероятно, если заставить пользователя вручную выбрать действие, ему придётся отодвинуть устройство от метки и разорвать соединение. Вам следует разработать действие так, чтобы оно обрабатывало только нужные ему NFC-метки, чтобы предотвратить появление окна выбора действий.

Чтобы помочь вам в этом, Android предоставляет специальную систему отправки меток, которая анализирует отсканированные NFC-метки, разбирает их и пытается найти приложения, которым нужны отсканированные данные. Это происходит следующим образом:

Анализ тега NFC и определение типа MIME или URI, идентифицирующего полезную нагрузку данных в теге.
Инкапсуляция типа MIME или URI и полезной нагрузки в намерение. Первые два шага описаны в разделе «Как NFC-теги сопоставляются с типами MIME и URI» .
Запускает действие на основе намерения. Это описано в разделе «Как NFC-метки передаются в приложения» .

Как теги NFC сопоставляются с типами MIME и URI

Прежде чем приступить к написанию NFC-приложений, важно понимать различные типы NFC-меток, как система отправки меток анализирует NFC-метки и какую особую работу выполняет система отправки меток при обнаружении сообщения NDEF. NFC-метки выпускаются с использованием самых разных технологий и могут записывать данные различными способами. Android обеспечивает наибольшую поддержку стандарта NDEF, разработанного NFC Forum .

Данные NDEF инкапсулируются в сообщение ( NdefMessage ), содержащее одну или несколько записей ( NdefRecord ). Каждая запись NDEF должна быть правильно сформирована в соответствии со спецификацией типа записи, которую вы хотите создать. Android также поддерживает другие типы тегов, не содержащие данных NDEF. С ними можно работать, используя классы из пакета android.nfc.tech . Подробнее об этих технологиях см. в разделе «Расширенные возможности NFC» . Работа с этими типами тегов требует написания собственного стека протоколов для взаимодействия с ними, поэтому мы рекомендуем по возможности использовать NDEF для простоты разработки и максимальной поддержки устройств на базе Android.

Примечание: Чтобы загрузить полные спецификации NDEF, перейдите на сайт спецификаций и документов по применению NFC Forum и ознакомьтесь с разделом Создание распространенных типов записей NDEF , где приведены примеры создания записей NDEF.

Теперь, когда вы немного знакомы с NFC-тегами, в следующих разделах более подробно описывается, как Android обрабатывает теги в формате NDEF. Когда устройство на базе Android сканирует NFC-тег, содержащий данные в формате NDEF, оно анализирует сообщение и пытается определить MIME-тип данных или идентифицирующий URI. Для этого система считывает первую NdefRecord в NdefMessage , чтобы определить, как интерпретировать всё сообщение NDEF (сообщение NDEF может содержать несколько записей NDEF). В правильно сформированном сообщении NDEF первая запись NdefRecord содержит следующие поля:

3-битный TNF (формат имени типа): Указывает, как интерпретировать поле типа переменной длины. Допустимые значения описаны в таблице 1 .
Тип переменной длины: Описывает тип записи. При использовании TNF_WELL_KNOWN используйте это поле для указания определения типа записи (RTD). Допустимые значения RTD описаны в таблице 2 .
Идентификатор переменной длины: Уникальный идентификатор записи. Это поле используется нечасто, но если вам нужно однозначно идентифицировать тег, вы можете создать для него идентификатор.
Полезная нагрузка переменной длины: Фактические данные, которые вы хотите прочитать или записать. Сообщение NDEF может содержать несколько записей NDEF, поэтому не стоит предполагать, что вся полезная нагрузка находится в первой записи NDEF сообщения NDEF.

Система отправки тегов использует поля TNF и type для сопоставления типа MIME или URI с сообщением NDEF. В случае успеха она инкапсулирует эту информацию в намерение ACTION_NDEF_DISCOVERED вместе с фактической полезной нагрузкой. Однако бывают случаи, когда система отправки тегов не может определить тип данных на основе первой записи NDEF. Это происходит, когда данные NDEF невозможно сопоставить с типом MIME или URI, или когда NFC-тег изначально не содержит данных NDEF. В таких случаях объект Tag , содержащий информацию о технологиях тега и полезной нагрузке, инкапсулируется в намерение ACTION_TECH_DISCOVERED .

В таблице 1 описано, как система распределения тегов сопоставляет поля TNF и типа с типами MIME или URI. Также указано, какие TNF не могут быть сопоставлены с типами MIME или URI. В этих случаях система распределения тегов возвращается к ACTION_TECH_DISCOVERED .

Например, если система диспетчеризации тегов обнаруживает запись типа TNF_ABSOLUTE_URI , она сопоставляет поле переменной длины этой записи с URI. Система диспетчеризации тегов инкапсулирует этот URI в поле данных намерения ACTION_NDEF_DISCOVERED вместе с другой информацией о теге, например, о его полезной нагрузке. С другой стороны, если система обнаруживает запись типа TNF_UNKNOWN , она создаёт намерение, которое инкапсулирует технологии тега.

Таблица 1. Поддерживаемые TNF и их сопоставления

Формат имени типа (TNF)	Картографирование
`TNF_ABSOLUTE_URI`	URI на основе поля типа.
`TNF_EMPTY`	Возвращается к `ACTION_TECH_DISCOVERED` .
`TNF_EXTERNAL_TYPE`	URI, основанный на URN в поле типа. URN кодируется в поле типа NDEF в сокращённой форме: `<domain_name>:<service_name>` . Android сопоставляет его с URI вида: `vnd.android.nfc://ext/ <domain_name>:<service_name>` .
`TNF_MIME_MEDIA`	Тип MIME на основе поля типа.
`TNF_UNCHANGED`	Недействительно в первой записи, поэтому возвращается к `ACTION_TECH_DISCOVERED` .
`TNF_UNKNOWN`	Возвращается к `ACTION_TECH_DISCOVERED` .
`TNF_WELL_KNOWN`	Тип MIME или URI зависит от определения типа записи (RTD), заданного в поле «Тип». Дополнительную информацию о доступных RTD и их сопоставлениях см. в таблице 2 .

Таблица 2. Поддерживаемые RTD для TNF_WELL_KNOWN и их сопоставления

Определение типа записи (RTD)	Картографирование
`RTD_ALTERNATIVE_CARRIER`	Возвращается к `ACTION_TECH_DISCOVERED` .
`RTD_HANDOVER_CARRIER`	Возвращается к `ACTION_TECH_DISCOVERED` .
`RTD_HANDOVER_REQUEST`	Возвращается к `ACTION_TECH_DISCOVERED` .
`RTD_HANDOVER_SELECT`	Возвращается к `ACTION_TECH_DISCOVERED` .
`RTD_SMART_POSTER`	URI на основе анализа полезной нагрузки.
`RTD_TEXT`	Тип MIME `text/plain` .
`RTD_URI`	URI на основе полезной нагрузки.

Как NFC-метки отправляются в приложения

Когда система отправки тегов завершает создание намерения, инкапсулирующего NFC-тег и его идентификационную информацию, она отправляет это намерение заинтересованному приложению, которое фильтрует его. Если несколько приложений могут обработать намерение, отображается окно выбора действий, позволяющее пользователю выбрать нужное действие. Система отправки тегов определяет три намерения, перечисленные в порядке убывания приоритета:

ACTION_NDEF_DISCOVERED : Это намерение используется для запуска действия при сканировании тега, содержащего полезную нагрузку NDEF, и при условии, что он относится к распознанному типу. Это намерение имеет наивысший приоритет, и система распределения тегов старается запустить действие с этим намерением раньше любого другого, если это возможно.
Примечание: Начиная с Android 16, сканирование NFC-тегов, хранящих URL-ссылки (т. е. схема URI — «httptps://» или «http://»), будет активировать намерение ACTION_VIEW вместо намерения ACTION_NDEF_DISCOVERED .
ACTION_TECH_DISCOVERED : Если ни одно действие не зарегистрировано для обработки намерения ACTION_NDEF_DISCOVERED , система диспетчеризации тегов пытается запустить приложение с этим намерением. Это намерение также запускается напрямую (без предварительного запуска ACTION_NDEF_DISCOVERED ), если сканируемый тег содержит данные NDEF, которые невозможно сопоставить с типом MIME или URI, или если тег не содержит данных NDEF, но относится к известной технологии тегов.
ACTION_TAG_DISCOVERED : Это намерение запускается, если ни одно действие не обрабатывает намерения ACTION_NDEF_DISCOVERED или ACTION_TECH_DISCOVERED .

Основной принцип работы системы отправки тегов заключается в следующем:

Попробуйте запустить Activity с намерением, которое было создано системой отправки тегов при анализе тега NFC ( ACTION_NDEF_DISCOVERED или ACTION_TECH_DISCOVERED ).
Если ни одно действие не отфильтровывает это намерение, попробуйте запустить действие со следующим по приоритету намерением ( ACTION_TECH_DISCOVERED или ACTION_TAG_DISCOVERED ), пока приложение не отфильтрует намерение или пока система отправки тегов не попробует все возможные намерения.
Если ни одно приложение не фильтрует ни одно из намерений, ничего не делайте.

По возможности используйте сообщения NDEF и намерение ACTION_NDEF_DISCOVERED , поскольку оно наиболее конкретное из трёх. Это намерение позволяет запускать приложение в более подходящее время, чем два других, обеспечивая пользователю более удобный интерфейс.

Запросить доступ NFC в манифесте Android

Прежде чем вы сможете получить доступ к оборудованию NFC устройства и правильно обрабатывать намерения NFC, объявите следующие элементы в файле AndroidManifest.xml :

Элемент NFC <uses-permission> для доступа к оборудованию NFC:
```
<uses-permission android:name="android.permission.NFC" />
```
Минимальная версия SDK, поддерживаемая вашим приложением. API уровня 9 поддерживает только ограниченную отправку тегов через ACTION_TAG_DISCOVERED и предоставляет доступ к сообщениям NDEF только через дополнительный параметр EXTRA_NDEF_MESSAGES . Другие свойства тегов или операции ввода-вывода недоступны. API уровня 10 включает комплексную поддержку чтения/записи, а также приоритетную отправку NDEF-сообщений, а API уровня 14 предоставляет дополнительные удобные методы для создания записей NDEF.
```
<uses-sdk android:minSdkVersion="10"/>
```
Элемент uses-feature позволяет вашему приложению отображаться в Google Play только на устройствах с оборудованием NFC:
```
<uses-feature android:name="android.hardware.nfc" android:required="true" />
```
Если ваше приложение использует функциональность NFC, но эта функциональность не является критически важной для вашего приложения, вы можете опустить элемент uses-feature и проверить доступность NFC во время выполнения, проверив, является ли getDefaultAdapter() значением null .

Фильтр для намерений NFC

Чтобы запустить приложение при сканировании NFC-метки, которую вы хотите обработать, приложение может фильтровать по одному, двум или всем трём намерениям NFC в манифесте Android. Однако обычно для максимального контроля над запуском приложения требуется фильтрация по намерению ACTION_NDEF_DISCOVERED . Намерение ACTION_TECH_DISCOVERED является резервным для ACTION_NDEF_DISCOVERED , когда ни одно приложение не фильтрует ACTION_NDEF_DISCOVERED или когда полезная нагрузка не является NDEF. Фильтрация по ACTION_TAG_DISCOVERED обычно слишком общая для фильтрации. Многие приложения будут фильтровать по ACTION_NDEF_DISCOVERED или ACTION_TECH_DISCOVERED до ACTION_TAG_DISCOVERED , поэтому вероятность запуска вашего приложения низкая. ACTION_TAG_DISCOVERED доступен только в качестве крайней меры для фильтрации приложений в случаях, когда не установлены другие приложения для обработки намерения ACTION_NDEF_DISCOVERED или ACTION_TECH_DISCOVERED .

Поскольку способы развертывания NFC-тегов различаются и зачастую находятся вне вашего контроля, это не всегда возможно, поэтому при необходимости можно использовать два других типа намерений. Если вы контролируете типы тегов и записываемых данных, рекомендуется использовать формат NDEF для форматирования тегов. В следующих разделах описывается, как фильтровать данные по каждому типу намерений.

ACTION_NDEF_DISCOVERED

Чтобы отфильтровать намерения ACTION_NDEF_DISCOVERED , объявите фильтр намерений вместе с типом данных, которые вы хотите отфильтровать. Следующий пример фильтрует намерения ACTION_NDEF_DISCOVERED с MIME-типом text/plain :

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

В следующем примере выполняется фильтрация по URI в форме https://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="https"
              android:host="developer.android.com"
              android:pathPrefix="/index.html" />
</intent-filter>

ACTION_TECH_DISCOVERED

Если ваша активность фильтруется по намерению ACTION_TECH_DISCOVERED , необходимо создать XML-файл ресурсов, в котором указаны технологии, поддерживаемые вашей активностью в рамках набора tech-list . Ваша активность считается соответствующей, если набор tech-list является подмножеством технологий, поддерживаемых тегом. Этот список можно получить, вызвав getTechList() .

Например, если сканируемая метка поддерживает MifareClassic, NdefFormatable и NfcA, в вашем tech-list должны быть указаны все три, две или одна из технологий (и ничего больше), чтобы ваша активность была сопоставлена.

В следующем примере определены все технологии. Необходимо удалить те, которые не поддерживаются вашей NFC-меткой. Сохраните этот файл (вы можете назвать его как угодно) в папке <project-root>/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>

Вы также можете указать несколько наборов tech-list tech-list Каждый из них рассматривается независимо, и ваша активность считается совпавшей, если любой из tech-list является подмножеством технологий, возвращаемых функцией getTechList() . Это обеспечивает семантику AND и OR для сопоставления технологий. Следующий пример сопоставляет теги, которые могут поддерживать технологии NfcA и Ndef или NfcB и Ndef:

<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>
    <tech-list>
        <tech>android.nfc.tech.NfcB</tech>
        <tech>android.nfc.tech.Ndef</tech>
    </tech-list>
</resources>

В файле AndroidManifest.xml укажите файл ресурсов, который вы только что создали в элементе <meta-data> внутри элемента <activity> , как в следующем примере:

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

Дополнительную информацию о работе с технологиями тегов и намерении ACTION_TECH_DISCOVERED см. в разделе Работа с поддерживаемыми технологиями тегов в документе Advanced NFC.

ACTION_TAG_DISCOVERED

Для фильтрации по ACTION_TAG_DISCOVERED используйте следующий фильтр намерений:

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

ACTION_VIEW

Начиная с Android 16, сканирование NFC-меток, хранящих URL-ссылки, активирует намерение ACTION_VIEW . Чтобы отфильтровать ACTION_VIEW , см. this . Используйте Android app links , чтобы открыть приложение для URL-адреса.

Получить информацию о намерениях

Если действие запускается в результате NFC-намерения, вы можете получить информацию об отсканированной NFC-метке из этого намерения. Намерения могут содержать следующие дополнительные данные в зависимости от отсканированной метки:

EXTRA_TAG (обязательно): объект Tag представляющий отсканированный тег.
EXTRA_NDEF_MESSAGES (необязательно): Массив сообщений NDEF, полученных из тега. Этот дополнительный параметр обязателен для намерений ACTION_NDEF_DISCOVERED .
EXTRA_ID (необязательно): низкоуровневый идентификатор тега.

Чтобы получить эти дополнительные данные, проверьте, была ли ваша активность запущена с одним из намерений NFC, чтобы убедиться в сканировании метки, а затем извлеките дополнительные данные из намерения. В следующем примере проверяется наличие намерения ACTION_NDEF_DISCOVERED и извлекаются сообщения NDEF из дополнительного намерения.

Котлин

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    ...
    if (NfcAdapter.ACTION_NDEF_DISCOVERED == intent.action) {
        intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES)?.also { rawMessages ->
            val messages: List<NdefMessage> = rawMessages.map { it as NdefMessage }
            // Process the messages array.
            ...
        }
    }
}

Ява

@Override
protected void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    ...
    if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(intent.getAction())) {
        Parcelable[] rawMessages =
            intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
        if (rawMessages != null) {
            NdefMessage[] messages = new NdefMessage[rawMessages.length];
            for (int i = 0; i < rawMessages.length; i++) {
                messages[i] = (NdefMessage) rawMessages[i];
            }
            // Process the messages array.
            ...
        }
    }
}

В качестве альтернативы вы можете получить объект Tag из намерения, который будет содержать полезную нагрузку и позволит вам перечислить технологии тега:

Котлин

val tag: Tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG)

Ява

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

Создание общих типов записей NDEF

В этом разделе описывается создание распространённых типов записей NDEF для записи данных в NFC-теги. Начиная с Android 4.0 (API уровня 14), доступен метод createUri() для автоматического создания записей URI. Начиная с Android 4.1 (API уровня 16), доступны createExternal() и createMime() для создания записей NDEF MIME и внешних типов. По возможности используйте эти вспомогательные методы, чтобы избежать ошибок при ручном создании записей NDEF.

В этом разделе также описывается, как создать соответствующий фильтр намерений для записи. Все эти примеры записей NDEF должны находиться в первой записи NDEF сообщения NDEF, которое вы записываете в тег.

TNF_ABSOLUTE_URI

Примечание: мы рекомендуем использовать тип RTD_URI вместо TNF_ABSOLUTE_URI , поскольку он более эффективен.

Вы можете создать запись TNF_ABSOLUTE_URI NDEF следующим образом:

Котлин

val uriRecord = ByteArray(0).let { emptyByteArray ->
    NdefRecord(
            TNF_ABSOLUTE_URI,
            "https://developer.android.com/index.html".toByteArray(Charset.forName("US-ASCII")),
            emptyByteArray,
            emptyByteArray
    )
}

Ява

NdefRecord uriRecord = new NdefRecord(
    NdefRecord.TNF_ABSOLUTE_URI ,
    "https://developer.android.com/index.html".getBytes(Charset.forName("US-ASCII")),
    new byte[0], new byte[0]);

Фильтр намерений для предыдущей записи NDEF будет выглядеть следующим образом:

<intent-filter>
    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="https"
        android:host="developer.android.com"
        android:pathPrefix="/index.html" />
</intent-filter>

TNF_MIME_MEDIA

Создать запись TNF_MIME_MEDIA NDEF можно следующими способами:

Использование метода createMime() :

Котлин

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

Ява

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

Создание NdefRecord вручную:

Котлин

val mimeRecord = Charset.forName("US-ASCII").let { usAscii ->
    NdefRecord(
            NdefRecord.TNF_MIME_MEDIA,
            "application/vnd.com.example.android.beam".toByteArray(usAscii),
            ByteArray(0),
            "Beam me up, Android!".toByteArray(usAscii)
    )
}

Ява

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

Фильтр намерений для предыдущей записи NDEF будет выглядеть следующим образом:

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

Создать NDEF-запись TNF_WELL_KNOWN можно следующим образом:

Котлин

fun createTextRecord(payload: String, locale: Locale, encodeInUtf8: Boolean): NdefRecord {
    val langBytes = locale.language.toByteArray(Charset.forName("US-ASCII"))
    val utfEncoding = if (encodeInUtf8) Charset.forName("UTF-8") else Charset.forName("UTF-16")
    val textBytes = payload.toByteArray(utfEncoding)
    val utfBit: Int = if (encodeInUtf8) 0 else 1 shl 7
    val status = (utfBit + langBytes.size).toChar()
    val data = ByteArray(1 + langBytes.size + textBytes.size)
    data[0] = status.toByte()
    System.arraycopy(langBytes, 0, data, 1, langBytes.size)
    System.arraycopy(textBytes, 0, data, 1 + langBytes.size, textBytes.size)
    return NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, ByteArray(0), data)
}

Ява

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

Фильтр намерений для предыдущей записи NDEF будет выглядеть следующим образом:

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

Создать запись TNF_WELL_KNOWN NDEF можно следующими способами:

Использование метода createUri(String) :

Котлин

val rtdUriRecord1 = NdefRecord.createUri("https://example.com")

Ява

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

Использование метода createUri(Uri) :

Котлин

val rtdUriRecord2 = Uri.parse("https://example.com").let { uri ->
    NdefRecord.createUri(uri)
}

Ява

Uri uri = Uri.parse("https://example.com");
NdefRecord rtdUriRecord2 = NdefRecord.createUri(uri);

Создание NdefRecord вручную:

Котлин

val uriField = "example.com".toByteArray(Charset.forName("US-ASCII"))
val payload = ByteArray(uriField.size + 1)                   //add 1 for the URI Prefix
payload [0] = 0x01                                           //prefixes https://www. to the URI
System.arraycopy(uriField, 0, payload, 1, uriField.size)     //appends URI to payload
val rtdUriRecord = NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, ByteArray(0), payload)

Ява

byte[] uriField = "example.com".getBytes(Charset.forName("US-ASCII"));
byte[] payload = new byte[uriField.length + 1];              //add 1 for the URI Prefix
payload[0] = 0x01;                                           //prefixes https://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);

Фильтр намерений для предыдущей записи NDEF будет выглядеть следующим образом:

<intent-filter>
    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="https"
        android:host="example.com"
        android:pathPrefix="" />
</intent-filter>

TNF_EXTERNAL_TYPE

Создать NDEF-запись TNF_EXTERNAL_TYPE можно следующими способами:

Использование метода createExternal() :

Котлин

var payload: ByteArray //assign to your data
val domain = "com.example" //usually your app's package name
val type = "externalType"
val extRecord = NdefRecord.createExternal(domain, type, payload)

Ява

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

Создание NdefRecord вручную:

Котлин

var payload: ByteArray
...
val extRecord = NdefRecord(
        NdefRecord.TNF_EXTERNAL_TYPE,
        "com.example:externalType".toByteArray(Charset.forName("US-ASCII")),
        ByteArray(0),
        payload
)

Ява

byte[] payload;
...
NdefRecord extRecord = new NdefRecord(
    NdefRecord.TNF_EXTERNAL_TYPE, "com.example:externalType".getBytes(Charset.forName("US-ASCII")),
    new byte[0], payload);

Фильтр намерений для предыдущей записи NDEF будет выглядеть следующим образом:

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

Используйте TNF_EXTERNAL_TYPE для более универсальных развертываний меток NFC, чтобы лучше поддерживать устройства как на базе Android, так и на базе других ОС.

Примечание : URN для TNF_EXTERNAL_TYPE имеют канонический формат: urn:nfc:ext:example.com:externalType , однако спецификация NFC Forum RTD требует, чтобы часть URN urn:nfc:ext: была исключена из записи NDEF. Поэтому достаточно указать только домен (в примере example.com ) и тип (в примере externalType ), разделённые двоеточием. При диспетчеризации TNF_EXTERNAL_TYPE Android преобразует urn:nfc:ext:example.com:externalType в URI vnd.android.nfc://ext/example.com:externalType , что и заявлено в фильтре намерений в примере.

Записи приложений Android

Запись приложения Android (AAR), представленная в Android 4.0 (уровень API 14), обеспечивает более надежную гарантию запуска вашего приложения при сканировании NFC-метки. В запись AAR встроено имя пакета приложения в виде NDEF-записи. Вы можете добавить AAR к любой записи NDEF вашего сообщения NDEF, поскольку Android ищет AAR-записи во всем сообщении NDEF. Если AAR найден, приложение запускается на основе имени пакета в AAR-записи. Если приложение отсутствует на устройстве, запускается Google Play для его загрузки.

AAR полезны, если вы хотите запретить другим приложениям фильтровать то же самое намерение и потенциально обрабатывать определённые теги, которые вы развернули. AAR поддерживаются только на уровне приложения из-за ограничений на имя пакета, а не на уровне активности, как в случае фильтрации намерений. Если вы хотите обрабатывать намерение на уровне активности, используйте фильтры намерений .

Если тег содержит AAR, система отправки тегов выполняет отправку следующим образом:

Попробуйте запустить Activity, используя фильтр намерений, как обычно. Если Activity, соответствующий намерению, также соответствует AAR, запустите Activity.
Если Activity, которая фильтрует намерение, не соответствует AAR, если несколько Activities могут обработать намерение или если ни одна Activity не обрабатывает намерение, запустите приложение, указанное в AAR.
Если ни одно приложение не запускается с AAR, перейдите в Google Play, чтобы загрузить приложение на основе AAR.

Примечание: Вы можете переопределить AAR и систему отправки намерений с помощью системы отправки на переднем плане , которая позволяет приоритетному действию при обнаружении NFC-метки. При использовании этого метода действие должно находиться на переднем плане, чтобы переопределить AAR и систему отправки намерений.

Если вы всё же хотите фильтровать отсканированные теги, не содержащие AAR, вы можете объявить фильтры намерений как обычно. Это полезно, если ваше приложение заинтересовано в других тегах, не содержащих AAR. Например, вы хотите гарантировать, что ваше приложение обрабатывает как собственные теги, развёртываемые вами, так и общие теги, развёртываемые сторонними разработчиками. Имейте в виду, что AAR специфичны для устройств Android 4.0 и более поздних версий, поэтому при развёртывании тегов вы, скорее всего, захотите использовать комбинацию AAR и типов MIME/URI для поддержки максимально широкого спектра устройств. Кроме того, при развёртывании NFC-тегов подумайте о том, как вы хотите написать свои NFC-теги, чтобы обеспечить поддержку большинства устройств (устройств на базе Android и других). Вы можете сделать это, определив относительно уникальный тип MIME или URI, чтобы приложениям было проще различать их.

Android предоставляет простой API для создания AAR-записи — createApplicationRecord() . Всё, что вам нужно сделать, — это встроить AAR-запись в любое место вашего NdefMessage . Не используйте первую запись NdefMessage , если только AAR не является единственной записью в NdefMessage . Это связано с тем, что система Android проверяет первую запись NdefMessage для определения MIME-типа или URI тега, который используется для создания намерения для фильтрации приложениями. Следующий код показывает, как создать AAR-запись:

Котлин

val msg = NdefMessage(
        arrayOf(
                ...,
                NdefRecord.createApplicationRecord("com.example.android.beam")
        )
)

Ява

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

Список разрешенных приложений для сканирования NFC-тегов

Начиная с Android 16, пользователи получают уведомление, когда приложение получает первый сигнал о намерении сканировать NFC-метки. Пользователю предоставляется возможность запретить приложению сканировать NFC-метки в уведомлении.

Приложения могут проверять, разрешил ли пользователь приложению сканировать метки NFC, с помощью NfcAdapter.isTagIntentAllowed() .
Приложения могут предложить пользователю снова разрешить сканирование меток NFC, отправив намерение ACTION_CHANGE_TAG_INTENT_PREFERENCE .

Примечание: список разрешенных приложений для сканирования меток NFC доступен в разделе Settings > Apps > Special app access > Launch via NFC .

Этот механизм был добавлен для решения проблем, о которых сообщали пользователи, поскольку некоторые приложения, в которых были зарегистрированы фильтры намерений для намерений меток NFC, неоднократно выводились на передний план, когда они подносили телефон к метке NFC (кредитной карте, другому телефону/часам и т. д.).

Основы NFC Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Система отправки тегов

Как теги NFC сопоставляются с типами MIME и URI

Как NFC-метки отправляются в приложения

Запросить доступ NFC в манифесте Android

Фильтр для намерений NFC

ACTION_NDEF_DISCOVERED

ACTION_TECH_DISCOVERED

ACTION_TAG_DISCOVERED

ACTION_VIEW

Получить информацию о намерениях

Котлин

Ява

Котлин

Ява

Создание общих типов записей NDEF

TNF_ABSOLUTE_URI

Котлин

Ява

TNF_MIME_MEDIA

Котлин

Ява

Котлин

Ява

TNF_WELL_KNOWN с RTD_TEXT

Котлин

Ява

TNF_WELL_KNOWN с RTD_URI

Котлин

Ява

Котлин

Ява

Котлин

Ява

TNF_EXTERNAL_TYPE

Котлин

Ява

Котлин

Ява

Записи приложений Android

Котлин

Ява

Список разрешенных приложений для сканирования NFC-тегов

Основы NFC