Change-Id: I116b76d844c5c89e068acc55430d93c7de8bc61e
Signed-off-by: Daniel Rosenberg <drosen@google.com>

Turn off unused parameter warnings to unclutter the build output
When storing an int in a void*, use intptr_t to cast between them
Store pointer handles in an intptr_t or a uintptr_t

Change-Id: If48290ca23dd295f1a87220c5b1d5232ebdc8d45

The connect callback wasn't cleared in error cases,
which could cause spurious callbacks including data
that used to be allocated on the stack, and has been
freed by now.

Also, always add the -3a tech for any IsoDep target,
even if the remote device has the P2P bit set.

Bug: 10360259
Change-Id: I73141c4a1106f66ff89c6b1c53c4977e9cb78fa1

This allows the caller to recovery by trying again.

Bug: 8552749
Change-Id: Iff979c097d33f9adda06654de9e588595daf89a3

There is a tight race condition where opening
of the SE can fail, due to a tag/p2p device
having just come in. In that case, restore
the original state of the SE activated mode.

This will prevent future calls into this
method and Connect() from immediately bailing out.

Bug: 8599167
Change-Id: I1890e4efb73a9f5bdd6abe0644f88051b32e8c02

In some conditions these would persist
over a link tear-down, causing them to
be sent out the next time the link comes up.

Also, don't overwrite them if a send is
still in progress.

Change-Id: I19dec5d79ae4b25f41fb5e8a0514e565ceca7a91

When a call to disconnect() failed, the
connect() callback was cleared, not the
disconnect() one. This would cause deadlocks,
where JNI threads were forever blocked on
doConnect().

Bug: 7324226
Change-Id: I784c8d700c87d643315f2417610ca75ef8f9aa7c

On Android we now start connecting SNEP/other LLCP
services as soon as the link comes up. That means
we will have connect requests incoming, accept
responses outgoing, connect requests outgoing and
accept responses incoming.

This lays bare a lot of threading issues in this lib.
Since the receives come in serialized, those typically
do not cause any issue. However, we may be sending
something on a thread coming from the NfcService,
while at the same time we'll receive for example
a connect frame from the remote, to which the receive
thread immediately wants to send a response.

This is a first attempt at making sends thread-safe:
already there was a lot of logic to deal with the fact
that another send was in progress, in the form of the
bSendPending variable. That variable was however
not checked atomically, and some operations did not
even set it correctly.

This change tests and sets that variable atomically,
more or less implementing a semaphore with try-acquires
and fallbacks for the failure case.

The generic structure is:

if (testAndSetSendPending()) {
   // Another thread is sending, stash data
   // and most importantly do *NOT* change shared data
} else {
   // We're now the only one sending, we're free
   // to change shared data until the callback is
   // called.
}

This is just a band-aid fix, but given the fact that
this stack will be deprecated it is hopefully enough
for our planned usecases.

A decent fix would involve switching to
a TX-queue per socket, and a generic TX-queue
for the whole LLCP link. This allows us to fully
decouple the connection layer from the transport
layer, as it should be.

Change-Id: Ibd8742f7350a58459771f5036a049af3a487f783

On first establishment of the LLCP link, if we are
the initiator, we waited the full LTO before sending
the SYMM to the target. This will prevent the target
from communicating with us for 750ms! Old Android
implementations only connected LLCP on touch, but
newer ones will immediately connect LLCP.

To solve this, bounce the SYMM back immediately, to allow
the target to start sending as soon as it wants to.

Change-Id: I2fb09599798527f2e6f908b8ba362e0061120be2

NDEF Type 3 tag reading was not ignoring the padding bytes, which
leads to failure of parsing the NDEF data. This patch fix that problem.

Bug: 7600630
Change-Id: I45cf1841bdc343503a8a12d622ac8470c3e64ce4