IMEs recently gained the ability to layout out under the nav bar,
but our core measuring logic does not give height=WRAP_CONTENT windows
the entire screen height when computing desired window height.
Since IMEs can be identified by type, let them use the entire screen
height for measuring purposes, to properly handle the cases where
space is constrained, making that unaccounted-for nav bar height
important.
Bug:11215678
Change-Id: I1d0b73454c0c629e7d669b9de70641c7e8c4d333
A measurement optimization has exposed some apps that are relying
on incidental layout requests to have themselves update. With the
optimization enabled, these apps break.
Apps targetted at older versions of Android should not
break due to this optimization.
bug:11192311
Change-Id: Id5fc7f83ec2cb1541d3d0d16f951cd57c0afaccd
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
The existing View.SYSTEM_UI_FLAG_IMMERSIVE flag will be somewhat
redefined. Swiping will clear the flags, revealing the normal bars.
The new View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY flag will enable
hideybars - the auto-hiding, semi-transparent bar mode.
Bug:11062108
Change-Id: Ibf8be9072f0075953baa4580cd976e7562d44455
Ensures accessibility framework is notified when subtree visibility
changes as a result of hiding descendants. Fixes collision between
HAS_TRANSIENT_STATE flag and IMPORTANT_FOR_ACCESSIBILITY mask.
BUG: 11087525
Change-Id: I92dba27350970a09e76b5a878c7604ea06cae197
Specifically, ignore any flags that alter the visibility of the navigation
bar and transparency.
BUG: 11082573
Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
Migrate View.SYSTEM_UI_FLAG_TRANSPARENT_(STATUS/NAVIGATION) to
WindowManager.LayoutParams.FLAG_TRANSLUCENT_(STATUS|NAVIGATION).
Add associated public attrs for both new window flags:
windowTranslucentStatus
windowTranslucentNavigation
Introduce convenient four new themes that set translucent decor:
Theme.Holo.NoActionBar.TranslucentDecor
Theme.Holo.Light.NoActionBar.TranslucentDecor
Theme.DeviceDefault.NoActionBar.TranslucentDecor
Theme.DeviceDefault.Light.NoActionBar.TranslucentDecor
Update PhoneWindowManager mechanism to plumb these values back to
SystemUI to drive bar mode state.
The new translucent flags come from the top fullscreen window, not
the focused window, so translucency does not change when opening
dialogs.
Imply some window-level system-ui visibility if one or both of these
new flags are present, specifically:
FLAG_TRANSLUCENT_STATUS implies LAYOUT_STABLE, LAYOUT_FULLSCREEN
FLAG_TRANSLUCENT_NAVIGATION implies LAYOUT STABLE, LAYOUT_HIDE_NAV
Rename all associated variable & resource names to use the term
translucent instead of transparent. (Retain the term semi-transparent
for the transient bar style).
Recents activity allowed to inherit translucent decor state via the
new PRIVATE_FLAG_INHERIT_TRANSLUCENT_DECOR. Compensating changes
to use the full screen area more appropriately.
Update keyguard to use new WM flags.
Update docs and various api artifacts.
Sanity-check fixes:
- Toasts and alerts given stable layout.
- Suppress nu-gradient when in transient (hidey) mode.
- New translucent flags use top-fullscreen window, dialogs don't clear.
Bug:10674960
Bug:11062108
Bug:10987178
Bug:10786445
Bug:10781433
Change-Id: If667a55bea4cf5e008549524b9899197fab55ebe
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
Since older versions of the platform will crash if the mode is
set to 3, this CL adds an extra bit and uses 4 as the mode. This
will also cleanly default the mode to AUTO on unsupported
platforms.
BUG: 11031947
Change-Id: I48035abbf35523d65cead6f27be10f8087973ceb
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
Instead of keeping a single global system decor rect around
in WindowManagerService, calculate and store policy-defined
system-decor frame for each window.
The per-window decor rect is useful for smooth transitions, since it
determines window cropping during transition animations.
Bug:10938001
Change-Id: Ice6652aa5946027c45c0b7ab4e46473a0f8e3f90
When an inset computer is registered with the view tree observer,
we report content insets to the window manager. When an inset computer
is subsequently unregistered, we must take care to clear these insets.
This patch remembers whether the previously computed insets were
non-empty so that it can force insets to be reset when needed.
Bug: 10840662
Change-Id: I4cce5ba64cc5234b98363b025ac4bb42e64349f1
Since binder call permissions are not transitive by design,
the proper way to fix this is to have the call talk directly
to keyguard from the navigation bar.
Fixes bug 9409008
Change-Id: Ibd90a79bb638c969b514455a2ad93c6ff668222d
When in the SyntheticKeyHandler, a missing constructor paramater caused the
wrong contstructor to be called. This would cause the device id, scan code and
flags to be incorrect.
Bug: 10966229
Change-Id: Ib84ef88d28c0da517b376c5493a851cf8fe0a9f7
Bug #10911502
Views creating hardware resources need a way to safely interact
with the hardware. This new method invokes HardwareRenderer.safelyRun()
which executes a Runnable after making sure the hardawre rendering
context is in a valid state.
With the OpenGL backend, executeHardwareAction() tries to call
eglMakeCurrent() if needed. This method is not guaranteed to
work.
Change-Id: I38ec65132eeba85605cffb1a6de12b7a0184e213
The original bug is fixed already, but showed up some problems in
the underlying fade-transition implementation. This fix addresses
those and other issues. The biggest part of the change should help
transition robustness in general, as it removes the dependency on the
public 'alpha' property of views and uses, instead, a new hidden property
on views called 'transitionAlpha'. This is a value which is normally
opaque (1), but which can be used by transitions (only) to animate the
translucency of views without disturbing the actual 'alpha' value which
might be manipulated outside of transitions. This should make transitions
much more robust in general.
In implementing and testing this overall fix, I noticed a couple of things
about transitions that were simply wrong (such as starting fades from the
wrong start value, and incorrectly avoiding transitions on some views
that didn't happen to have ids), and those are fixed in this CL as well.
Issue #10726905 ActionBar weirdness in People app
Issue #10727937 Menu items in gallery appear in faded color after selecting an image/album by long press
Change-Id: If1618446db10c1bfcff4761449241de4f559afc1
The leak fix of the CopyOnWriteArray in ViewTreeObserver was
too aggressive, always clearing the shadow copy when it should only
have cleared it when needed. The way it works now, we will always
clear the listeners for ViewTreeObserver after the listeners
are processed.
Issue #10815924 ViewTreeObserver leak fix too aggressive
Change-Id: Iff0095d73beb38e52b0a5ae6b6378afec4458fd3
Transitions were leaking views due to TransitionsValues holding references
to views/parents. The references were fine, but the retention of the transition
objects themselves were not. There were a few different places that needed to
be plugged:
- clones were not making new copies of some fields, leading to caching references
in the original object (which was then cloned later to other clones)
- Visibility was using a persistent field to cache temporary values. This transition,
when cloned, would retain these instances, keeping references to views
- ViewTreeObserver had a bug that would leak listeners
Issue #10749071 Activity instance leak between TransitionManager and InputMethodManager
Change-Id: I1d5d457dc5e020c7b9e8392a95e3b2c488461119
A recent change to ViewPropertyAnimator.withLayer() builds the layer
immediately after creating it. This works in general, but if the view
is not attached, buildLayer() throws an exception.
The fix is to ensure that the view is attached before calling buildLayer().
Issue #10750925 Dialer crashed and phone dropped while on call
Change-Id: I801c835a0f5cb81e159fe90c157c122cf2d0da01
