When a system app requests "forceDeviceEncrypted" they expect their
default app storage to point at a consistent location regardless of
device FBE support. So when booting upgraded non-FBE devices, we
may need to migrate any data from CE to DE. Note that on non-FBE
devices these are just semantic locations with identical protection.
This migration *only* works for non-FBE devices; changing
forceDeviceEncrypted flags on an FBE device always requires a full
data wipe.
Bug: 26668510
Change-Id: Ic5dfeaaf2db26c385901a638ca8ec35eb3c52859
It was incorrect when disabling bt tethering. Note that this had
no practical effect because there's no callback for disabling, but
the change is good for readability's sake.
Change-Id: Id80de58b24e94ec5a8ee38d94fb3016ae7835e43
Wire up preparing of user-specific app storage to existing user
lifecycle hooks. This way we're sure the storage is ready to roll
just before we start reconciling app data directories.
This also has the nice property that we only prepare storage when
we know that keys are unlocked.
Bug: 25796509
Change-Id: Ic7df9ddbcfb1e20649d11b6cf68d424e3c365ee1
We need the auth token for FBE. In a future commit I'll get rid of the
"verify" method altogether, but no need right now.
Bug: 22950892
Change-Id: Ied2b666f0613dd97e021d3416ec06e44b9397d11
Slowly chipping away at TetherUtil to clean up this code.
This CL also adds an admin check to
ConnectivityService.isTetheringSupported to get parity with the
TetherUtil function before removing it.
Change-Id: Ibe7c5c9fb420d57e5458f77dad30e8a1e751a3e2
It is possible for the docked divider to be in an unstable location
when sys-ui dies. E.g sys-ui animating the divider from behind the
nav bar. When this occurs we reset the divider to the middle of the
screen so that the system remains in a useable state. Otherwise, the
docked stack can be fullscreen always preventing the user from going
into any other application.
Bug: 26965731
Change-Id: Icd254fffe69da4ee3f2efb4ff1d210a778703f64
This could potentially cause AM to set focus back to the top running,
and lead to inconsistent focus in AM and WM.
Also add some warnings to watch out for such cases.
bug: 26819496
Change-Id: Ie3fceeddedec4f2103a427989c9543cb3e9ff8f2
We don't want any tasks manipulated before the user is done setting-up
their device included in the tasks list we give to the Recents activity.
However, the task can be included back in Recents if it is manipulated
after the user set-up is complete. E.g. you go into the gmail activity
during setup the task will be exclude, but if the user goes back into
gmail after setup then we start including the task.
Bug: 25959392
Change-Id: I421d48f0a9bcfc782d1ef19aa2f63e8b34a668e2
- Remove the LocaleList#getPrimary() API. It had become confusing
after locale negotiation was completely implemented. For example,
it could create the confusion that calling getPrimary() on the
default locale list would provide the default locale, etc.
- Use the adjusted locale list from LocaleList.getAdjustedDefault()
in Paints created with no locale list provided.
- Change LocaleList#get() to treat out of bound indexes from both
negative indexes and too large indexes the same way.
Bug: 26984092
Bug: 26193251
Bug: 26834387
Change-Id: I75f77aea6b75e38793ed8477e5e5a4420d5e6d85
* changes:
Hide swipe-up gesture behind tuner flag
When long pressing recents and already docked, undock
More multi-window fixes
Use separate flag to suppress resizes
Only treat "null" bounds as fullscreen
Exclude stable insets from task config
Fix bug where surface was not clipped off during resizing
Fix crash in SysUI when configuration changes
- When exiting multi-window (taskOverride gets EMPTY), emulate
the same task configuration so we don't end up with unnecessary
relaunches.
- Fix flicker by not calling WM.setAppVisibility if the app is
already visible. setAppVisibility makes a dummy transition,
which sets the transformation's alpha to zero if we think that
the app is not visible, which is the case because the app is in
DRAW_PENDING state because we are waiting for it to exit the
dragResize mode, but it's really visible.
Change-Id: Ieb4f586ae86e1185b21a901c57883a1f19d58fee
When moving a task between stacks, we temporarily suppress resize
changes because while moving, the task is still in another stack
which might get resized by the docked stack because when fetching
the stack, we might create it and thus resize the other stack.
Introduce mTemporarilyUnresizable which makes it really not resizable,
regardless of whether we are force resizing our activities.
Change-Id: Ib51163a0606106fd55f5bdeecf8e53f08add4b4b
When long pressing on the recents button, we made it one pixel smaller
than fullscreen so we don't dismiss the stack immediately again.
However, this is a huge hack, and lead to problems with navigation bar
background because there we actually rely on the fact whether
the window is fullscreen or not to determine whether to draw the
navigation bar background, which lead to flickering.
Bug: 26777526
Change-Id: Ifdfcf3ad4138bc88c5164177cd20f1ff1635085f
When a app is in fullscreen, we exclude navigation bar and status bar
size when calculating the config. However, when in multi-window, and
the task was almost fullscreen, the height/width reported to the app
was actually larger than when it was in fullscreen. In order to fix
this, exclude the stable insets when calculating the task
configuration, and also fix a bug when calculating the screen layout.
Change-Id: I843ae012fb3050c79643d125550aacb6e73d27da
When dragging the divider in a way such the task size goes through
the following transition
- Half size
- Full screen
- Half size
the surface wasn't clipped off anymore. This was because in full
screen configuration, computeDragResizing() == false thus when
going full screen -> half size, we reset the draw state to
DRAW_PENDING to get notified when it has finished drawn. However,
this also broke clipping.
In order to fix this, we always put the window into a resizing mode
no matter whether the bounds are fullscreen or not.
However, this introduces an ugly flickering on the navigation bar,
when going into docked mode, because the app doesn't draw navigation
bar background in resize mode.
To fix that, we calculate the presence of navigation bar whether the
window is fullscreen, and not just whether it's resizing. For that,
we need to calculate the presence in BackdropFrameRenderer, by using
the insets just sent by window manager.
Change-Id: Idf56df4ae7fefe67d068bc2eeda8dc4d83bbefb7
Improves logging in perioidc job period clamping.
Added sourcePackage to dumpsys in JobScheduler.
Bug: 26874152
Change-Id: Iaccd6df3e70dfcae16e983893a708342fda637b3
Symptom:
When AlarmClock fires in IDLE, state is changed to ACTIVE.
But the ACTIVE state continues under some conditions.
Root cause:
Transition from IDLE state to ACTIVE state when AlarmClock fires
1. Send ACTION_STEP_IDLE_STATE intent
2. Calles onReceive() in BroadcastReceiver
3. Calles stepIdleStateLocked()
4. Calles becomeActiveLocked()
Check point (1) to change from ACTIVE state to INACTIVE
(Display On -> Off)
1. onDisplayChanged()
2. updateDisplayLocked()
3. becomeInactiveIfAppropriateLocked()
Check point (2) to change from ACTIVE state to INACTIVE
(charging -> not charging)
1. ACTION_BATTERY_CHANGED
2. updateChargingLocked()
3. becomeInactiveIfAppropriateLocked()
There are only two check points to change from ACTIVE to INACTIVE.
If state transition, from IDLE to ACTIVE,
happened by AlarmClock when display is off and not charging,
ACTIVE state will be kept and never changes to INACTIVE state.
Change-Id: I93398366307f529b9c0074ac58b19ad6e4695790
