When the activity override configuration changes, we need to apply any
pending application info changes so that when the activity is
recreated, it will have updated overlays.
Bug: 193256671
Test: change live wallpaper and observe launcher colors
Change-Id: I6b8c25a6e6756f612a0f57c921625bc58ac1ecf6
For cases where the attribution soruce doesn't need to be
registered as trusted we are now using a shares static
token since the only purpose of the token in these cases
is for watching the source process dying as opposed to that
and security for registered cases.
bug: 192415943
Test: CtsPermissionTestCases
CtsPermission2TestCases
CtsPermission3TestCases
CtsPermission4TestCases
CtsPermission5TestCases
Change-Id: I93fde9ca1cacada7929761533dcae11b2736ce1e
Obsolete: the use cases for which it was introduced now have a clean
internal API layer to use instead, and this reduces informational
exposure about package presence & states.
Bug: 185513355
Test: atest SyncManagerTest
Test: atest CtsSyncManagerTest
Change-Id: I4aa1848950061dce3a1378f7d0117364e62ba59f
This reverts commit 76370b6fe6.
Reason for revert: Fix the merge break in ShellTaskOrganizerTests.java
Fix: 193069342
Test: atest WMShellUnitTests:ShellTaskOrganizerTests
Change-Id: I02c4bddc407eaac0ebb7cd5abb0b394f242d4d6e
Security report shows that this can cause leak token of different app.
Replace the functionality with a callback to the TaskOrganizerController
to restart activity when size compat restart button is clicked.
Bug: 186776724
Test: manually verify the restart button still works
Change-Id: I097b9f02e8435e6765695b9d5a531a4e165bac66
Merged-In: I097b9f02e8435e6765695b9d5a531a4e165bac66
Mistakenly matching against id alone, rather than the (id,tag) tuple,
led to some notifications mistakenly being flagged as FGS-related.
Bug: 191518901
Test: atest CtsAppTestCases:android.app.cts.ServiceTest
Test: atest CtsAppTestCases:android.app.cts.NotificationManagerTest
Test: manual
Change-Id: I11c3993c13ded7859a5a860dcc99728f3db9809f
In S, we're preventing apps from closing notification shade unless they
fall into certain exemptions. The methods togglePanel() and
handleSystemKey() weren't properly protected, so fixing that.
These methods were @hide, only available in the AIDL and their only
usages were inside the system
Introducing @TestApis to be able to verify this in CTS.
Bug: 192946152
Test: atest -d CtsAppTestCases:android.app.cts.StatusBarManagerTest
Test: atest -d CtsLegacyNotification30TestCases:android.app.notification.legacy30.cts.StatusBarManagerApi30Test
Test: 1. adb shell input keyevent KEYCODE_SYSTEM_NAVIGATION_DOWN
2. Verify status bar expands
3. adb shell input keyevent KEYCODE_SYSTEM_NAVIGATION_UP
4. Verify status bar collapses
Change-Id: I925e3570c8d275a1159e4b6912e4628c9528cb61
* Mention any PIN is allowed, not necessarily
just ordered or repeating PINs.
* Mention alphanumeric and alphabetic passwords
are allowed.
Bug: 181873824
Test: build
Change-Id: Iac75dbdde18de39e0b66ab03463830f5b4f28033
If an application info update is pending and
RM#applyConfigurationToResourcesLocked is called with a config
with an older sequence that RM's current global config, the application
info update should not be applied, nor should the global config be
updated with the older config.
Similarly, when an application is updated and there is a pending
application info change for the previous version of the package,
clear the currently pending application info updates for that package
to prevent the old overlays from being applied on top of the newly
updated application.
Bug: 189100984
Bug: 192449747
Test: toggle wallpaper and observe QS has correct colors
Change-Id: I4bab55960febdae16df7150ccac44e06245e8333
Internal services within system_server can query the PID list of
the isolated processes with packages matching the given UID.
Also added a shell command to help the testing.
Bug: 191703385
Test: atest FrameworksServicesTests:ActivityManagerTest
Change-Id: I9749bc9c70902221f41945c7e785d13631acbae2
Add and populate a "trusted" attribution flag, that verifies the
attribution sources used to create it were trusted.
Fixes: 192270935
Test: atest RuntimePermissionsAppOpTrackingTest
Change-Id: Ifd8f825151bec55aa795da7bee0a3069509f5abe
This reverts commit fa5ab2d27b.
Reason for revert: Was not the cause of the test failure
Fixes: 189100984
Test: toggle wallpaper and observe QS has correct colors
Test: launch an app, navigate away from the app, change wallpapers, and
observe app is relaunched and has correct colors when resumed
Change-Id: Ib3930c06b53f71749ec31784ebe6e8a735a1046d
This reverts commit cb5a80ea57.
Reason for revert: Was not the cause of the test failure
Fixes: 186622527
Test: atest FrameworksCoreTests:ContextTest
Change-Id: I705854f080200f0465d94a7754e710f05a3ec92c
Instead of managing across all users we can restrict globally and fast
fail if the restriction is set
Test: atest CtsSensorPrivacyTestCases
Bug: 191016260
Change-Id: Ida1a2d1734b7e3d40818485062bec0f96270bc4b
We currently specially handle the HotwordDetectionService uid in
AppOpsPolicy. But CheckOpsDelegate doesn't currently include finishOp,
so that doesn't work for the hotword service. This change adds finishOp
to the interface and implements it in AppOpsPolicy to be consistent with
the other ops.
Bug: 190011174
Test: manual - no error in logs for finishOp
Test: manual - privacy indicator works as expected (with another wip
change)
Change-Id: I77907092a917362aacd0d5562e54abd6f3c3d47b
If the IME is bound with capabilities it is considered to be in use by
the user so when they attempt to open the mic or camera we show the
dialog to renable.
Test: Disable microphone and use gboard
Bug: 187154145
Change-Id: Icf8d91f2a2b97068852c1b98d36916c07c42d3fa
Previously we use cache to store value returned from
DisplayManagerGlobal#getAdjustedDisplay(int, DisplayAdjustments)
in RM#getAdjustedDisplay(int, DisplayAdjustments).
Since RM#getAdjustedDisplay(int, DisplayAdjustments) is just
used in RM#getDisplayMetrics(int, DisplayAdjustments), we can
furthur call getDisplayInfo(int) from DisplayManagerGlobal and call
DisplayInfo#getAppMetrics to obtain DisplayMetrics directly.
Also, #getDisplayInfo has binder cache, so we don't need another cache
to store returned DisplayMetrics value from DisplayManagerGlobal.
Before this CL
[1/1] android.app.ResourcesManagerPerfTest#getDisplayMetrics: PASSED
(10.844s)
getDisplayMetrics_median: 1840
perfetto_file_path:
/sdcard/test_results/android.app.ResourcesManagerPerfTest_getDisplayMetrics/PerfettoListener/perfetto_android.app.ResourcesManagerPerfTest_getDisplayMetrics-1.pb
getDisplayMetrics_mean: 1857
getDisplayMetrics_min: 1817
getDisplayMetrics_standardDeviation: 35
After this CL,
com.android.perftests.core (1 Test)
[1/1] android.app.ResourcesManagerPerfTest#getDisplayMetrics: PASSED
(11.185s)
getDisplayMetrics_median: 733
perfetto_file_path:
/sdcard/test_results/android.app.ResourcesManagerPerfTest_getDisplayMetrics/PerfettoListener/perfetto_android.app.ResourcesManagerPerfTest_getDisplayMetrics-1.pb
getDisplayMetrics_mean: 733
getDisplayMetrics_min: 725
getDisplayMetrics_standardDeviation: 5
Test: atest android.app.ResourcesManagerPerfTest#getDisplayMetrics
fixes: 191662456
Change-Id: I934ecae19431800a9a4e0f3e3821e80ef4b5d8cf
In R, when overlay changes a configuration change event is triggered
within the app process affected by the overlay change immediately
after updating the overlay paths of resources objects. All activities
would be relaunched after the configuration changed occurred resulting
in activity life-cycle events occurring for activities running in the
background. Apps may assume that onResume is invoked while they are in
the foreground so we made a fix that triggered the activities to be
relaunched when they are brought to the foreground.
The fix involved storing the asset sequence in the AMS and triggering
a configuration change from the AMS for each process affected by the
overlay change. This created problems where the app may receive a
configuration from the AMS with an updated asset sequence before the
event to handle the application info changing actually updated
resources objects. This resulted in reinflating views with the updated
configuration before the overlays were updated in the underlying
resources objects.
This change allows allows RM to apply changes to application infos when
it sees the asset sequence increase during a configuration change,
rather than having to wait for handleApplicationInfoChanged to run.
Bug: 189100984
Test: toggle wallpaper and observe QS has correct colors
Test: launch an app, navigate away from the app, change wallpapers, and
observe app is relaunched and has correct colors when resumed
Change-Id: Icf81845da9890cda0fb38cf6fe51d1d66e5ea840
Enforce the permission check for both INTERACT_ACROSS_USERS and
PACKAGE_USAGE_STATS permissions.
Bug: 191382775
Test: atest CtsUsageStatsTestCases:UsageStatsTest
Change-Id: I1371070478306005b2b4a59a1bc794bc368ae0c4
Add a historical flag to signify that attribution chains should be
assembled. Assemble the chains, filter out middle nodes, and attach the
last visible node to the start as a proxy info
Bug: 158792096
Test: manual
Change-Id: I8fbd8f438c62b28fd90039440e86224c624dea79
All populations were being set to 0, causing all colors to be wrong.
Test: manual
Bug: 191391779
Bug: 191374703
Change-Id: Id5bef180ca3e6f30e30631781a74b2efb4402ac5
When a context is requested through Context#createApplicationContext,
the underlying LoadedApk cached in ActivityThread#mResourcePackages is
updated using the ApplicationInfo passed in. This creates unexpected
problems when using APIs that expect to be able to read resources from
a previous version of a package after that package has been updated.
With this change, contexts requested through
Context#createPackageContext and Context#createApplicationContext will
will have an underlying LoadedAPK that is tied to the version of the
package represented by the ApplicationInfo. If createPackageContext
is invoked before a package updates and then after a package updates,
the two contexts will have different underlying LoaddApks.
The ActivityThread#mPackages and ActivityThread#mResourcePackages now
only hold LoadedAPKs of that were created using ApplicationInfos that
were sent to this process from system_server in order to run the
application. Whenever a newer version of an ApplicationInfo is
delivered from system_server for one of these packages, the previously
cached LoadedAPK will be updated using the new ApplicationInfo. This
will usually be because of an overlay change or "don't kill" package
upgrade.
Bug: 188059515
Test: atest FrameworksCoreTests:ContextTest
Change-Id: Iea54abf38449c9d8ab9dae16d36d95cbb4d7d8b0
After the introduction of the uses-native-library tag,
sharedLibraryFiles might contain native library names such as
"lib_aion_buffer.so". The old method makePath in the LoadedApk class was
looking for APK paths under the assumption that all the paths in
sharedLibraryFiles are APK paths. Parsing on the results of makePaths
could lead to app crashes because the results are not valid APK paths.
This CL fixes that.
BUG: 190787130
Test: manual
Change-Id: I2b3d439f8edda7ef27e1106046cf8c0b88d755d9
Bug: 186778818
This makes two changes to PropertyInvalidatedCache.
1. disableLocal() now disables all current and future caches that use
the same name (not the necessarily the same property) , in the
local process. Previously, disableLocal() only disabled a single
cache instance, but the intent was always to disable all instances
of the same cache in the process.
disableInstance() is available with the old behavior.
2. A bypass() method has been added. If bypass() returns true,
query() will skip the cache and go straight to the binder call as
though the cache had been disabled. The default implementation
always returns false. Caches can override the implementation to
avoid caching selected queries.
These changes specifically address the problem of caches that are
created dynamically and which should be disabled in the local
process.
A unit-test is added for PropertyInvalidatedCache. This is not a
complete test because test processes are not allowed to set system
properties. The unit-test will be improved in the future by modifying
PropertyInvalidatedCache to use an invalidation mechanism other than
system properties.
Manual test: boot a phone with a baseline build and with the build
under test and verified that the list of disabled caches is the same.
Use 'dumpsys cacheinfo' to get the cache status.
Test: atest
* FrameworksServicesTests:UserManagerServiceCreateProfileTest
Change-Id: I9f604b872911290e4e3d8a58b3e28e328b2000a9
