The snapshot profile produced with `adb cmd package snapshot-profile`
needs to be readable by the others group so that adb can pull it.
Test: adb shell cmd package snapshot-profile pkg;
adb pull /data/misc/profman/pkg.prof
Bug: 74081010
Change-Id: Ibef8551704116e0b695f725e95f1671acbb82b5d
In the current design, IdleController of Job service considers devices as ‘idle’ after 71 minutes of screen off. But under docking use scenario, devices screen might remain on for a very long time and it’s not necessary implying the device being interactive with users.
So create a mechanism for device to enter the ‘idle’ state that JobScheduler can kick off idle tasks.
Bug: 79183658
Test: atest DeviceStatesTest
Change-Id: I5b307ca51e28ffca63f79a9c43984c3b76e51629
There is a legitimate use case when sending a PendingIntent from
within system_server, for example AlarmManager. However, we used
to WTF always in this case.
To fix this, we only WTF when trying to use a remote animation
that originates from within system_server.
Test: Boots, open apps
Change-Id: I7bafae9f899cbb8966cf22166270000ce887baba
Fixes: 79417917
UPDATE_APP_OPS_STATS lost the privilege to change app ops modes, so we
need to add this permission to the tests.
Test: atest com.android.server.job.BackgroundRestrictionsTest
Fixes: 79887147
Change-Id: I085c522cf3969a4cd7de7c47209eb83225b34254
The only way to know the runtime state was check dumpsys usagestats, and
parse through a lot of output.
This makes it easier to retreive the state.
Test: adb shell settings put global app_standby_enabled 0
adb shell dumpsys usagestats is-app-standby-enabled
Bug: 74336662
Change-Id: Ibe80d27bdf940682b9e4c3c14f93b4871f9f1746
Some app launches go through different stacks. However, in P we
have one stack per task, which broke launch time tracking for
certain apps.
We fix this by tracking launch time per windowingMode, like we
do in ActivityMetricsLogger.
Test: Delete Chrome app data (to ensure FirstRunActivity gets
invoked, am start -n com.android.chrome/com.google.android.apps.chrome.Main -W
Fixes: 78302265
Change-Id: I739e63aeaf04d6336621e3d61f065259e518d9b4
When an app calls startForegroundService() from a bg state (e.g. from a
broadcast receiver) but the user has placed it under FAS, it's incorrect
to crash the app: it hasn't actually violated the fg/bg restrictions
contract. Fail quietly instead, just like the legacy-app case when O+
restrictions are imposed on it.
Change-Id: I3e8ed2ea6bdbf4167249132ddf9b7c549b9a8062
Fixes: 79235311
Test: ApiDemos [before and after changing target sdk to O+]
Test: atest android.app.cts.ServiceTest
- When avoiding moving the stack to the front, skip resuming as well (since
the recents activity is starting in the back, and this prevents having
to add more checks to skip moving the task to the front).
The avoid-move-to-front option is only used for the recents animation,
and only used when starting a new activity, so the effects of this change
should only be limited to that logic.
- Also execute the app transition explicitly since it isn't triggered when
we aren't resuming the newly started activity, which was causing the
app-transition timeout to occur before launcher was next made visible
and good to go).
Bug: 77154670
Test: Open app, install launcher in the background to kill the activity,
then swipe up and ensure that it actually works instead of running
the normal task-dismiss transition
Change-Id: I8c39d95e7a6ca65a099aba7285e852b2480804ca
Apparently comparing Spannables is dangerous because
the various Span classes do not implement .equals() in any
meaningful way, so all CharSequences must be converted to
flat Strings before being compared.
Lots of additional debug code remains, for the next time we
don't understand why an innocuous notification update
appears to be interruptive.
Test: atest com.android.server.notification.NotificationManagerServiceTest
atest com.android.server.notification.NotificationTest
Bug: 78643290
Change-Id: I1c282238687f28b5b197e28a4b878dc697049f4d
- In O, the fullscreen stack was resized once we enter splitscreen (and
is updated with the tempOtherTaskBounds as we resize for minimized
state). However, in P, since we are creating a new stack for each task,
the launch of a task while in splitscreen now falls into
TaskStack.updateBoundsForWindowModeChange() which incorrectly calculates
the bounds of the secondary stack using the minimized bounds of the
primary stack. Subsequent launches are fine because the stack already
exists and is just being brought forward.
Bug: 73745166
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerSplitScreenTests
Test: Enter split screen, launch an app from scratch and ensure it
animates to the right place
Change-Id: I7da856b9bb88db0db9616d56bb9fefdce918d7c3
