Bug 27893230
When isTopOfTask is called prior to the window being added, it
will throw an IllegalArgumentException. This checks that the
window has been added before making the call.
Change-Id: Idd14c0f1051e16d96a0a1fa9f990f380a1f69911
DevicePolicyManager:
* getDeviceOwnerLockScreenInfo now returns CharSequence as it returns a string
for display to a user
* setDeviceOwnerLockScreenInfo
** accepts CharSequence, not String as this is a string displayed to the user
** Returns void; throws an appropriate runtime exception on failure
Bug: 27531295
Change-Id: I30528569cfa66ee76f857fbee1c3196f821718fd
Allows the user to access the task through recents since
it isn't currently visible on screen.
Also, changed recents to launch task currently in the docked
stack in the fullscreen stack when selected from recents list.
Bug: 27864383
Change-Id: I58549023920d064a30b6355367c3193ce3207bbd
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
* changes:
Implement transition for docking task in recents #6
Implement transition for docking task in recents #5
Implement transition for docking task in recents #4
Implement transition for docking task in recents #3
Implement transition for docking task in recents #2
Implement transition for docking task in recents #1
Show a scrim activity if task is not resizable
- When the docking transition is happening, defer updating
the bounds of the home stack until the transition is done.
This is to preserve the scrim which is drawn in the recents
activity.
- Use the PROLONG_AT_START infrastructure to hide the task
in recents when starting the app transition.
- When recents finally get resized at the end of the transition,
reset it's draw state so we don't move the old surface around,
and the new surface gets drawn at the new position, to avoid
flickering.
- Remove hack around not layouting docked divider if it's not
visible, it's not needed anymore and resulted in a wrong
initial position.
- Fix animation selection for docked stack divider.
- Make sure win.moved() always gets called.
Bug: 27607141
Change-Id: I76c35f09461f044a90e2c88335008284b5839cc0
Add a callback to TaskStackChangeListener which gets fired when the system
might need to inform the user that a specific app might not work in
multi-window.
Use that callback in SysUI to show a translucent activity which scrims the
activity behind to inform that it might not be resizable.
Debounce the information to once per multi-window session, to not make it
annoying.
Introduce launchTaskId to start an activity in an existing task, and protect
that with START_TASKS_FROM_RECENTS permission.
Bug: 27327287
Bug: 27431869
Change-Id: I89e8d653872ab01ba3c1e252b426e5481da0e6ca
- Changing task view thumbnail layout. In portrait, scale the thumbnail
to width for portrait screenshots, and apply the same scale to
landscape screenshots. In landscape, scale screenshots up to 1:1, and
tweak the app transition to clip the sides instead of scaling.
In both orientations, fill with the background color in the remaining
space.
- Moving some resources related to the title bar to be calculated
programmatically so that we can have different header bar sizes which
completely overlap the action bar in the screenshot in each
orientation.
- Constraining the task stack width in landscape to portrait
Bug: 27504677
Change-Id: Ic9b6fdde6dd728d9f2d20a8b89c05b3a350edfbf
- Pull most of the inner classes out into their own files.
- Move everything to a new android.app.procstats package.
- Move all of the code that was manipulating the big list
of longs to use the new SparseMappingTable class rather
than doing everything by hand. The logic is unchanged.
- Add a sequence number check to SparseMappingTable so
when the big list of longs and the individual tables are
reset, which happens somewhat independently, we can
assert when one of them doesn't get reset.
Bug 27778109
When switching from forced visibility to using real visibility,
I didn't take into account the fact that invalidating INVISIBLE
Views skip invalidation. This CL invalidates the scene root
to ensure that the transition is properly executed.
Change-Id: I092d0fe42229390927f7d1b65fc2b3ce5fc2938d
Framework edition
In a few configurations the child fragment state of a
retained-instance fragment would not be preserved correctly, leading
to child fragments not being restored. Clean this up along with live
state management issues that were leading to logged warnings during
normal fragment operation.
Bug 27371492
Bug 27477824
Change-Id: I847ac05b1757392580e008dc20c50c3ef365ca68
Ensure we have at least 3:1 contrast for the
action buttons. Also ensures that the inline
reply box background has 4.5:1 contrast to white.
Further modifies the color of the inline reply
background to satisfy a 4.5:1 contrast ratio for
the entered text.
Bug: 26831312
Change-Id: If42b1c99d1adee547d0a583c1a69c48ef7287c23
Bug 27389255
In Idf21542464a13bac7b4d4a17f6b9303f68d550c3, I had removed
a suppressLayout check from forced visibility. Unfortunately,
when the transition ends, it calls layout if there was a
requestLayout during the transition. This prevents the
suppression at the level of the individual views so that it
can be handled at the decor View level as it was before.
Change-Id: I0f016e6356fd1ceff705b122a6b4ac3f3f09600d
Previously, we show launcher when keyguard is dismissed.
It introduces these issues:
1. There can be no device lock
2. user could take a quick peek of the work app
Current behavior:
1. We now show launcher once the work profile is locked.
2. Lock profile immediately if there is no device lock
3. Add cancel "lockProfileLater" logic
Bug: 27241680
Bug: 27673460
Change-Id: I765aa22d4c8ae5017c1611f5a340a4b33d463b1e
Instead of minting it's own hander thread, have WifiManager use
the looper from ConnectivityThread.
Bug: 27432949
Change-Id: Iddeebeb8ab506c912f526c7569f304e10b9d7ab8
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
