* commit '66442b566f51edb41f8d18f702c219c4a4c8c3df':
docs: Added landing page for Google Play Games Platform Services. cherrypick from jb-mr1-dev docs: Play Games changes Change-Id: I5117db8511907e05ddc84005bf6903251de46f71
* commit '775deb88945e4acffba2d91a89931a426d9ca4bf':
docs: Added landing page for Google Play Games Platform Services. cherrypick from jb-mr1-dev docs: Play Games changes Change-Id: I5117db8511907e05ddc84005bf6903251de46f71
* commit '9af9744319f389b6583b8c39ea65bf90afc10fe5':
docs: Added landing page for Google Play Games Platform Services. cherrypick from jb-mr1-dev docs: Play Games changes Change-Id: I5117db8511907e05ddc84005bf6903251de46f71
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
The NsdManager init was thinking it was done before the AsyncChannel
was fully setup and if the setup were slow and the app fast, the app
could make calls to the NsdManager that it wasn't ready for.
bug:8545006
Change-Id: I2cb2a7c0a1c7f3d2b81ac0f66d37346e6d2d720d
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
cherrypick from jb-mr1-dev docs: Play Games changes Change-Id: I5117db8511907e05ddc84005bf6903251de46f71
Change-Id: I0e5e2c69fc0d13b0637504e5fd3e76c1a91a0109
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
