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
checkUriPermissions is an API to check Uri permissions on a list of
Uris. This is an optimisation over calling checkUriPermission separately
for each Uri in the list as each call is a binder call.
The bug is caused due to getContext.checkUriPermissions() for User 10
calling into ActivityManagerService(AMS) for User 0. The old APIs
(checkUriPermission for 1 Uri) resolves the user one step before
calling into AMS that is in ContextImpl class. But resolving the
calling user via context in AMS is not resolving the actual user (in
this case the calling user is user 10, and AMS context resolves the
userId to User 0).
Resolving the user in AMS was a conscious decision we made as we wanted
to resolve the user for each uri in the list separately.
Fixed the above issue by passing userId to AMS from ContextImpl and then
resolving the user for each uri.
Bug: 194700183
Test: atest --user-type secondary_user CtsScopedStorageDeviceOnlyTest:android.scopedstorage.cts.device.RedactUriDeviceTest#testSharedRedactedUri_openFileForRead -c
Change-Id: Ia4f0ba39a34c8ae4bd46d6f10bca1052f1331400
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
When an app registers an exported component in its manifest and adds an <intent-filter>, the component can be started by any intent - even those that do not match the intent filter. This has proven to be something that many developers find counterintuitive. Without checking the intent when the component is started, in some circumstances this can allow 3P apps to trigger internal-only functionality.
Bug: 161252188
Test: atest CtsContentTestCases:PackageManagerTest
Change-Id: I19e8ee0a529314b3417435471c6e68988a2ab897
This allows applying split rules to activity start requests for
different processes and covers APIs like 'startActivityAsUser',
not requiring app developers to use dedicated APIs to start to side
instead.
When the client organizer observes a new activity being started, it
creates a new TaskFragment first and modifies the activity start
options to target that container.
Bug: 194140227
Bug: 190433398
Test: Manual, using reference implementation and sample app.
Change-Id: Ice3de8ec725d327266ec38052129b4158608855e
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
Remove "simulated" location time zone provider mode and enable "fake"
location time zone providers. This allows for more realistic testing
with binder-based LTZPs.
Many of the changes in this commit are the removal of command-line infra
and test logic associated with "simulated" mode. The new
"start_with_test_providers" command is required to enable changes to how
providers are discovered, since test providers are not found on the
system image and will not have the full permissions expected (which are
requirements of "real" providers). As part of this change "state
recording", something only used in tests, can only be turned on by
"start_with_test_providers". A "clear_recorded_provider_states" has been
added to enable tests to clear the recorded state.
The new test mode config deliberately does not survive a reboot.
Bug: 188780558
Bug: 184947690
Test: atest CtsLocationTimeZoneManagerHostTest
Test: atest com.android.server.timezonedetector
Change-Id: I7d8fc217fa070aee791fb376efb398057320503a
This reverts commit 8d6900e011.
Reason for revert: The UIDs in this CL are Linux UIDs, which are never
negative. The @UserIdInt annotation is incorrect and the bypass()
override is unnecessary. See the comments on ag/15339446 for another
instance of this issue.
Change-Id: I79ccbb40c3f0ab1a3bb48f55da5a72696d4fb2b1
These changes cause some noted app ops to be swallowed due to one-way
app ops.
Fixes: 187721493
Test: atest AppOpsLoggingTest
Change-Id: I3b761b65b2e06138fc1d130bf80587f8885bb1d5
is completed.
Construct the EnterpriseSpecificIdCalculator object after boot phase is
complete, as some of the dependencies(telephony and wifi service) for
this class are not properly initialized before that.
Bug: 191741106
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testEnrollmentSpecificIdCorrectCalculation com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testEnrollmentSpecificIdCorrectCalculation com.android.cts.devicepolicy.MixedDeviceOwnerTest#testEnrollmentSpecificIdEmptyAndMultipleSet com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testEnrollmentSpecificIdEmptyAndMultipleSet
Change-Id: I20927cdc6844591f12d390ced7f1471733602a81
Activity#onCreate is called before receiving the TaskFragment
appeared event in the client process. So, the client split
controller created another split and resulted in unexpected
behaviors.
Bug: 194860679
Test: start activity to side
Test: wm presubmit
Change-Id: Iac34bd39376940c5c0224c8687ad9858a4190e20
With this change, WallpaperController sends "freeze" / "unfreeze" commands when the app window is letterboxed / not letterboxed indicating that:
- "freeze": a screenshot of the wallpaper is taken by WallpaperServices and put on top of the main surface while the wallpaper host is notified through onVisibilityChanged(false) callback that it's no longer visible.
- "unfreeze": a screenshot of the wallpaper is removed and the wallpaper host is notified through onVisibilityChanged(true) callback if the wallpaper is visible again (e.g., if transitioned from an app to the Home screen).
Logic isn't applied to static wallpapers.
When wallpaper size changes while being frozen, the screenshot is scaled and cropped to adjust to the new size.
Fix: 177884751
Test: Manual, atest WallpaperServiceTest, WallpaperServiceTests
Change-Id: If0300478cdccc07d226117e01ce3d43aa0b432a0
* 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)
* Also add a warning message for future flags being added.
Fixes: 177097561
Test: atest CtsAutoFillServiceTestCases
Change-Id: Ia2e78601dfb18a50c2a243936a210d5f372821cf
