Only one simple method of the lib is used, that doesn't need to
include the medium size lib.
Bug: 159102753
Test: TaskStackChangedListenerTest
Change-Id: I312c75a366bdfc5a9017c32443732b1ac96797ab
The state field is declared as volatile. And the field is always
written on display thread without lock. So it is unnecessary to
lock the getter method.
Bug: 173467481
Test: CtsWindowManagerDeviceTestCases
Change-Id: I6324f6745fd849438b7b0d326bd63bd2d0580421
If the user is not loaded in ShortcutService, there is no need to reset
the current default launcher. This is to prevent any unnecessary file IO
when the default launcher changes.
Bug: 173614832
Test: atest com.android.server.pm.ShortcutManagerTest1
com.android.server.pm.ShortcutManagerTest2
com.android.server.pm.ShortcutManagerTest3
com.android.server.pm.ShortcutManagerTest4
com.android.server.pm.ShortcutManagerTest5
com.android.server.pm.ShortcutManagerTest6
com.android.server.pm.ShortcutManagerTest7
com.android.server.pm.ShortcutManagerTest8
com.android.server.pm.ShortcutManagerTest9
com.android.server.pm.ShortcutManagerTest10
com.android.server.pm.ShortcutManagerTest11
atest CtsShortcutHostTestCases
atest CtsShortcutManagerTestCases
Change-Id: Ic3bbb0f7b4d308bddbff1d586a8700388f317f6b
MediaRouterService maintained bindings to provider services
once those are established.
With this CL, it only binds services when there is a non-empty
discovery preference set by a foreground app or an app is casting.
This change may break output switcher, which enables transfer media
of background apps.
To alleviate that MediaRouter2Manager#startScan and #stopScan are added
so that system UI can force the service bind to the services and find
remote devices to cast.
Bug: 169575701
Bug: 172920557
Test: manually and CTS
Change-Id: I4a47fdb1c9fe05a04d26950485833c9cbfb91a69
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
CaptivePortalLoginActivity is exported without any permission check
which has security concerns: The captive portal activity can be
tricked into making various carrier calls, including
resetAllCarrierActions.
Bug: 160871056
Test: Build
Change-Id: Ib7cc1ba4aca665bc94f8582de6bba7af252c481d
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
Currently, we are dumping information on ViewRootImpl, but it doesn't
include some of the critical pieces. Add attachinfo information. Also,
attach a dump of a variable that determines whether the input events
will be dropped.
Example of newly added piece of dumpsys:
mPausedForTransition=false
...
mAttachInfo= AttachInfo:
mHasWindowFocus=true
mWindowVisibility=0
mInTouchMode=true
mUnbufferedDispatchRequested=false
Bug: 173675649
Test: adb shell dumpsys activity -v all
Change-Id: I7b8801436f74a123bf96735de30b238146413545
- DROPBOX_ENTRY_ADDED is sent to the system user.
- In headless system user, the current user could not be the system
user.
- This CL make it broadcasted to all interested receivers.
Bug: 158246058
Test: atest
CtsAppExitTestCases: android.app.cts.ActivityManagerAppExitInfoTest#testAnr
Change-Id: I897782a809ef5a115c536b03348296bdc4166630
Added View API to configure RenderEffect on the underlying
RenderNode
Bug: 159712515
Test: Added CtsUiRenderingTestCase
Change-Id: Ic64009ac79927d61c7c1f63306ced3da18fce1da
