The new tag dispatch process in Android 2.3.3

Posted on Mar 01, 2011 - By

One of the new features in the Android framework API 2.3.3 is the improved support for NFC to interact with tags in a more friendly way. This changes include a new tag dispatch process, so, probably your NFC applications written for previous api levels now will fail. This is because these older versions used a single-step intent dispatch to notify interested applications that a tag was discovered. From 2.3.3 version (Api level 10), the platform uses a four-step process that enables the foreground application to take control of a tag event before it is passed to any other applications. This new process is designed to dispatch a tag to the correct activity without showing to the user the activity chooser dialog.

The four steps are based on the enable/disable foreground dispatch method and three intent actions:

Dispatch process

Tag dispatch process

First step: The NfcAdapter.enableForegroundDispatch Method

This method will enable foreground dispatch to the given activity. This means, calling this method will give priority to the foreground activity when dispatching a discovered Tag to an application. You can provide any IntentFilters to this method and the are used to match dispatch Intents for both the ACTION_NDEF_DISCOVERED and ACTION_TAG_DISCOVERED. Remember that you must call disableForegroundDispatch(Activity) before the completion of their onPause() callback to disable foreground dispatch after it has been enabled.

The typical example of using this method is an application showing the screen “Waiting for tag…” for read or write. When the user taps a tag this activity has priority for the discovered tag so the activity chooser dialog will not shown.

 

Next steps: 3 Intent actions

If a tag is detected and there is no call to the enableForegroundDispatch method, then the system broadcasts three intent actions in this order, from specific (checking the content) to generic (just a tag):

1 – ACTION_NDEF_DISCOVERED

This intent is started when a tag with NDEF payload is discovered. The system inspects the first NdefRecord in the first NdefMessage and looks for a URI, SmartPoster, or MIME record. If a URI or SmartPoster record is found the intent will contain the URI in its data field. If a MIME record is found the intent will contain the MIME type in its type field. This allows activities to register IntentFilters targeting specific content on tags. Activities should register the most specific intent filters possible to avoid the activity chooser dialog, which can disrupt the interaction with the tag as the user interacts with the screen.

If any activities respond to this intent neither ACTION_TECH_DISCOVERED or ACTION_TAG_DISCOVERED will be started.

2 – ACTION_TECH_DISCOVERED

Intent to start an activity when a tag is discovered and activities are registered for the specific technologies on the tag. To receive this intent an activity must include an intent filter for this action and specify the desired tech types in a manifest meta-data entry. Here is an example manifest entry:

Manifest

The meta-data XML file should contain one or more tech-list entries each consisting or one or more tech entries. The tech entries refer to the qualified class name implementing the technology, for example “android.nfc.tech.NfcA”.

A tag matches if any of the tech-list sets is a subset of Tag.getTechList(). For the current api version this could be:

NfcA (also known as ISO 14443-3A)
NfcB (also known as ISO 14443-3B)
NfcF (also known as JIS 6319-4)
NfcV (also known as ISO 15693)
IsoDep (ISO 14443-4)
Ndef on NFC Forum Type 1, Type 2, Type 3 or Type 4 compliant tags
MifareClassic
MifareUltralight
NdefFormatable

Each of the tech-lists is considered independently and the activity is considered a match is any single tech-list matches the tag that was discovered. This provides AND and OR semantics for filtering desired techs. Here is an example that will match any tag using NfcF or any tag using NfcA, MifareClassic, and Ndef:

Tech list

If any activities respond to this intent ACTION_TAG_DISCOVERED will not be started.

3 – ACTION_TAG_DISCOVERED

This is the last step, more generic, if no activities respond to the previous intents, this one (as previous Android versions) will start an activity when a tag is discovered.

 

 

Tagged , .

One Comment

  • duluca says:

    Excellent article and great job with the tag writer app. I have an app with a pending intent subscribed to NDEF_DISCOVERED and a normal intent subscribed to TECH_DISCOVERED.
    It looks like I need to have the latter intent, so that my app will come up in the NFC selection action screen.
    However, with my pending intent (which is modeled after the API reference code) I have to scan the tag twice for the OnNewIntent to fire.
    Do you think I really need two intents to capture both in app scans and out of app scans?
    Why would you think my pending intent is requiring two scans? Is it because I’m subscribing with it in the manifest as well or because I have two NFC intents (albeit at different levels) ?

Trackbacks and Pingbacks