This reverts commit fa9c73975e.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: I567f20b4f545bed906938731c27eac6eb7aeddff
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
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 UsageStatsTest [all]
Change-Id: I94a8e3dfca8ef4c7616f77944d61726e06043b85
Merged-In: I94a8e3dfca8ef4c7616f77944d61726e06043b85
This is a CP of ag/14736230 to qt-dev.
Apps were able to bypass BAL and BG-FGS restrictions by retrieving their
own notifications and firing their PI since those were allowlisted for
those operations.
Now we strip the token that granted them that ability
from notifications returned via NM.getActiveNotifications(), which
returns the notifications of the caller.
Notifications returned via notification listener APIs still contain such
token, as they should.
Bug: 185388103
Bug: 169821287
Test: Manually tested
Change-Id: I2ede0d639a560f6acacec3864a0a7d23af152ba5
Merged-In: I2ede0d639a560f6acacec3864a0a7d23af152ba5
(cherry picked from commit 5fbeff59df)
The base APK is loaded during normal execution even when isolated splits
are requested. This preserves that behavior during instrumented tests,
which previously skipped the base APK (causing class loading errors).
Test: tested on device with a trivial automated instrumented test
Bug: 146183755
Change-Id: Ia54072ee91b7c06cb4a787a8954ad2e69b322cac
(cherry picked from commit 6f2978c9fc)
permissions.
1. Create FgsWhileInUseTempAllowList, the uid on this list is allowed to
have while-in-use permission when the FGS is started from background for
a duration of time.
2. When media button is pressed, the targetUid is added to
FgsWhileInUseTempAllowList for the duration of 10 seconds, this way the
targetUid can start FGS from background and have while-in-use permission.
3. When checking for ProcessRecord.
mAllowBackgroundActivityStartsTokens, it is the caller app's
ProcessRecord should be checked instead of the service's ProcessRecord.
Bug: 182481312
Test: use b/167998084 reproduce steps, use Line app to make a voip call, the
receiver side screen is unlocked, the receiver side uses bluetooth
headset button to pick up the call, "dumpsys activity -a" shows the FGS
"com.linecorp.voip.core.common.notification.VoipNotificationCommand" has
"allowWhileInUsePermissionInFgs=true" and "isForeground=true".
Change-Id: Ic80aefe4202fe2210881bb8eea24b6e34cb1e7d0
Merged-In: I32a14d675550cd262976bb8e16a48a070387d318
Applications crashed due to duplicated top resumed activity change
events. Currently, the only possible scenario we know if that the
application invokes Looper#loop() and reverse the messages order.
Write warning logs vs. throwing exceptions to prevent application
crashes.
Bug: 140571893
Test: build and boot pass
Change-Id: If6f6c502b96ccc11b230ba075c61118f03e13d5c
* changes:
Fix DevicePolicyManager.isBackupServiceEnabled() breakage.
BackupManagerService: Make new behavior conditional on ChangeId.
Enforce BACKUP permission on Service end.
App holding System Gallery role is allowed WRITE_MEDIA_* appops by
virtue of the role. This allows the System Gallery app write-access for
images and videos.
When app preferences are reset AppOpsService toggles the appops for
all apps. Only the appops mentioned in sOpDisableReset are not toggled.
Disable WRITE_MEDIA_* appops to reset, as the system gallery app loses
write access on images/videos.
Bug: 179133883
Test: Manual
Change-Id: I168221c641566a9f691ed7956c038206b114d802
Merged-In: I168221c641566a9f691ed7956c038206b114d802
(cherry picked from commit de862be6a8)
This reverts commit 10f79644fc.
Reason for revert: Explained in b/153995973#comment40
Bug: 153995973
Change-Id: I437400528cb98e9ce665ebc308bfe05f4f24ca13
Use ApplicationInfoAsUser() to get the application information by
user id to make sure we have correct permission, othewise we will
get the SecurityException due to lack of INTERACT_ACROSS_USERS.
Bug: 176313819
Test: atest CtsVoiceRecognitionTestCases
Test: manual.
1.create profile user
2.Install sample recognizer app
3.Function works fine and no security exception occurred after
apply the change
Change-Id: I6958dbf661373606fb9dba55e386aaea4399a146
Merged-In: Iaf485537b8082d2109d2134ff987dc7244e31218
Currently, it will always look in user 0 since it uses the DPM from
mContext, which will always be from user 0 as WPMS is in the system
server process.
Extend DPMI to provide the necessary external helper API. This is
preferable to just using createContextAsUser before getting the DPM
instance since it avoids a second binding.
Fixes: 144048540
Fixes: 172682826
Bug: 153995973
Bug: 174642338
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testSetWallpaper_disallowed
Change-Id: I52b71000fac31ff6725ddded58206f69b263ae33
(cherry picked from commit 5b36ee3f1d)
Delegate the resetting of the INTERACT_ACROSS_PROFILES app-op to
DevicePolicyManager, which knows whether it should be pre-granted and
knows to apply it equally across all users in the profile group.
Further unit tests for DevicePolicyManagerInternal will be added in
b/175440570 when we have the better infra for that.
The CrossProfileAppsServiceImpl changes look more complex than they are.
They consist of the following:
- Inclusive language changes to 'allowlist'
- Static imports of permissions to improve readability
- Previously, the setInteractAcrossProfilesAppOp method would set the
app-op for every user within the profile group of the 'calling user'.
However, given that we are now exposing this as a server-side internal
API where we need to pass in a user ID (from AppOpsService), we don't
necessarily have the guarantee that the 'calling user' is in the same
profile group. So we split it up: the client-side API and AIDL API still
set the app-op for the calling profile group, whereas the internal API
sets the app-op for every user within the profile group of the provided
user. The changes simply abstract away references to the 'calling user
ID'.
Fixes: 166561076
Bug: 175440570
Test: atest services/robotests/src/com/android/server/pm/CrossProfileAppsServiceImplRoboTest.java --verbose -c
Test: manual
Change-Id: I2181fe66022aaf6c3e6d784c0569d2f41ab66537
(cherry picked from commit d004f41188)
Base CL ag/12885739 introduced unconditional enforcement of the BACKUP
permission for callers of BackupManagerService.isBackupServiceActive()
in the service, but dropped the enforcement on the app process side
(BackupManager).
This CL makes the behavior change conditional on a compat ChangeId.
Bug: 158482162
Test: Manually checked that an app similar to the code sample from
http://b/158482162#comment1 can reproduce the behavior.
This is true both before the base CL and after this CL, when
the app targets an old SDK version (26).
Test: Checked that both (a) before this CL, (b) after this CL where
the change is manually enabled for the app via the below commands,
the app runs into a SecurityException instead:
$ adb shell am compat enable 158482162 com.example.tester
$ adb shell dumpsys platform_compat | grep 158482162
ChangeId(158482162; name=IS_BACKUP_SERVICE_ACTIVE_ENFORCE_PERMISSION_IN_SERVICE; enableSinceTargetSdk=31; packageOverrides={com.example.tester=true})
Change-Id: I58e5d2a0b438296137fd76720636c8fdce740ded
Merged-In: I58e5d2a0b438296137fd76720636c8fdce740ded
(cherry picked from commit 7671f0d95c)
BackupManager runs in the client process, whereas BackupManagerService
runs in the system server process. Therefore, apps permissions need should
be enforced on the service side.
Bug: 158482162
Test: Manually checked that a sample app encounters SecurityException
after but not before this CL, when running code similar to the
sample in http://b/158482162#comment1 to figure out whether
isBackupServiceActive() for its own uid.
Change-Id: I59693819542a80a065a9c88373393b0ba0dbef65
Merged-In: I59693819542a80a065a9c88373393b0ba0dbef65
(cherry picked from commit b2ab2c414f)
If an app has already been granted a permission and it requests that
permission again, the user shouldn't see a system dialog. Update the
documentation to reflect this intended behavior.
Test: m ds-docs-java
Bug: 157530031
Exempt-From-Owner-Approval: Docs-only change
Change-Id: I7096e17480831324dee72f4093cdaa064e3b9165
This is a workaround solution for Android R QPR2. We are not allowed
to change the API for QPR release. This is a special case that allows
the current voice recognizer to note proxy ops if it is also the
voice interactor. In S, we will define a new permission that designed
one as a trusted blamer and tie it to a role.
Bug: 17095434
Test: manual
Test: TreeHugger presubmit
Merged-In: I506bbeb95e622b99693dbf5a135c7961b7fd81c1
Change-Id: I0852d1bb438d25b3e93224a71de1bf3b6df72c1c
This reverts commit ae03031efe.
Reason for revert: Merge the reverted patch by accident.
Bug: 162627132
Change-Id: Ic2f072730050cb47926cec6ed24af7ef9e5e7055
.. to match behavior post I1f9662c2bd14b34e00fbc8ebb926538f0329c37a
Bug: 167593637
Test: Javadoc change only.
Change-Id: I4cb9fe4a5ae74b1474f9da39b6aeb3a374f8cf12
