SysUI status bar updates currently happen upon receiving either the
CONNECTIVITY_ACTION broadcast (which is deprecated) and
INET_CONDITION_ACTION broadcast (which is sent upon validation state
change of networks only).
This leads to status bar showing stale connectivity state. The correct
fix for this is to listen to changes in network state by registering
NetworkCallbacks (see more details in http://b/79286300#comment9).
In the P timeframe, not listening to the broadcasts completely is out of
scope. So this CL just listens for changing network capabilities of the
default data network, which should fix all the cases where the
broadcasts are not getting sent.
Later, when we stop relying on the broadcasts, we will also have to
override onAvailable and onLost (and perhaps the other callbacks too).
Test: runtest --path frameworks/base/packages/SystemUI/tests/src/com/android/systemui/statusbar/policy/
Bug: 71904788
Change-Id: I2e58b9cfceb9937a0b54874dee116ead5339b37b
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
Previously we mis-count each different activity, regardless of the app
it belongs, as one app launch. We should instead count each different
app open, either created, or brought front as a different app launch,
but different tasks created from the same app is considered one launch.
Fixes: 79885137
Test: Manual test
Change-Id: I5b4b8bee9b0ed4aa23a4ea9eefdfa112b6442455
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
KeyguardUpdateMonitor's Handler runs on the main looper by design,
we need to ensure that whenever we're processing messages, that
they will also be received on the main looper.
Also unregistered a broadcast listener to avoid a possible race
condition
Test: atest packages/SystemUI/tests/src/com/android/keyguard/KeyguardUpdateMonitorTest.java
Bug: 79550837
Change-Id: I14a319da5c6bc46fd32675ae205e14a6228efaa4
- 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
Refactor code which update summary in updateState,
Move them into new method refreshSummary.
Fixes: 67997698
Fixes: 67997726
Test: make RunSettingsLibRoboTests
Change-Id: Icbcedcd08efa2103042ba40a756e8d4b615e1352
Merged-In: Icbcedcd08efa2103042ba40a756e8d4b615e1352
We need to be able to print the PhysicalChannelConfig
for debugging/dumping, so adding a toString() method
to print in a format that we can easily digest and
is consistent with other Telephony log formatting.
Bug: 78791811
Test: manual / TelephonyDebugMenu
Change-Id: Ieb12f78a821369072ca9f03d28b28759836f84b4
