| c8768e4b2ab114d227bd8af441d81525837f78cb |
|
25-Mar-2014 |
Martijn Coenen <maco@google.com> |
Goodbye secure element.
I really liked you,
but everybody else wanted you too.
Maybe some day you'll be back,
connected to the host CPU.
Change-Id: If78bce7c7178a77919b8b1b64334909f4ff7e037
/packages/apps/Nfc/nci/jni/JavaClassConstants.h
|
| 9f8f6cf9c58405ecafe2d425801e6c14088db8c7 |
|
30-Apr-2013 |
Martijn Coenen <maco@google.com> |
Host-based card emulation.
Initial check-in that allows to build basic HCE apps:
- Introduced new RoutingManager, taking care of programming
the routing table to the NFCC.
- Added DeviceHost interfaces for adding/removing aids to
the routing table, and sending raw frames.
- On devices that have an eSE, the eSE is the default route.
- Removed routing code from SecureElement class.
- HostEmulationManager resolves and dispatches AIDs
routed to the host to an application service.
- Simple Messenger service interface for exchanging APDUs.
- RegisteredAidCache keeps a cache of AIDs that are registered
by Android applications, as well as their route.
TODO:
- Dynamic registration of AIDs.
- Dynamic updates of the routing table.
- AID conflict resolution.
- Allow apps to indicate AIDs present "off-host".
- Implement base-class HCE service in framework.
- Switch default route to host.
Change-Id: I7d7643770fcc848699810ec5443d0d9b81d85669
/packages/apps/Nfc/nci/jni/JavaClassConstants.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/JavaClassConstants.h
|
| 525c260303268a83da4c3413b953d13c9084e834 |
|
14-Dec-2012 |
The Android Open Source Project <initial-contribution@android.com> |
Snapshot 1a6bcf3cca90fedfbad33c1cdd6d05af5774fc01
Change-Id: I3ccb25bf7cde2c22f52260cae0e9957517e6bb5f
/packages/apps/Nfc/nci/jni/JavaClassConstants.h
|