Age | Commit message (Collapse) | Author |
|
Bug: 327049496
Test: CTS
Change-Id: I4fc961a8362cafbd7dea82dc6d8ae55fb10aa503
|
|
fbd4607a8d
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/18193382
Change-Id: I43faad66df8bacdfd311791ea5e6132bdc528e95
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
1. Support RTL language.
2. Make Info, Vendor and permission icon darker in dark mode.
3. Increase the size of back button
4. Increase the size of vendor, info icon
5. Make CDM dialog rotateable in landscape mode
6. Add ScrollView for CDM dialog
7. Add a lable for Info icon
Test: atest CtsCompanionDeviceManagerCoreTestCases
atest CtsCompanionDeviceManagerUiAutomationTestCases
atest CtsOsTestCases:CompanionDeviceManagerTest
Fix: 231387185, 231387975, 231395535, 231397714, 231407966, 231407973, 231410305
Change-Id: I0df377f6b30e933ea8674291b2c8bf26c7f8ab36
|
|
Fix several issues in order to make the API CL clean. This CL doesn't
contain any API changes, but has been tested with the API changes.
1. Renamed isPermissionSyncAllPackages() to
getPermissionSyncAllPackages() due to API convension.
2. Changed return type in the request store from List to ArrayList to
fix a runtime expection that AbstractList can't add elements.
Bug: 213338076
Test: manually added and tested the user consent dialog flow in the CDM test app
Change-Id: Ibabb02e797f0ccf5288de976acfcc73ef6f67896
|
|
Inorder to make CompanionDeviceMananger to be able to
get appInfo from non-0 profile we need to add
android.permission.INTERACT_ACROSS_USERS permission and
make CompanionDeviceManager.ap platform signed.
Fix: 215160795
Test: atest CtsCompanionDeviceManagerCoreTestCases
atest CtsCompanionDeviceManagerUiAutomationTestCases
atest CtsOsTestCases:CompanionDeviceManagerTest
Change-Id: I26cebadcdef05274436cd454b4d635d82eb2b7e2
(cherry picked from commit bd4f2c2f8a520ab1ac12d0eabb694f650e8c05de)
|
|
Inorder to make CompanionDeviceMananger to be able to
get appInfo from non-0 profile we need to add
android.permission.INTERACT_ACROSS_USERS permission and
make CompanionDeviceManager.ap platform signed.
Fix: 215160795
Test: atest CtsCompanionDeviceManagerCoreTestCases
atest CtsCompanionDeviceManagerUiAutomationTestCases
atest CtsOsTestCases:CompanionDeviceManagerTest
Change-Id: I26cebadcdef05274436cd454b4d635d82eb2b7e2
|
|
Adapt CDM Association flow for new associate() API, which supports
self-managed associations.
Add support for new device profiles: APP_STREAMING and
AUTOMOTIVE_PROJECTION.
Start CDM discovery service only after UI is visible.
Lift "one request at a time" limitation (remove
AssociationRequestsProcessor.mRequest field).
Bug: 194301022
Bug: 208307075
Test: atest CtsCompanionDevicesTestCases:AssociateTest
Test: atest CtsCompanionDevicesTestCases:AssociateSelfManagedTest
Test: atest CtsCompanionDevicesTestCases
Change-Id: I6cb796c375421f101e87ad436111996495eb74d9
|
|
This change is part of defining a distinct BLUETOOTH_ADVERTISE
permission to guard the BluetoothLeAdvertiser APIs, since that's a
distinct enough of an operation from SCAN and CONNECT. It'll
continue to be covered under the general "Nearby devices" runtime
permission group.
Bug: 181813006
Test: atest CtsPermission2TestCases
Test: atest CtsPermission3TestCases
Change-Id: I8b62e4d625df1e201f12a73025cd29c431feea79
|
|
An upcoming platform change is introducing a new "Nearby devices"
runtime permission which contains the new BLUETOOTH_CONNECT and
BLUETOOTH_SCAN permissions.
We have logic in place to use <split-permission> to translate the
older BLUETOOTH and BLUETOOTH_ADMIN permissions into these new
runtime permissions, but modern apps will need to pivot to
requesting them directly as part of targeting Android S.
This change requests both the old and new permissions to avoid
breakage while the new permission enforcement is being phased in.
Bug: 181813006
Test: atest CtsPermission2TestCases
Test: atest CtsPermission3TestCases
Test: atest CtsStatsdAtomHostTestCases
Change-Id: I39f45e7d22d132d44c84017cd98e6d9e98533c7f
|
|
Using a service context has potential corner cases where it tries
to create UI using it, causing issues.
Test: presubmit
Bug: 180931292
Change-Id: I3a6d13ff69797cb5c7c2f25b810785e458d69430
|
|
Since CDM has sensitive user consent UIs, it should be able to hide
non-system overlays
Test: use a 3p overlay app with a visible overlay to ensure overlay disappears when CDM is shown
Bug: 171221090
Change-Id: I78673b7b95f4c3cb31fab180201eb17c9123bddf
|
|
|
|
With b/150232615, we will need an explicit value set for the exported
flag when intent filters are present, as the default behavior is
changing for S+. This change adds the value reflecting the previous
default to the manifest.
Bug: 150232615
Test: TH
Change-Id: Ic35ee82ec75ac7697498652725dc10188885a514
|
|
This change makes the CompanionDeviceManager visible to all apps and
gives it the ability to query all apps on device.
Bug: 149810887
Test: manual; no crash on wear setup
Change-Id: I3df2b25265a38d90fef9dae2877ceae49b7dec45
|
|
Fixes: 140524365
Test: turn off location in settings and ensure devices still shown in UI
Change-Id: Ifea696c18977fc5e94d93ced4f5d8b916587d0ec
|
|
Bluetooth scans now require FINE instead of COARSE
location permission.
Bug: 120224777
Test: Taimen with Wear OS pairing.
Change-Id: I3d7b0544b4641ed26370f495ea0a744e5a8b731f
|
|
companiondevicemanager only runs in the background
and needs location access to handle BT scan results.
Bug: 120224777
Test: Build/flash on Taimen, ensure BT scan results
show up when initiated from WearOS app.
Change-Id: Ib90eb708553f83f003256162252d418f5e91dc10
|
|
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I0a978787551a1ee5750ec5544b241d3bbfed5a7c
|
|
This reverts commit e70e6aa62c6f3a9a79624a4f9d97df95edda0364.
Change-Id: I12857cbbea0a0c74521191ab5e3713db230626ab
|
|
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I6621da388e2bf4ed97c5af2692629a321d0b63c7
|
|
Test: Ensure the device chooser dialog looks nicer.
Bug: 30932767
Change-Id: I62e6437e26f229aedb051998a8745a6e1918dbdc
|
|
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
|