This reverts commit 51b874f628.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: Icf2d0a656512e6b6bb46dd7ffef3e3cd71ac1a37
The size of the input of both setStream and setResource may very big
that system server got oom while handling it, so we try to decode it
first before copying it to the wallpaper path, if the decoding fails, we
treat the input as an invalid input.
Bug: 204087139
Test: Manually set wallpaper, no PDoS observed.
Change-Id: I014cf461954992782b3dfa0dde67c98a572cc770
A background app that changes the wallpaper, was able to change the
device theme.
This change will apply the theme if the app is on the foreground, like
WallpaperPicker would be, but would defer the event until the next power
button cycles, like we do with Live Wallpapers, to avoid the same type
of DoS.
Test: manual
Test: atest ThemeOverlayControllerTest
Fixes: 205140487
Change-Id: I2086b29ef9bf3bb6fb7d9ebba6e7b8db9392e459
Merged-In: I2086b29ef9bf3bb6fb7d9ebba6e7b8db9392e459
If a profile owner is defined for a specific user, do not delete usage
stats for a package on package deletion.
Bug: 197399948
Test: atest UserUsageStatsServiceTest
Test: atest UsageStatsTest [all]
Change-Id: I94a8e3dfca8ef4c7616f77944d61726e06043b85
Merged-In: I94a8e3dfca8ef4c7616f77944d61726e06043b85
setTurnScreenOn shouldn't dismiss keyguard automatically even when the
keyguard is insecure.
The keyguard state should only be affected by requestDismissKeyguard
and/or setShowWhenLocked, and for either case setTurnScreenOn can be
used to wakeup device if the activity is going to be resumed and
visible.
Bug: 201103497
Test: atest ActivityVisibilityTests KeyguardTests KeyguardLockedTests
Change-Id: I283dea469a33286fc9cf835e39ee5a3be2444739
(cherry picked from commit f3a1274a38)
* changes:
Use Process.getRss instead of mProfile.getLastRss in CacheOomRanker.
Change CacheOomRanker's "uses" feature.
Fix race condition when using mPreserveTopNApps.
Allow CacheOomRanker to rerank when there's <8 processes in the cache.
Fix CacheOomRankerTest.
allowlisted.
Previously when PowerExemptionManager.addToTemporaryAllowList() is
called for a second time before the first time call's duration expires, the
second call does not update ActivityManagerService's
FgsTempAllowList for the new duration. This CL fixes this problem.
Bug: 199801023
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Change-Id: Ibb8c6f41740a9b7468b50a4cdabe526ae58550ec
The previous implementation was incorrect, as an app goes in and out of
the cache several times during oom_adj calculation. If all apps started
at the same time, then this would be OK - as they all get incremented
the same amount, plus get incremented when they actually go in and out
of the cache. This would result in the relative counts being correct.
However, as all apps aren't started at the same time, the old
implementation is instead a measure of how long the app has been
started.
So instead we use mSetProcState, which isn't changed on each oom_adj
calculation. This measure should accurately reflect the number of times
the process is used - whether that's by a user app open, or a content
receiver call, or an intent being broadcast.
See go/sim-v-impl for more details.
Test: atest CacheOomRankerTest
Bug: 196031723
Change-Id: I49d02362b8277f8472355e78412f79256c2289a1
Merged-In: I49d02362b8277f8472355e78412f79256c2289a1
(cherry picked from commit 480cc3123c)
As part of fixing the security vulnerability(b/192245204), do not
return admin package details in the returned
Intent(ACTION_SHOW_ADMIN_SUPPORT_DETAILS) from createAdminSupportIntent
API. Insted introduce an API to return admin info given user and
restriction, this API will be used by the Activity that handles the
Intent returned by createAdminSupportIntent API.
Bug: 192245204
Test: atest MixedDeviceOwnerTest#testCreateAdminSupportIntent
atest MixedProfileOwnerTest#testCreateAdminSupportIntent
atest MixedManagedProfileOwnerTest#testCreateAdminSupportIntent
atest DevicePolicyManagerTest#testCreateAdminSupportIntent
Change-Id: I3ed502a078eebac62e0b8a27f6302410c22111e4
Merged-In: I3ed502a078eebac62e0b8a27f6302410c22111e4
WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
Sometimes see temporary black wallpaper after setting a new image
wallpaper because of:
- decode bitmap twice, results in long latency until drawing.
- the set wallpaper apis didn't sync with wallpaper rendering well.
Solutions:
- Only decode bitmap when necessary.
- Make set wallpaper apis wait for image wallpaper rendering finished.
Bug: 194080642
Test: see b/194080642#comment3
Test: atest WallpaperManagerServiceTests --iterations 50
Test: atest SystemUITests
Change-Id: I369eff5195571161cf286b3ec97175481b02eed7
* changes:
Reduce the color contrast requirements for the emphasized action button fill color.
Refactor the color span code inside Notification.java and add tests.
This reduces the contrast requirement between the notification background and the button fill from 3:1 to 1.3:1
Fixes: 196393060
Test: manual testing using the go/notify2-apk and the CallStyle color customizer
Test: android.app.NotificationTest
Change-Id: I0fc3b7ae1ede7afd28974c59fa2a58d7fea2e9de
* This makes it easy to reduce the contrast requirement between the notification background and the button fill in another review.
* This also fixes a bug where partial-length color spans within the emphasized buttons would be contrast-adjusted only with the notification background color rather than the button fill color.
Bug: 196393060
Fixes: 197572220
Test: manual testing using the go/notify2-apk and the CallStyle color customizer
Test: android.app.NotificationTest
Change-Id: I712e6d6b2da1de89afeacda7bd2fc4ad24632811
Enable ANGLE as a Game Dashboard intervention via Phenotype.
Bug: b/188475576
Test: GameManagerServiceTests
Change-Id: I91894a76b8dcf7a97244cff679a501001734f671
Merged-In: I91894a76b8dcf7a97244cff679a501001734f671
(cherry picked from commit acf3851b8f)
This reverts commit 6a5ca92e75.
Reason for revert: This is affecting notification channels that are using the system sound and is resulting in users losing most of their notification settings
Change-Id: I350cf8190eec6296a597bef38b711900336ddf75
Fixes: 197129198
This is a short-term workaround to dump error log instead of throwing
the exception to unblock the test.
Bug: 197484331
Test: build pass
Change-Id: I2ece3b9d85edc1ae43038e6f69b35f59b160a3dd
This will allow vendor versions of System UI to backup their
vendor-specific data.
Test: Tested locally
BUG: 195548201
Change-Id: Iebf512104be2a8fa0dfb614af12d95ed6a3625eb
Fixes: 196585371
Test: post colorized notification with luminance between .2 and .5; validate that smart replies and remote input use black text to match the notification.
Change-Id: I5ea69181755ed5c2b48352a0379ae4e898202e21
Merged-In: I5ea69181755ed5c2b48352a0379ae4e898202e21
Currently the <cloud-backup> section in android:dataExtractionRules is
ignored unless it contains rules. Instead, we should interpret it as
'everything other than cache and no-backup dirs is eligible for cloud
backup'.
Bug: 195095045
Test: 1. atest BackupEligibilityHostSideTest
2. Use a test app with empty <cloud-backup> section to manually
test:
2.1. Empty section - everything is backed up
2.2. Empty section but "disableIfNoEncryptionCapabilitites"
set to "true" - data only backed up if the transport supports
encryption.
Change-Id: Ic8066721a46bda688f9211c51a0f2497e9caf93b
ActivityClientRecord#activity is assigned after calling
Activity#onCreate. A use case is that the app uses
support library to set night mode in onCreate.
Bug: 195418295
Test: Invoke Activity#recreate() in Activity#onCreate.
Change-Id: I6319cd6ee94fc2603979da47303963d04168db04
Add attribution flags and chain IDs to start callbacks, and have the
PermissionUsageHelper listen for starts. This ensures that, if another
start happens while an op is already running, and has chain information,
then this chain information will be recorded.
Test: manual
Bug: 194198234
Change-Id: I0ab1aa0969b70e18001f4a814ea5689f9329a019
These changes cause some noted app ops to be swallowed due to one-way
app ops.
Fixes: 187721493
Test: atest AppOpsLoggingTest
Change-Id: I3b761b65b2e06138fc1d130bf80587f8885bb1d5
* When we changed the default color of emphasized actions to an accent color instead of the notification background color, I didn't split the two into different locals, and this meant the accent color was used to enforce the color contrast of the custom color. This led to color desaturation in an attempt to meet contrast (when in dark mode) and a failure to ensure sufficient contrast (in light mode).
* A piece of this that applies specifically to colorized notifications is that we used the 'night mode' state as a shortcut for whether the background was light or dark. This led to 1) different foreground colors for the same background color, depending on dark mode state, and 2) frequently a failure to meet contrast (and/or extreme desaturation) in one of those modes.
* Also adding different night-mode colors for CallStyle actions, to meet spec.
Test: validated sufficient contrast of default and various colorized background/button combos using the accessibility scanner.
Bug: 194935539
Change-Id: I3a69eadc89f1d9d98a816c44a36873c7615a177e
Starting in R, some methods in ConnectivityManager like
getNetworkCapabilities started passing the package name from
the context stored in CM to check that the package is really
whom it pretends to be. Unfortunately, in some cases, the
context contains package "android" for an app, and since the
app is not the system, the check fails and crashes the app.
It seems the culprit is updateHttpProxy, which is called by
ProcessList when the PROXY_CHANGE_ACTION broadcast is sent.
If this happens to run between the time the process is created
and the activity thread is "bound", then the mInitialApplication
member is not set, and updateHttpProxy uses a system context.
Since ConnectivityManager caches the context forever in a
static, this leads to subsequent legitimate calls crashing.
Setting the proxy can be deffered until such a time that the
app is bound, as it can't run any code before then. The member
is never reset to null, so it's guaranteed to be non-null at
bind time.
An alternative would be to post a runnable on the handler
thread if the member is null to try again later. This
could however run the lambda a considerable number of times
as binding can be delayed, and risks causing an infinite loop
if some invariants are changed in the future.
See also b/73572062 and ag/4056059
Bug: 155549446
Bug: 189360509
Test: ActivityThreadTest FrameworksNetTests NetworkStackTests
Test: Manually set a proxy, observe the broadcast being sent and
apps not crashing
Change-Id: I956f76be2e0a1a675576511fb394d7ed4354b28a
(cherry picked from commit b0d13e29515d5b7c82daed7533b78ac57e46bd93)
