1. If app clears transient flag w/ a gesture, the touch-outside
listener would always win, causing an unsightly hide + immediate
reshow. Instead, give the app some time to clear the flag, then
perform a smooth transition in place.
2. When the transient bars are hidden, we do not know ahead of time
which background will be used on reshow (if transient bars are
revealed, the background is semi-transparent, if transient bars
are cleared, the background is opaque). Window manager is responsible
for showing windows, but sysui is responsible for setting the view
background. Therefore, we need some level of coordination between
the two in this case. Introduce two new non-public sysui flags
that represent the window manager's request to reshow the hidden
bars, but do not reshow until sysui acknowledges (by clearing the flag).
This gives sysui whatever time is necessary to prepare itself for
reshow, avoiding unsightly blip from opaque -> transparent during
the enter animation.
3. When both system bars are hidden, any low-profile changes are
moot. Avoid unsightly low-profile animations during bar reshow
by suppressing the flag in this case.
4. Improve transient bar home -> launcher transition by cancelling
the -> opaque animation. This also fixes a bug where hitting
home from the transient bar would leave you with a semi-transparent
bar in a non-transient state.
Bug:10284800
Change-Id: I238210561d8d5f70c1a517283b986c9105a1ec75
It's possible to update the native surface pointer while the
surface is locked (via lockCanvas). This leads to a surprise when
the surface is unlocked. Avoid the surprise by tracking the
locked surface separately.
Bug 10289713
Change-Id: I84346c952be859bbd91ceae7df07b91dabe0948e
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
