Allows a privileged app to set standby bucket states for apps.
Bug: 63527785
Test: adb shell am set-standby-bucket com.example.foo 0
Change-Id: I613f8872ae816e39b167aad1c289187362aa6094
Allows a privileged app to set standby bucket states for apps.
Bug: 63527785
Test: adb shell am set-standby-bucket com.example.foo 0
Change-Id: I069546555e1b370247f8cd45b2f4c32e6abe15ed
On standalones, stay in vr mode until the Power Policy Service notifies
us it has switched to standby mode.
We still have a few issues elsewhere in the code, so the "stay in vr
mode" functionality is only enabled if the system property
"persist.vr.use_standby_to_exit_vr_mode" is set to true, which you can
do like this:
$ adb shell setprop persist.vr.use_standby_to_exit_vr_mode true
Bug: 65248224
Test: - Confirmed on a standalone that doffing leaves us in vr mode for
5 minutes, then we get a notification that we've entered standby, and we
exit vr mode. Confirmed we enter vr mode again when we don the device.
- Confirmed no behavioral change on phones, as expected.
Change-Id: I41d62761fe8c2fc7630f0615732453669cb25f06
This changelist removes checks that enforce that only fullscreen,
opaque activities may request orientation changes. An application
may itself be compatible with the change and update their SDK level.
However, it is possible they use a library that has not itself been
updated and still leverages this feature for non-fullscreen
activities.
Change-Id: Ie1d300e3531fc8c588d2124dea698e4a876713c2
Fixes: 68684796
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
- Move the task stack listener wrapper into the shared lib, along with some
other AM calls.
Bug: 67510855
Test: Launch recents
Change-Id: Icb5ea78ec42d4b76a1c531ce336dd9a3f07a9629
Tablets have the ability to dock to the right side in landscape. This
change supports minimized mode for right dock side.
Test: run-test CtsActivityManagerDeviceTestCases
android.server.am.ActivityManagerDockedStackTests#
testMinimizedFromEachDockedSide
Change-Id: Ie879bdf7bf74226c0ceda9295f9de2004fd6a9b5
Fixes: 68017311
LockTask was first designed to be single-task only. It was later
expanded to multi-task use cases in a rather flawed manner. Many aspects
of the implementation overlook the implications of more than one locked
tasks, and sometimes completely ignore the LockTask-unaware apps.
For example, LockTask-unaware apps are not registered in
LockTaskController's list of locked tasks, although they can be launched
in LockTask mode as long as they are whitelisted. As a consequence,
these unregistered tasks are not finished when their whitelist
authorization is removed.
In this patch, we make sure LockTask-unaware apps are also registered,
and introduce the notion of a root task, thus providing a genuine
multi-task experience with LockTask.
Bug: 66130096
Bug: 66132035
Test: bit FrameworksServicesTests:com.android.server.am.LockTaskControllerTest
Test: cts-tradefed run cts-dev -m DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Test: manual, by using TestDPC > Start kiosk mode
Change-Id: I68a26d2198fa3991f85ae1e7a6acae5981c34db5
Renamed a few functions related to moveTaskToDockedStack to use the new
notion of split screen primary windows instead of docked stack. Most of
the calls that use moveTaskToDockedStack are renamed.
Test: go/wm_smoke
Bug: 68017311
Change-Id: I73df051a9261d213b3415ac132962d91ec632e0a
- Only the recents component package can launch the overview activity
directly, and if an assist data receiver is provided, then assist data
will be proxied to the caller.
Bug: 67864419
Test: com.android.server.am.RecentTasksTest
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: Icdd7e6716a84c11e9262ce5453f7d39ae7d8ce77
- This logic will also be used when the recents component is started to
fetch assist data associated with the current activity.
Bug: 67864419
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: I4cb3c2536a104d7071bc0a1fd6e31dfc2c0ce8d0
This API is useful to improve the autofill performance for the scenarios where
the service knows it cannot autofill an app or activity.
Bug: 67867469
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases -t android.autofillservice.cts.LoginActivityTest#testFillResponseAuthWhenAppCallsCancel
Change-Id: I58e3eb5714db840104e699d614e750c03e26e8ca
Fixes several issues with the way PendingIntents are being whitelisted
from background check with Notifications. Most visibly, this causes the
whitelisting not to work on Notifications that use the DecoratedContentViewStyle,
but there are some conditions where the whitelisting breaks for regular
notifications too.
- After a Notification is rebuilt with Notification.Builder, the set
of PendingIntents in the notification was not rebuilt.
This broke the whitelisting whenever a PendingIntent is added after
the Notification was already sent once. Workaround for broken platform
releases: always use a fresh Notification object, or clone before
sending.
- Fixes PendingIntent.writePendingIntentOrNullToParcel to invoke the
OnMarshalListener.
This broke whitelisting for any PendingIntents attached to custom
RemoteViews. Workaround for broken platform releases: Also attach
the PendingIntent to the Notification's extras.
- Changes RemoteViews to keep the parcel cookies that were present
during unparceling, such that they can be reapplied when it gets
cloned.
This broke whitelisting for any PendingIntents attached to a
DecoratedContentViewStyle *even if added to extras*. Workaround
for broken platform releases: none.
- Fixes Notification.whitelistToken mistakenly being static.
There's an unlikely race condition where the field could be
overriden with null by an incoming notification right as another
notification is sent out. Workaround for broken platform releases:
none.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java && runtest -x core/tests/coretests/src/android/widget/RemoteViewsTest.java
Bug: 68218899
Change-Id: I02e44040604a1d24422340611ae9e0332a611800
The system would like better insight into the shape/size of network
traffic that jobs will be performing. For example, the system may
choose to delay jobs with large network usage estimates when the
device has a poor network connection, in order to save battery.
This also paves the way for more interesting optimizations, such as
allowing small jobs to use surplus metered network quota to improve
the overall user experience.
For now, we use these estimates to perform a simple sanity check to
skip jobs that have no possible chance of finishing within the
10-minute job timeout on a given network. (For example, a job
trying to upload 10MB over a 128Kbps EDGE network is a terrible
idea.)
Test: verified via DownloadManager
Bug: 67040695, 64133169
Change-Id: I9210168b6bda0f0364975a5c7ea25d953a096767
- Add resource for recents component which can be overridden in an overlay
- Allow the static recents component access to APIs which would otherwise
require privileged permissions
- Remove some unused TV recents code
Bug: 67864419
Test: com.android.server.am.RecentTasksTest
Test: #testNotRecentsComponent_denyApiAccess
Test: #testRecentsComponent_allowApiAccessWithoutPermissions
Change-Id: Ia4939b7d443a6058ab4bb41d8c194eb4611cbf80
- Move running task code from stack/supervisor into its own class
- Reduce work to calculate running tasks. Instead of creating RunningTaskInfo
for every single task and then limiting to the requested set, calculate
the set and then create the infos.
- Consolidate calculation of number of running activities in a task between
the RecentTaskInfo and the RunningTaskInfo
- Remove unused flag argument, adding another method to instead filter the
collection of running tasks to exclude certain activity types and windowing
modes. This allows us to fetch only the last running task in SystemUI and
not have additional logic on our side.
Bug: 34270611
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/am/RunningTasksTest.java
Change-Id: Iaba7487cea0545f69739da7cd3095b500a0df6fc
With OC-MR1, for Android Go, we're considering the definition of
"low RAM" to be <= 1GB of RAM. So we update the definition in
this documentation. Additionally, we remove the comments about
screen resolution, as various devices might make trade-offs in
terms of modem stack carveout vs. screen resolution, and those
don't concern us as much as just the total amount of RAM.
Bug: 68277942
Test: None. This is a documentation change.
Change-Id: Ib02024a3e543f8fec11a1735de32ec58278db6e4
Moving to the proto/.../server directory since PowerManagerService is in
com.android.server.
Extracting enums from other components into their own files.
Bug: 65750826
Bug: 65750806
Test: flash device and check incident.proto output
Change-Id: Ib91b7c08142fa66adf18b6e85106d4cbb5adf660
Everything is now moved out of the pm command except for
the various install commands. I am going to hold of on
those since they require doing some resolution with the
current implementations in the package manager to make
sure they match and behave identically to the implementations
currently in the pm command. But other than that, everything
in pm is now just redirecting over to "cmd package".
Also fix up some of the dumpsys output of a few other sevices
when asking to print the data for a particular package, so
the "pm dump" command gives a little more sane result.
Test: manual
Change-Id: I139e06e560203b72243d7eea9543c2240db0f8f8
On devices with multiple active networks, or rapidly switching
between networks, we need an API to tell jobs explicitly which
network to use. (For example, the default route could meet all
job criteria, but we could have changed the default network by the
time we spun up the JobService.)
This also paves the way for us choosing to run jobs over
non-default networks.
Test: verified via DownloadManager
Bug: 64133169
Change-Id: Ic8d654707e39236c8da85a5e172161ac39e5f0b3
