This facilitates exposing the Parsed_ classes as
@SystemApi(client = SYSTEM_SERVER) while keeping everything inside
services.jar rather than having it split across both jars.
This reverts getPackageArchiveInfo to use legacy PackageParser, since
framework.jar can no longer access the moved classes.
Bug: 214038417
Test: presubmit, no logic changes
Change-Id: I152d70fb4f643d32efb012cfb20b0fbc5f88f2d8
Adds APIs to record a state at some time and use that state to commit
changes to package state. Which allows reconcilation and retry of
competing changes without needing to take the data model lock unless
absolutely necessary.
Also copies over data model/settings changes to make it compile.
Split from actual usage to make review easier.
Bug: 202291547
Test: presubmit, no usages yet
Change-Id: I6738829185022efef4add1805b5a52b3de3d173a
+ Use explicit flag types in PackageManager.
+ Distinguish AllocationFlags from StorageFlags.
BUG: 207030431
Test: Builds
Change-Id: I641c76859d3a16f70acad17507695ddd161f339a
We are running out of int flags for public API methods such as
PackageManager.getPackageInfo(String packageName, int flags). As a
solution, we will change the flags param to Flags objects. At the
same time, we deprecate the old methods that directly use int flags.
The new flags classes are: ApplicationInfoFlags, PackageInfoFlags,
ComponentInfoFlags and ResolveInfoFlags. Because there are already
annotations of the same names, we renamed the annotations to *FlagsBits.
Old API usage example:
getPackageInfo(pkgName, MATCH_UNINSTALLED_PACKAGES)
New API usage example:
getPackageInfo(pkgName, PackageInfoFlags.of(MATCH_UNINSTALLED_PACKAGES))
See b/204433742 for discussions.
CTS-Coverage-Bug: 206147270
BUG: 204432643
BUG: 204433659
Test: manual
Change-Id: I8ab2adad6907670c5879c043d170c950afefe46c
Changes IPackageManager.aidl methods to use long flags instead of int.
Public API change to be followed.
BUG: 204432643
BUG: 204433659
Test: manual
Change-Id: Ib5c42fef998f0116e312c71d620e1a15329e26e0
In most non-install, non-mutate areas, migrates away from locking
PackageManagerService directly in favor of the Computer snapshot.
This will relieve more lock contention and allow scoping
PackageSetting to mutate-only scenarios, such as install.
Bug: 202291449
Change-Id: Ie92ebfeacdc4a00484373f11739fdfe3c3897a7f
Moves to a read-only interface inside Computer and all of its
dependencies. This is the next step towards true data model
immutability and mutation time snapshots.
Bug: 202291449
Test: atest PackageManagerServiceUnitTests \
PackageManagerSettingsTests \
PackageUserStateTest \
PackageParserTest \
PackageManagerTest \
ScanTests \
PackageInfoUserFieldsTest \
DexoptUtilsTest \
PackageManagerComponentLabelIconOverrideTest
Change-Id: If5afb44e20b50a15b2b99057b0797c9b88e6e60b
We estimate the next app launch time by looking at the past 7 days of
usage history and assuming that the user opens the app like clockwork.
If there is at least 24 hours of usage events, then we take the earliest
ACTIVITY_RESUMED event and estimate that the app will be launched
exactly 7 days after that event. If there is less than 24 hours of
history (which would be the case for a new app), then we take the
earliest ACTIVITY_RESUMED and add 24 hours. If we don't see any launch
event in the past 7 days, then we just say the app should be launched
within a year. If we have a long estimate for an app and it is launched,
then we re-evaluate our estimate because we can now estimate a launch
within the next 7 days.
Bug: 194532703
Test: atest FrameworksMockingServicesTests:PrefetchControllerTest
Test: manually launch apps and check dumpsys for expected launch time changes
Change-Id: I9ef5fc3e3df3c2d029243b1fb8949a4bf21900db
A separate class for handling app data directory setup and reconciling
apps data duing boot.
Notice that I moved some related booting sequence into the new class.
BUG: 199428170
Test: manual
Change-Id: I0d2e0f70b815f0f8e340de9ee876d6ac5c8a6ee9
Callers need to either declare <queries> element with the specific
package name in the app's manifest, be the owner of the session, or
has appropriate permission to get the session infos.
Bug: 187176203
Bug: 187176993
Bug: 194694069
Bug: 194694094
Test: atest AppEnumerationTests
Test: manually using the PoC in the buganizer to ensure the symptom
no longer exists.
Change-Id: I51e84e9560ebff3c5fcde1639542efd04a77557b
- Retrieve the previous uid permission state and create a copy of it as
the new app's uid state.
- Remove the app from the original shared user group. Other apps in the
shared user group will perceive as if the original app is uninstalled.
- The new permission state is updated in updatePermissions() just like
a normal package upgrade.
Test: atest CtsSharedUserMigrationTestCases
Bug: 179284822
Change-Id: I9d7c3b16959dd4b2c2684ddaf8bd223fb32c3c41
When the developers change any code in
frameworks/base/service/core/java/com/android/server/pm,
frameworks/base/service/core/java/android/content/pm, and
frameworks/base/packages/PackageInstaller, it should invoke all of
the tests under cts/tests/tests/packageinstaller.
service/core/java/com/android/server/pm/TEST_MAPPING already imports
core/java/android/content/pm/TEST_MAPPING which imports
cts/tests/tests/packageinstaller/TEST_MAPPING. Adding
service/core/java/android/content/pm/TEST_MAPPING to import
core/java/android/content/pm/TEST_MAPPING is just like
service/core/java/com/android/server/pm/TEST_MAPPING.
This patch also removes invoking CtsAtomicInstallTestCases with the
file patterns because invoking CtsAtomicInstallTestCases with file
patterns is redundant. It has been imported in
cts/tests/tests/packageinstaller/TEST_MAPPING. And,
cts/tests/tests/packageinstaller/TEST_MAPPING is imported in
core/java/android/content/pm/TEST_MAPPING that is imported in
service/core/java/com/android/server/pm/TEST_MAPPING.
Test: atest --collect-test-only -p \
frameworks/base/services/core/java/com/android/server/pm
Test: atest --collect-test-only -p \
frameworks/base/services/core/java/android/content/pm
Bug: 180650365
Change-Id: If24e4b2308891775965cb7b2659cb7e25f255436
Moves all the PackageInfo/ApplicationInfo values into core SDK side
interfaces which represent all the mirrored functionality.
Creates AndroidPackageApi, PackageState, and a new PackageUserState
interface that act as the actual exposed interfaces for consumers like
mainline.
To avoid taking the PackageManagerService lock, and to avoid mutability
issues, PackageSettings are shallowly copied into PackageState objects.
And class PackageUserState objects into interface PackageUserState.
Eventually PackageSetting/class PackageUserState should be migrated to
the corresponding interfaces.
Miscellaneous additional changes:
- Removes PackageSetting#uidError, was never used
- Removes PackageUserState#categoryHint, was a package level field
without per-user difference, use PackageSetting#categoryHint instead
- Add locking to class PackageUserState overlay paths so they can be
copied for the new interface.
Bug: 173455397
Test: atest com.android.server.pm.ScanTests
Change-Id: Ib98c66a9b4d78d09151724eaf14c16074c3621c9
System grants implicit visibility when the Uri permission is granted.
But, all the visibility rules would be cleared when package updating.
Since the implict visibility doesn't come from manifest, we cannot
restore it via recompuating visibility. This solution is similar to
how UriGrantsManagerService handles the granted Uri permissions when
packagea updated. We keep them unchanged instead of clearing them.
Bug: 161912313
Test: atest AppsFilterTest
Test: atest AppEnumerationTests
Test: atest UriGrantsManagerServiceTest
Test: manually use test APKs on buganizer to verify
Change-Id: I3026e06574f78c15dbf60c74db126679c677adb1
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
The original resolveContentProvider api gets the caller's uid using
the Binder#getCallingUid. That may cause the package information
disclosure issue if the caller has cleared the calling identify.
This cl migrates the callers of resolveContentProvider to use the
new one with a calling uid parameter. The caller could pass the
correct caller's uid to use the api.
Bug: 192354703
Test: atest UriGrantsManagerServiceTest
Test: atest UriPermissionTest
Test: atest ContextTest
Change-Id: I153df4e77642f0622c7f0f5804639795e90ded21
Use PackageManagerInternal methods instead.
+ Also removes PackageManagerService.getPackages which is only used by
OtaDexoptService
Test: builds
BUG: 194319951
Change-Id: Ibadbb5996e4589ef321c41d7d00fe4aa5b59b805
Intent ACTION_PACKAGE_DATA_CLEARED is sent without the allowlist so
it may potentially leakage the package information.
Bug: 191291133
Test: atest AppEnumerationTests
Change-Id: Ica10615db22c0bc0eb4fba550bc069031f18c9a9
App can query which applications are installed on the device via
api grantUriPermission and checkUriPermission. This cl enforces
package visibility filter to the api checkUriPermission to fix
the security issue.
Bug: 180019130
Test: atest AppEnumerationTests
Test: atest CtsProviderTestCases
Test: atest UriGrantsManagerServiceTest
Test: atest UriPermissionTest
Test: atest ContentProviderTest
Test: atest ContentResolverTest
Test: atest DownloadManagerTest
Test: atest MediaProviderTest
Test: atest ManagedProfileCrossProfileTest
Change-Id: Ic19caef7f3f221b9c35afe2805336e50d838cf26
Pass in the calling UID when asking PackageManager to resolve the
content provider. This makes sure PM is resolving the provider based on
the calling UID's permissions and not the system server's permissions.
Bug: 189122544
Bug: 189122545
Test: atest CtsContentTestCases
Test: atest CtsJobSchedulerTestCases
Test: atest FrameworksServicesTests:UriGrantsManagerServiceTest
Change-Id: Iaa421e982fca1e29828eda43f0762893199b5ce1
Retrieve the number of freed bytes from PM and store it in
GlobalLevelState when a package is globally hibernated. Reset the value
when it gets unhibernated and write it to disk to persist across device
reboot.
Bug: 188819665
Test: atest AppHibernationServiceTest
Change-Id: I187ec803776cc76c77a660e1ba2f72c2e77765f9
The current implementation does not work when the multi-user feature is
enabled because it clears the "globally" protected packages set by the
device owner whenever a new user is created.
Bug: 178500150
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.OwnersTest
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Test: Ran the CTS tests that were added
Change-Id: Id04cb9b5b2357b0a0b5090442a39d97405287dbe
Use two separate interfaces for flags and single value. This produces
correct API documentation.
Bug: 160605420
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I9a7eaf86af558d8dcfd1636a4baf6a28e2ee79b1
For consumers who don't care about blocking package data updates and
only need data at a specific snapshot in time, these methods would
avoid locking PMS during the iteration process.
Bug: 183643808
Test: atest com.android.server.pm.test.verify.domain
Change-Id: Ia951381798d75f77c4ad5fc010a469b69992f074
Also remove streaming health status reporting which could cause
startable state change because it is also not needed any more.
BUG: 171920377
Test: builds
Change-Id: I7284e7a63df79da7dbf3d16ff64302b3d1ce1348
Migrate the |documenter permission flag to the role infrastructure
Bug: 158878560
Test: atest CtsPermission2TestCases:PermissionPolicyTest
Change-Id: Iad1ad168064688b2efbb964a1eae9110a4cac231
