This API allows a single assistant on the device to help the
user manage their notification stream by taking actions on
individual notifications:
- modifying their priority up or down when they are posted
- possibly changing if and how the notification interrupts the user
- adding annotations under notifications
Bug: 22455414
Change-Id: Idf47972bb71c83f1dc1c9ec68a6fa92ac4fc522f
When an activity is moved to a stack using the
ActivityStack#moveActivityToStack API a new task is created to
hold the activity in the stack. However, when the new task is
created in the window manager side it uses the stack id of the
previous stack the activity was in. We now pass the stack to use
from activity manager to window manager.
Bug: 25987309
Bug: 25961636
Change-Id: Iecc71f6d9b3e70a8d88e134b42f7532ba5327bad
This allows us to tell lock checks from FBE checks separately,
and will be useful when dealing with password unification.
Change-Id: Ifbea425f749fee4d6d51faddd8b64bf717a1a5f8
When the Work Challenge is in place, re-route the
enforcing of Admin policies on the password to the
work profile. The Admin should not be allowed to
dictate policies on the device lock in this case.
This is part of the Separate Work Challenge feature.
Change-Id: I757973e540797b5fb10bea7a2fd1925561655bc9
Add a TYPE_QS_DIALOG window type, that is in the same layer as
apps and dialogs and such. It is guarded by having a token
that is granted by SysUI after a click has occured. If the
app shows a dialog before listening finishes (QS closes) then
the token will stay granted until the tile is removed by the
user, otherwise the token will be removed immediately to avoid
later dialogs.
Also fix a couple tiny TileService issues:
- Stop/Start listening reversed
- Fix javadoc referencing wrong action
Change-Id: Iedcdd5fd9a2af2b33eb7f6f17bb0e6c997879876
The work challenge should be locked whenever the device goes to sleep + admin
timeout or when the power button is pressed if the lock setting is on.
This change creates the infrastructure to lock a specific user instead of the
device and uses it in these cases. Then, the current code that brings up the
work challenge can check to only show it if the user is locked.
Change-Id: I89b4342b1458d97734d7afa66be52bf04ec3a3d4
Windows in the pinned stack shouldn't receive input keys, so we prevent
they from gaining window focus so the focus/input keys goes to the stack
below the pinned stack.
Also, cleaned up some code.
Bug: 25580816
Change-Id: Iea1f944d167310233c3dbaea140a4ada568bb815
It forces the user to stop instead of going into the background. Also
changed behavior of stopUser method. Now it also attempts to stop related
users along with the specified userId.
Based on ag/807976, with the only difference that it's now a user restriction.
Bug: 24579258
Bug: 24708668
Change-Id: I357298908816fc58feeed83b7e9979fc33d25da6
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
Without this touch events on the input method will trigger focus change
if there is a window underneath the input. When focus changes, the input
method will go away too.
Bug: 25930832
Change-Id: I532cb9e78f6fe37b1ddfada75594fc695898a090
