Validate writeDescriptor and writeCharacteristic methods at API invocation
for non null initialisation.
Bug 18395071
Change-Id: I411a57b77981310d8db1f98c67e03b4327c93339
The HeadsetService is now bound directly by the BluetoothManagerService.
The IBinder object related to the HeadsetService is then given back to
the BluetoothHeadset and to the client app. This change makes the
HeadsetService available for managed profile clients.
Bug: 16968338
Change-Id: I016d1837e4f987c0fab1fc2c64cb06eb91b24d87
When a client requests to update the LE transport MTU, the server
currently does not get notified and can therefor not properly size
notifications appropriate to the current MTU.
Bug: 18388114
Change-Id: I515bfc2cc9846490d57de71860f41ea9a61fa243
non-connectable adv.
When the advertisement is non-connectable, give back the
bytes to the advertiser where the adv flags would have been.
This increases the non-connectable advertisement's advertise
data from 24 to 27 bytes.
Bug:18359570
Change-Id: Ia3cc48dca50cc3c51095ee92a489f143f6d350b1
The close in finalize() is pointless, as finalize() will only be called
if there are no references to BluetoothA2dp. Until close() is called,
BluetoothManagerService will have a reference to BluetoothA2dp,
preventing garbage collection and finalize() to be called. This means
finalize() is not serving its purpose of cleaning up in cases close()
is not called, as finalize() is only called if close() has already
been called.
Actually calling close in finalize here means unregistering the already
unregistered mBluetoothStateChangeCallback which can lead to crashes
when pairing/unpairing BTH. A typical crash would look like:
*** FATAL EXCEPTION IN SYSTEM PROCESS: BluetoothManager
java.lang.NullPointerException
at android.os.RemoteCallbackList.unregister(RemoteCallbackList.java:143)
at com.android.server.BluetoothManagerService$BluetoothHandler.handleMessage(BluetoothManagerService.java:780)
at android.os.Handler.dispatchMessage(Handler.java:99)
Change-Id: Ib65962917ecbacf7900d7fe540057e6915f0532d
To clarify that BluetoothLeAdvertiser object will return null
when BT is off OR if the hw doesn't support these capabilities
bug: 18006072
Change-Id: I635d7971711a3cae7c58f7a0636faf9a03f19970
Currently, users' preference in phonebook and call history or message
access per each Bluetooth-paired device is stored in Settings application's
shared preferences.
However, some privileged applications other than Settings need to access
such data. So we decided to migrate the data from Settings application's
shared preferences to Bluetooth application's.
Bug: 17158953
Change-Id: I3771f03eaea3f57cf60d93ab9fd41c9eb3e1e99c
Post callback to main thread to execute. In general we should avoid
running app's callback method from binder thread as the callback method
may block.
Also removed callback from advertisers on stop advertising callback.
This fixes the issue of not being able to restart adv for limited
advertising.
Bug: 17045567
Change-Id: I56cd2bdf4b1ad120a0358fa4065ad77be4bff144
Root cause of the issue:
Client registeration was done on caller's thread, while
onClientRegistered was called from binder thread. There is a slight
chance that onClientRegistered was called before registerClient
returned, causing a premature notifyAll before wait was called.
By forcing acquiring the same lock now it's guaranteed wait would
happen before onClientRegistered callback was executed.
Bug: 16707401
Change-Id: Ic60adec475085741d14ecd2d2bb462246f88da58
Fixes b/16528460
This allows Advertiser and Scanner to be reused after bluetooth recycle,
which follows same behavior for BluetoothAdapter.
Also prints manufacturer data array for ScanRecord.
Change-Id: I78bca40ac294433782a054bf2a00a775dac02d96
