Causes the current thread to wait until another thread invokes the
notify() method or the
notifyAll() method for this object, or
some other thread interrupts the current thread, or a certain
amount of real time has elapsed.

ACTION_NDEF_DISCOVERED

Intent to start an activity 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.

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(). 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:

enableForegroundDispatch

This will give give priority to the foreground activity when
dispatching a discovered Tag to an application.

If any IntentFilters are provided to this method they are used to match dispatch Intents
for both the ACTION_NDEF_DISCOVERED and
ACTION_TAG_DISCOVERED. Since ACTION_TECH_DISCOVERED
relies on meta data outside of the IntentFilter matching for that dispatch Intent is handled
by passing in the tech lists separately. Each first level entry in the tech list represents
an array of technologies that must all be present to match. If any of the first level sets
match then the dispatch is routed through the given PendingIntent. In other words, the second
level is ANDed together and the first level entries are ORed together.

If you pass null for both the filters and techLists parameters
that acts a wild card and will cause the foreground activity to receive all tags via the
ACTION_TAG_DISCOVERED intent.

This method must be called from the main thread, and only when the activity is in the
foreground (resumed). Also, activities must call disableForegroundDispatch(Activity) before
the completion of their onPause() callback to disable foreground dispatch
after it has been enabled.

For NDEF push to function properly the other NFC device must
support either NFC Forum's SNEP (Simple Ndef Exchange Protocol), or
Android's "com.android.npp" (Ndef Push Protocol). This was optional
on Gingerbread level Android NFC devices, but SNEP is mandatory on
Ice-Cream-Sandwich and beyond.

enableReaderMode

Limit the NFC controller to reader mode while this Activity is in the foreground.

In this mode the NFC controller will only act as an NFC tag reader/writer,
thus disabling any peer-to-peer (Android Beam) and card-emulation modes of
the NFC adapter on this device.

Use FLAG_READER_SKIP_NDEF_CHECK to prevent the platform from
performing any NDEF checks in reader mode. Note that this will prevent the
Ndef tag technology from being enumerated on the tag, and that
NDEF-based tag dispatch will not be functional.

ignore

Signals that you are no longer interested in communicating with an NFC tag
for as long as it remains in range.
All future attempted communication to this tag will fail with IOException.
The NFC controller will be put in a low-power polling mode, allowing the device
to save power in cases where it's "attached" to a tag all the time (e.g. a tag in
car dock).
Additionally the debounceMs parameter allows you to specify for how long the tag needs
to have gone out of range, before it will be dispatched again.
Note: the NFC controller typically polls at a pretty slow interval (100 - 500 ms).
This means that if the tag repeatedly goes in and out of range (for example, in
case of a flaky connection), and the controller happens to poll every time the
tag is out of range, it *will* re-dispatch the tag after debounceMs, despite the tag
having been "in range" during the interval.
Note 2: if a tag with another UID is detected after this API is called, its effect
will be cancelled; if this tag shows up before the amount of time specified in
debounceMs, it will be dispatched again.
Note 3: some tags have a random UID, in which case this API won't work reliably.

int: minimum amount of time the tag needs to be out of range before being
dispatched again.

tagRemovedListener

NfcAdapter.OnTagRemovedListener: listener to be called when the tag is removed from the field.
Note that this will only be called if the tag has been out of range
for at least debounceMs, or if another tag came into range before
debounceMs. May be null in case you don't want a callback.

handler

Handler: the Handler that will be used for delivering
the callback. if the handler is null, then the thread used for delivering
the callback is unspecified.

Returns

boolean

false if the tag couldn't be found (or has already gone out of range), true otherwise

invokeBeam

The Android Beam animation is normally only shown when two NFC-capable
devices come into range.
By calling this method, an Activity can invoke the Beam animation directly
even if no other NFC device is in range yet. The Beam animation will then
prompt the user to tap another NFC-capable device to complete the data
transfer.

The main advantage of using this method is that it avoids the need for the
user to tap the screen to complete the transfer, as this method already
establishes the direction of the transfer and the consent of the user to
share data. Callers are responsible for making sure that the user has
consented to sharing data on NFC tap.

setBeamPushUris

Set one or more Uris to send using Android Beam (TM). Every
Uri you provide must have either scheme 'file' or scheme 'content'.

For the data provided through this method, Android Beam tries to
switch to alternate transports such as Bluetooth to achieve a fast
transfer speed. Hence this method is very suitable
for transferring large files such as pictures or songs.

The receiving side will store the content of each Uri in
a file and present a notification to the user to open the file
with a Intent with action
ACTION_VIEW.
If multiple URIs are sent, the Intent will refer
to the first of the stored files.

This method may be called at any time before onDestroy(),
but the URI(s) are only made available for Android Beam when the
specified activity(s) are in resumed (foreground) state. The recommended
approach is to call this method during your Activity's
onCreate(Bundle) - see sample
code below. This method does not immediately perform any I/O or blocking work,
so is safe to call on your main thread.

setBeamPushUrisCallback

Set a callback that will dynamically generate one or more Uris
to send using Android Beam (TM). Every Uri the callback provides
must have either scheme 'file' or scheme 'content'.

For the data provided through this callback, Android Beam tries to
switch to alternate transports such as Bluetooth to achieve a fast
transfer speed. Hence this method is very suitable
for transferring large files such as pictures or songs.

The receiving side will store the content of each Uri in
a file and present a notification to the user to open the file
with a Intent with action
ACTION_VIEW.
If multiple URIs are sent, the Intent will refer
to the first of the stored files.

This method may be called at any time before onDestroy(),
but the URI(s) are only made available for Android Beam when the
specified activity(s) are in resumed (foreground) state. The recommended
approach is to call this method during your Activity's
onCreate(Bundle) - see sample
code below. This method does not immediately perform any I/O or blocking work,
so is safe to call on your main thread.

setNdefPushMessage

This method may be called at any time before onDestroy(),
but the NDEF message is only made available for NDEF push when the
specified activity(s) are in resumed (foreground) state. The recommended
approach is to call this method during your Activity's
onCreate(Bundle) - see sample
code below. This method does not immediately perform any I/O or blocking work,
so is safe to call on your main thread.

If you want to prevent the Android OS from sending default NDEF
messages completely (for all activities), you can include a
<meta-data> element inside the <application>
element of your AndroidManifest.xml file, like this:

And that is it. Only one call per activity is necessary. The Android
OS will automatically release its references to the NDEF message and the
Activity object when it is destroyed if you follow this pattern.

setNdefPushMessageCallback

Set a callback that dynamically generates NDEF messages to send using Android Beam (TM).

This method may be called at any time before onDestroy(),
but the NDEF message callback can only occur when the
specified activity(s) are in resumed (foreground) state. The recommended
approach is to call this method during your Activity's
onCreate(Bundle) - see sample
code below. This method does not immediately perform any I/O or blocking work,
so is safe to call on your main thread.

If you want to prevent the Android OS from sending default NDEF
messages completely (for all activities), you can include a
<meta-data> element inside the <application>
element of your AndroidManifest.xml file, like this:

And that is it. Only one call per activity is necessary. The Android
OS will automatically release its references to the callback and the
Activity object when it is destroyed if you follow this pattern.

setOnNdefPushCompleteCallback

This method may be called at any time before onDestroy(),
but the callback can only occur when the
specified activity(s) are in resumed (foreground) state. The recommended
approach is to call this method during your Activity's
onCreate(Bundle) - see sample
code below. This method does not immediately perform any I/O or blocking work,
so is safe to call on your main thread.

The API allows for multiple activities to be specified at a time,
but it is strongly recommended to just register one at a time,
and to do so during the activity's onCreate(Bundle). For example:

And that is it. Only one call per activity is necessary. The Android
OS will automatically release its references to the callback and the
Activity object when it is destroyed if you follow this pattern.