An accidental side-effect of introducing the XML content file and its
domain semantic checking was that the shared-storage domain got
dropped on the floor. Now the mechanism understands what it means
again.
Bug 29999884
Change-Id: I22b99c96869683d1a92430f237dda54b170b8f60
Updates to progress bars are the main culprit in system
performance events caused by apps spamming the notification
service. Rate-limiting only updates allows us to set a lower
threshold wihtout the owrry of mistakenly dropping bursts of
notifications being quickly posted after a network sync.
Also reduce logspam caused by the rate-limit events.
Bug: 30132961
Change-Id: I49acda6a2831204da45e899ddd3d62d571d7174b
- When the cached UID state says a UID is in the background,
check with AM and get the latest state, since the state
might just have been changed.
Bug 30640208
Change-Id: If448f6f21f290fa0fc13550d9c740f56aa8bfce0
A lot of calling framework code expects a null value on failure,
and didn't catch the previous exception. There were some strange
corner cases where previously a null value was not checked for
in framework code, allowing the null Resources object to be
returned to the caller. Introducing an exception changed the
semantics and can crash certain apps.
Bug:30422475
Change-Id: I51d34ae43c9ec605a8790989c56cf85b815ff5b8
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Icc8f8dbd060762ae1a7b1720e96c5afdb8aff3fd
- Log when hasTopUi state changes
- Add hasTopUi to dumpstate
- Only allow persistent processes to honor this flag
Bug: 30292998
Change-Id: Ifb481c8d50b102ea4cac3078ea3eb39e45c08259
Bug 30230667
Ensure that pre-N applications initialize in the proper order,
but allow N and above applications to be created prior to
asking for a Transition.
Change-Id: I859f22a7c5518e4b496cbd7ee58ef1d3206a5c86
(cherry picked from commit 78d38fc839)
The previous path "worked" but left the wallpaper bookkeeping with
incorrect SELinux labeling, which led to cascade failures later on
when apps tried to set new system wallpaper imagery or read the
current image for the picker UI.
We now (a) explicitly label wallpaper files in all change cases,
(b) let the restored imagery flow through the full crop path, as
should have been done in the first place, and as a result (c) lift
the size restrictions on the source image, because now we are doing
a device-appropriate scaling operation on the image.
The "when to crop/scale" test has been slightly relaxed such that
a restored image of exactly the right size now longer triggers a
superfluous factor-1.0 scaling operation.
Bug 30361282
Change-Id: I9a305eea2227952493f64ab78862648cafb816ff
Also fixes a bug which didn't set the correct renderThreadTid
when restarting an app (for example, when SystemUI gets killed).
Bug: 30292998
Change-Id: I420bee8a11d430b1e52ded050536e56a85a48800
Fixes a bug where onServiceDisconnected could be delayed
such that it would be dispatched after the connection has
already reconnected.
Bug: 30182617
Change-Id: I6e3fc2f125a477bb342de601530c254c34ffb4f7
When app is transferred from split-screen mode to fullscreen
and the app doesn't handle configuration change, relaunch is
scheduled with non-empty override config corresponding to
fullscreen size. This override config is then used in instance
of DisplayAdjustments and in size/metrics calculations in
corresponding methods of Display class. To obtain correct values
in fullscreen mode override config should be empty.
Configuration change that follows relaunch has correct (empty)
override config, but it is not really applied for resources
because final config matched current activity config.
Bug: 30185335
Change-Id: I95fb69e0c229c2c6b0c1cd79e9d60556de579ae4
Also fix b/30230996.
TODO: Support the sourceBounds argument to LauncherApps.
startShortcut().
Bug 30218829
Bug 30230996
Change-Id: Ibb6c59d5b7c0a320c21d09436d016d0eac94644f
