Remove some abstraction-breaking magic in ActionBarView and replace it
with proper resolution of the icon/logo when creating a window. The
old implementation relied on the ActionBarView's context being an
Activity.
Bug 9171554
Change-Id: Idbbb1942622195dcb55e8119f2d64287b07bb509
Load app icons using AsyncTask instead of during list item binding.
Make sorting resolved components by display name case insensitive.
Change-Id: I8e69781ed021035b9f0dac349791b3d8a674cf60
This is a new kind of key/value mapping that stores its data
as an array, so it doesn't need to create an extra Entry object
for every mapping placed in to it. It is also optimized to reduce
memory overhead in other ways, by keeping the base object small,
being fairly aggressive about keeping the array data structures
small, etc.
There are some unit and performance tests dropped in to some
random places; they will need to be put somewhere else once I
decided what we are going to do with this for the next release
(for example if we make it public the unit tests should go in
to CTS).
Switch IntentResolver to using ArrayMap instead of HashMap.
Also get rid of a bunch of duplicate implementations of binarySearch,
and add an optimization to the various sparse arrays where you can
supply an explicit 0 capacity to prevent it from doing an initial
array allocation; use this new optimization in a few places where it
makes sense.
Change-Id: I01ef2764680f8ae49938e2a2ed40dc01606a056b
Loading the avatar icons and drawing them into the sized bitmap
turns out to be quite expensive and the cost increases with number
of users. Caching them shaves off several hundred milliseconds from
Keyguard inflation time during user switching on the lockscreen.
For instance, 15ms vs. 750ms with 3 avatars on a certain 7" tablet.
Bug: 7986933
Change-Id: I3e2065bfa25aa263133ba204ca364c3b04d7c0ff
Basic implementation of an undo manager. Supports
multi-level undo/redo, building on the top undo state
as edits occur, managing multiple distinct entities in
the undo state (such as embedded objects in a document),
and saving/restoring the full undo state. Still some
work remaining on correctly dealing with dependencies
between undo states that hold multiple owners.
Also do a simple implementation of undo state in TextView
to see how things actually work. The implementation here
is very primitive: it needs a lot more work to correctly
identify when to merge undo ops, is not trying to do
anything smart with style spans, etc.
Change-Id: Ie30f4e133351e2f569ffb48c6c44a2b19cadee27
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
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
Introduces new DocumentsContract which storage backends must
implement. Backends surface a simple directory-like organizational
structure that enables a document to appear at multiple locations in
that hierarchy. Querying a document or the contents of a directory
will return a Cursor populated with DocumentColumns, which includes
simple metadata.
Adds new OPEN_DOC and CREATE_DOC Intents, and permission to protect
storage backends.
Change-Id: Ib4984bc980182b2cedbe552908e5be94604ef085
By adding these stubs, they will be automatically added to framework.aidl
in sdk builds.
This makes it easier for unbundled apps to pass these objects across
AIDL calls.
ContentValues & CursorWindow are already public Parcelables. It is an
oversight that they were not already in framework.aidl.
There are a lot of other public Parcelables that are missing from
framework.aidl. This just fixes two commonly requested ones.
Change-Id: If61e19b1206da1680413d9ea03de87a90b6d233e
Only allow through changing direction configs for drawables.
Explicitly map layout direction values to an index in the
preload arrays.
Drawables that don't vary by configuration should go in to both
the rtl and ltr preloads.
Change-Id: Ib92dd11738082a795e02d1d4191adb54702d651c
