Restore uses moveTo(), not open/write/close, so we need
to watch for that as well. Now the wallpaper service sees
and regenerates the wallpaper image immediately upon restore.
Bug 17909454
Change-Id: I0db224c3d507bdc40399d49bb4bea01899f76ad1
Cherry-picked into klp-modular-dev.
bug:17441218
GLConsumer uses glBindTexture() directly instead of going through
Caches::bindTexture(). This can cause libhwui to draw with the wrong
texture bound in the following case which involves 2 TextureViews:
Frame 1:
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 1)
HWUI renders TextureView A:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 1) and draws
Frame 2:
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 1)
GLConsumer::updateTexImage() calls glBindTexture(GL_TEXTURE_EXTERNAL_OES, 2)
HWUI renders TextureView A:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 1) and draws
HWUI renders TextureView B:
calls Caches::bindTexture(GL_TEXTURE_EXTERNAL_OES, 2) and draws
In this case, HWUI will incorrectly draw TextureView A using texture 2 on
frame 2, because mBoundTextures[0]=1, even though the texture currently
bound to GL_TEXTURE_EXTERNAL_OES is 2.
Since GLConsumer is always used with a target of GL_TEXTURE_EXTERNAL_OES,
work around this problem by having mBoundTextures[] store only the
textures bound to the target GL_TEXTURE_2D. This is the common case
where the extra performance is needed. Since it's legal to have
different textures bound to GL_TEXTURE_2D and GL_TEXTURE_EXTERNAL_OES
on one texture unit, Caches::bindTexture() does not need to clear
mBoundTextures[mTextureUnit] when target != GL_TEXTURE_2D.
Change-Id: I8bc54ab8adcfacad7f3ed17a31236dc7a86c967a
Signed-off-by: Fred Fettinger <fred.fettinger@motorola.com>
(cherry picked from commit e4de36bbc2baf13206deb53ced39f0befadb1861)
Retry connecting to MmsService when disconnected or upon each API call
if disconnected.
b/17862188
Change-Id: Iecfb0a6ffb59b94f6c1121bf00ba2db438ed7001
After completely iterating over a UsageEvents object, the internal parcel
is recycled. If resetToStart is called then, it does nothing.
Bug:17909428
Change-Id: I7bc68d3429e4621a50dedbfc1789576d44dbb3be
A previous change introduced a regression in the case where
a device has been added but is initially blanked. Because
we made changes to defer certain work until we escape the
critical section when making changes to the global display
state, we forgot to apply these changes when displays are
initially added.
This causes problems with HDMI displays remaining blanked
after they are plugged in.
Added a quick fix to ensure we perform the work when adding
a display although we don't bother trying to defer it outside
of the critical section.
Bug: 17909838
Change-Id: If5373d20d8827b7f4330a8cf49f8de64ca3f0740
- Add entries for units and range into javadoc
- Fix up existing units entries and add new ones
- Fix up range entries to be consistent for enums
- Add range entries where it makes sense
- Minor fix to javadoc gen to allow for code indentation
- Lots of edits for consistency, especially to
available* entries.
Bug: 16525650
Change-Id: Id09663d897ec98122073e6e13719731ec0de4dad
Before beginning a full-system restore we need to tell the widget service,
so that it can properly start remapping IDs from the ground state.
Bug 17869323
Change-Id: I152257563f5b52cae67244e936bc2c44ced7618d
Bundles can't be read from multiple threads safely. This adds locking
around a read that had been previously overlooked and ensures that
unparcel is called on the metadata before it is even available to
other threads.
bug:17894033
Change-Id: I9a4b86a0d0af05b1dcba28a52df2e7a87c685704
When we added scan paths, we forgot to bring them along through
Parcel and copy constructor.
Bug: 17900178
Change-Id: I0ee9374f909d375768045976fd88cee7431f7d4d
