When entering split-screen mode by long pressing the recents button, the
top task in the fullscreen stack is moved to the docked stack and the new
top task is the fullscreen stack is considered visible for a short amount
of time until sys-ui launches the recents activity. This causes the new
top activity in the fullscreen stack to be relaunched due to configuration
change.
To fix this sys-ui now sends an hint to activity manager to move the home
stack forward so that it can be on-top of the fullscreen stack and makes
it invisible before recent is launched and animated in.
Bug: 28470261
Change-Id: Icfd85e932fe913dfb498752b5878cc7c690fd559
This causes foucs to move to the current activity in the stack which isn't
needed. Focus will be moved when the new activity is started in the stack.
Bug: 26381750
Change-Id: Ia76962dc5ba3ce336d2a4e074d14db06eebbe78c
During stopAllRecognitions(), the internal state of a sound model was
being cleared (which made it look like the model was being unloaded).
However, the model was still loaded, so subsequent calls to load a 'new'
model would break.
Bug:28432002
Change-Id: I7090bf52704c6e46e3bb6d495d8fe4b8a1d9e2ad
Transition is not set to ready until it's executed, which could happen
a bit later after the setAppVisibility where we set up the dummy.
It is rare, but an animation pass could still slip in between, and
since the transition is not ready, it modifies the scale and show a
bad wrong frame.
bug: 27742244
Change-Id: I97fb1955e810c7c4f01dc55a28d2e4ce4f47d5eb
Do not enforce unlocked state when running on the background thread. User can
be in the stopping state or removed by the time the message is being processed.
Bug: 28471878
Change-Id: I1862849661d93b424a07ea94e80563bea7a94ce5
Previous assumption was ActivityInfo was completely initialized in
PackageParser, but that isn't the case with the ResolverActivity
whose ActivityInfo in populated in PackageManagerService.
This was causing the device to exist multi-window mode since
the default ActivityInfo.resizeMode was 0 (RESIZE_MODE_UNRESIZEABLE).
Bug: 28378995
Change-Id: I46e58d434f2a0274c461a8ff00b59ed3d2a1dd52
GmsCore will use different filenames to distinguish a security update
from a normal update. (update.zip for normal update and update_s.zip for
security update.) So, if framework observes the filename as
"update_s.zip", write command "--security" to BCB. This cmd ask the
recovery image to choose the right background string for update.
Bug: 27837319
Change-Id: I2ef12267a6be57d8a81f7f9f34c09aea54530c1f
- The PrintActivity has to handle all config changes to not loose track
close the connection to the printing app
- In the case where onDestroy is called we need to make sure to
- not do any more UI operation
- on async calls after destroy is already called, handle failure to
unbind services.
Change-Id: If21335543fbfa16ecfe77d1965b2e8a13dfa14b8
Print throttling counters per each component and time remaining before
counters will be reset.
Also adjust estimate of space needed for events serialization.
Bug: 28204408
Change-Id: Ib57a24db554645e9f933126da00ef74c23097d1c
By declaring a <restrict-update> tag in its manifest, a system package
can restrict its update to be the singular package that has the same
given hash. An update's hash is the SHA-512 across all its APKs [i.e.
for splits, the SHA-512 is calculated over the concatenation of the
base plus all splits].
The restriction only applies to system packages.
Bug: 28398205
Change-Id: Iec493fc8ef27edee53f1d437cb0caaa78782f329
The only permissions a user can control for a legacy app in
runtime style without crashing the app are the ones defined
by the platform because we have app ops only for these and
also we contorl the access to data guarded by them.
bug:27102458
Change-Id: Ifd1350d056b4fe29739ab8fdc5cbea89fa2e4037
When a job will eventually run in the foreground, the internal
scheduling needs to ignore any background network restrictions when
satisfying constraints. This also means the job should ignore the
current device doze state, since the requesting app could get the
same behavior by starting their own foreground service.
Always dispatch network policy changes to ConnectivityService first
to ensure that it has up-to-date information. Fix bugs around data
saver that were causing networks to not be marked as BLOCKED for
background apps; before this fix apps would have been spinning in
internal connectivity loops, thinking that the network was actually
connected when the kernel was actually blocking their traffic.
Offer new ConnectivityService method overloads to ignore the blocked
state for a specific UID.
Print unsatisfied job constraints to aid debugging.
Bug: 26571724
Change-Id: Iaaa17933e6dc1bf6d3dff26d0bfc12222e51e241
Always save tile specs after move and don't trigger an entire data
set changed because we are aware of all changes.
Change-Id: Ic75b9ea8ed9b7d1a11d02f9af7858f3d040ec074
Fixes: 28334197
The HUN logic delays removing notifications for a second or
two, but this makes Direct Reply stick around too long after
sending. To prevent this, cancel notifications in the sending
state immediately.
Change-Id: I9e655bb17674265761e1f6cc25acb2fb9f0c72a6
Fixes: 28421972
If the insets change, "mWidth/mHeight" won't change
as it's based on the window frame (not the surface size),
we need to track when the insets change and call
HardwareRenderer.setup with the new values.
Bug: 28257246
Bug: 28368990
Change-Id: Ida304b57c4671d010d1cf7b370674c9453841c97
I think we were getting accounts uninstalled on android devices when
SyncManagers called validateAccounts() while GmsCore was updating.
I try to prevent this by not removing accounts unless the data directory
has actually been removed (which shouldn't happen during updates).
Bug: 25611016
Change-Id: Ib526b3000ad741815d48fd020af2cc19d6205166
