Bug: 17947547
Pull the ResourceCache (aka, ref-counting side channel) out of
Caches so that DisplayListRenderer doesn't use Caches, avoiding
the risk of instantiating Caches on the wrong thread or
without a GL context
Change-Id: I7d63b70b3b0a0163308c5dedd6ef255eadebe8fd
- Add in category for graphics driver, and knowledge about it
for N5 (more devices will be added later).
- Renaming the labels for the .oat and .art files to be just
that, so it is clear what they are talking about.
Change-Id: I663ca8bd2febce41fcdde74b0d3a96ef9325edf1
If apps are writing malformed content (typically not a PDF file) or if the
PDF content they provide to the print system is password protected, are now
crashed as both of these are app bugs.
bug:17636435
Change-Id: Ifce6a3199e587448dd38f6a84290a965c24b698b
Bug: 17208461
* Switch Layer to be VirtualLightRefBase instead of
Caches' side-channel ref-counting
* Include active layers in gfxinfo dump
* Run gfxinfo dump on the correct thread
* Dump gfxinfo on Layer creation failure
Change-Id: I28d195699e2334518e215ab28c7a17355aee9678
When rendering a PDF file for print preview we take into account
the selected print options such as paper size, orientation, etc
without modifying the document. To print we send the doc in its
original form and the print options so the print service can apply
the necessary transforms in addition to the optional custom options
it supports. When saving to PDF we have to actually change the
document as we act as a print service.
bug:13545980
Change-Id: Icdcecf962bec6ff742cc6015df5af9d9086ce760
Also, assert that we always have a private application directory for non
system_server case.
Bug: 18027433
(cherry picked from commit 79ec4c15ab941419d21700a9734f5238b975c31a)
Change-Id: I9ce578949dbe522d5033465df7ca49fdd3aa3cbf
This patch changes the profiler system property
"dalvik.vm.profile.max-stack-depth" to "dalvik.vm.profile.stack-depth"
so that the length of the option is less than PROP_NAME_MAX.
Bug: 17294224
(cherry picked from commit 4d033e1c44c1b94ea5311713b8cc8bfb56bdcdd2)
Change-Id: I10dd0b3bfa46b836def437a3822f6c48538167dd
Bug: 18099195
Don't use EGL_SWAP_BUFFER_PRESERVED on surfaces that will
never benefit. Also clean up some confusing naming
Change-Id: I674ca64e0464a3282cff79e5ecd350d08f47c014
We now use Mapped to not double-count cached pages that are
mapped in to app processes. Also read in some more values that
count towards kernel RAM use, and count buffers as free rather
than used RAM.
It also looks like the zram accounting is broken -- it was never
collecting the total zram reserved space. I need to figure out
how I was finding that before.
Change-Id: I883f6fc93966774b5c7d2801d1801666dd11ed41
Recently we added a way for SkImageDecoder::decode to distinguish
between successfully decoding the entire image and only partially
decoding the image (see https://codereview.chromium.org/647023006).
Only consider a call to decode() a success if the image was completely
decoded. This matches pre-L behavior, and lets the caller know that
they need to try to decode again.
Requires a change to external/skia (I33e6940e247b74b20361ae041f8d36eb600df49f)
BUG:17419670
Change-Id: I17ed7288b2359fafaec9551adb16d1d037800eb7
If there is a copy, JNI_ABORT does NOT copy back into the
corresponding java array. Changing this to 0 is what you want since
this will copy the data back if needed and free the temporary
storage.
Bug: 16858794
Change-Id: I3f3b426ea3cbba577bb720532c16ebf7493f1c1c
Bug: 17765082
DeferredLayerUpdater had fallen behind RT updates. Re-snap to
latest expectations, ensuring to call requireGlContext() prior
to detachSurfaceTexture to avoid leaking SurfaceTextures
Change-Id: Ic65fb9831e5284f658866da8da9ad5af1d227699
The attribute name resource IDs were never fixed up with
the runtime package ID so we weren't finding attributes
whenever the runtime package ID was different than the build
time one, which happened to be when a shared lib referenced itself
(0x00 vs 0x02).
Bug:17666947
Change-Id: Icf3e874bcea0e27eebe42d60fbed626a34bf9266
Drop down the limit on when we log, since under normal operation we
will never get more than a few K of data due to strict mode.
Try to clean up the code paths coming in and out of binder IPCs to
plug any places where we could disrupt the gather flag of a thread,
causing it to keep gathering stack crawls (which is the thing that
is causing our strict mode data to become so large).
Change-Id: I9a46512283d33e863c429840b465855d1fabb74e
Add the app directory to the arguments for starting a process.
Add a check for NeedsNativeBridge and a call to PreInitializeBridge
in the native fork code.
(cherry picked from commit 2eacd06bfb82b33dfcbccafbcfc0bf1218484bb5)
Bug: 17671501
Change-Id: I970db5b284b0c12e2d8a45df3950c1fff2927a4e
Bug: 17675571
- Check for JPEG footer in correct location from ImageReader
when using the RGBA override.
- Add additional error checks in produceFrame method.
- Avoid allocating extra space for jpeg buffers due to
incorrect width calculations.
Change-Id: I926f37e8b3e5c4bad24c16dcee48d52adb1706dd
