Simplifies behavior wrt automatically setting the
web URI for ACTION_VIEW Intents, by not doing so
for custom Intents.
Adds a boolean isAppProvidedIntent() as a signal for
recepients of the AssistContent that a custom Intent
was provided. Custom Intents are more likely to be
relevant.
Change-Id: Ibe4bfa040eba904411b9820ab4ddfcf509413829
* Introduce VoiceInteractor.Prompt, holding multiple voice prompts
("What genre?", "What genre of music?", "What genre of music, for
example classical?") as well as a different visual prompt to show
on screen ("Choose genre").
* Migrate framework voice interactor code from a CharSequence prompt
to Prompt.
Bug: 21024958
Change-Id: Ib595fbdb2801cc558085e9b8366d619ff1d4d656
This patch adds a send-trim-memory command to the ActivityManager to allow
for better debugging&testing.
The command is
adb shell am send-trim-memory [--user <USER_ID>] <PROCESS> <LEVEL>
whereas LEVEL can be one of the following:
[HIDDEN|RUNNING_MODERATE|BACKGROUND|RUNNING_LOW|MODERATE|
RUNNING_CRITICAL|COMPLETE]
Bug: 21633189
Change-Id: I7a41ce02c3c9043ffd3e5aaa791f7b7306a9de49
It is possible for deadlocks to occur when sending/processing
PendingIntents due to components like AMS holding global service
locks when dispatching the broadcast without specifying an
handler and the receiver calling back into AMS.
We now set a default handler to process the broadcast on if we
are in the system process and a handler wasn't specified.
Bug: 19502993
Change-Id: Iccde32c6c1df997784155bc41ef39e52ee0f7243
Start moving Assist* stuff to android.app.assist.
Clean up some more of the VoiceInteractionSession APIs.
Clearly document that finish() is not the same as hide(),
always call hide() instead, and fix the finish() path to
also always do a hide to make sure everything is cleaned
up correctly.
Change-Id: I962d4069fcb34fe89547a95d395ae1b9fa3b4148
Also remove the doc saying that factory reset is impossible if there
is a device owner: the device owner may not set the user restriciton
DISALLOW_FACTORY_RESET.
BUG:19889110
Change-Id: Iadc084a38e541061c0b0c95bfc95da73d48842d7
Annotated all uses of the ComponentName parameter to methods in
DevicePolicyManager to indicate whether null is acceptable.
Deleted/fixed some inconsistent or poorly-worded documentation.
Bug: 21422939
Change-Id: Iadfa78c5170bf4899a9daaf93c3d4e9d8b170a45
API to allow an app to be whitelisted for network and wakelock
access for a short period. So even if the device is in idle
mode, such apps can be given a chance to download the payload
related to a high priority cloud-to-device message.
This API is meant for system apps only.
A new permission CHANGE_DEVICE_IDLE_TEMP_WHITELIST is required
to make this call.
Bug: 21525864
Change-Id: Id7a761a664f21af5d7ff55aa56e8df98d15511ca
ActivityView shouldn't set the surface on the main thread, because it's
a binder call and causes jank. Instead it should delegate the call to a
background thread and let it do the work there.
Bug: 15752100
Change-Id: I6f2764c93dfb8f3e00d79f0e97d4a6688b6fdd8f
Changes to the data provided to AssistStructure:
* Text foreground color is correct even if the view has not yet been
painted.
* Text background color is now always 1 (TEXT_COLOR_UNDEFINED) for a
TextView, as it has no separate concept of background color.
* Switch now reports the text size/color/style of the label text
(usually user visible) rather than the on/off text on the button
itself (usually hidden in Material, and not usually revelant when
visible).
Bug: 21080375
Change-Id: I7e15f68d89510a76cab76031c2c8ca6ca3f32435
Also rework how we transfer AssistContent and AssistStructure
to the assistant, so they are delivered as completely separate
objects rather than the kludgy bundling them in the assist
data thing.
Change-Id: Ib40cc3b152bafeb358fd3adec564a7dda3a0dd1d
If the app tried to do various things with too much data --
starting an activity, starting a service, sending a broadcast --
this would fairly silently fail with little indication of what
was going on. Fix this in two ways:
- Now when the native code generates a TransactionTooLargeException,
it may include an additional message in it telling you how much
data was in the parcel being sent, to help you understand why
this happening.
- In all the framework code paths where we call to the system and
may fail, convert these failures into a a runtime exception and
rethrow them back to the app so that it will clearly get the
above message.
Change-Id: I745159b97d3edb6fca86aa09cbc40c1f15a7d128
This adds a new ActivityOption for the caller to ask the
system to track the time the user is in the app it launches,
delivering the result when they are done.
The time interval tracked is from when the app launches the
activity until the user leaves that app's flow. They are
considered to stay in the flow as long as new activities
are being launched or returned to from the original flow,
even if they cross package or task boundaries. For example,
if the originator starts an activity to view an image, and
while there the user selects to share, which launches gmail
in a new task, and they complete the share, the time during
that entire operation will be included.
The user is considered to complete the operation once they
switch to another activity that is not part of the tracked
flow. For example, use the notification shade, launcher, or
recents to launch or switch to another app. Simply going
in to these navigation elements does not break the flow
(although the launcher and recents stops time tracking of
the session), it is the act of going somewhere else that
completes the tracking.
The data is delivered to the app through a PendingIntent,
which includes the total time the app was in the flow along
with a time break-down by app package.
Change-Id: If1cf8892d422c52ec5042eba0e15a8e7e8f83abf
Previously getHomeActivity() returned the topmost home activity
independent of which user was currently running. That defeated the
purpose of the method. This fix returns the home activity of the
current user or null if one has not yet been created.
Also remove some cruft that accumulated.
Fixes bug 21055376.
Change-Id: Ic1d58129aedbe3624f8a9d12c05c84674687b0a4
We have APIs for a DO/PO to fix a permission in a granted or
denied state in which the user cannot manage this permission
through the UI. However, there is no way to go back to the
default state in which the user gets to choose the permission
grant state.
Change-Id: I2562a1d8b1385cd740b44812844ef14c895c2902
First, when parceling a notification with no small icon:
Well, you shouldn't attempt to do this anyway, since NoMan
will reject a notification without a valid smallIcon. But
setServiceForeground parcels up the Notification on its own
before handing it off to NoMan, so it will crash on an
invalid small icon. (In general, parceling code should never
ever crash, even if the object is in an undesirable state.)
And when build()ing a notification: Same thing---don't build
a notification with no icon; you're going to have a bad
time. But maybe you're going to fix it before you hand it
off to NoMan. Or maybe it's just one page of a wearable
notification, so it doesn't really need its own icon. Either
way, Notification shouldn't crash.
Bug: 21286186
Bug: 21298403
Change-Id: Ie482cde0a3afe3aaabf07be0536551b8e4bceba0
