This reverts commit 35ef88f4cc.
Reason for revert: re-introduce change after disabling test in
Ia4303f6ba0160c24ac8949c359dfe3e28a544cc6
Change-Id: I14402335736559c4997439425d2ab49ac172d9ca
This reverts commit 2fd993fd6c.
Reason for revert: test monitor, was identified as culprit for b/223768516
Change-Id: I871e5ab1c9cbe083a4aea4e916eb45a820725155
Effectively removes the lock and trampoline Computer wrappers as
we enforce that snapshots are always available now.
Also isolates IPackageManager and PackageManagerInternal from
PackageManagerService to prevent misuse of the APIs. The separated
base classes have access to a snapshot method which is then proxied
to, or used to call into PMS.
This makes it impossible for a caller using PMS directly to
accidentally call into one of these other API surfaces that won't
use the caller's provided snapshot, causing inconsistency problems.
Also removes live locking annotations and the related infrastructure
since we just assume that doesn't matter anymore.
Also migrates some _Helper logic to take/pass snapshots to match the
PMS methods, but not all of the helper logic migated to consistent
snapshots. That will be done in a follow up.
With this, all known extra overhead has been removed and metrics
should return to normal.
Bug: 215403184
Test: presubmit
Change-Id: I7e977f600f49b070c3a539901cc06d523fb7517a
To avoid leaking IPackageManager methods directly into
PackageManagerService, moves the IPM implementation into an inner
class similar to PackageManagerInternal.
This will help enforce snapshot consistency by ensuring that all
non-IPM PMS methods can always take in a Computer instance to re-use.
Bug: 217961172
Test: presubmit
Change-Id: Ibf7bd3d1d90a40786279763ba8d62eb9348bb760
Adds a new method to PackageManagerInternal that checks
if a given package belongs to the calling uid. This logic also
accounts for calling uids in the sdk sandbox range.
Deduplicates two methods in NotificationManager and ActivityTaskManager
which have implemented this logic.
Bug: 219750831
Test: atest NotificationManagerServiceTest
Test: Manual test using Sdk Sandbox test app
Change-Id: I1c566f75c81112dfeeb664827dcb27768959c377
When handling post-install during the installation process, some
tasks are posted to PackageHandler and be executed after notifying
the install observer (install initiator). The task includes force-
stopping the package. If the install observer starts the app right
after being notified, the ongoing force-stop will kill the process.
The race happens. To mitigate the potential race, We should defer
the notification until these tasks are done.
Bug: 165012101
Test: atest -p services/core/java/com/android/server/pm
Change-Id: Ia6b32f72f3d75b8a40c42e11d21f21c459db5299
Merged-In: Ia6b32f72f3d75b8a40c42e11d21f21c459db5299
(cherry picked from commit bad03aa3c9)
Lambdas were used to ensure consistent locking around the snapshot,
but since it's impossible to lock the snapshot now, this is no longer
necessary, and all methods should just store a reference.
Also migrates DomainVerificationService off PackageSetting lambdas,
which cleans up a lot of extra emthods.
Bug: 215403184
Test: atest com.android.server.pm.verify.domain
Test: atest SuspendPackageHelperTest
Change-Id: Ib4e3442e5c16e935b14b8421fbc33adff65dcf68
Migrates ComponentResolver and ResolveIntentHelper away from calling
PM directly in favor of using a consistent Computer snapshot. This
saves on snapshot rebuild and ensures data consistency within a single
method call.
Bug: 215403184
Change-Id: Id017db704493f38d94fd498f77d2264fe008ef45
Removes the ability to disable PackageManagerService snapshots. The
new PackageState and related APIs rely on never taking PMS#mLock, so
a snapshot Computer must always be available.
To keep changes small, this does not migrate existing
executeWithConsistentComputer calls, but that can be done in a simple
follow-up to save on lambda allocation costs.
Bug: 202291547
Change-Id: I243988b0c48938a8701842a9de5cfc465c1d38d8
On detecting excessive battery usage of a background uid, we may
move the background restriction of the apps running in this uid to
more restrictive levels.
Bug: 200326767
Test: atest FrameworksMockingServicesTests:BackgroundRestrictionTest
Change-Id: I6c2d41e44367a283d8aa9491be683018a80a810c
Client apps need the ACCESS_AMBIENT_CONTEXT_EVENT permission to use the service. The permission protection level is internal|role.
API overview: http://go/ambient-framework-api
PRD: http://go/ambient-attribution-prd
Design doc: http://go/ambient-service-api
Test: CTS test
Bug: 192476579
Change-Id: I9daede83af34f215c278cb0530238faba1be5c70
Ignore-AOSP-First: to prevent new feature leak.
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
