AutofillManager keeps track of which views the AutofillServiec is interested to
save, so when these views are gone, the session is finished.
But when the AutofillService returns a dataset whose views it can not save,
the FillUi for these views are not hiding when the views are gone. This CL
fixes this issue by:
- Keeping track which non-savable views should be tracked.
- Pass the view (instead of it's id) when the UI on such views should be hid.
This CL also optimized some AIDL and internal calls by avoiding the creating of
unnecessary Lists.
Test: manual verification with Snapchat
Test: existing CtsAutoFillServiceTestCases pass
Test: new tests on MultipleFragmentLoginTest pass
Fixes: 38199452
Change-Id: I78fa357962dbc6667146d8e08cd6bacb63e0f337
This is a potential fix for a global reference leak in the
system process by a JobService in an app.
Bug: 38467796
Test: manual
Change-Id: I8756c39ac77bead068c88fce750c4024f9ac1c03
Turns out there was another path in to the activity manager
to trigger a PendingIntent, which needs to be modified to
now also pass in the whitelist token of that pending intent.
Test: manual
Change-Id: I755ff87db1b782fa6974d404dcb490786053c5e0
...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
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
- 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
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
- Ensure that an activity that is auto-entering PiP when hitting Overview
does not show up in Overview. This is done by listening for the
onActivityPinned() callback from the system, and remove the pinned task.
- Ensure that we show the PiP task in Overview after it is dismissed, while
Overview is open. This is done by listening for the onActivityUnpinned()
callback from the system and refreshing the task list similar to when
the multi-window mode changes.
- When launching from a PiP activity, or launching back into Overview where
the next task should be PiP, then ensure that we scroll the stack to the
front so that the first task is fully visible.
- Fix two lingering Overview issues, when there are no handlers (ie. with
dynamically registered handlers), ensure that we call pre/post dispatch
callbacks (otherwise it could cause animated events not to work correctly).
Also, ensure that we don't update the dummy stack view TaskStack without
clearing the stack first, since we may be modifying the same stack
that the activity consumed when starting.
Bug: 34185886
Bug: 38207296
Test: Launch PIP activity from hitting Overview in the various ways
described above
Change-Id: I699e655106e6ed7206e163f9d3c15477bbfd52ef
Because we were relying on the output to go in the right direction
already, this could be wrong. We're now only following the given
lightness direction if it is even possible to satisfy contrast.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java
Change-Id: I06d934a6b5c328ebbf0cf707030b0d707ccb5ab4
Fixes: 38182819
Previously the colorization wouldn't work if the notification
was not targeting N and above, since for those the
remoteviews would be built into the notification and we couldn't
colorize it.
Test: runtest -x packages/SystemUI/tests/src/com/android/systemui/statusbar/notification/MediaNotificationProcessorTest.java
Fixes: 38147364
Fixes: 37743600
Change-Id: Iabad02a4515c42676c0660293e58cf62d5d8ff88
- for apps that don't target O but use channges
- Rename misc channel if it already exists
- Add method so settings can tell if it needs to show legacy config
Bug: 38120923
Test: runtest systemui-notification
Change-Id: I5c7c077321f1792851b003b9d9e42505dddd50f0
This is safe for O as all updates come from a trusted
source.
Change-Id: Iab8ec1e68f8f9f9e345ebf4d5e44718191cc49e6
Fixes: 37986254
Test: runtest systemui-notification
