1. 31 May, 2013 1 commit
  2. 22 May, 2013 1 commit
    • Martijn Coenen's avatar
      Use top activity when determining foreground package. · 2f61bcad
      Martijn Coenen authored
      If you have an activity stack where the base activity
      belongs to a different package, NfcService would use
      the wrong package for determining whether the current
      foreground app is allowed to have an ndef message (callback) set.
      This could cause Activity stacks like Settings -> Storage ->
      Pictures & Videos -> Gallery to fail sending pictures.
      
      Use the top activity instead.
      
      Bug: 9072009
      Change-Id: I32fbbea1423333117d2a0522eced98ecf9a758e7
      2f61bcad
  3. 21 May, 2013 2 commits
  4. 10 May, 2013 2 commits
  5. 02 May, 2013 1 commit
    • Martijn Coenen's avatar
      Don't overwrite SWP_CFG on SE pipe enable/disable. · f5954743
      Martijn Coenen authored
      Different BCM2079x revisions have different interpretations for
      bits in the SWP_CFG config parameter. Instead of overwriting
      whatever is there, read the current value, and just set/unset
      the bit for UICC_IDLE timeout as desired.
      
      Bug: 8776949
      Change-Id: I33807aef1e94cfa6a2f4af0dd6a46dae630d850f
      f5954743
  6. 26 Apr, 2013 1 commit
    • Martijn Coenen's avatar
      Fix more race conditions. · 476ee8a6
      Martijn Coenen authored
      In the old NXP JNI:
      - We can be in the process of discovering a tag/p2p target
        when we try to configure discovery. In case ConfigureDiscovery
        returns BUSY, don't immediately call abort(), but retry a few
        times.
      - Completely disable Tag/P2P discovery *before* opening a pipe
        to the SMX. This avoids nasty races with opening the SMX
        while a P2P/Tag device enters the field.
      
      Bug: 8552749
      Change-Id: I433a40c918373c661abda3bc40dd36db7b233245
      476ee8a6
  7. 25 Apr, 2013 1 commit
    • Martijn Coenen's avatar
      Avoid P2P/SMX race conditions in NXP stack. · 7a499e77
      Martijn Coenen authored
      Google Wallet can trigger off field P2P field events
      and initiate communication with the SMX. The NXP stack
      appears to contain some tricky race conditions around
      opening/closing the SMX close to P2P interactions. For now,
      do not allow NFCEE access while a P2P link is still active.
      
      Bug: 8552749
      Change-Id: I7acae39bc22cebb5d79a484990dcd3fc5f3dad23
      7a499e77
  8. 19 Apr, 2013 1 commit
    • Martijn Coenen's avatar
      Don't close the NFC-EE pipe immediately on disable. · 3e38dca2
      Martijn Coenen authored
      The combination of an outstanding APDU request together
      with a "warm-reset" HCI command that we send on NFC disable
      sometimes cause a complete NFC controller lockup (depending
      on the order and timing).
      
      To prevent this, delay closing the NFC-EE pipe for a while on
      NFC disable to give processes a chance to finish their outstanding
      APDU request.
      
      Bug: 8660403
      Change-Id: I40d5f33fc41453aa3592a50721b8bef793e0af5d
      3e38dca2
  9. 17 Apr, 2013 1 commit
    • Martijn Coenen's avatar
      Fix RF field stuck on race condition. · 2526197c
      Martijn Coenen authored
      If we deactivate a tag to sleep after an NDEF check,
      we're waiting for a DEACTIVATE_NTF event from the core
      stack to unblock us. However, there is a
      code path where we can be unblocked even without a
      DEACTIVATE_NTF event. If you'd happen to remove the tag
      right after the deactivation, we'd be getting read/write
      interface errors, which erroneously unblock the deactivate
      before it has been completed.
      
      Then, we send another deactive command to go back to discovery.
      However, because the previous deactivate is still pending, the
      deactivate to discovery command gets dropped, and we stay in
      a situation where the RF field is stuck on, burning power.
      
      For now fix by adding RW_INTF_ERROR_EVTs to the list of events
      that do not unblock a thread waiting on deactivate. Ideally
      no other event is allowed to unblock, but we'll need more time
      to verify that is actually true.
      
      Bug: 8616351
      Change-Id: I381046f0320fd4b31c5ec65d54ef2e9530c3b13c
      2526197c
  10. 15 Apr, 2013 4 commits
  11. 12 Apr, 2013 1 commit
    • Martijn Coenen's avatar
      Restore discovery notification callback when (de)selecting SE. · 18cbef12
      Martijn Coenen authored
      When the host opens the pipe to the SE for communication,
      the notification callback is temporarily changed to a
      SE-specific callback. In itself this is fine, because
      there can be no other devices discovered while the eSE
      is connected.
      
      However, when disconnecting the connection from the host,
      the PN544 already resumes discovery. This is before we
      call enableDiscover(), and before we've restored the
      correct target notification callback. This race-condition
      can cause a crash.
      
      Fix it by restoring the proper notification when
      (de)selecting the secure element.
      
      Bug: 8599167
      Change-Id: I26816eb8851637de18058e974b98607e4379f55d
      18cbef12
  12. 10 Apr, 2013 2 commits
  13. 09 Apr, 2013 5 commits
    • Martijn Coenen's avatar
      Fix Beam animation deadlock. · 595ab7e9
      Martijn Coenen authored
      There was a path possible where finish() was
      being called while a screenshot was still
      captured on another thread. When the thread
      finished, it would throw up the animation
      and never exit.
      
      This fix stores the request to finish() in the
      state, waits for the screenshot thread to complete,
      and moves to the IDLE state in case.
      
      Also made the entire view touchable for initiating
      the Beam.
      
      Bug: 8576613
      Bug: 8578026
      Change-Id: I0d0158fb95918e23e32dc22c6537f5dac2aa46b1
      595ab7e9
    • Martijn Coenen's avatar
    • Martijn Coenen's avatar
      Properly reset field / listen mode flags in SE object. · b408fc37
      Martijn Coenen authored
      On NFC disable, the SE object is "finalized" but not
      destroyed. It is reused on the next NFC enable, but
      the listen mode / field status flags were not cleared
      then.
      
      Bug: 8574917
      Bug: 8489820
      Change-Id: I8e11c60eda47762404a5d5020a0c2e6ff95ead2a
      b408fc37
    • Martijn Coenen's avatar
    • Martijn Coenen's avatar
      Improve Kovio reading reliability. · 89baa714
      Martijn Coenen authored
      NfcBarcode tags such as Kovio are only activated very briefly,
      just to spit out the uid. Consequent NDEF and reconnect() calls
      by the NfcService will often fail, causing the tag to not be
      reported properly to the upper layers.
      
      For now, don't perform NDEF checking on these tags, and just
      dispatch them when we see them.
      
      Bug: 8576348
      Change-Id: If011f6e99d85a61d19d9cea15719fab90cffad43
      89baa714
  14. 08 Apr, 2013 2 commits
  15. 07 Apr, 2013 1 commit
  16. 30 Mar, 2013 1 commit
    • Martijn Coenen's avatar
      Deal with pre-MR2 PN544 NXP stack LLCP bugs. · 57a44d07
      Martijn Coenen authored
      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
      57a44d07
  17. 27 Mar, 2013 5 commits
  18. 25 Mar, 2013 1 commit
  19. 18 Mar, 2013 1 commit
  20. 14 Mar, 2013 1 commit
  21. 13 Mar, 2013 1 commit
  22. 12 Mar, 2013 1 commit
  23. 11 Mar, 2013 3 commits