When we have a lot of devices paired and try to enable bluetooth,
loadBondState will take a some time. During this all UUIDs would
have been registered and we would send out the Bluetooth On intent.
When Settings apps or phone app gets the Bluetooth On intent, they
try to initialize state. However, the enable Thread in Bluetooth Service
is still initializing internal state in loadBondState leading to
ANRs and deadlocks. So register SDP records as the last step of enable Thread.
Change-Id: Iaa0a773e31b9d269f4c56c4f975a0e2973e02d6e
Distinguish between NAP and PANU disconnect in BT tethering
and call appropriate functions. We were never disconnecting
NAP role devices.
ToDo: BluetoothService needs to be refactored, its become too big
1) BluetoothAdapter and BluetoothDevice properties need to be moved to separate
classes.
2) BluetoothPanProfile and BluetoothInputDeviceProfile which are handled
by BluetoothService need to be moved to a separate file.
3) Integrate PAN to the profile state machine.
Change-Id: I32a8d274f38c78931434bd9738c8f6570ba89fcf
Wait till all SDP records are registered, before sending STATE_ON intent.
This would fix crashes in Settings app when the profile manager
is not registered.
Problem:
We were sending Bluetooth State on intent before we got the uuid state
change intent from Bluez, which is asynchronous.
Hence when the Settings app queries for the profiles
to decide if headset profile was registered it would get false and
the profile manager would be null causing crashes.
This was not 100 % reproducible, well because it was a race condition.
Change-Id: I791eb63dfbc78aba4c06fd8db933069cb5fde00d
PBAP is contact transfer to cars and headsets.
This is closely tied to handsfree profile.
Without calling functionality it was of practically no use.
It will just confuse users when they see a "Dial" button
on their car systems.
Bug: 3395362
Change-Id: I4e4597f0e4b371f69ed7af95d73893554e3fb8ac
Multiple HID devices can be connected. There is no pointing
maintaining the global state. Check individual device state.
Bug: 3350904
Change-Id: I03d9a6015e39e4f9d7f68cc8bbdb19731129b4e6
When the remote Jerry device is powered down the BT link to the
phone is dropped, and the Jerry firmware in the phone quite
immediately tries to re-connect to the Jerry device. Then
SDP and Discover Services is started, fetchRemoteUuids() ->
discoverServicesNative(). This results in an asynchronous dbus
call dbus_func_args_async() that is provided with a callback
function, onDiscoverServicesResult(), but before this callback
function is used Bluetooth is disabled according to the problem
scenario above. For some reason this discover services activity
is not cleared when Bluetooth is disabled, so when Bluetooth
is enabled again the (old) callback function
onDiscoverServicesResult() is executed, but the following
getAddressFromObjectPath() fails. The reason for this is that
the deviceObjectPath parameter contains an old value,
containg the process id of the old bluetoothd (the one running
before Bluetooth was disabled). Then the new updated
AdapterObjectPath /org/bluez/<new bluetooth hd pid>/hci0/dev_
is not a prefix of the old deviceObjectPath /org/bluez/<old
bluetooth hd pid>/hci0/dev_<BT_ADDR>, which results in that null
will be used as address in sendUuidIntent(), and later on,
ending up in the BluetoothDevice constructor where and
IllegalArgumentExceotion is thrown due to
Bluetooth address = null. Then the phone will crash.
Making sure sendUuidIntent() is not called when address is null
is a work-around for the problem.
Change-Id: I8ff60bad80de3b379cef0970402943dfa4de3cfd
Try auto pairing with such keyboards.
Also fix bug where dynamic auto pairing file was not being created.
Change-Id: I93afb96fee8bc4f245f96ec5961979c620de7948
BT can come up before the system boots up and we send a broadcast,
this can cause issues.
Bug: 3259948
Change-Id: I53ce6b9851fbf611309db1f0a16768ef9f388e0c
InterfaceConfiguration changed to use InetAddress and stop with the string->int->string
conversions.
bug:2542681
Change-Id: I11c4954547333c43bb840fa0469ddde57b0d043b
SDP records are now registered with a dbus call so we don't have to wait
for initiating auto connections.
Also reduce time to connect other profiles case by 2 secs.
Change-Id: I8f0eab6a95d3bfaf11a8eb7495a024949639d7fc
1. These involve disk operations and multiple processes.
2. onPropertyChange already informs us asychronously.
3. Settings app is the only user, will have to revisit the function
if we make them public.
Change-Id: If019a83c05a0c9e625f27faf99063d33f369f0d8
Most of the time it will either be empty or have 1 device.
Using list makes it much a better API and since its supported
by the AIDL format, the code becomes much nicer.
Change-Id: I5a2508b33ba754fc8cc738409d658e1235aaf2cf
Merge commit '8b525c076068eb38106dca05513816c01d8bdddb' into gingerbread-plus-aosp
* commit '8b525c076068eb38106dca05513816c01d8bdddb':
Check for state before disconnecting.
This is a race condition exposed after we turned off some STOPSHIP
logging and some other logging. We drop the ACl connection after 2 secs
of inactivity and hence the device didn't exist -> DBUS crash.
Bug: 3097224
Change-Id: I90adbbee2c5793924037685e484027ed5cd2e0d0
