In preparation for permission BROADCAST_CLOSE_SYSTEM_DIALOGS
(go/close-system-dialogs), which will be signature|recents in order to
lock down Intent.ACTION_CLOSE_SYSTEM_DIALOGS. That intent is used by
recents when it's invoked.
Currently, recents is configured via existing config
config_recentsComponentName, so using that to determine the recents
package in PM.
It's my understanding that the package defined in such config will be
responsible for recents no matter which launcher is active. It's also my
understanding that the package being explicit in the system config means
that package has to come from the system image, hence it's fine to use
ensureSystemPackageName() in PM. Please advise if any of
this is wrong.
Test: Will work on CTS once we agree on the proposal here.
Bug: 159105552
Change-Id: I9f73e1f05d8df26666da156b672e370dce5030de
Moving this class out of android.os will reportedly
greatly reduce ART overhead.
Test: compiles
Test: atest FrameworksServicesTests FrameworksCoreTests
Bug: 165817914
Exempt-From-Owner-Approval: no-op refactoring
Change-Id: I1f3e77120979e2f336e5f42e4ec6e459d6492083
Better error cases handling.
Using internal handler to process digests to not overcommit
PackageManager's.
Fixes: 170777013
Test: atest OrgOwnedProfileOwnerTest#testSecurityLogging
Change-Id: I741c10ef3ceeec01e5436f92caa6a52d0c6b6003
This reverts commit 69475be847.
Also reverts commit Iaf8e2c075f188df95c68824b71362629c6adabfc.
Reason for revert: Trying again but will submit with new tests
BUG: 165841645
Test: atest NexusLauncherOutOfProcTests
Test: atest LauncherAppsSingleUserTest
Test: atest LauncherAppsMultiUserTest
Test: atest LauncherAppsProfileTest
Test: atest LimitAppIconHidingTest
Change-Id: I5ed5871ccddefbd922b3aa3ee4c1ad53cc0bfa9b
The numbers of KnownPackage should be continuous and the string
representation should not be unknown.
Fix: 170356374
Test: atest PackageManagerServiceTest
Change-Id: I2d96ca74a49b8f24ff87f8e21981d8cc0d43a469
Exposing package state changes and progress changes via LauncherApps
and LauncherActivityInfo as public APIs.
BUG: 165841645
Test: builds (will add CTS tests)
CTS-Coverage-Bug: 168925573
Change-Id: I2b5ea698799f9a762b7d9c79d62636d3db187c1f
Add helpful known-packages section in bugreport.
Fix: 121374459
Test: Using 'adb shell dumpsys package (known-packages)' to check
whether these known packages are dumped.
Change-Id: Ie43871d7ba8adca01bc17761dd9137129f47c58e
It wasn't including pre-created users; as such, apps that were not
installed on pre-created users got installed on reboot.
To test it:
adb shell pm create-user --pre-create-only
m ApiDemos
adb install --user current ~/Downloads/apk/ApiDemos.apk
adb shell dumpsys package com.example.android.apis |egrep ".*User .*:"|grep installed
adb shell stop && adb shell start
adb shell dumpsys package com.example.android.apis |egrep ".*User .*:"|grep installed
Without this fix, the second dumpsys would show the app installed
for the pre-created user.
Test: manual test (see above)
Test: atest CtsMultiUserHostTestCases:android.host.multiuser.PreCreateUsersTest
Bug: 160252062
Change-Id: I46c2ec94a3ab422e3e39b66239c21fb6cbff5a8e
Incremental Serivce periodically polls loading progress and sends to
Package Manager Service. Package Manager provides APIs for other
interested parties to listen to the loading progress.
BUG: 165841827
Test: unit test
Change-Id: I44b9e17c2240b9efe53bc09fc728b6671f1f7dfe
This method was added to operate as an internal variant of the
public getPackageUid method since pmInternal#getPackageUid already
exist. However, pmInternal#getPackageUid method just called to the
public interface, and enforcing permissions and visibility checks.
Since we don't expect any UID/permission checks in a local service,
any callers to this method requiring permission checks should be
migrated onto the PackageManager public method. Remove the original
pmInternal#getPackageUid and rename #getPackageUidInternal to take
its place.
Bug: 148235092
Test: Build pass and boot
Change-Id: Ibd4aa8a6a7743ff378a23e21c68efc52692580c7
UserController calls SystemServiceManager on some stages of the user
switch lifecycle, and SystemServiceManager calls the respective
callbacks in the SystemService objects it manage.
Prior to Android 11, these callbacks would take a @UserIdInt userid,
but now they take a TargetUser (which in turns contains a Userinfo).
So, currently, UserController calls SystemServiceManager passing the
userid, and SystemServiceManager gets the UserInfo from
UserManagerService. That works fine most of the time, but there might
be some race conditions when a user is removed that can crash the
system when such user is stopped (because UserManagerService doesn't
have its UserInfo anymore).
This CL fixes this issue by refactoring the user switch workflow so:
- TargetUser doesn't hold a reference to the UserInfo anymore, but
offer the methods needed by SystemService implementations.
- SystemServiceManager keeps track of the TargetUser objects used in
the callbacks.
Test: manual verification
Fixes: 159831354
Change-Id: If68ab1b5e247c7389c8cac16432d8b8809507e86
Alongside SIGNATURE and ACTOR_SIGNATURE policies, add CONFIG_SIGNATURE
policy to overlayable that overlay fulfills if it is signed with the
same certificate as the reference package whose package name is
declared in 'config-signature' tag of SystemConfig and is vetted by
OMS that it's a system pre-installed package.
BUG: 158726924
TEST: regular aapt2, idmap2, OMS tests
Change-Id: I645ee72271496008742886274be0d63a2985201b
It's up to system-server to make sure it's doing the right thing.
-50ms create time for PM
Bug: 157191740
Test: adb reboot; adb logcat | grep -e PackageManagerTiming
Change-Id: I8b64164464fcc6447871cfb94475af7379b72c16
* if no apps are suspended by the DO prior to migration, nothing
changes
* if some apps were suspended by the DO and the DPC targets R+
via DPM.setPackagesSuspended(), this will result in personal
apps suspended explicitly by the PO DPC as if it called
DPM.setPersonalAppsSuspended(). The apps will stay suspended.
* if the DPC target SDK is below R, the apps will be unsuspended
because the DPC won't have a way to unsuspend them. And the
user will be stuck with suspended apps.
+ when unsuspending apps, don't collect the list of apps subject
to suspension, but rather unsuspend all that is suspended. It
is more robust, e.g. when some app stops meeting the
conditions, e.g. not SMS app anymore.
Bug: 157270093
Test: com.android.server.devicepolicy.DevicePolicyManagerServiceMigrationTest
Test: Manual, with TestDPC, also patching it to target R
Change-Id: I1eba7216dd557c94bef822b77d25b484dfcd6f63
Do not update package mappings for the system user when the user is
first unlocked. Instead, schedule a job to be executed after 24 to 48
hours from when the system user is unlocked. This makes the service
initialization phase for the system user a little quicker since their
data is not likely to be stale. Additionally, this also ensures that
restored data is not pruned by mistake if there is a device restart
before restore is completed. The updating of the mappings occurs
normally for other users, on user service initialization.
Bug: 155209652
Test: manually ensure job is skipped for system user
Test: atest android.app.usage.cts.UsageStatsTest
Change-Id: I2c03a1a05246d6b454569c4569813e90bede3693
Another way was to clear it using existing APIs for each package
but each call would cause Package Manager to re-serialize the
package-restrictions.xml, so I added a separate API to do it in
one go.
Bug: 149075700
Test: manual, set TestDPC as a DO, block uninstall, remove DO.
Test: manual, set TestDPC in COMP, block uninstall, migrate to COPE.
Change-Id: I9be69af5d7ae9e0ddda087d3e01e35f3429f25f4
PackageCacher uses file name and modified time to determine if the
parsed cache is still valid. However, all APK-in-APEX would have
the same name and modified time. This results in the out-of-date
cache would be treated as valid.
We need to invlidate the cache for the APK-in-APEX when that APEX
is going to be installed.
Bug: 152352677
Test: atest -p frameworks/base/core/java/android/content/pm
Test: atest -p frameworks/base/services/core/java/android/content/pm
Test: Update/rollback an APK-in-APEX, and check its version code
Change-Id: I2a722036d8b1e9c5121d385f8d0667fb908cc7a1
* Sort the user restrictions to local restriction
set and global bundle in DPMS instead of User
Manager.
* Simplify pushUserRestrictions.
* Split the list of user restrictions the profile
owner of an organization-owned device can set into
a global and local list. The user restrictions in
the local list will only be applied to the personal
profile as opposed to the whole device.
Bug: 149743941
148453838
Test: atest com.android.cts.devicepolicy.UserRestrictionsTest
atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.server.pm.UserRestrictionsUtilsTest
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionSetOnParentLogged
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionsSetOnParentAreNotPersisted
Change-Id: I1faa1f4776deb98e38595a358c01c3fbabfb1840
The UserSystemPackageInstaller (USPI) uninstalls system
packages that are not needed, depending on the user type.
When that determination changes (or the feature is disabled)
it can also re-install those packages.
This cl specifies when it is appropriate for USPI to actually
perform the (un)installation.
1.
Introduces uninstallReason: records the reason why a package
was uninstalled from a given user. Right now, the only values
are UNKNOWN and USER_TYPE. The latter indicates that the USPI
system uninstalled the package. If the USPI whitelist changes
(or the USPI feature is disabled), uninstalled packages will
only be installed by USPI if the uninstallReason was USER_TYPE.
Any further uninstalls (e.g. by ManagedProvisioning) will reset
the uninstallReason to UNKNOWN, so USPI will no longer install
such packages in the future.
This prevents USPI from reinstalling system packages that other
mechanisms (such as ManagedProvisioning) uninstalled.
2.
USPI will uninstall a system package if it is blacklisted, but
only if that system package is new, i.e in two circumstances:
a. on first boot
b. on an OTA where the package was not present prior to the OTA
Bug: 143200798
Test: atest UserSystemPackageInstallerTest
Test: Confirmed (un)installations during manually simulated OTAs
Change-Id: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
Merged-In: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
* changes:
Remove telephony protection level.
Revert "Allowed telephony to bind network service"
Revert "add telephony role to some permissions needed by telephony module"
The android.os.action.POWER_SAVE_MODE_CHANGED broadcast already exists for context-registered receivers, this additionally sends the broadcast to a manifest-registered receiver specified in config_powerSaveModeChangedListenerPackage string.
Bug: 149978380
Test: manual using demo apk
Change-Id: I6a363650da7aee11f8f820a0ff78e7a2ec434fad
If the version of the permsision controller is different than what was
persisted then call the upgrade controller defined in the permission
controller.
Exempt-From-Owner-Approval: Got verbal approval from an OWNER
Bug: 148595539
Test: Manual; verify the version is persisted in runtime-permissions.xml
verify the upgrade is run when changing the version number
move runtime-permissions.xml to old location, verify works
Change-Id: I873ea4d5a0f1f66fed121e38cc6be62fa046a210
This change adds logging for debuggable and test-only apps when they are
the caller and visibility of another app is blocked due to app
enumeration.
It also adds an adb command to turn logging on and off for other apps to
help developers while debugging issues.
Test: atest AppsFilterTest AppEnumerationTests PackageManagerPerfTest
Bug: 145623959
Change-Id: I1fa930ef40bf08b00c41f51aa25c50b2189395bf
The session id will be used by RollbackManager to simplify the code in
searching for rollbacks and sessions.
(Cherry-picked from 503c1aca53)
Bug: 149663536
Test: m
Merged-In: I94003873f4f244fd6543f22bdbe7b6d4a31aceaf
Change-Id: I94003873f4f244fd6543f22bdbe7b6d4a31aceaf
When permission is granted to another app via URI, we implicitly grant
visibility to that app of the app ID that that URI resolves to.
Test: atest AppSecurityTests
Fixes: 149781706
Fixes: 145677500
Exempt-From-Owner-Approval: Owner approved prior to cherry-pick
Change-Id: I7c8967a4464fd821e4f95d8eb6c0bcfadadb912e
Serialising package restrictions uses synchronous disk access; callers
of these methods should probably use background threads for this.
Bug: 149216360
Test: TreeHugger
Change-Id: I6607a7225bf7daaad8a78e4d1e4c585ba5ac3efc
Signed-off-by: Julius D'souza <jdsouza@google.com>
