Read NFC tag without specific application?

问题:

I was wondering if there is any way to save a string of text (URL) to an NFC tag, let us say MIFARE or NTAG203, that can be read by other devices (smartphones) without the need of any special tag reading application.

I have tested several applications, e.g. Trigger for Android, and noticed that if the device reading the tag does not have the required application to read the data/instructions off the tag it still opens a URL that sends you to the Play Store to download that application.

So there must be a way to save some data readable by all/some NFC enabled phones. Simply put I want to create an applcation for Android that will write data to NFC tags and the data can be read/opened/executed by a random NFC enabled phone.

So is it possible to prepare an NFC tag that triggers some action on the reading device without requiring a specific application? What type of data could I write on an NFC tag with my app to achieve this?

回答1:

First of all, in general, I agree with CommonsWare point of view that it's always a "special" app that handles NFC events. However, when looking into Android, I would consider the various platform apps from AOSP as part of the Android system. Even though not all of them may be available on all devices.

Looking into Andrid 4.4+, the following data types are handled by such system apps:

• Browser: URIs with schemes "http:" and "https:".
• Contacts and Dialer: MIME types "text/vcard" and "text/x-vcard" for importing contacts.
• E-mail: URIs with scheme "mailto:"

In addition, if no other app handles a certain tag, NFC devices should(?) have the Tag app, that tries to handle various types (upon user confirmation):

• URIs with scheme "tel" will cause an ACTION_CALL intent to call the given number.
• URIs with schemes "sms"/"smsto" will cause an ACTION_SENDTO intent to start editing an SMS message.
• Other URIs should(?) be forwarded in ACTION_VIEW intents.
• MIME type records with type "text/x-vcard" (if not already handled) should be forwarded in ACTION_VIEW intents.
• The text message of Text RTD records (not text/* MIME types!) should be displayed in the Tag app. Unfortunately many stupid(!) NFC apps register for Text records, thus you will normally not get to the Tag app.
• MIME type records with type image/* (if image type is supported by Android) should be displayed in the Tag app.

Some records are handled by the NFC service itself (this should always be available on Android):

• Android Application records (NFC Forum external type with type name "urn:nfc:ext:android.com:pkg") cause an ACTION_VIEW intent with the URI "market://details?id={PACKAGE_NAME}" to be sent.
• NFC Forum external types with type name "urn:nfc:nokia.com:bt" are parsed for Bluetooth connection handover.
• NDEF messages starting with a Handover Select RTD record and containing a MIME type record of type "application/vnd.bluetooth.ep.oob" are parsed for Bluetooth connection handover.

回答2:

Everything with NFC involves an application for responding to the tag. Whether that is a "special tag reading application" depends on your own personal definition of "special tag reading application".

For example, some Web browsers will support NDEF-formatted tags with the payload being a URL. But that's a browser thing, not an OS thing. For example, the AOSP browser app has the manifest entry to respond to NDEF-formatted tags with URLs beginning with http or https. By my definition of "special tag reading application", the AOSP browser is a "special tag reading application". While hopefully all NFC-capable devices will ship with a Web browser that supports NDEF-formatted tags, that's not guaranteed.

If your "some data" is anything else, whether or not there is an app that is set up to respond to that sort of data. After URLs, the next-most-common tag payload is identified via a MIME type, just like you use with Web apps, and so if there is an app installed that supports NDEF and is set up to respond to your MIME type, it will pick up your data. This is no different than having your Web server serve up content under some MIME type -- an app needs to be installed that honors http/https URLs (or files downloaded by a browser) and that MIME type.

if the device reading the tag does not have the required application to read the data/instructions off the tag it still opens a URL that sends you to the Play Store to download that application

An AAR (Android Application Record) was added to the NDEF message written to the NDEF-formatted tag. That is the only NDEF item that can be thought of as being handled by the platform itself, and that's only for devices that support the Play Store (and apps that are distributed via the Play Store).