There mas a missing defensive copy causing false positive detections of
"associations not changed" case, leading to xml file not being updated once
at least one record is present
Bug: 30932767
Test: Associate at least two different devices and ensure the xml has both.
Change-Id: Ic0dc615dd2b847e137555c1084c616831b4dde83
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
This allows apps to listen for beacons, etc., without having to
run a foreground service and register a callback. They can instead
register a PendingIntent which will be fired when scan results
are available or when an error occurs.
Bug: 37254611
Test: WIP
Change-Id: I1793eee67ff0211370ed6fc38be4d95a4c5853f5
(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
This allows any service to interact with JobScheduler, which
should give us a lot more opportunity to do interesting stuff
in the support lib.
Test: bit CtsJobSchedulerTestCases
Change-Id: I0843e8b212a0a63a17558b837b899b90cac22805
This api will return the timestamp at which this activity start was last
initiated by the system. Implementation is wip.
Bug: 9058261
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases -t \
android.app.cts.ActivityStartTimeTest
Change-Id: I396458ecefbb09108f414b95f9c0beb6d609a4e1
- The session might be gone by the time the handler is called, hence check
the sessionID
- Access getClientLocked() and mSession only under mLock.
Test: cts-tradefed run cts-dev AutoFillServiceTestsCases
Change-Id: I445a24557589afadb1f5372b63ef9db88021b609
The method now accepts a locale for overriding the labels
"Suggested", "All regions", etc.
Fixes: 31257462
Test: Manual
Change-Id: I6e8c95d8d3e7b05a284b171f2cf2819d32e53d8d
This patch changes how callback unregistration works in order to be
consistent with undocumented use cases currently de-facto supported
by the API (although in a buggy way):
- callback recycling: releasing then reregistering a callback again.
- multiple request registrations with the same callback.
The second use case is not desirable but needs to be taken into account
for now for the purpose of correctly releasing NetworkRequests
registered in ConnectivityService.
In order to support request release in both use cases with minimal
amount of complexity for the time being the following changes are done:
- request to callback unmapping is done synchronously at callback
release time.
- all requests associated to a callback are unmapped at callback
release time.
This fixes the following issues:
- a callback stops being triggered as soon as it is released.
Otherwise when recycling the callback immediately, it is possible
the previous request associated with it triggers it, confusing the
app.
- when a callback is registered multiple times, the requests are not
leaked.
- when a callback is registered multiple times and then released, the
N-1 first registrations do not trigger the callback anymore.
In the future it would be desirable to enforce the intended 1:1 mapping
between callbacks and requests at registration time.
Bug: 35921499, 35955593, 20701525
Test: - added new tests in ConnectivityManagerTest to test releasing,
recycling, and a disabled test for no multiple regristration.
- new tests catch regression causing b/35921499, b/35955593.
Change-Id: Ia0917ac322fc049f76adb4743bc745989fed6d26
