Note: This is a workaround. The read problem is that
we are making a call to Bluez when it is not ready yet.
The interface has not been registered, so dbus call should fail.
We need to fix this properly.
Dr No: Eastham
Bug: 2317784
For incoming connections, we don't have the device in the Settings cache.
After we tried to readPairedDevices, check if we added to the cache.
If we successfully added it, continue with the connections, else bail out.
Bug id: 2160617
Change-Id: I25f2afba8ef6d2c32a7940f967cf12f1321ad9e0
Reset connect timer event if profile was non-empty.
Clear profiles after unpair
mConnectAttemptedWithoutUuid
Change-Id: I5eab1270a755c6c87eb5be13a2f43dbbcd9a2f88
Settings apps invalidates its cache whenever a new scan is started.
When there is a new incoming pairing request, we will not get a DeviceFound
signal, because its not due to a inquiry scan. Thus when the pairing request
is displayed, the settings app doesn't have it in cache and hence will
just display the address. Make it query the framework when it doesn't have the name.
Add incoming pairing dialog
Add DisplayPasskey handling of pairing keyboards with 2.1 devices.
Modify code path to show errors when bonding request fails.
Misc fixes like string changes.
Split BluetoothDevice into BluetoothDevice and BluetoothAdapter.
BluetoothAdapter: Represents the local BT adapter. Operations on the local
adapter (start a scan, etc).
BluetoothDevice: Represents a remote BT device. Operations on remote devices
(pair, connect, etc).
