1. Add field mAllowStartFgs in ProcessRecord to indicate this app can
start FGS.
2. mAllowStartFgs is true if the process has
* any of these permissions: START_ACTIVITIES_FROM_BACKGROUND,
START_FOREGROUND_SERVICES_FROM_BACKGROUND, SYSTEM_ALERT_WINDOW
* the process's uid is ROOT_UID, SYSTEM_UID, NFC_UID, SHELL_UID.
* the process's proc state is higher or equals to
PROCESS_STATE_BOUND_FOREGROUND_SERVICE.
* the process's uid is DeviceOwner, or allowlisted by
DeviceIdleController.
3. The mAllowStartFgs ability can be passed to another process by
service binding. Except if the binder is PROCESS_STATE_PERSISTENT, this
ability does not pass down.
Bug: 171305836
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java#testFgsBindingFlagNone
Change-Id: I20d977ce7ae65316cdec2cd0ef9cf9bafec2adbd
This is the first step towards moving letterbox gravity logic from WM Shell to WM Core. It's important to do this even before the new implementation in WM Core is ready because surface repositioning in WM Shell causes visible flickering on rotation for all apps on devices with cutout.
Fix: 174632285
Bug: 175212232
Fix: 173440321
Test: atest WMShellUnitTests
Change-Id: I2b3706a1a46bb2c7ee4bb3789fb09b216e32f290
CAPTIVE_PORTAL is a CS-managed capability, and causes CS to log a wtf.
When this test is run on an eng build, this sends SIGSEGV to the test,
which is pretty difficult to debug.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I72fc46a6daa4e886425b4dc967318cca9f1a5302
Currently, ConnectivityService assumes that only VPNs can have
underlying networks. Make the code decide this based only on the
return value of NetworkAgentInfo#supportsUnderlyingNetworks.
This allows non-VPN network types to support underlying networks
in the future.
This requires storing the original agent's capabilities in
NetworkAgentInfo so that applyUnderlyingCapabilities can mix in
the underlying network capabilities without overwriting the
capabilities of the network itself. Currently, the only
information that applyUnderlyingCapabilities takes from the
original agent's capabilities are the metered bit (stored in
NetworkAgentInfo#declaredMetered) and the transports (assumed to
be exactly {TRANSPORT_VPN}. Store the full capabilities instead.
This is more state than needed but it ensures that we do not need
to make any changes if in the future we want to propagate new
types of information from the underlying networks.
This should have no impact on current use cases (i.e., VPNs).
There is a change in ordering: in disconnectAndDestroyNetwork,
the new code propagates underlying network capabilities before
removing the network from LegacyTypeTracker, instead of after.
This is done to simplify the new code. When the new code
propagates underlying network capabilities in response to a
change for a particular network (e.g., connect, disconnect,
capabilities change), it only considers networks that have the
changed network as underlying. Because determining the
underlying networks requires knowing the default network,
the new code runs before the default network is changed and
LegacyTypeTracker is updated.
This shouldn't have app implications because the connectivity
broadcasts sent by LegacyTypeTracker and the callbacks cannot be
ordered, since they run on separate threads with unpredictable
delays. The capability change callbacks resulting from
propagation of underlying network capabilities were already
sent before the rematch, so the callbacks themselves are not
reordered in any way.
Bug: 173331190
Test: atest FrameworksNetTests \
CtsNetTestCases:NetworkAgentTest \
CtsNetTestCases:Ikev2VpnTest \
CtsNetTestCases:VpnServiceTest \
CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest \
HostsideVpnTests com.android.server.connectivity.VpnTest
Change-Id: Ic5353a928a3a3541dcf953c35f47277c5e295db8
