Add new Activity.isVoiceInteractionRoot() API that an activity can use
to determine whether it is the root activity of a voice interaction
session started by the user's designated voice interaction service.
This is a special new API that apps must explicitly check, because as
with visual activities the model behind an activity should usually be
that it accomplishes its task by interacting with the user (implicitly
getting their approval) rather than trusting that whoever invoked it
is telling it to do what the user once. In the voice world, however,
there are some cases where quick interactions want to allow for immediate
execution without further user involvement, so this API allows for that
without opening up security holes from other applications.
Change-Id: Ie02d2458f16cb0b12af825641bcf8beaf086931b
Doing this so we don't break current apps. In the future we should
properly position the activity in the stack (i.e. behind all current
user activity/task) and not change the positioning of stacks.
Bug: 21801163
Bug: 13507605
Bug: 22929608
Change-Id: I979b6288e66f5b2ec2a6f22cb8d416e5c68109bd
Now that stacks represent workspaces we can define static
stacks which help shape the characteristics of the tasks
they contain. For example, fullscreen tasks/activities will
normally be launched in the stack with id
FULLSCREEN_WORKSPACE_STACK_ID, while freeform tasks/activities
will normally be launched in the stack with id
FREEFORM_WORKSPACE_STACK_ID.
Also, added ability to position a task at any index in a stack.
Bug: 22068114
Change-Id: Ib6c62a84b5f204fbf072755264c5c5eda6184f97
The app ops mananger service maintains a mapping from UID to
a list of packages where each package is mapped to a list of
non-default app op states (default states are inferred and
not stored). Hence, specifying the app op state for a UID
requires setting the app op for each package in the shared
UID.
This is problematic when installing new packages if there
is a non-default app op policy set for another already
installed package in the same UID as the app op for the new
package has to be updated to be in sync. The package installer
cannot do this as it is in another process and the app op
update will not be atomic. Therefore, the app ops manager
service has to support specifying app op policy on a per
UID basis.
We now have a UID state object that contains the per package
non-default app op states as well as the per uid non-default
app op states. If there is a UID policy specified then it
takes precedence over the per package one. Even further,
changing the uid policy updates the package policies in this
UID if the state is non-default. Changing a package app op
state also updates the app op state for the whole UID if
the per UID policy for this op is non-default. Clearing the
app op state for a package, clears the policy for the UID
as well.
bug:22802981
Change-Id: I78044906d9fcc6066abf07e706c2c88f3397d293
Tasks are now resizeable just like stacks. Adjusting the size
of a stack will also adjust the size of all it's containing
tasks. This model allows us to be more flexible
in using stacks as workspaces (like you would have in a
desktop environment) and tasks as the resizeable windows
within the workspace.
Also added "adb shell dumpsys window visible-apps" for
getting the list of visible app windows.
Bug: 22068114
Bug: 19182363
Change-Id: I5bf77063252a5abae4e327f6fc42e607091749f9
The methods startUsingNetworkFeature, stopUsingNetworkFeature and
requestRouteToHost were @removed in all the M preview builds, but
internal and external developers have noted that this imposes
additional burden for applications that need to work across
multiple platform versions because it causes compile-time errors.
We switched from @removed back to @deprecated to avoid these
problems. In order to effectively deprecate these methods, which
are error-prone and insecure, make them throw
UnsupportedOperationException if the app's target SDK is M or
above.
Because there are still one or two places in system code that use
these APIs, exempt Process.SYSTEM_UID and the OMA-DM client from
the check for now.
Bug: 22728205
Change-Id: I790bd32f3aa8067cbb625962a209bb9232f4b58c
changes)
AppOpsManager:
Changed the default operating mode for WRITE_SETTINGS to MODE_DEFAULT from
MODE_ALLOWED.
packages/SettingsProvider:
We no longer do static permission checks for WRITE_SETTINGS in early checks and
defer that to app op when MODE_DEFAULT is returned. For some operations,
checking against WRITE_SECURE_SETTINGS is sufficient.
ActivityManagerService & PowerManagerService:
Incorporated app op checks and handled the MODE_DEFAULT case.
provider/Settings:
Added helper function to do checks on whether app ops protected operations
can be performed by a caller. This includes checks for WRITE_SETTINGS and
SYSTEM_ALERT_WINDOW.
Also added a public API (with javadocs) for apps to query if they can modify
system settings.
Changed the javadocs description for ACTION_MANAGE_WRITE_SETTINGS and
ACTION_MANAGE_OVERLAY_PERMISSION.
Added public API (with javadocs) for apps to query whether they can draw overlays or not,
and also javadocs description on how to use that check.
Change-Id: I7b651fe8af836c2074defdbd6acfec3f32acdbe9
RemoteViews now allows Icons as TextView compound
drawables in RemoteViews, but not yet as public API.
Bug: 22600607
Change-Id: I986a0ce3bede09746f0b121884184679f39a79f5
In addition to cleaning up some bare references to the icon
slot, we now apply updates to notification RemoteViews in
the context of the supplying app's package. This ensures we
can find the drawables inside any Icon objects that were
constructed without a proper package name, such as is the
case with Actions (because the builder and constructor are
Context-free and so don't know the package name).
This CL also makes clear what was previously only implied:
Non-resource action icons are not actually supported yet
since they can't be pushed to TextView compound drawables
using today's RemoteViews APIs. That will require an API
change.
Bug: 22600607
Change-Id: Ie6b88aed36e4db05be35f843ea3bc1898d4a5c96
