If the power profile was not set yet, the default sizes of
cpu freq arrays could have been too small.
Bug:24244089
Change-Id: Ic17a1e8f2058c51fbdda14db35b7b62f4880be00
Propagate the boot status explicitly to installd so that we do not
have to rely on dev.bootcomplete, which isn't meaningfully set
when the device needs the decryption screen on boot.
Bug: 23898216
Change-Id: I9b34298caf70b1e5d40970cc0d04c469016a80a7
Always connected devices don't have power_profiles,
so handle the case where the default cpu speed count of
1 is used on a device with more cpu speeds.
Bug:23776983
Change-Id: Ifdddad2f28eea5b730833622a6b6043b3086efd2
Also fixes incorrect call from MenuItemImpl to dispatchMenuSelected,
which should according to the documentation be passing the direct
parent menu of the menu item.
Bug: 23725571
Change-Id: I2d1f04b80ce05d141ba2dfd77f62bb13b2268625
When two or more activities with the same user-visible label are
shown, we have traditionally shown the app name or package name if the
app names also match. This was to help the user tell the difference
between multiple apps publishing similar activities and avoid
unintentionally starting the wrong one. However, in the case of
explicit choosers (e.g. ACTION_SEND sharing) a few common collisions
occur in practice and falling all the way back to package name isn't
very helpful.
Instead, we now assume that the app icon, which the user has seen
before at install time, is unique enough on its own to disambiguate
these cases and avoid user confusion. We no longer show the app name
or package name as secondary text in the chooser.
In cases where an activity has a different icon from its containing
app, we now badge the activity icon with the app icon so that the user
knows which app a potentially ambiguous choice belongs to.
Bug 24113937
Change-Id: Ie54fbf77bfcc86e50768f93be2be0e53cf2ce7b5
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
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
(cherry picked from commit 9761ab2a64)
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
