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
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
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: I37a9e03ecdca6f7a6eb9d7f094e2f95a97036612
This change adds a "BluetoothPermissionChecker" that ensures that
all Bluetooth permission annotations are consistent. In addition, it
verifies that all Bluetooth public APIs have been audited to be
permission protected where relevant.
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.
This change is only annotations and has no behavior changes.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: Ie80b15b058359bf1e9a6ee881b89cb3e5b584ca1
Technically these APIs required both ADVERTISE and CONNECT, since
internally it would attempt getting the device name as part of
calculating packet lengths. These methods shouldn't require the
CONNECT permission, so we add a getNameLengthForAdvertise() method
internally to remove this dependency.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I245417bfc26d6d3a4f8be14077c7f1d271b5959e
Recent work has introduced a new "Nearby devices" runtime permission
which protects all existing Bluetooth APIs; we've done this by
defining a <split-permission> to convert the old BLUETOOTH and
BLUETOOTH_ADMIN permissions into one of three new permissions:
* BLUETOOTH_ADVERTISE: Required to be able to advertise to nearby
Bluetooth devices.
* BLUETOOTH_CONNECT: Allows applications to connect to paired
bluetooth devices.
* BLUETOOTH_SCAN: Required to be able to discover and pair
nearby Bluetooth devices.
At its core, this change begins updating the Bluetooth APIs to have
correct @RequiresPermission indicating which permission is actually
enforced internally. To ensure alignment across Binder, the newly
added "RequiresPermissionChecker" Error Prone checker was used to
discover any inconsistencies, ensuring correctness from server-side
enforcement up through to the public APIs.
In addition, since developers will continue building apps for both
modern and legacy platforms, this change introduces new auto-doc
annotations which will emit helpful consistent documentation
describing the behavior of older devices that are still using the
old permission model.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I02aa127e8e07f239561f4f2a3bbdfc6fccb82f7f
