...can't hide themselves
Propagate to notification manager the apps that are causing
the "running in background" notification to be shown.
Also hopefully this time fix the problem with the notification
being stuck. (We were mixing elapsed time in the state management
with uptime in the message scheduling.)
Test: manual
Change-Id: I9e38bff5fe69fa75b418e34c84d4e704ef70f460
- Events are obfuscated based on whether the app was instant or not at
the time each event was logged.
- UsageStats are obfuscated based on whether each app is instant or
not at the moment.
Bug 38202133
Test: Manual test using UsageStatsTest and instant apps
Change-Id: I3c74309196b88d010d317cb0dd6749bf4624e876
Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: I6001e29145f8e56deb9c4ead46c53c87c9191436
Merged-In: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Bug 38277003
The back stack was being moved while executing operations and
then again when the postponed transaction was executed. It should
only be done once.
Test: Ie47e1f2f158325b9cfd6edb5c40c65d764ff9056
Support Lib Change: I3159c2345a7b77fa82f1c602f4639f51b5a47980
Change-Id: I3b7a032e7e8a9aec565157d42dcaa7232b256ae8
When the autofill service returns a null FillResponse, the session is marked
"gone" because the service cannot autofill it. But there might be cases where
the view structure change and it's now autofillable, so need to allow users
to manually request autofill again in such cases.
Fixes: 38205945
Test: CtsAutoFillServiceTestCases pass
Test: LoginActivityTest.testAutofillManuallyAfterServiceReturnedNoDatasets()
Test: LoginActivityTest.testAutofillManuallyAndSaveAfterServiceReturnedNoDatasets()
Change-Id: I9b23c255e563dd0646bf266d31ddb10dcc4f7f6d
Add registration for the camera lift trigger sensor and handling for its
events to GestureLauncherService
Test: Confirmed camera launches on lift gesture if setting is enabled
(and other pieces are in place)
Change-Id: Ibfad2040409d86af2d019e2ce97ab546bef9ba78
- Now keep track of the time a job was enqueued, and order
the pending list by that.
- Added configuration constants for rescheduling: maximum
times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
JobStatus was old and didn't require the caller to hold a
lock, so made a copy, which didn't contain all the data we were
interested in. Now with our simple locking, we can just make
that require the caller hold a lock and return the real
JobStatus object.
- Include oom_adj and procstate when printing information about
processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019
Only do access checks if there's a cache miss. If there's
a cache hit then those checks have necessarily already
passed once so we don't need to repeatedly do them
on every access.
Before:
timeCachedGetSharedPreferences_mean=126084
After:
timeCachedGetSharedPreferences_mean=362
Test: ran perf test
Change-Id: I51f0186f8e66c05ea0e5a457930377d1460dea17
The return result from starting activity actually represents two
pieces of information. First, it conveys whether the activity
started. Secondly, it conveys whether there was a fatal error if
the activity did not start. Many parts of the code assume that a
value greater than or equal to the defined success means that the
activity successfully started. This is not the case as there are a
number of results greater than success where the activity does not
start.
This change addresses the issue by introducing three distinct
result ranges. The first represents results where the activity
could not start due to a fatal error. The second represents results
where the activity did not start due to a non-fatal error. The last
range represents successful activity starts. Two convenience methods
have been added to ActivityManager to return whether the result
represents a fatal error and whether the result was successful.
Change-Id: Ifaf844c353641a28b03b3c2d7b6be053fd9b8b44
Fixes: 38021882
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
