GitLab

This caused SE access on eng builds to fail, and
was pretty dangerous on other builds.

Change-Id: Iea8f09559e8da61862cdb24ec0ea5ace91d5bbd1

Throw NdefFormatable only when ICODE tag.

Change-Id: I6cc54f5f076cfd1a223d0daaac0951d5d56007a3

Added type for NDEF on ICODE, changed type for MIFARE_CLASSIC as discussed.

Change-Id: I29f38c4e963f2f2211ca22f4fde244c29d5a590e

The NFC API's isConnected() is mapped to isPresent on a NativeNfcTag
object, which in turn uses a cached value. This value was however not
updated properly when the internal presence check loop detected the
tag to be gone. The cases where isConnected() does work properly
are screen off and explicit disconnect.

Change-Id: Ieac76ceb1f161ead772ce9fd2acf273b23caca37

The tag handle was only registered after the dispatch; with the "normal"
dispatch the activity would take a while to start and this problem would not be
seen. With foreground dispatch however, if you'd immediately try to connect to a tag,
sometimes the tag handle is not registered yet, causing the connect() to fail.

Change-Id: I92b5e36a5d8f08e410a656d364e88bce2d25c854

Change-Id: I019ad3fc62f49280031320c2c32532e64097d3f9

Change-Id: Id825345c0c5cd131d25ff23184a57ee53f9fa9dd

Change-Id: Ic7046ea686b1cf3eb232f6125122dea5d919ac2d

Change-Id: Ie9fc3f32cfdb043e67c774e3c222aa599f138932

Change-Id: I83f79bc7a5f3227ef4a8222dc879beda53a8ab31

Change-Id: I0b709084992e8022deacd67e1b8c24f33e8d73fc

Use a cached value instead, which is based on the presence check that is running
anyway.

Change-Id: Ifa50ff38e884fa865bb7ba95dde45da39bebf7e8

Suppose you have a MifareClassic tag with NDEF; the following scenario failed
MifareClassic.connect()/close() -> Ndef.connect()/close() -> MifareClassic.connect() .

This last connect fails because the service refuses to connect any technology
on the same handle, except for NDEF. This check was too strict - it was only
intended to catch connecting to a NfcA technology on an IsoDep tag, as libNFC does not
support this. This change always allows connecting a tech on the same handle, except
when you want to connect a non-IsoDep technology on a tag that does have the IsoDep
technology on the same handle - in which case it refuses. This
matches exactly what libnfc supports.

Change-Id: I64d552b3cd51beb36712676492f36d182c605748

Bug: 3398076
Change-Id: Ib1a0ac03299f713b00bc93de2e8bb7a3b531711c

Change-Id: I0a62d1ee539aa6bf9147bed56055a460b9804aea

Change-Id: I0d8fce569f2e6431fe62a299278a0106c86cda9a

Some tags may be left in an inconsistent or "non-responding" state after we
do NdefFormatable checks. For example, tags that identify as DESfire
but don't support the getVersion() command. To make sure the stack can continue
to work with them, we reconnect().

Change-Id: I2890d3c70cc7cf7d15fb98090a031686d434168d

The pattern matching wasn't sufficient with the
move to identifying technologies with their class
names so now we use a custom dispatching mechanism.

Change-Id: I3e6379d454458bbb65730ade32cdaa1680c5e339

If the P2P target connect failed, the P2P target disconnect cannot be done.
However the polling loop must be restarted. This is already done in JNI layer
by the failing connect itself.

Change-Id: I1c3323e4c038c8133e7b6e16b3a238c050427cfc

This patch fixes the tag disconnect sequence in 2 cases:

1.
When the NFC service disconnects a tag because it is not needed anymore, the
disconnection should be effective immediately and not delayed until the tag is
removed from the field. The NFC service is responsible for discovering again
the same tag if the polling loop is restarted.
The looping "presence check" in native code is then removed.

2.
Before the screen is turned off, the polling loop configuration and - if any
tag is present - the tag disconnection must be done accordingly to the "normal"
tag management. In particular the watchdog must be stopped properly.

Change-Id: I58ee27cede110c419052b4eef07f1e4bd35ae208

libNFC doesn't support formatting tags that are already NDEF formatted. This
needs to be fixed in libNFC, but as a temporary work-around we will only
throw the NdefFormattable technology if no NDEF has been found on the tag.

Change-Id: I487b875de5fd66fdfec2d1b9c30fa886d8ca1477

There are lots of ways things could go
wrong when faced with invalid NDEF data
so just got for the catch-all and handle
it properly.

Change-Id: Ia762c8e337aef8fed867beab8159e6ed05bbacea

Foreground dispatch overrides now interpret
null for the filters as "catch all".

Foreground NDEF push disables standard dispatch
and only honors foreground dispatching so that
two NDEF push apps don't end up just swapping
between each other when the push happens.

Change-Id: Ic305d4a3a593fff732b8d88ae72e09b4a03d6286

The code located at the end of the com_android_nfc_NfcManager_doDisconnectTag()
was unreachable, due to a missing test.

The function was returning without waiting for the semaphore (allocated on the
stack) and when the callback was triggered, it was accessing the previsouly
de-allocated semaphore.

Change-Id: I3785b545802ab9858390b48dfb59cb9e70883c9c

Change-Id: Ic30625a81e1e0a8f01955cd82b2e75ac2571c6d0

Change-Id: I0eaf93fb62fd28e417b8f65c3d4da69060cd4d90

The home screen and other system apps call stopAppSwitches() to prevent
malicious applications from starting their activity again when the user exits.
The startActivity() call is delayed by 4 seconds.

We can override this in NFC service because we are a system service, using
resumeAppSwitches(). If a tag comes into the field we really want to show it
immediately. It feels really laggy otherwise.

Change-Id: I5394647f352e3f49f821b5346cd4c9af103137ca

This method takes the buffer, the start offset and the end offset as
parameters.

Change-Id: I52e33d7083a26bea57e0f3c819c40c8daa4e3816

libNFC has a distinct return code indicating it can no longer communicate
with the tag - usually because it is no longer in the RF field.
Propagating this to the API allows applications to react to this
specific event and provide more detailed feedback to the user.

Change-Id: I9d82c749f56c5aee8e5baef84c17d28e326842f4

Change-Id: I2ae2884d78af8268852c8812a4ff7cfbece6c53a

The LLCP receive function may return NFCSTATUS_SUCCESS is some data have
already been received. This case should be updated according to the change
in libnfc-nxp.

Change-Id: I21ea159e2ec13f4db6ea53dd0edd2c1b916ea064

At the NFCIP-1 level, the LLCP frames are splitted in 251-bytes
packets. Knowing that NFCIP-1 packets have a 3-bytes header, the
optimal size for a LLCP packet is 248-bytes.

With the previous value (256), each LLCP frame was splitted in
two NFCIP-1 packets, one 248+3 bytes and another one of 8+3 bytes.
This was leading to less-than-optimal performances.

Change-Id: Ide31b1ee24efc910c71d690a8ae100331b62ccf8

The global variable previously used to store a single incoming
connection request has been removed. Now, the requests are queued
in a list until the corresponding accept() method is called or
if the link goes down.

This should also fix issues related to multiple incoming connection
requests that can happen when activating/deactivating the link
fastly.

Change-Id: I3ab6c37b586b9f38b0de825e70f1efa06adf2062

When an application tries to access a closed socket, the NFC
service will fail to find it in its internal socket table,
returning a null object which is impossible to cast to a
LLCP socket class, generating a ClassCastException.

This patch handle the exception catching, avoiding a service
crash.

Change-Id: I236652b83a51b78fcfe8258402888a74f3144a7f

With the latest libnfc-nxp library, the LLCP socket internals are
initialized when configuring the LLCP link parameters because it
must be the first LLCP function called.

Due to this, these parameters are now set only once at the NFC
service startup instead of each peer discovery.

As a consequence, the NFC Manager initialization now use the
application properties (which contains link parameters) so these
properties are loaded before initialization.

Change-Id: I8e04c3135646a12a48c392d47cb47d09cd234ea1

Until now, the NFC native library (libnfc-nxp) had some limitations
on the socket life cycle that made impossible to ensure the local server
socket was listening before the remote client was trying to connect.

The RegisteredSocket class was created to workaround this by enabling
socket creation at the Java layer prior to link establishment. This
solution was not fully satisfactory since there were still some race
conditions.

A fix for these limitations has been submitted in the library project
in a commit named "Allow LLCP socket creation before link establishment"
and this patch takes advantage of it to remove the RegisteredSocket
class and all the associated code.

As a consequence, the socket creation methods have been simplified, the
link activation processes is lighter (no need to recreate native sockets
on link activation).

This patch also includes some cleaning (removed unused variables).

Change-Id: I643509d620105ae7d3ba24ea68eae37f05bc6ef3

Change-Id: I7ad0fc608c2dd81b42dcbca994759352ffae9360

Change-Id: I691f1568ae83f2483bd6c60489d427cf62b1c9c8