| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Bug: 206121418
Test: Compile
Change-Id: Idb55371e9d678296fe46e5f4231ec2d12ec8b978
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since Bluetooth is becoming a mainline module, it can no longer call the
allowBlocking hidden api.
Instead, all interface are moved to be oneway and use a synchronous data
to handle the return value.
Bug: 200200870
Test: Build + start Bt and play something on speaker
Tag: #refactor
Change-Id: I776a6322faadca1504bce24f2b6b041e756b6448
|
| |
|
|
|
|
|
|
|
|
| |
Attributable is called by bluetooth and it's hidden.
By copying into bluetooth we are now allowed to call it
Bug: 210467788
Test: build
Tag: #refactor
Change-Id: I73ea07c9439988ab5477c82799f718c6d81513be
|
| |
|
|
|
|
|
|
|
| |
BYPASS_INCLUSIVE_LANGUAGE_REASON=exact wording for constant from BT specification
Bug: 150670922
Tag: #feature
Sponsor: jpawlowski@
Test: compile
Change-Id: If0e5861e882636afba6a29c0ae34362d179035ea
|
| |
|
|
|
|
|
|
|
| |
Bug: 150670922
Tag: #feature
Sponsor: jpawlowski@
Test: Manual
Change-Id: Ib385b24d6b10754d9cadea2363e81c78b4382a44
|
| |
|
|
|
|
|
|
|
| |
Bug: 150670922
Tag: #feature
Sponsor: jpawlowski@
Test: Manual
Change-Id: Id9145e6e2631d0eae102bcc502ae4aa233b61d7b
|
| |
|
|
|
|
|
|
|
| |
Bug: 150670922
Tag: #feature
Sponsor: jpawlowski@
Test: Manual
Change-Id: Icb2e7681e4b5e7ba2e796671ff6f4c59bbff29d7
|
| |
|
|
|
|
|
|
|
| |
Bug: 150670922
Tag: #feature
Sponsor: jpawlowski@
Test: Manual
Change-Id: I7782f95cca7478dcd585d435f585bba6a453f1ab
|
| |
|
|
|
|
|
|
|
|
| |
Patch implements connection state handling for LE Audio device group.
Tag: #feature
Test: Set LE audio device as active
Sponsor: jpawlowski@
Bug: 150670922
Change-Id: I11222ca07e265ac8b6dc3c21650874ebeffa473c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This is boilerplate code for Bluetooth LE Audio profile
Bug: 150670922
Test: compilation
Tag: #feature
Change-Id: Iadc3af12fd8b2808db2f4e933a1906a819824ade
|