ag/1437028 tried to fix this problem, but limited intent
delivery to only paused activities in a minimized docked stack
to reduce the effect of the change since we are late in the
release cycle. However, it didn't completely solve the problem
for example when the ChooserActivity comes up in the fullscreen
stack un-minimizing the docked stack and then the user selects
the app in the docked stack from ChooserActivity.
We now immediately deliver intents to paused activities as they
are currently visible to the user and we want the user to see
the visual effects caused by the intent delivery now.
Bug: 31371093
Change-Id: I94f9717da66daa512071bb96e62b2f9811691a78
During refactoring in ag/613666 waitingVisible flag clearing
was mistakenly removed. It was added back in ag/1221328 but
only for activities that are finishing.
This caused activity not being stopped in some cases when
window visibility change was handled before receiving idle
callback from client. This is easily reproducible when there
is a scene transition animation specified.
Bug: 31078584
Change-Id: Ic09c5199ad4fceae0607e4bcce02be5335c8870b
If the process is forced to the foreground due to a toast,
don't inform usage stats of an interaction. Otherwise app standby
will be defeated easily.
Bug: 31544592
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdle_toast
Change-Id: I100d839ef8cf361704fd5db4b26dcc878672a235
Currently, when the avoid bad wifi setting changes, we rematch
all networks and requests, but do not update any NetworkFactories
with new scores. This means that if a wifi network's score goes
down as a result of enabling bad wifi avoidance, we will not look
for another network (e.g., cell data) to satisfy its requests.
This makes it so that when the user enables avoiding bad wifi,
we will attempt to bring up cell data will if it is not already
connected.
Bug: 31075769
Change-Id: Ie5b685be8676999adea8c9ecbbc1abb92f81a74f
NMPS was listening to both ACTION_UID_REMOVED and
ACTION_PACKAGE_REMOVED, which not only was redundant but would also
cause problems when a package with shared UIDs was removed.
Fixes: 31375684
Change-Id: Iec006dbbec0e6298f1e568cbf81ed3672f61b7d2
(cherry picked from commit fdebbea401)
Prevent sending media key events from the non-system app to the global
priority session through the MediaSessionManager.dispatchMediaKeyEvent().
Note that any app can use the API indirectly with
the public API AudioManager.dispatchMediaKeyEvent().
Bug: 29833954
Tested: Installed malicious apps and confirmed that they don't work.
Tested: Run CtsTelecomTestCases and CtsMediaTestCases
Change-Id: I2a9e78196ba7455324e485f098f095d03b47ee15
If no service is present that could satisfy a given ServiceWatcher,
then return false. For example, on devices were there is no Geocoder
service implementation, we need to avoid claiming that the API is
supported.
Test: booted
Bug: 30837973
Change-Id: Ib0834cf1a12623733f8b472dc3da7b3e2adc4515
Bug 31247871 and Bug 31273203 are the same in terms of that both can be
triggered by calling TSM##getCurrentSpellCheckerSubtype() but different
in terms of what lock objects are involved.
To summarize
Bug 31273203: between IMMS#mMethodMap and IMM#H
A. OnClickListener.onClick() running in the IMMS locks IMMS#mMethodMap
then does some View operations, which can be blocked until
IMM#H is unlocked (e.g. IMM#onViewDetachedFromWindow()).
B. TSMS#getCurrentSpellCheckerSubtype() internally calls
IMM#getCurrentInputMethodSubtype(), which locks IMM#H then can be
blocked until IMMS#mMethodMap is unlocked.
The tricky point here is that IMMS and TSMS are running in the same
process hence IMM#H are actually shared between them.
Bug 31247871: between IMMS#mMethodMap and TSMS#mSpellCheckerMap
C. IMMS locks IMMS#mMethodMap then calls
InputMethodUtils#setNonSelectedSystemImesDisabledUntilUsed(), which
can be blocked until TSMS#mSpellCheckerMap is unlocked.
D. TSMS#getCurrentSpellCheckerSubtype() locks TSMS#mSpellCheckerMap
then may call IMM#getCurrentInputMethodSubtype(), which can be
blocked until IMMS#mMethodMap is released.
This CL aims to remove the layered lock in D to close Bug 31247871,
while the previous CL [1] took care of B to close Bug 31273203.
Note that A and C are still concerning and should also be taken care of
as a part of Bug 31273203.
[1]: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
fa1886feea
Bug: 31247871
Bug: 31273203
Change-Id: I26479e7aa306e0df91d9911891d5625dd5f99678
This contains the following changes:
1. Make NETWORK_AVOID_BAD_WIFI a tristate: 0 means never avoid
bad wifi, unset means prompt the user, 1 means always avoid.
2. Look at NETWORK_AVOID_BAD_WIFI only if the carrier restricts
avoiding bad wifi (previously, we relied on the setting being
null and defaulting to the value of the config variable).
3. Add an avoidUnvalidated bit to NetworkAgentInfo to track
whether the user has requested switching away from this
unvalidated network even though avoiding bad wifi is generally
disabled. This is set to true when the user selects "switch"
in the dialog without setting the "Don't ask again" checkbox.
4. Add a hidden setAvoidUnvalidated API to ConnectivityManager to
set the avoidUnvalidated bit.
5. Additional unit test coverage.
Bug: 31075769
Change-Id: I1be60c3016c8095df3c4752330149ce638bd0ce1
- Prevent third party apps from inadvertently changing internal SystemUI
flags through a call to setSystemUiVisibility(). These flags are only
set in the individual SystemUI components and can be updated in WMS
directly.
Bug: 29875297
Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
When parole state changes, compute the uids that have been
impacted by the change of idle state and inform listeners.
Bug: 31399882
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleNonMetered_whenCharging
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleMetered_whenCharging
Change-Id: I5cc49464a2d359890b5c48033149e569a5b021ca