1. The scheduling was relying on receiving battery level broadcasts
which however are not sent if the device is asleep. The maintenance
window was not bound and we could miss a frame if the user did
not interact the device longer than the min time between two
maintenance windows.
2. Hide the idle maintenance intents since this will be rewritten
to user services.
bug:8688454
Change-Id: I17b421b09823cb46ec218cabda19e02432d94f8c
- Replace calls to ActivityStack.resumeTopActivity() with calls to
ActivityStackSupervisor.resumeTopActivities().
- Move dim layers from display scope to stack scope. This applies to
both the animation background dim layer and the FLAG_DIM_BEHIND dim
layer.
- Move windows on stacks that are not targeting wallpaper above the
wallpaper. Otherwise wallpaper placement hides the non-focused stacks.
Change-Id: Ic6b97ac6b094672bb1ddac17ce46ea58c738f073
1. When a service dies we clear its state and remove it from the bound services waiting
for new onServiceConnected call in which to initialize and add the service. The
problem is that after clearing and removing a dead service there is a call to
onUserStateChangedLocked with will end up rebinding to the service, so we get
multiple onServiceConnected calls as a result of which we add the service twice and
it becomes a mess. Note that every time the service dies we end up being bound to
it twice as many times - royal mess! onUserStateChangedLocked is not even needed
since we cleare and remove the serivce and this method will be called when
the service is recreated.
2. When a service dies and is recreated by the system we were not adding it properly
since we regarded only services that we bond to and wait for the connecton. Now
we are also regarding service which died and are recreated.
bug:8796109
Change-Id: I5ec60c67bd3b057446bb8d90b48511c35d45289d
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
Also be sure to drop any pending package-changed broadcasts
that are targeted to a now-removed user.
Bug 8594153
Change-Id: Ib14874b4a67b968bbf6ca12ee095c85383aff324
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
...app storage size for apps w/ .so files
The lib directories are tagged with the apk install number,
so must be explicitly passed down to installd.
Change-Id: Ic37b03726f9a7405eb05956703f8198223b22595
Bug: 8365223
This change is a supplement for I77f01c70610d82ce9070d4a
The disabled state of disabled pre-installed imes should be changed
to ENABLED_STATE_DISABLED_UNTIL_USED on boot or user switch.
Change-Id: If8ff1b2b95c36d33148def2ab87bd006aa520cc0
Continuing to flesh out storage backends by adding an external
storage document backend. Still rough, but it can traverse files
and directories.
Early pass at OPEN/CREATE_DOC picker UI, which offers to traverse
any known storage backends. Supports opening subdirectories and
returning a picked file.
Change-Id: Idc3554036b3816a93d9b465ee8a620746859d2ae
If a task is supposed to launch home when it finishes but then
launches another task and finishes itself, then the new task must
launch home when it finishes.
Fixes bug 8778263.
Change-Id: I6495f6c2e99a906217e73b7b6dcae8ecff435e5f
I.e. don't bother trying to send a BOOT_COMPLETED broadcast to the
newly-installed/enabled system app when its host user isn't live.
Also use the static isSystemApp()-type helpers instead of duplicating
those tests locally.
Bug 8594153
Change-Id: I4bd0b86351d67f72c44eae8d1afce6a98f034d31
Add a test for being the top task when closing the last activity in a
task. Without this test, if the last activity in a task was flagged to
return to the home activity on completion but that activity had
launched a new task we would not go to the new task but would instead
launch the home activity.
Fixes bug 8775949.
Change-Id: I7fd9d9ebbdbff8064d894407c35190894a141ecf
Recent changes started watching for CONNECTIVITY_ACTION broadcasts
to handle the case where a network is disconnected without the
interface going down.
However, when lockdown VPN is enabled, the broadcast contents are
augmented, and all connections appear disconnected until the VPN
comes online. This caused a reset feedback loop to occur.
Since LockdownVpnTracker already handles networks being disconnected
separately from interfaces going down, this change disables handling
the broadcast when lockdown is enabled.
Bug: 8755148
Change-Id: I70a348aa97a4b22eaaf23aa5ed344de3e9a9ab0b
Specifically, send it a BOOT_COMPLETED broadcast just as it would have
received during device (or user) startup.
Bug 8594153
Change-Id: I847c16df56d038a25758e594f951bc15348edc19
