We've seen evidence of a Binder leak, and our hunch is that it's
caused by one of these anonymous "new Binder()" sites. Adding
descriptors will help us identify the leak cause.
Bug: 192415943
Test: atest BluetoothInstrumentationTests
Change-Id: I30cd15f084cf50f67edd833b27b853c4b22e1db1
Update BluetoothAdapter#startDiscovery and
BluetoothDevice#fetchUuidsWithSdp documentation to
indicate that it queues the request if a device is
currently bonding
Tag: #feature
Bug: 187165224
Test: Manual
Merged-In: I3dbcdacff062f6c33c2fdc8d64170bf60b2fbf6f
Change-Id: I7e598417ba96a5acc9f13fb6d29a0612740f31b4
Update BluetoothAdapter#startDiscovery and
BluetoothDevice#fetchUuidsWithSdp documentation to
indicate that it queues the request if a device is
currently bonding
Tag: #feature
Bug: 187165224
Test: Manual
Change-Id: I3dbcdacff062f6c33c2fdc8d64170bf60b2fbf6f
This change contains two item,
1. public BluetoothProfile.LE_AUDIO that App can use
BluetoothProfile.ServiceLister with LE Audio profile, such as HFP, A2DP
and hearing aid profile.
2. public getGroupId API that App can use this api to identify which
devices are in the same group
Bug: 150670922
Test: Manual test
Change-Id: I32865720a8195b7c5ae29411cd1f3de95e7fc9b5
Merged-In: I32865720a8195b7c5ae29411cd1f3de95e7fc9b5
This is very simple API to allow Android to connect VCP profile.
Bug: 150670922
Test: compilation
Sponsor: jpawlowski@
CTS-Coverage-Bug: 190833351
Merged-In: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
Change-Id: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
This change contains two item,
1. public BluetoothProfile.LE_AUDIO that App can use
BluetoothProfile.ServiceLister with LE Audio profile, such as HFP, A2DP
and hearing aid profile.
2. public getGroupId API that App can use this api to identify which
devices are in the same group
Bug: 150670922
Test: Manual test
Ignore-AOSP-First: prevent merge conflict
Change-Id: I32865720a8195b7c5ae29411cd1f3de95e7fc9b5
This is very simple API to allow Android to connect VCP profile.
Bug: 150670922
Test: compilation
Sponsor: jpawlowski@
CTS-Coverage-Bug: 190833351
Merged-In: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
Change-Id: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
This is very simple API to allow Android to connect VCP profile.
Bug: 150670922
Test: compilation
Sponsor: jpawlowski@
CTS-Coverage-Bug: 190833351
Change-Id: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
Merged-In: Ib20d967fcf6797077abf83b40b0eda526e5ab89d
We've seen evidence of IBluetoothProfileServiceConnection and
IBluetoothStateChangeCallback references being leaked, so attempt to
unregister them when an object is finalized without closing.
Bug: 189091551
Test: manual
Change-Id: I23792d48d94578acd7fc7a5164a95171801ee721
Since developers can use a BluetoothDevice object can make remote
calls, it needs to have an accurate AttributionSource. Previous CLs
had updated many places where these BluetoothDevice instances were
passed across Binder interfaces, but this change updates several
remaining locations which had been missed.
Introduces new "Attributable" marker interface to offer consistent
tooling when applying AttributionSource updates.
Bug: 187097694
Test: atest BluetoothInstrumentationTests
Change-Id: Icad3b9726591f0fbad58a493cefa5a0af7648280
This broadcast doesn't contain any sensitive BluetoothDevice extras;
it only contains a single boolean indicating tethering state, so
relax it to no longer require the BLUETOOTH_CONNECT permission.
Bug: 188706031
Test: atest BluetoothInstrumentationTests
Change-Id: I2ff5c501844186a5813b2347246bbc83c190222d
accepts null input and returns an int (with error codes).
Update CompanionDeviceManager#canPairWithoutPrompt to take a
UserHandle instead of an int. Adds BluetoothStatusCodes class for all
new Bluetooth error / success codes. Moved OOB and hci disconnect
constants to the new BluetoothStatusCodes class.
Tag: #feature
Bug: 184714087
Test: atest BluetoothDeviceTest#test_setAlias_getAlias
Change-Id: Ife03506f2cf68800f5824cb5fa94fec8aa34a39c
There are some Parcelables which offer to perform Binder calls, and
when these are delivered via Intent extras they fallback to
ActivityThread.currentAttributionSource(), instead of being tagged
based on the relevant app component.
This change begins using Intent.prepareToEnterProcess() as a hook to
fix-up AttributionSource when those extras finally land in the
destination process. It uses the relevant AttributionSource based
on the Activity or Service the Intent is delivered to, which
developers have control over via AppComponentFactory.
In the case of <receiver> manifest elements, this change applies the
first android:attributionTags value to the Context used for that
BroadcastReceiver.
Bug: 187097694
Test: atest AttributionTest
Change-Id: I8f5197db7e8d7277d34f0ef2bb90bfdf1871186a
