2dfff7620070cff76fb117aafcd06e57cceb59fb |
|
15-Dec-2016 |
Ruchi Kandoi <kandoiruchi@google.com> |
Changes data types to standard type Data types were changed using platform/system/bt/tools/scripts/change_types.sh: UINT8->uint8_t UINT16->uint16_t UINT32->uint32_t UINT64->uint64_t INT8->int8_t INT16->int16_t INT32->int32_t INT64->int64_t Test: Compiles Change-Id: I04b6c7b7836145033537aa2af27e18311b3c6d91 Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
/packages/apps/Nfc/nci/jni/PeerToPeer.h
|
b5a6c9615433734869c7a73a06c1b3799ebe0c9f |
|
06-Jun-2014 |
Martijn Coenen <maco@google.com> |
JNI code from Broadcom. Contribution from Evan Chu <evanchu@broadcom.com>. Changes made to make it build with current tree: - Removed deferred start/stop logic (no SE code in AOSP). - Removed separate enable/disable implementations (no SE code in AOSP). - Removed second option for P2P workarounds with PN5xx as it's not used. Change-Id: Ia33e3fa29b09dca2f6d2721307edde746605da54
/packages/apps/Nfc/nci/jni/PeerToPeer.h
|
57a44d07a3de327e8cdbbcd622118aa517313dbe |
|
28-Mar-2013 |
Martijn Coenen <maco@google.com> |
Deal with pre-MR2 PN544 NXP stack LLCP bugs. In MR2 we started connecting LLCP on link activation instead of when the send was confirmed. Pre-MR2 NXP-stack devices have a bug that causes them to only send the first SYMM after 750 ms (in case they are the initiator). There is another bug that causes that same stack to crash if two threads try to send a packet at the same time. Unfortunately, this combination of factors creates the following race: 1) pre-MR2 PN544-initiator initiates p2p link with MR2 device 2) pre-MR2 PN544-initiator starts Touch to Beam animation 3) pre-MR2 PN544 doesn't have data to send, but delays SYMM for 750ms 4) MR2 device finally gets SYMM after 750ms, and sends CONNECT PDU 5) pre-MR2 PN544-initiator device responds to CONNECT PDU with CC on Thread 1 6) Within a ~50 ms window, the user on the pre-MR2 PN544-initiator touches the screen to confirm the send. This causes Thread 2 to try to send something, which fails. As a result, the Beam transaction fails. Unfortunately this is quite easy to reproduce, since the Beam animation takes about 750ms, just the same amount of time it takes for the SYMM to get sent. To prevent such a race condition, we should make sure that we do not create multi-threaded access on the remote device. The best way to do that is to not connect the LLCP services automatically when talking to a pre-MR2 PN544-initiator. Long story short, when we don't receive a first packet of data after 200 ms, we consider the remote device to be a buggy implementation, and delay the connect until the time the user decides to send something (in which case it's fine - it's unlikely the user at the other side tries to send something at exactly the same time). Also fixed RF field notifications to be more robust; whenever p2p is activated, we disable field events, and always treat the field as being on. Bug: 8508568 Change-Id: I41b427afb24c7f8d228adc91d258cca553539588
/packages/apps/Nfc/nci/jni/PeerToPeer.h
|
218b2ef897289d3e6fd7818c6883809149f62f08 |
|
27-Mar-2013 |
Martijn Coenen <maco@google.com> |
Update JNI to work with latest stack drop. Also improved support for Kovio. Change-Id: If3c7a7a638f9af30b21fd86e4d7609cfb2c35558
/packages/apps/Nfc/nci/jni/PeerToPeer.h
|
525c260303268a83da4c3413b953d13c9084e834 |
|
14-Dec-2012 |
The Android Open Source Project <initial-contribution@android.com> |
Snapshot 1a6bcf3cca90fedfbad33c1cdd6d05af5774fc01 Change-Id: I3ccb25bf7cde2c22f52260cae0e9957517e6bb5f
/packages/apps/Nfc/nci/jni/PeerToPeer.h
|