This CL is mechanical code moving and does not change any existing
behavior.
buildInputMethodsAndSubtypesString is introduced by
If0104151b3526da6ecc669adde3119a239ecafeb for addressing Bug 19822542.
This code moving is one of the TODOs in above change.
Bug: 22285167
Change-Id: Ie63cf593794c9062919887e04a64208a900b1b8b
When the cascading feature is enabled, users can mouseover a
submenu item in a popup menu to expand and open the new submenu
(after a short timeout). Similarly, if a user mouseovers a
different menu item in the original menu, the submenu gets closed
(again, after a short timeout).
This should complete the implementation of cascading submenu
functionality.
Also fix two other issues:
(1) Update some oudated code in PopupMenu that was still opening
the submenu when a user clicks on a submenu item; this
responsibility now lives within the MenuPopupHelper's delegate
MenuPopup class, so it doesn't need to live in PopupMenu anymore.
(2) Fix an issue where icons would be force-set on a submenu when they
should not be. Instead, decide whether to show icons in a submenu
based on whether to show them in the top level menu, as intended.
Bug: 20127825
Change-Id: Ia46852c7f99436065ab4bc234de94dffc0019666
Preserving decor view across activity relaunches would leak the first
activity, because the decor view would hold onto into in the form of the
context. This CL fixes that by having DecorView and NonClientDecorView
use application context instead.
Another source of a leak is DecorView being inner, non static class.
This would keep the orignal, first PhoneWindow around, which in turn
holds a reference to the activity. DecorView is now static and has
explicit reference to the PhoneWindow.
Change-Id: I3df58755d65d3d36ea2157908b0000b2d5c4ab70
This addresses a few oversights from an earlier CL:
1. In MenuPopupHelper#show() make sure to create a new MenuPopup in
case the earlier one was dismissed.
2. Ensure the on-dismiss listener gets called even if the MenuPopupHelper's
MenuPopup was previously closed and if a new one is opened.
3. Handle global layout changes properly by having the MenuPopup
re-drawing/positioning itself.
Bug: 23973158
Change-Id: Iee866079770026f0fe17814892abc9825f9760a2
This changes application code behavior when the activity relaunches due
to configuration change. It only applies to scenarios, where the
configuration change was triggered by a user generated resize of an
activity (i.e. user drags a corner of an activity and thus changes its
size).
Preserving a window means that we will keep the decor view and non
client decor view around, but remove all children views when the
activity gets destroyed. When the activity gets created again, it will
attach its new content to the preserved view hierarchy. Mind, we
actually recreate application side Window object, since some of its
features might changed, but we retain its elevation (to not trigger
relayout with new layout params).
Preserving the window also means that we don't call the window manager
service to remove and later add the window. Instead, we continue using a
single window state throughout the resize operation.
Change-Id: Ie3d2878ed09c99ff343044bfe7a29a0ba07a265e
- add a startMoving API to initiate a window move from app, once
the move starts WindowManager will take over the event handling.
- detect touch events along window's outside border and start
a resize if necessary
Change-Id: Ic7e8baba34e0aa27a43173e044ffb46e93e219e0
This change adds a new Cascading implementation of MenuPopup. When
enabled, submenus will show up in a cascading side by side fashion
when opened next to popup menus.
Bug: 20127825
Change-Id: Ie3c797fb5dbada7521cd93dc4171950af2be2ff7
Gatekeeper retains lockouts after reboot, but framework
doesn't. This causes odd behavior on a reboot after a lockout
as gatekeeper refuses to check the password and the framework
thinks it's an invalid attempt. Reset the lockout deadline
if we notice the clock reset in the framework.
Bug: 23681267
Change-Id: I3127ccd8f205494af5a8ed2b44d4370c37cc2f8f
Fix cases where we could try to unbind from a ChooserTargetService
that is not connected. This could happen if we still had stale replies
coming back after the activity was destroyed.
Always offer users an explicit choice in ChooserActivity, don't
auto-start a single option.
Make sure we don't allow a wedged ChooserTargetService to hold a hard
reference to the ChooserActivity via its internal result callback.
Bug 23152483
Change-Id: I7c8b1fc9559dcd477702ef582011b088b07d646b
This is just a straight constant replace. The feature is tracked in a
separate bug b/22388012.
Bug: 19913735
Change-Id: I7ae0953558bfdb77441e9efd749f1bb1cc77050c
Ensures views that manage drawables follow the contract set forth in
the Drawable.setState() documentation.
Bug: 23792020
Change-Id: I4e5a449cd6535487873fd8443da50555c38e8ed9
Move much of the responsibility into implementations of this interface.
Delegate functionality to it where appropriate.
Provide a standard (non-cascading) implementation for this interface.
This CL should have NO BEHAVIOR CHANGES.
A follow-up CL will provide a cascading implementation, whereby a
config variable will enable submenus to open side by side with their
parent menus. That CL will be the first with functional/ actual behavior
changes.
Bug: 20127825
Change-Id: Iecac2d340dd8750ebe4e99162d447c9411f09227
