1. 07 Nov, 2013 3 commits
  2. 06 Nov, 2013 4 commits
  3. 04 Nov, 2013 1 commit
  4. 03 Nov, 2013 1 commit
  5. 02 Nov, 2013 2 commits
  6. 01 Nov, 2013 2 commits
  7. 29 Oct, 2013 2 commits
  8. 24 Oct, 2013 3 commits
  9. 23 Oct, 2013 3 commits
    • Zhihai Xu's avatar
      cbd63326
    • Zhihai Xu's avatar
      Do not deregister HH GATT IF in bta_gattc_disable for hid over GATT · 36b68652
      Zhihai Xu authored
      The root cause is bta_gattc_disable de-register the HH GATT IF
      which cause  bta_hh_cleanup_disable called
      before we receive BTA_HH_INT_CLOSE_EVT.
      The fix is "don't deregister HH GATT IF  in bta_gattc_disable and
      let HH module to de-register the HH GATT IF by bta_hh_le_deregister".
      because HH GATT IF is a special GATT IF
      which won't be exposed to uplayer and
      HH GATT IF belong to BTA HH module, it should be managed by BTA HH.
      bug:11284861
      
      Change-Id: Ia14cd2be3f3548a4d1e2dcfbc89fa3a75d9651db
      36b68652
    • Andre Eisenbach's avatar
      LE: Only prepend valid HID report IDs · 0ef5e932
      Andre Eisenbach authored
      If a remote HOGP device does not supply a valid report ID, do not
      prepend it to the HID report.
      
      This fixes interop issues with various LE mice, where the cursor would
      not move on screen as expected.
      BLTH02618447
      
      Bug:11342157
      Change-Id: I7832bb091654a5625f37b1531bd80fad9bbe6a51
      0ef5e932
  10. 20 Oct, 2013 2 commits
  11. 17 Oct, 2013 1 commit
  12. 12 Oct, 2013 1 commit
  13. 10 Oct, 2013 2 commits
  14. 09 Oct, 2013 4 commits
  15. 07 Oct, 2013 2 commits
    • Andre Eisenbach's avatar
      LE: Improved handling of illegal GATT PDUs · ccf9c15f
      Andre Eisenbach authored
      Do additional length checks when handling malformed messages. These
      messages are never valid, and should be dropped if seen.
      
      Before starting to parse out PDU content, it is verified that the
      buffer contains sufficient bytes and error condition is returned
      if this is not the case.
      
      Bug: 11045073
      Change-Id: Ifb792d1575e0514f33e75ed73247ea638807901e
      ccf9c15f
    • Matthew Xie's avatar
      Add toyota venza to the auto pair blacklist · fdb11682
      Matthew Xie authored
      bug 10904063
      
      Change-Id: Ia14f00eb45ff8ba1d7df73db575aff552af7677a
      fdb11682
  16. 04 Oct, 2013 1 commit
  17. 29 Sep, 2013 2 commits
    • Zhihai Xu's avatar
      Crash after unpairing BT keyboard · fac9fef5
      Zhihai Xu authored
      The crash is caused to access an array use invalid index value.
      The solution is to check the index before access the array.
      bug:10992001
      
      Change-Id: Iad83764de9545fb2348105cf9cd9d32a85f1d654
      fac9fef5
    • Zhihai Xu's avatar
      Failure to start playback on A2DP sink after connection · 379743be
      Zhihai Xu authored
      This is what happen:
      after Headset is connected, we call start_audio_datapath which will send AVDTP_Start command to Headset,
      Headset reject it with bad state. Bluedroid stack will ack failure to start_audio_datapath.
      The next time we write audio data to bluetooth, we will call start_audio_datapath again to send AVDTP_Start command to Headset
      Headset reject it with bad state again. Bluedroid stack will ack failure to start_audio_datapath.
      When the third time we call start_audio_datapath, right at that time we receive  AVDTP_Start command from Headset.
      Handle AVDTP_Start command and Handle start_audio_datapath are in two different threads.
      Handle AVDTP_Start command is in btu_task thread.
      Handle start_audio_datapath() is in btif_task thread.
      We have race condition in this case
      Because when  btif_task processed BTIF_AV_START_STREAM_REQ_EVT(triggered by start_audio_datapath),
      it don't know we receive  AVDTP_Start command which is processed in  btu_task.
      btif_task will send a message BTA_AV_API_START_EVT to btu_task, which will be handled by bta_av_do_start.
      AVDTP_start command from headset is handled by bta_av_start_ok.
      bta_av_start_ok will send BTA_AV_START_EVT with suspending true to btif_task and send AVDTP_Suspend command
      to headset to suspend the AVDTP for reconfiguration purpose.
      
      in bta_av_do_start, we will check whether the AVDTP is already started, we will know the AVDTP is already start at this time because
      bta_av_do_start is also running in btu_task. We will send BTA_AV_START_EVT with success to btif_task.
      
      In the btif_task, BTA_AV_START_EVT will be processed by btif_av_state_opened_handler:
      For the first BTA_AV_START_EVT with suspending true sent by bta_av_start_ok, it will ignore it:
      if ((p_av->start.status == BTA_SUCCESS) && (p_av->start.suspending == TRUE))
                     return TRUE;
      For the second BTA_AV_START_EVT with success sent by bta_av_do_start , it will ack success to start_audio_datapath, and change to
      BTIF_AV_STATE_STARTED/BTAV_AUDIO_STATE_STARTED, after receive success ack from bluedroid stack, we will start send Audio data to bluetooth.
      
      At last we received  AVDTP_Suspend response accept from Headset, we will send BTA_AV_SUSPEND_EVT to btif_task, which will be
      handled by btif_av_state_started_handler. It will call btif_a2dp_on_suspended and call audio_state_cb  with new audio state
      BTAV_AUDIO_STATE_STOPPED.
      so The state between bluedroid stack and audio data path is out of sync.
      The fix is to send failure message if we know we suspend AVDTP in bta_av_do_start,
      also make sure we won't miss acknowledgement for pending start if we exit opened state,
      to avoid audio data path dead lock.
      
      bug:10953908
      Change-Id: I1704839977324b7c4e234eb843cddf3719e10d2c
      379743be
  18. 18 Sep, 2013 1 commit
  19. 17 Sep, 2013 1 commit
  20. 14 Sep, 2013 2 commits