Register docked stack listener in ActivityManagerService.
If the docked stack is leaving minimized state, check whether the user
of the docked stack is locked. If yes, show credential confirmation.
Also, we now show work challenge in home task.
And we now scan the entire top task to handle the case the work app is
somewhere in the middle of the task. (eg: open personal camera in work app)
Bug: 27565539
Bug: 28094505
Change-Id: Iaf0738f43ae916a535b17949ec0f322bbfb194dc
Framework edition
Previously we would throw away any stopped LoaderManagers when we went
to retain instances to pass along as nonConfigurationInstances during
config changes or similar activity restarts. This causes loaders to do
more work than they need to when a calling activity starts a new
activity on top, a config change happens (e.g. screen rotation) and
then the top activity is finished, restarting the caller in a new
configuration. The loaders would go through onReset unnecessarily,
potentially throwing away data to be reloaded again after the config
change completes.
Instead of throwing away stopped LoaderManagers in this case, restart
them and retain them across the config change so they can resume where
they left off.
Bug 27176186
Change-Id: Ia52c6448d2ad41dcb25d493770d9ffae20a19d2a
We need to remember task which requested to be locked
because we can accidentally lock another task after
user interacts with pinning request dialog.
Bug: 27876860
Change-Id: Ie8e607df4380dd33ea9b3474afc247b02e31de07
This is a privileged permission and is only to be used by
the core OS and related packages whose names are confusing
or misleading when shown in notifications.
The user will always be able to see the true package name by
accessing the notification inspector (longpress or swipe
gesture on the notification row in SystemUI).
Fixes: 26517701
Change-Id: I2b021c9da0757b99df76399666af263668d88070
Introducing a new callback in VoiceInteractionSession to
provide assist data for additional activities in the
foreground in a multiwindow setup.
PIP, docked windows and free-form windows (top-most)
will be queried for assist data and passed through the
new API to the Voice Interaction service.
Bug: 27718385
Change-Id: Ib4427c304611b75c2078dcb54f1f7e47ae7d9cfa
...for monitoring content providers
We now have some delays before reporting URI changes, to allow
them to batch together.
Also clean up debug output, and fix some issues with how we
were managing the content observer state.
And while I am here, fix the device idle and app idle controllers
to no longer maintain their own list of jobs, but just directly
iterate over the JobStore.
Change-Id: If3fdff23c00c2f1b99901a9be096d851562d3439
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
Added an api to delete application cache files for a specific user. This
allows settings to clear cache files for work profile apps as well.
Bug: b/25338468
Change-Id: I52d4944a7a03b6d63ad44dd6bb868aec62815eab
- Returning and accepting CharSequence instead of String
- Enforcing 100% opacity and adjusting javadocs for color
format
- Adding @ColorInt annotations
Bug: 27531295
Change-Id: Id27d4fd5e7bb4d746cc61288457eb4eb86224505
Also avoid creating a heavy LoadedApk object which will be cached
around in the long-lived system process.
Bug: 28116427
Change-Id: I1a5fc43e6d559a09088636b2fe4b5c76f08d3413
Loaders report entering the started state in two places, once from
their host callbacks and once when moving into their host fragment's
starting state. In the former, we will also deliver load results if
we're finishing a retained cycle.
In practice, the individual fragment start happens first which clears
the report-next-start flag, then the finishRetain step sees that flag
is cleared and dispatches the finished load results again. Change
reportStart to only call onLoadFinished if we are not finishing up a
retain step.
Bug 28074512
Change-Id: I85b848f7d7b239c8fac5aec8f0c91e4eea6bcebf
