We only stop scanning on timeout but don't limit the time the
user has to select a device.
So timeout != failure. Cleaning that up from javadoc to avoid confusion
Fixes: 74080737
Test: proofread
Change-Id: I36b2d96f85c3c15c20742b954a0b34956f23d6f8
Fixes: 63383044
Test: Ensure all fields of CompanionDeviceManager.CallbackProxy are
null-checked in onSuccess and onFailure
Change-Id: If95a46686f74d184bccfcb2d8c8195add4747a07
Fixes: 62678460
Test: Tap recents while the dialog is shown and ensure it's not in a
separate task
Change-Id: I0572ddc84d76643ac8a373939273c221ff20676f
The root cause of the exception was that the activity destroy listener was
reacting to any activity being destroyed instead of just the one used with
the CompanionDeviceManager
Fixes: 62549525
Test: Ensure the attached bug no longer reproduces
Change-Id: I2f977e9ac9176247f5be9d08d19b3875f2b4a703
This is required for migration scenario, where device(s) are already
paired(and thus no longer discoverable) but didn't go through companion
flow.
This also fixes a bug with filtering by mac address, which is also relevant to
the use-case of associating a specific device
Test: Pair with a device first, and call associate with a filter with its MAC
address and single device requested. Ensure the device is found.
Ensure only that device is ever returned when filtering by MAC address.
Bug: 62487084
Change-Id: Ic7cc6affc0648ad85b15620e8c3aba4b9fc91aa1
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
Fixes: 37356792
Test: Call associate many times rapidly with alternaring request value
Ensure no stale result is displayed
Change-Id: Icaa230d9ad468119e20b3de89f19c36531c2c60f
Test: 1. Trigger the confitrmation dialog.
Ensure it looks exactly like the one from settings.
2. Call an API without associating the appa first
Ensure exception is thrown with a message mentioning the need to associate 1st
Change-Id: I94d4116e1988db869ed445ae3fd018c50590e3f4
This effectively treats chooser activity pause event as cancel.
Bug: 30932767
Test: Install two toy apps and call associate API from both.
Ensure foreground app always end up showing fresh data.
Change-Id: I7f5742e9878245550f678efd244bf84c427baef3
(when such filter is not provided)
See change in BluetoothDeviceFilterUtils
Bug: 30932767
Test: Call API with a BLE filter with no raw bytes filter, matching some device.
Ensure that the device eventually shows up.
Change-Id: I4397fa33dd0c48771c8a754791a171f2d0bd64eb
1. Listen to calling package binder death stopping the scanning on that.
2. Don't restart scanning when a request with the same values was made.
Bug: 30932767
Test: 1.:
- Using a test app start scanning and kill the app.
- In debug mode ensure that DeviceDiscoveryService#stopScan gets triggered
2.:
- Start scanning and rotate the device while device chooser is visible
- Ensure no visible loss of state is happening
Change-Id: If126a2c963da90172a956fbd88e6b3dcd7ac8b01
There was a typo causing the feature to be falsely detected as not present.
Test: Ensure feature presence is now detected correctly
Bug: 30932767
Change-Id: I44d137e89546596058b272e8eeaccc0a1db21aef
1. On package removed -> remove all its associations
2. On package updated -> if had associations, update special access permission
in accordance with (potentially changed) permission entries in manifest
Bug: 30932767
Test: 1. Remove app, and ensure xml entries for it got removed.
2. adb install new version of app without special permissions in manifest, and
ensure whitelist removal method got called
Change-Id: I87261c05ddcf40a18332d160b44ee2f8284df5e4
Bug: 30932767
Test: Add just the feature gating first, ensure Context#getSystemSetrvice now
returns null.
Add feature in the configuration files, ensure companion device feature works again.
Change-Id: I4ad2d52f7877eae0e951f43ddbb23881d5de8d8b
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
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
Bug: 30932767
Test: Ensure file not exists -> query associations -> ensure result is empty list
Associate device -> cat xml file -> ensure record appears as extected
Disassociate device -> cat xml file -> ensure record is no longer present
Change-Id: Ibe456a6d9292e05e2391f5138e43fdaa37f87e1b
Companion apps can declare they want background access and
background execution exceptions via dedicated permissions
in their manifest. If such a permission is requested we
auto-grant the corresponding exception after the user has
chosen a device from the companion UI. These permissions
are appop ones allowing us to use the app ops for gauging
whether the user has made a change after we auto-granted
the permission since we would like to revoke these special
privileges when the app disassociates itself from the
companion device if the user did not make an excplicit
choice otherwise.
While at this auto-grant fixed location permission to the
companion device discovery service.
Test: manual
Change-Id: I46ee4291e5e5a8f7613f0dd75eb61d6b9341f306
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
