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 passes the AttributionSource to AdapterService and GattService
methods that perform scanning or discovery.
Bug: 183203469
Test: atest GattServiceTest
Test: atest AdapterServiceTest
Test: atest CtsPermissionTestCases:android.permission.cts.NearbyDevicesPermissionTest
Change-Id: Id68558624fbae69eac3a8613b9536eb6e0df75bf
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
As part of building out support for robustly matching Bluetooth LE
devices in the wild, this change checks all "fields" contained in a
ScanRecord against a given BytesMatcher.
To support matching variable-length Eddystone beacons, this change
also expands BytesMatcher to support both exact length and prefix
based rules, which are then used with rules that verify that example
Eddystone and iBeacon values can be detected with these rules:
Eddystone: ⊆0016AAFE/00FFFFFF
iBeacon: ⊆00FF4C0002/00FFFFFFFF
Expands testing to confirm all newly added capabilities are working.
Bug: 181812624
Test: atest BluetoothTests:android.bluetooth.le
Test: atest FrameworksCoreTests:android.os.BytesMatcherTest
Change-Id: I1cff8e08604436f4bba6f55aad64c3ce5969bf56
- Modify createOutOfBand to be a SystemApi, and accept p192 and p256 data objects.
- Modify OobData to become a SystemApi and to provide a Builder pattern for creation.
CTS-Coverage-Bug: 182420103
Bug: 178007935
Test: compiles and runs
Tag: #feature
Change-Id: I46aec8c2cb64a8da8957d01d32b879d60df7a31c
Merged-In: I46aec8c2cb64a8da8957d01d32b879d60df7a31c
- Modify createOutOfBand to be a SystemApi, and accept p192 and p256 data objects.
- Modify OobData to become a SystemApi and to provide a Builder pattern for creation.
CTS-Coverage-Bug: 182420103
Bug: 178007935
Test: compiles and runs
Tag: #feature
Change-Id: I46aec8c2cb64a8da8957d01d32b879d60df7a31c
They were retricted because we thought they were unused, but it turns out
that they are needed afterall.
NoNonSdkCheck: 170729553
Bug: 181103983
Test: N/A
Change-Id: Iddf7916456be27d60d2a7520d7cadcda1d04cac6
* changes:
Update Companion to new BluetoothConnectionCallback
Add BluetoothConnectionCallback to Companion App
Surface ACL disconnect reasons from native to Java
Make BluetoothConnectionCallback static
HCI disconnect commands and events have an accompanying "reason"
parameter comprising of a HCI error code. This can be useful in both
debugging and re-connection logic at the Java level.
This CL grabs the HCI codes from native and passes it up to Java via an
extra parameter to existing ACL connection callbacks.
Tag: #feature
Bug: 177668957
Test: atest BluetoothInstrumentationTests
Change-Id: Ic729140b8ffb1273a9ca53cdfd39c9f5d71e1522
