When Activity.convert{To|From}Translucent() is called the
ViewRootImpl is now notified when it is safe to convert the Canvas
from translucent to opaque and back to translucent. This will make
it possible to save resources when compositing opaque layers.
Fixes bug 10349536.
Change-Id: I7282aee1d54601fb00611d20be204bf164d873f6
Previously, a running transition on a scene root would simply
be canceled when a new transition was started. This would result in
abrupt scene changes, especially in generic use cases where apps/widgets
would spawn multiple transitions in successive rendering frames due to
small changes in view properties.
The new approach is to check all running animations against new transitions.
If there are overlapping properties that are being set to different values,
the new animations win and the old ones are canceled. If the end values are the
same, the new animations are noop'd and the old ones are allowed to continue
as-is.
There was also improvement to capturing state while other transitions are
running, necessary in this new world where old transitions are allowed to
continue running. Now, transitions are pause()'d while values are captured,
then resume()'d after capturing is done. This allows the system to see what the
real view properties are, instead of the mid-animation values.
Change-Id: I8e77fb9c1967087a682bb26a45763005f5ca9179
Previously, old animations (view.animation.*) would cause invalidations on
both the area of the child view and then the entire parent area. There's no
reason for the second invalidation; only the child area need be redrawn.
Issue #10229470 Old animation code in View.draw() may be invalidating too much
Change-Id: I4d0d16321e20b2f34dc579eacf5d3841aed33d6d
- This enables keyboard navigation for window without focus.
- FLAG_LOCAL_FOCUS_MODE puts window into local focus mode.
- Application needs to put window in local focus mode, control focus, and
inject events to make dpad navigation work.
- Window in local focus mode does not interact with window manager or ime
regarding focus related events.
- Also renamed ViewRootImpl.dispatchKey to dispatchInputEvent to allow both key and touch events injection.
Change-Id: I8e8561f29e0dade3797fb7ae3ee7690e6b7f8895
This issue has been actually revealed by a fix for bug #7034321 (Need Drawable RTL support)
where I identified an issue with Drawables resolution in TextView (was missing a call to
resetResolvedDrawables() and resolveDrawables()).
- add missing resetResolvedDrawables() and resolveDrawables() in TextView.setRelativeDrawablesIfNeeded()
- fix View.resolveDrawables():
this was a bit trycky as View.resolveDrawables() was wrongly supposing that the layout direction was
resolved and it could access View.getLayoutDirection() and could position the PFLAG2_DRAWABLE_RESOLVED
bit.
Dont forget that resolution of RTL properties (layoutDirection, Drawables ...) is happening in
View.measure() but in our case (TexView constructor) we still need to resolve the Drawables.
So now, be sure that we cannot resolve the Drawable if layout direction has not being resolved and the
raw layout direction is LAYOUT_DIRECTION_INHERIT.
But we can also "cheat" if the raw layout direction is LAYOUT_DIRECTION_LTR or LAYOUT_DIRECTION_RTL
or LAYOUT_DIRECTION_LOCALE as its resolution will give the same value :-)
Change-Id: I7a242d918697e1e1c2febf229e8edf1866b855be
Two new public sysui flags for views to request transparent
bars:
View.SYSTEM_UI_FLAG_TRANSPARENT_STATUS
View.SYSTEM_UI_FLAG_TRANSPARENT_NAVIGATION
This first change simply introduces the flags at the framework
level, and makes the requisite layout tweaks to WM.
As part of this change, expunge the term "hideybars" from the
codebase. The flag to declare support for transient bars is called:
View.SYSTEM_UI_FLAG_ALLOW_TRANSIENT
Final visuals/transitions between opaque/transparent bars will be
done as a subsequent change. Right now the transparent style is
identical to the transient bars.
Change-Id: I5ead9c5e7b77f212df5b2a5f6e770596cd2226f3
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
Devices can be configured to remain in their default landscape or
portrait orientation by setting config_forceDefaultOrientation true
in overlay/.../values/config.xml.
Activities that desire to run in the non-default orientation are
supported by creating a logical display within the physical display.
Transitions to and from the activity perform a crossfade rather than
the normal rotation animation.
Also, improve SurfaceTrace debug output.
Fixes bug 9695710.
Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
- default value is "no mirroring"
- introduce android:autoMirrored as a new attribute for Drawable,
BitmapDrawable, LayerDrawable, StateListDrawable and NinePatchDrawable
- setting android:autoMirrored="true" means that the drawable will
be mirrored when the layout direction is RTL (right-to-left)
- also fix an issue with ImageView drawable layout direction not
updated correctly when RTL properties were changed
See bug #7034321 Need Drawable RTL support
Change-Id: If595ee5106c786f38e786d3a032e182f784a9d97
The implementation of getInterpolator() was always returning null
(probably a quick copy-paste from the default Animator implementation).
This patch fixes the problem by returning the interpolator set by
setInterpolator(TimeInterpolator) or the default one if none has been
set yet.
This patch also avoid creating multiple instances of ValueAnimator in
order to retrieve some default values.
Change-Id: I8880f419f021a8b980fb32bebe927915fde19bf7
Calling unFocus() leaves the view hierarchy in an inconsistent
state. This is okay in ViewGroup, where the state is manually
updated, but causes issues in ViewRootImpl.
BUG: 9983358
Change-Id: Id63e62962d895e6bd4f816f202dcf77254ceab4e
