* changes:
Support for an activity to change and/or query it's associated stack
Support creating/launching a task with non-fullscreen bounds
Support finishing a task with any finishing activity in the task.
Add additional information about the intentions of result codes in
device-owner and profile-owner launch intents, in alignment with
changes made in http://ag/732321.
Bug: 21063241
Change-Id: I0e0a931739cee5f46e8fc7622fe1de49e26dcb0a
Add new Activity callback to tell it when its saved state has
been invalidated.
The problem is that delivering the permission result does not go
through a path where the compatibility code can see it first to
mark its fragment manager as no longer having saved state. So this
new callback gives it a place to do that.
Change-Id: I5a4a185d9c746bae1afb5c588aba82c8daccf079
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