- When the flag changes, apply an animation from the current value
- When the flag change is caused by an app transition, synchronize
the status bar animation with the app transition animation.
PhoneWindowManager calculates the timings based on some heuristics
of the app transition animations and supplies these timings to
StatusBarService.
Bug: 19233606
Change-Id: I4f99afba8f1eebb3524699ed4d7fbafee5463a37
Introduces the concept of a listener to be notified about app
transition events. The only client at the moment is window manager
which notifies activity manager about completed transitions, but this
can be used for various clients, including the status bar.
Bug: 19233606
Change-Id: Ia6fec5837b6eb4db90f3cb1c999d3f157ba6dd4a
This is a follow up CL for I7d932e60311b80c05be8f02c9e803f18da0e0054,
which revealed that we could not use deprecated 2-letter code like "in"
to query subtype which has new language codes like "id".
This CL addresses the above issue by normalizing the language code
with Locale#Locale(String, String) before comparing one to another.
Change-Id: I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10
When a device was woken up in a different orientation than what it
went to sleep in, the window manager would force a resize to get it to
predraw in the new orientation. The predraw was done in the old
orientation however because layouts are skipped when the activity was
stopped.
This change allows layouts to proceed when the activity is stopped if
the flag to report resize events is true.
Fixes bug 18444400.
Change-Id: Ib2def3449dd67918f6fb838bdb1fe5cc6ec57f8e
This change will allow us to create ActionMode representations on the
fly after onCreateActionMode by using the Decorator pattern. The new
ActionModeWrapper will be responsible for the creating the
appropriate ActionMode depending on the type chosen by the client,
and setting it up.
Things pending that are NOT addressed by this CL:
- ActionModes created by callback.onWindowStartingActionMode(). This
includes all current usages in an existing ActionBar, as it is
handled by Activity. This requires some additional refactoring.
- Representing the floating type
- Moving the view creation code specific to StandaloneActionMode
from DecorView to ActionModeWrapper, decoupling DecorView from
StandaloneActionMode completely
- Supporting two ActionModes in parallel in DecorView, one of each type
Change-Id: I1a8db711f53b771eac74f0e6496106acf1ca2727
The flag needs to be set based on the top window that is either
reaching beneath the status bar or is dimming.
Bug: 19233606
Change-Id: I7b97f6869e3b7d5ae2b7030122b311ee9e13871f
Prevents color view from showing up on phones when
the orientation changes to landscape. Previously, the
animation was only prevented when the stable inset of a
bar became nonzero; now we disable animations whenever
the nonzeroness changes.
Bug: 19353466
Change-Id: Ibcf15ee4e0c9fba429745dde1b808ee41c7473cf
Apps normally use context.getResources().getDisplayMetrics()
or getWindowManager().getDefaultDisplay() to get information
about the screen dimensions. Not all the screen space is available
for apps in a multi-window environment, so we limit the dimensions
of the display object exposed to the app to that of the containing
stack.
Bug: 19225079
Bug: 19354838
Change-Id: I8dc3a6c9b99ecedcca28fc4ddaba9f31feb4f871
The special logic for clicking on views in accessibility mode should not
prevent event interception and if a view interceptes the gesture we must
clear the special flag and do normal event dispatch. Also once we have a
view handling the touch gesture we do not need the special flag as we
know what will handle the event. This tightly follows standard event
dispatching.
bug:19252492
Change-Id: I0c9764c5050ec73f5f7980f3f0340dd9509a725a
