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
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
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
Also fixes logBatteryStatsLocked() to output valid dump data, instead
of just a usage message.
Bug: 8708665
Change-Id: Ie0d8d90e1a470b7e1e902643333309c2cf7bdb72
This change is removing the check for debuggable build to
log fstrim events. While this was done everywhere else, one
place was overlooked.
bug:8688454
Change-Id: I354e1deebfd801f971dd91b9e7972c6ebfd093f3
Added the precondition that the device should be charging to the
existing ones of the device not being used for awhile and the
battery level being high enough. Note that even if the device is
charging, we have to check the battery level since the user can
unplug it at any time.
bug:8688454
Change-Id: I709b1620571301743dc3504a6a625e2018951bfa
Continue to layout windows that are animating away. Otherwise they
don't track with their parent windows that may be moving at the
same time.
Change-Id: Ic5b762ee538219fd6193e27dde6c245cbaa098df
