1. Reposition the toolbar on predraw only when positioning has changed.
2. Update the toolbar popup's position only if the content rect changed.
3. Fix FloatingToolbarPopup.cancelOverflowAnimations().
The previous implementation wasn't actually cancelling the animation.
(1) is enough to fix the bug. But (2) and (3) fix issues in the
toolbar directly related to this bug.
Bug: 22039189
Change-Id: I84ec793d788f9402a1f8635e68e3344746f6af07
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I62fb25d126dd815aea699b33d580e3afb90f8fd2
This ensures that theme attribute values that affect the look and
feel of the FloatingToolbar views are the ones specified in the
framework.
The aim is to avoid apps modifying the toolbar's look and feel in
unexpected ways by overriding Theme attributes.
Bug: 21957785
Change-Id: Idd472b4e8511f0a039cd07f98b1fd3ce93ae97fa
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
