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
device is bonding, we either broadcast cached UUIDs or wait for SDP to
be performed after the device is bonded.
Tag: #feature
Bug: 187157597
Test: Manual
Change-Id: I1bd694195c4e974b7cd72f81848a6343b45c98fd
When users revoke a runtime permission, they expect all interactions
to be blocked, including those protected by the BLUETOOTH_PRIVILEGED
permission.
This change finishes applying that policy to any remaining Bluetooth
APIs which didn't already implement it. To keep the implementation
straightforward, this change does "data delivery" checks when
registering for callbacks; the ideal behavior would be to wait
until data is actually delivered through the callbacks, but
RemoteCallbackList doesn't have support for AttributionSource yet.
Bug: 186405452
Test: atest BluetoothInstrumentationTests
Change-Id: Idd7be143eb8baff020a0718065293baae708041b
As part of the new "Nearby devices" permission work, the
registerStateChangeCallback() API has been relaxed to no longer
require permissions. However, we've discovered that some apps were
depending on that SecurityException being thrown, so this change
restores throwing behavior for those legacy apps.
Bug: 186176507
Test: atest BluetoothInstrumentationTests
Change-Id: Ife536dee246b300ffb3dd78aef0b059a230f3835
Wires up AttributionSource across the remaining long-tail of
Bluetooth AIDL interfaces, ensuring that developers can accurately
make calls chained back to a specific Context.
Moves "for data delivery" permission checks to happen in a single
location on each interface to ensure they're performed consistently
with the new AttributionSource arguments. Note that "for data
delivery" isn't the best name; it's designed to represent that the
requested action was performed and should result in the relevant
appop being noted for the caller.
This change has the positive side effect of ensuring that all
interfaces are consistently enforcing the BLUETOOTH_CONNECT
permission, even in the case where BLUETOOTH_PRIVILEGED is also
required; this is what ensures that revoking the "Nearby devices"
permission takes effect for all callers.
Additionally, standardizing on enforcing permissions closer to the
AIDL entry point reduces the need for @RequiresPermission annotations
to be carried around inside the Bluetooth stack.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I8023dda654e325b8bfa2f0cdb994ad63a2b429d4
To prepare for future work which will plumb AttributionSource values
through all remaining AIDLs, we need profiles to interact directly
with the specific BluetoothAdapter they were created from. This is
how we'll ensure that the relevant AttributionSource can be chained
down from the original Context they're obtained from.
This change also marks getDefaultAdapter() as deprecated to clearly
communicate that BluetoothManager.getAdapter() is the best-practice
path to obtaining a correctly scoped BluetoothAdapter instance.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I1e15170d7679019bbb6e396279d6e633e3dad4d6
This adds attribution source to BT method calls. This is now
required to allow the app ops for the new BT permissions
(BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE, and BLUETOOTH_SCAN)
to be noted.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I81598553b762e491d6364064a2e1ef41dec89bf9
Previous CLs had started passing AttributionSource values across
Binder calls inside BluetoothDevice instances, but this can cause
confuse the permission check logic in the future; we should instead
always aim to use the AttributionSource closest to the app making
the call, instead of parceling it.
This change also improves logging to highlight when we're quietly
treating a permission as denied, and when a UID is mismatched.
Bug: 186106084
Test: atest BluetoothInstrumentationTests
Change-Id: I5d3fdb3c573cb9e77474952d8680caa4c4c464eb
Recent work has been using Error Prone rules and annotations to
reflect the current state of permission enforcement across the
Bluetooth stack, and we're now in a position were we can add new
permission enforcement that had been missing.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I53ac7a4fe1dea57316048c3cac4fa237b6ba3d38
This adds attribution source to AdapterService bluetooth method
calls. This is now required to allow the app ops for the new
bluetooth permissions (BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE,
and BLUETOOTH_SCAN) to be noted.
Bug: 183626112
Test: atest AdapterServiceTest
Test: atest CtsPermissionTestCases:android.permission.cts.NearbyDevicesPermissionTest
Change-Id: I8d1fe41ca9945a3baab584f248a17b3a1eb255f7
