AndroidRuntimeBase (exported by libandroid_runtime_base.so) is all you need
to link against to gain the ability to do AndroidRuntimeBase::getJNIEnv()
thus minimizing build dependencies.
Change-Id: Ia7f0c94c8c02b974c068e0db34774827f96aa95b
Remove all of the pieces except the PointerController and SpriteController over
to frameworks/native in preparation for inputflinger. Those two need to stay in
frameworks/base for now because they depend on Skia currently. In the long run
they should be merged into either the InputManager or the WindowManager rather
than as a part of the inputservice / inputflinger.
Change-Id: Iebef71f3030fb3d26a5f338eb66d75bb37c17734
With this patch, framework does at least some of its text rendering
using Minikin instead of TextLayoutCache. There's a lot of stuff broken
and not yet implemented, but the phone will boot.
Changes are hidden behind USE_MINIKIN, which should be set in
BoardConfig.mk for the brave. Without that, there are changes to
signatures in JNI methods and so on, but shouldn't be any visible
changes.
This commit also introduces a new abstraction for Typeface:
The new TypefaceImpl abstraction represents the functionality that
corresponds to a Java Typeface object. Currently it is backed by
SkTypeface, but in the migration to Minikin it is a FontCollection
combined with a FontStyle. This patch introduces a USE_MINIKIN
preprocessor switch, so there is no substantial change to existing
Skia-based code, but which lets us start replacing the implementation
with the Minikin version.
Change-Id: I532c4c2d32d4f4c1f349dc1db37caa112af587ea
Merge GlRenderer and Gl20Renderer
Move GLRenderer to its own file
Move native methods from HardwareRenderer to GLRenderer
Change-Id: Ib4680b03dd98101b2a428062cc94774ff73baa75
vold now parse out UUID and label for inserted physical devices,
and reports them to framework. Add these to hidden StorageVolume
class for use by DocumentsUI and MediaProvider.
Remove last JNI method in FileUtils!
Bug: 11175082
Change-Id: I1cfcd1ade61767b103f693319ea2600008ee2e3c
Any OpenGL memory reported by /proc/pid/smaps will not be included
in the GPU GL memory count and will be considered Unknown. This is
an artifact of how some memory reporting is done in libmemtrack
and some is done in this module.
bug:10294768
Change-Id: Id8fb63b2e86520f4dbc8410573a509e66b96b13b
1. Move PdfDocument to android.graphics.pdf.
2. Changed the PdfDocument as per API concil request.
3. Updated the documentation.
bug:10461180
bug:10552565
bug:10681585
bug:10552336
Change-Id: I08e15b34cf37bb064248c887e6f59808019cafe8
Also increase the size of the buffer we do need, simplify the code, and
fix some of the error checking.
(cherry-pick of 56968581ce77d3c0ee4286da6b0d5548874934b9.)
Bug: http://code.google.com/p/android/issues/detail?id=36193
Bug: 10363597
Change-Id: Iadd2ee25469a37ddf06c3292b675a4cbcc4ecfa3
When reading from the end of a pipe or socket, there is no way to
tell if the other end has finished successfully, encountered an error,
or outright crashed. To solve this, we create a second socketpair()
as a communication channel between the two ends of a pipe or
socket pair, sending a status code with details about why the
ParcelFileDescriptor was closed.
The writer end of a pipe or socket can closeWithError() to send a
message to the reader end. When the reader encounters EOF, they
call checkError() to detect if any error occured. This also detects
the case where the remote process died without sending a success
message.
This design is also extended to support regular files on disk, using
the communication channel above to detect various remote close events
or crashes, and delivering that event to a supplied OnCloseListener.
Replaces JNI with best-practice Libcore.os calls, and deprecates
some flags to match Context.
Bug: 10330121
Change-Id: I8cfa1e4fb6f57397667c7f785106193e0faccad3
* Add a Rational class
* Can get/set Key<T> where T is a primitive (or Rational)
* Can get/set Key<T> where T is a primitive array
* Can get/set Key<T> where T is an enum (synthetic constructor only)
Not implemented yet:
* When T is anything else, i.e. Rect, Size, etc
Bug: 9529161
Change-Id: I64438024a1e8327a38dd2672652626f0ffbb70e3
No longer compile libandroidfw as a static library on the device
since it already exists as a shared library. Keeping the static
library would force us to provide a static library version of
libinput for the device as well which doesn't make sense.
Change-Id: I3517881b87b47dcc209d80dbd0ac6b5cf29a766f
* Working streaming preview requests only
* Almost everything else returns empty objects that don't do anything
Bug: 9213377
Change-Id: Ie6f02a7c0952b0f5ebc41905425b15cae221f7d3
* Working streaming preview requests only
* Almost everything else returns empty objects that don't do anything
Bug: 9213377
Change-Id: I183dd47ddd737ec2c3c374e5c3461542a97f09b0
This change adds simple APIs that enable an Android application
to generate a PDF document by drawing content on a canvas.
Change-Id: Ibac93d7c37b01a376ce7c48238657d8c7698d588
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
