When reporting views to accessibility services we are ordering the
children in a parent based on their location on the screen. The
initial implementation worked pretty well in practive but violated
the transitivity property leading to rare crashes in apps. The current
implementation does not violate transitivity but does not produce
good ordering.
Given the lack of time and to minumize risk this change uses the
old strategy which works most of the time and if that fails we
fall back to the current strategy. Coming up with a correct strategy
that produces good results requires more time.
bug:17887986
Change-Id: I1c233ecdf318befc315e793696ac48bd6c652ab6
We know a priori that the PMBA metadata package's backup pass
doesn't need to be tracked for timeout, because it's run inline
rather than as an asynchronous separate-process operation.
Change-Id: Ifd21ab3a016917f5e557a38c1c88f8d8ac1337d2
Previously we would stop at the first match when looking for a type string,
but we should search all packages in case a feature Split added a type
with the same name.
Bug:17924027
Change-Id: I6bc7ef073324db99448538cd8bdf566658f066ff
New plan: We need this for the Device Preview images provided on the final L-Preview page.
This reverts commit 4974e7f27cf93842001c10379c0be0b24eb035d7.
Change-Id: I1b5fd6d58c53c6ac14f86c688eaea540d683134a
Shows one notification per profile instead of one notification per
user or (previously) one notification per device.
Bug: 17794425
Change-Id: I6f0d34a16fa2a45082941387ac765dd99eefa131
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
