ActionMenuViews work in two modes: hosting another Menu instance or
creating their own. The former is used when an action bar is
displaying a window's options menu. The latter is used when an
ActionMenuView (or Toolbar) is placed within an arbitrary layout and
the getMenu method is called.
When showing a window's options menu, ActionMenuPresenter calls into
the ActionBarPolicy to determine if we should reserve an overflow
button or if overflow will be presented by the window instead. Always
reserve overflow if the ActionMenuView is presenting its own menu.
Bug 17381966
Change-Id: I17c495986994d421bf6276ae39ba233243432e97
Simulates the relevant portions of a DOWN/UP event pair to request focus
and bring up the IME.
BUG: 8213791
Change-Id: Idb32d81552ecbbdefc64686c914eba6d8e28b0b8
Since implementation is still largely synchronous, this is safe.
For the future full-asynchronous implementation, this is the behavior
we want in any case.
Bug: 17345630
Change-Id: Ib54a3441b21fa8cb42bcc6548e5639d9db7ec193
Otherwise, cannot reliably match up capture progressed and failure callbacks
with the start callback.
Bug: 17421092
Change-Id: I91d92be70a15536b215bac330370ce37e426ec26
This can be controlled by MDMs via DPM.
Also fixes:
- javadoc for restrictions
- persisting of cross profile copy/paste restriction
Bug: 17387303
Change-Id: Ie148f56189181d2a4c6345c0823d417ab13a94a3
- Both are move to FileChooserParams, remove UploadHelper class.
- createIntent only handls non-capture intents
- parseResult is the static member of FileChooseParams and should
be used with createIntent.
BUG:17253647,16624450
Change-Id: I81cac7c1b739880db4e4c1f2b4612ed2ee87cb1b
There was a race where ActivityManager would return null
for getCurrentUser() when switching between guest accounts.
This is because the Guest account was marked for deletion
while it was still active.
Bug:17290209
Change-Id: I224fb4b6836380e5acb7dbeb8f3343d74505f88a
(Noticed the difference in a javadoc diff between Notification and
NotificationCompat)
Bug: 17424399
Change-Id: I639a46c429ffebf8ca47118b2ea80f40ccdc1286
As per API review. This will be submitted in sync with a new version of DMAgent, as the string is hardcoded there.
Bug: 17389863
Change-Id: I3a3d7a9cf05bcb713da8690ceec6af02845a5ff1
This should not break any apps as this API has been marked
@removed more than a week ago.
Bug: 17425123
Change-Id: I19d7e933a3f2a59e1b406a9f87d272f058a13e0d
Switch back to using a list as the grid and differently positioned
activity icons were confusing to users. Keep the distinct "last used"
presentation but align icons and titles with the further choices
below. Adjust this to make the fold more apparent. Remember
open/closed slider state across config changes.
Fix some bugs in nested scrolling and flinging.
Bug 17301272
Change-Id: I175937d5821df27b6ac7ffad7f01cd9a6ed3e3e3
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
This allows micro-consoles or other devices to signify that there's a
game controller in the box, even if the user hasn't connected it.
Change-Id: Ie5e2cf69f777ebe84abb83f34c9ed63d9555deff
ApplicationInfo.uid isn't enough because when system
posts notifications it Context.getUserId doesn't match
userId bit of ApplicationInfo.uid, so put back the
mOriginatingUserId.
Bug: 17002733
Change-Id: Ie3d8de121255bcb551cbe80c263e74f1a60b6f1c
Cache in ActivityThread means this still doesn't make sure we will
get an ApplicationInfo for the user being requested. So reverting.
This reverts commit 4a3b8aa08d743b28d53b327597abf03a925641f2.
Bug:17002733
Change-Id: Ie40eb31c4074cea09de3d6a41fe38b14e00eb059
For restore use-case, session creation needs to complete quickly, so
delay ASEC allocation until session is opened. When preflighting
size checks, only consider external when we have a known size for the
container. Also relax size checks when using MODE_INHERIT_EXISTING
on external, since we don't know how much of existing app will be
copied over.
Consider session as "active" while commit is ongoing, until we're
either finished or pending user interaction.
Always publish first client needle movement away from 0. Use 25% of
internal progress to reflect ASEC allocation.
Avoid CloseGuard messages about leaking PFDs.
Bug: 17405741, 17402982
Change-Id: I6247a1d335d26621549c701c4c4575a8d16ef8c2
