Only prune ChooserTargets if the resolved activity source they came
from is still present after refreshing the list. Compare this directly
against the ComponentName rather than ResolveInfo.equals, as the
latter isn't implemented.
Bug 21953672
Change-Id: I6486bda85c19d7371167affe2a2b80a2668bd734
Had to add a way for BrightnessController to know when its the end
of a touch, so that we don't spam the event logs with intermediate
values.
Added visibility to BrightnessDialog as this is what settings
launches.
Bug: 21528168
Change-Id: Ie214b4ddb0c9f9bbe8c4f182f9c59f229963ebc7
All options are sent to the VoiceInteractor once ChooserTargetServices
have reported in. We don't perform explicit progressive refinement or
filtering, but an explicit option picked will be invoked.
Also fix a lingering bug around being able to nested-fling the
resolver drawer closed.
Bug 21516866
Change-Id: I6b141f5fa87d74dccec9dcb88110630696e9c38e
For apps not present on device, the state inherited from the ancestral
device is applied when the app is ultimately installed.
Bug 20144515
Change-Id: Ie05b4f1751357fc62f14e259da174b8cf465e913
Only sysui knows the true rank, since it can (and does) reorder things.
The visibility logs are down in the service because it has other bits of data.
Bug: 21395744
Change-Id: Ibf9479dc2306fb27fb5df3bf21e161478d36d587
This CL makes If8ff1b2b95c36d33148def2ab87bd006aa520cc0
multi-user aware.
It turns out that DISABLED_UNTIL_USED has not been correctly
set to IMEs seen from secondary users because we have used
IMMS#mContext.getPackageManager(),
which always returns the PackageManager with the primary
users' context, when specifying
COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED.
We should use IPackageManager instead as we have already done
in many places of IMMS since Ib23849d352db33f0747aa9d5a178f00.
Bug: 8148605
Bug: 8365223
Bug: 21953608
Change-Id: I4b9d6510bf965204bb1f68c8b527d1a4df23fac4
The doze wake lock is an internal implementation detail with no
power impact. However the draw wake lock is much more interesting
to track because it's essentially like a special purpose partial
wake lock which may be acquired while dozing.
Bug: 21949905
Change-Id: Iedd5f366eb010a47a9691374c5cd3d85ea68173d
Doze wake locks don't actually hold the CPU awake, so we should record them
separately from full wakelocks, which is what we did before.
Bug:21949905
Change-Id: Ib4db3399069e0ad11f1f0dc6925a87ad0ad21ff9
Add an animation that discloses delivery
of contextual data to the assist component.
Also fixes a bug where contextual data was
delivered to legacy assist activities even
though the user explicitly disabled context.
Bug: 21568059
Change-Id: I27dfaa36e2f677b0d73acfa4730f0f4ea3486919
-The toolbar is now rendered over the IME.
-The toolbar respects the presence of the IME and tries as much as
possible not to obstruct it.
-The toolbar may obstruct the IME if there is limited space and we
can't find a position that won't obstruct the IME.
*A side effect of the toolbar over the IME is that TextView handles
will also always be rendered over the IME where necessary. This was
the previous behavior before the regression.
Bug: 17510971
Change-Id: I26a49565bf025d7c007ba6bb80468c4988fcc051
When wifi traffic causes a stats collection, we shouldn't care about
cpu or bluetooth updates.
Bug:21478443
Change-Id: I177dc0fc09951813cb4a702ad0e5d951d69f8c22
Rework how we record active transitions in battery stats to be
more general, and add an API that others can call in to
DeviceIdleController to request that we go out of idle mode.
use this for VOICE_SEARCH_HANDS_FREE.
Change-Id: Ie58de60e63036a4142881283835961fbcceec892
Also removes the class name since it's not helpful to expose framework
internal class names to accessibility services that can't access them.
Bug: 18864087
Change-Id: If9b29d3929970bd893168444584a5dd1ba593c5b
Notifications in which the icon resource ID is changed after
Builder.build() is called (even, and particularly, as the
last step in the current implementation of
setLatestEventInfo()) were not having their icons properly
parceled. In these cases we now attempt to catch this at
parcel time and construct the necessary Icon object.
But wait! Parceling does not require a Context. So we don't
actually know which package to load the resource from.
Therefore we now allow an Icon to be constructed with an
empty ("") package name, which allows us to complete this
parceling task despite the fact that a Notification does not
know its own package name. (In case you attempt to load a
drawable for such an Icon, loadDrawable will spot the ""
package and instead substitute the Context from its
parameters to try to load the resource.)
As it happens, even though the Notification does not know
its own package name, BaseStatusBar does, because it was
provided at NM.notify() time and is therefore included in
the StatusBarNotification structure. So we can actually
patch up the Icon (if it is TYPE_RESOURCE) and be sure to
get the icon loaded out of the correct package.
While we've got the hood open, this change fixes a couple of
related problems:
• Foreground service notifications synthetically
constructed for naughty icon==0 notifications (which we
are still allowing...FOR NOW) were losing the
FLAG_FOREGROUND_SERVICE flag (because we're
re-build()-ing them from scratch rather than rewriting
the provided Notification object). Now we set the flag
and hang onto the new notification for next time
setForeground() is called.
• We now allow media notifications to avoid getting bumped
to the top of the notification list if they're
PRIORITY_MIN. You might want to do that, I guess?
Bug: 21333763
Change-Id: Ia5d1f1acb594c7677bcc75ee3d624da4ffca671f
We used to give 50% of the cpu time of each app to any app holding a wakelock
while the screen is off.
Since we switched to the new kernel module for measuring app's cpu time, this distribution
was lost.
Bug:21876567
Change-Id: I42c294547f63d150d9929271ca0e27fedaaa9d77
We were not taking into account configuration changes to update the
available space for the toolbar.
Bug: 21816857
Change-Id: I0f346e8eecb66ab788d1500239d5c1e020b87f97
This is fixed by avoiding calling toolbar.show() in PhoneWindow.
FloatingActionMode coordinates whether or not the toolbar should be
visible. PhoneWindow differs to it.
This CL also adds a new API:
ActionMode#onWindowFocusChanged(boolean)
Bug: 21617792
Change-Id: Ic49ce1000ce9c782d0f9e17e3d024d462c7b758b
b/19904873
> Reason: to prevent TransactionTooLargeException from occuring when
binder transaction size goes over the limit.
Change-Id: I054cb161d235234f3ccdaadd70314163e690b0db
For both PhoneWindow and VoiceInteractionSession, call
requestApplyInsets when the content view(s) change. This is generally
what the developer expects if the new view tree responds to insets in
any way.
Bug 21620924
Change-Id: I60a88af55bf85217c3587aa37f03fdc3fdce686d
