* commit 'd31f0ab93f4f35a7ca6df6d428db2a5fd3d6750a':
Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"
* commit '68b14054b96571d4009c6c5a9b4c3413d908a523':
Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"
This reverts commit 6bf6eb7d5f.
and also fbc21e126f
I have also removed all unnecessary calls to resolveLayoutDirection(int). This is possible as
we are resolving layout params on every child of a ViewGroup as of commit
fcc3348f61
Change-Id: I262a375b03fcc3c9261cbe2edebb6ec42ec2e186
- check layout direction previous value in the onResolveDrawables(int) callback
- dont do any Drawables resolution if we cannot resolve the layout direction
- also remove unnecessary call to resolveRtlPropertiesIfNeeded() in ViewGroup when
adding a child as the call to resolveRtlPropertiesIfNeeded() will be done into
the measure() call itself later
Change-Id: I62237af3d307dfea203f7f2865551d1c61a0e0b8
This new API makes it possible for an application to ask on
which Display it should show a Presentation based on the currently
selected media route.
Also added a new API on DisplayManager to query displays that
support a certain category of uses.
Improved the documentation of the Presentation class to explain
how to choose an appropriate Display for presentation.
Bug: 7409073
Change-Id: Iab451215e570ae55f3718fc228303143c800fe51
* commit '0182dc39bd969b797614c90e44978b83ac57fd1c':
FIx bug #7414801 Should make private and final View.TEXT_DIRECTION_DEFAULT and View.TEXT_ALIGNMENT_DEFAULT constants
* commit '3e297339f8b77d54f520d5471c90c9d04e78400e':
FIx bug #7414801 Should make private and final View.TEXT_DIRECTION_DEFAULT and View.TEXT_ALIGNMENT_DEFAULT constants
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
Bug #7391098
The existing code was doing a make current to guarantee we have a
current context. This can however fail when the surface is destroyed
which could lead to GL calls without an EGL context, and therefore
potential leaks. This change fixes the issue by using a technique
found in HardwareRenderer.destroyHardwareResources(). If the surface
is not available then we use a special 1x1 pbuffer as a way to get
a valid context.
Change-Id: I716d3799bf90120d793d76e90a83956837ecd491
Throw an InvalidDisplayException to addView if the display being
added to has been removed. Handle this exception in Dialog.show()
by removing the view after it has been added and rethrow the
exception from there.
Add javadoc to ViewManager.addView and Presentation.show explaining
the new exception and how best to handle it.
Bug: 7368565 partially fixed. It remains for the Videos app to
handle Presentation.show throwing the InvalidDisplayException.
Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
A bug in software rendering caused animations on views that are offscreen
to not get drawn, therefore the animation doesn't continue (since old-style
animations depend on the logic in the drawing code to keep running). Fix is
to special case the isAnimating case in ViewRoot to go ahead and schedule
a traversal even if the dirty rect does not intersect with the visible region.
Issue #7396035 Animations starting offscreen don't draw run/end/draw properly (sw rendering only)
Change-Id: Iae25b3a424ddc5a16ba431ecd68cf42d5500db3f
Bug #7385090
This change gets rid of two silly asumptions:
- That a layer needs to be cleared with opaque black (it shouldn't,
it's already cleared to transparent and the view will cover it up
with its own background)
- The the clip should be dirty at the beginning of a frame only
when the render target is opaque
Change-Id: I415b6d3cab196057fb0281419a53fef601a44e28
