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
There are three reference type members in UsageStats's constructor, when using "new UsageStats(stats)" to copy, it will be a Shallow Copy, which may cause concurrent modify problem.
For example, in UserUsageStatsService.java, the sUsageStatsCombiner is using "new UsageStats(stats.packageStats.valueAt(i)" to copy, and the value is passing to the computeCacheQuotaHints in
CacheQuotaStrategy.java. If we change the UsageStats.mForegroundServices at the same time, IndexOutOfBounds Exception will happen.
Therefore, it is necessary to modify the way of copying of the UsageStats.
Signed-off-by: zhuyunyi <zhuyunyi@xiaomi.com>
Change-Id: I58a54d17aad6ef5213e52658ee3387f3069339af
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
Merged-In: I956f76be2e0a1a675576511fb394d7ed4354b28a
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)
Reason: There is only one telephony stack shared
between the personal and work profile.
Bug: 194382185
Bug: 189942529
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testGrantOfSensorsRelatedPermissions
atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDenyOfSensorsRelatedPermissions
atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testSensorsRelatedPermissionsNotGrantedViaPolicy
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testGrantOfSensorsRelatedPermissions
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDenyOfSensorsRelatedPermissions
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSensorsRelatedPermissionsNotGrantedViaPolicy
Change-Id: I99384d5713bb2d04f5b6fbe20c17bd72a39b57d7
When a new Context is created from the Activity Context and used to
inflate views, Content Capture is disabled for those views because the
new Context is missing ContentCaptureOptions.
Fix: 194321297
Test: atest CtsContentCaptureServiceTestCases
Test: manual - view appeared events come through
Change-Id: I934d41953c7668e371d5961b66187ecd15408e3e
