45b9e40a4f23f36be88f7474660e931b58aedf1e |
|
10-Apr-2018 |
Suprabh Shukla <suprabh@google.com> |
setPackagesSuspended now overwrites all the state Earlier setPackagesSuspended ignored the rest of the paramters when suspend state did not change. This was a problem because then there was no good way to update the other parameters without unsuspending the app, which is not desirable. Removed setSuspendedPackageAppExtras as now they can be update with this api. Also sending broadcasts when packages get unsuspended due to suspending package removed. Test: Existing tests pass: atest com.android.server.pm.PackageUserStateTest atest com.android.server.pm.SuspendPackagesTest atest com.android.server.pm.PackageManagerSettingsTests Bug: 77522553 Change-Id: I72a3c228d3d65c430e242da97b2bc6997ec6a135
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
3c3af1406e9fc8afbe9593df6c23fe3d4daa6b42 |
|
30-Mar-2018 |
Suprabh Shukla <suprabh@google.com> |
Activity interceptor dialog for suspended apps Added an AlertActivity to intercept the start for an activity belonging to a suspended app. More details will be shown if the suspending app also defines an activity to handle the API action SHOW_SUSPENDED_APP_DETAILS. Test: Added tests to existing classes. Can be run via: atest com.android.server.pm.SuspendPackagesTest atest com.android.server.pm.PackageManagerSettingsTests atest com.android.server.pm.PackageUserStateTest Bug: 75332201 Change-Id: I85dc4e9efd15eedba306ed5b856f651e3abd3e99
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
021b57ab8df0927aa1f78a2f3bb01d5e70594b1a |
|
09-Mar-2018 |
Suprabh Shukla <suprabh@google.com> |
APIs to suspend packages with SUSPEND_APPS permission Changed the existing hidden api setPackagesSuspendedAsUser to a system api setPackagesSuspended that can be called by apps with either MANAGE_USERS or SUSPEND_APPS permission. Additionally, the suspending app can now specify optional extra information meant to be used by the suspended apps and the launcher to deal with this state. The following other APIs are added: - isPackageSuspended(): Apps can query whether they are in a suspended state - @SystemApi getPackageSuspendedAppExtras(String): Apps with permission SUSPEND_APPS can get the appExtras passed to PM when suspending the app. - @SystemApi setPackageSuspendedAppExtras(String, PersistableBundle): Apps with permission SUSPEND_APPS can update app extras for a suspended package. - getPackageSuspendedAppExtras(): Apps can call to get the appExtras passed in to PM when they were suspended. Test: Can be run via: atest com.android.server.pm.PackageManagerSettingsTests atest com.android.server.pm.PackageUserStateTest atest com.android.server.pm.SuspendPackagesTest Bug: 74336673 Change-Id: I3b9ed2c8478b34ee2e8986f5f5fddb2839d102e3
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
af6f195b15015f8ae5896aa777ff647dfe488114 |
|
13-Feb-2018 |
Todd Kennedy <toddke@google.com> |
Don't write settings just for install status This is an obsolete concept and not necessary. Remove the install status that's part of the package settings. Change-Id: I20a567145e579c9588d4392d0ac26ef4b5bbe301 Fixes: 62229032 Test: atest FrameworksServicesTests:PackageManagerSettingsTests
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
1dbe6d02849cb4af87bbd26b7537e11badead3b1 |
|
23-Jan-2018 |
Dan Cashman <dcashman@google.com> |
Add key rotation. Change certificate checks to also consider the possibility of signing certificate rotation by checking the SigningDetails#pastSigningCertificates field. In particular, add a SigningDetails#checkCapability method which reports whether or not the older SigningDetails is an ancestor of the current one, and queries whether or not the old one has been granted capabilities, such as being a sharedUser. Bug: 64686581 Test: Builds, boots, browser and camera work, all with v3 signing. Change-Id: I4199ff3f2d9ae959325b117b28e666ae31889800
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
77029c5b16351775cb2333369ef9a4bc1d9acf58 |
|
19-Jan-2018 |
Daniel Cashman <dcashman@google.com> |
Add proof-of-rotation information to PackageParser.SigningDetails APK Signature Scheme v3 enables APK signing key rotation by allowing an APK to embed a proof-of-rotation structure linking past signing certificates to the current one. This information needs to be exposed to the system before it can be used to make authorization decisions. Bug: 64686581 Test: Builds and boots. Change-Id: I49961f92fcec141d73b36197147d5d8fa64c149e
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
1ab3d6e56b56fe0cfe31e437326b5cbc66bdb361 |
|
07-Dec-2017 |
Ben Gruver <bgruv@google.com> |
Implement harmful app warning at activity launch Bug: 63909431 Test: manual Change-Id: I8a5497421cb8130af8cdd5129b0f6e1707a01e36
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
0f877fab392154c77251dbac321b732a2a747911 |
|
07-Dec-2017 |
Todd Kennedy <toddke@google.com> |
Refactor scanPackagesDirtyLI() Just a small drop in a larger sea of refactorings. This time we break up scanPackagesDirtyLI(). It's now in three sections: 1) data setup 2) package scan 3) data commit The goal is to not dramatically change the behaviour of the platform, but, to provide some structure for future changes. Ideally, only data commit would modify the running system. But, all three still modify some part of the system. The scan is the closest to being fully hermetic as only the PackageSetting object is modified. A future task is to remove the dependency of a singular PackageSetting object [with integer equality!] which will finally make the scan independent. The data setup and commit both modify the running system. We need to continue to push on making the data setup section hermetic. Or, at least track the allocations and be able to rewind if something goes wrong. The next refactoring will be rectify the difference between the new scan method and scanPackageInternalLI. Bug: 63539144 Test: bit FrameworksServicesTests:com.android.server.pm. Change-Id: I59d401a81de2aed3309b99d663afdfa91316bc0a
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
3accca05ddcad9d0b1b313eae49f273e39121d3c |
|
20-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Add major version code to platform. It turns the version code into almost a 64-bit integer, with the new major part being the upper 32 bits. The only tricky part about this is the backup manager, since it stored 32-bit version codes in its backup data sets. This is dealt with by, when the major version code is not 0, writing MIN_INT as the version code and following that by the full long version code, which we can detect when reading. Note that this makes backup sets containing apps with major version codes incompatible with older versions of the platform. Bug: 64459786 Test: Added in Change-Id: Iab8a682b62103babd6c16a56b8dc1e97d7078658 Change-Id: Ibfffe235bbfcf358b3741abd3f7197fdb063d3f3
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
c29b11a5f65829dc87b5f234c4d3c1fff7ef5a36 |
|
24-Oct-2017 |
Todd Kennedy <toddke@google.com> |
Move grantPermission to permission manager Last major movement of permission logic from the package manager to the permission manager. Bug: 63539144 Test: Manual. Builds and runs Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.PermissionsHostTest Test: cts-tradefed run commandAndExit cts-dev -m CtsPermissionTestCases Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases Test: bit FrameworksServicesTests:com.android.server.pm.PackageManagerSettingsTests Change-Id: I3225405fad4334917b8df0b08bb1936a58744480
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
0eb9738d1708d9aa7846782046e6828ffc9fe901 |
|
04-Oct-2017 |
Todd Kennedy <toddke@google.com> |
Move mPermissions from package settings Create a settings class only for use with permissions. It's subservient [and should only be accessed directly by] package settings or the permission manager. The rest of the permission related data needs to be moved to permission settings. At which point we can start pulling the permission methods out of the package manager service and into the permission manager. We still have a somewhat tight relationship between package manager and the permission manager. It's unclear how far we need to separate them and if relying entirely on an internal interface is sufficient. Bug: 63539144 Test: Manual. Builds and runs Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.PermissionsHostTest Test: cts-tradefed run commandAndExit cts-dev -m CtsPermissionTestCases Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases Test: bit FrameworksServicesTests:com.android.server.pm.PackageManagerSettingsTests Change-Id: I616184fa2135a11687e4ce615884f861466fdebe
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
91a39d126d1f6efa47948ca1039ca347c1bd19e6 |
|
27-Sep-2017 |
Todd Kennedy <toddke@google.com> |
Move BasePermission to own package This is the first of many changes. Moving permissions to their own package. Change-Id: I60e94e2da3c96788fc165e97e813ab5b9ee51586 Bug: 63539144 Test: Manual. Builds and runs Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.PermissionsHostTest Test: cts-tradefed run commandAndExit cts-dev -m CtsPermissionTestCases Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
5eb5a7db835a7b152690410e03f3d3a8baacde33 |
|
01-Aug-2017 |
Todd Kennedy <toddke@google.com> |
Add virtual preload bit to ApplicationInfo Change-Id: I2735b3823a8709b2ffb65cc8085ffcd952d3e1f2 Fixes: 64205417 Test: Manual Test: Create a sample app and install it as a normal app Test: See that it returns 'false' for "isVirtualPreload" Test: Create a sample app and install it as a virtual preload ["--preload"] Test: See that it returns 'true' for "isVirtualPreload" Test: Run sample apps after reboot and see they return the correct value
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
560830c9f06d07d97055426420709733571ca05b |
|
16-Jun-2017 |
Todd Kennedy <toddke@google.com> |
Track both framework and app overlays per package Always bundle framework and app overlays. The old implementation, where framework and app overlays were tracked independently, lead to an error in the following scenario: 1. Enable app overlay -> change reflected in app 2. Enable framework overlay -> error: no change reflected in app 3. Disable app overlay -> change reflected in app, including framework overlay This change also leads to better architecture since the package manager no longer needs to know that an app's overlays consist of both framework and app specific overlays. Instead, that knowledge is handled by the overlay manager. Also, correct indentation in "cmd package dump packages" output and remove obsolete constant DUMP_ENABLED_OVERLAYS. Test: Manual Change-Id: I707fc00052a15b22fb8c17e6155732520e6b2e52 Bug: 62680061
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
b274947dfb03f04872546774af0f8770ade5bed7 |
|
13-Jun-2017 |
Todd Kennedy <toddke@google.com> |
Save overlay paths as user state Instead of maintaining a separate structure just for overlay paths, store them as user state in the package setting. Also centralize updating the overlay paths to avoid issues with inconsistent updates. Fixes: 36561125 Test: Manual Change-Id: Iac1c987e8650074dbc564e332d5da1950fad6ac5
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
253984ed8c8f39fa0aa9c5f4addf2f44f334c749 |
|
24-Oct-2016 |
Vladislav Kuzkokov <vkuzkokov@google.com> |
Store "block uninstall" flag separately from the rest of package state. This allows to set "block uninstall" prior to installation and avoid the inevitable race that happens when Device Policy app tries to force install and then immediately block uninstall. BUG=31043188 Test: Block com.chrome.beta in TestDPC. install, fail to uninstall through adb, unblock, uninstall Change-Id: I5ffa2abcb003982eccfb77585c43b59532dd501d (cherry picked from commit 1fff9dcb9d0a4d7224ff8aa0f39e82df0b30152c)
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
ab53289c593aad60eddbe1ffc73402ac1f92c112 |
|
08-Mar-2017 |
Todd Kennedy <toddke@google.com> |
Add API to mark apps that have an update available Ostensibly for instant apps, we allow play to mark an app as having an update available. This will trigger instant app resolution even if the instant app is already installed on device. Bug: 35143464 Test: Manual; launch URI of installed instant app, see it runs w/o resolution. set bit. launch URI of installed instant app, see it runs resolution Change-Id: I511df2b2a3eab39377167c770255ccbe02d5dad2
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
426cbefdf3c78bd0aa80b180ffc1fb8b5a226bc3 |
|
10-Feb-2017 |
Netta P <nettap@google.com> |
Protobufferize PackageManager dumpsys Bug: 34230809 Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCase -t com.android.server.cts.PackageIncidentTest Change-Id: I6dc455db47a8a636267cf7abe993e135e9044b33
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
be0b8896d1bc385d4c8fb54c21929745935dcbea |
|
15-Feb-2017 |
Todd Kennedy <toddke@google.com> |
Revert "Revert "Per user setting for instant app"" This reverts commit be9ffa15af9e1906e9ffb505768328d62d4a3793. Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Change-Id: Ib21321cf157a79890de487060a093840f7182047
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
626ffb455650e334fff3fe407a31aa0fa437fdf2 |
|
15-Feb-2017 |
Guang Zhu <guangzhu@google.com> |
Merge "Revert "Per user setting for instant app""
|
be9ffa15af9e1906e9ffb505768328d62d4a3793 |
|
15-Feb-2017 |
Guang Zhu <guangzhu@google.com> |
Revert "Per user setting for instant app" Bug: 35390781 This reverts commit 2f5811dcfd840e149851a9333e27ef3cdddf7a46. Change-Id: Ibb1c8dacbdc6908fc7fa2bc5dca664f2455162bf
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
bf92b812dbe1c762ff2381ca4ba14290a5ece8b8 |
|
15-Feb-2017 |
Todd Kennedy <toddke@google.com> |
Merge "Per user setting for instant app"
|
23ab7f54d96386db2b45dc0b352b3451f665e331 |
|
23-Jan-2017 |
Amith Yamasani <yamasani@google.com> |
Kernel mapping for package scope by user Inform the kernel via configfs, of userids that should be excluded when an app is not installed for them. Also push userid to remove_userid when a user is removed so that the exclude list of that user can be cleaned up in one command for all packages. Test: runtest -x ....KernelPackageMappingTests.java Change-Id: Ib94b1a0b737f45b2d03deb9650f0f0eb68e363d9
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
2f5811dcfd840e149851a9333e27ef3cdddf7a46 |
|
30-Jan-2017 |
Todd Kennedy <toddke@google.com> |
Per user setting for instant app The same application can run as either an instant app or an installed app. Store this setting per-user instead of based upon the install location. Bug: 25119046 Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Change-Id: Iff565bb1ac10d631499f0bd0f69b401cb073c10e
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
6788212d17f54475ca9c3dd689a863e031db868f |
|
12-Dec-2016 |
Svet Ganov <svetoslavganov@google.com> |
Platform support for static shared libraries This change adds support for static shared libraries that emulate static linking allowing apps that statically link against the same library version to share a common implementation. A library is hosed by a package in a standard APK. Static shared libraries have a name and a version declared by a dedicated manifest tag. A client uses also a new tag to refer to the static library it uses by specifying the lib name, version, and the hash of the signing certificate. This allows two apps to rely on two different library versions and prevents impersonation of the shared library by a side-loaded app with the same package name. Internally apps providing static libs use synthetic package name generated from the manifest package name and the library version. This allows having different "versions" of the same package installed at the same time. An application cannot be installed if a static shared lib it depends on is missing. A used shared library cannot be uninstalled. Shared libraries can rotate certificates like normal apps. The versions of these libs should be ordered similarly to the version codes of the hosting package. Such libs cannot use shared user id, cannot be ephemeral, cannot declare other libraries, cannot rename their package, cannot declare child-packages. They must target O SDK. Also they cannot be suspended or hidden or their uninstall blocked. Generally, speaking policy regarding code in static shared libs should be applied to the packages using the library as it could have just statically linked the code. We now have APIs to query information about the shared libraries on the device in general. To clients static shared libraries are presented as multiple versions of the same package which is how they are declared and published. Therefore, one can have two versions of the same package which means we need way to query for and uninstall a specific version of a package. Also static shared libs can depend on other static shared libs which are versioned packages. To ease representation we add the concept of a versioned package which should be used in the case of static shared libs. A client can see only the static shared libs it depends on and more specifically only the versions it depends would be retrieved by using the standard package manager APIs. There is a new dedicated API to get info about all shared libraries which would provide data about all static shared lib versions. Also these libraries must use v2 signing scheme. Test: CTS tests pass bug:30974070 Change-Id: I4f3d537ee7a81f880950377b996e1d9d4813da5c
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
a34f53f61be31b7171d6cbcb12490ee143acffff |
|
11-Jan-2017 |
Bartosz Fabianowski <bartfab@google.com> |
Add install reason This CL allows a reason to be specified when installing a package. The install reason is a sticky piece of metadata: When a package is e.g. installed via enterprise policy and an update is then manually installed or sideloaded, the install reason will remain "policy." The install reason is tracked separately for each user. With this CL, two install reasons exist: "policy" and "unknown." Other install reasons will likely be supported in the future. Bug: 32692748 Bug: 33415829 Test: Tested manually with "adb install" / "adb uninstall" Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
9bc89af3f1bce8003ee4f93b89a1770d8f5b9cc9 |
|
11-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
Add API for apps to declare their "category". Upcoming platform features need to cluster apps together into broad categories to help summarize information to users. (For example, when presenting battery, network, and disk usage.) We are tightly limiting the set of categories to keep them easily presentable to users when summarizing information. This feature is not designed to be a general-purpose taxonomy, nor should it be allowed to become one. Older apps may not have defined a category in their manifests, so allow the installing app to define a category on their behalf. Test: builds, boots Bug: 33815939 Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
bdcdeb4cc470130db9ddb7abe7763c2170755e22 |
|
22-Nov-2016 |
Narayan Kamath <narayan@google.com> |
PackageManager: Avoid unnecessary calls to derivePackageAbi during boot scans In most cases, we can safely use the values from package settings instead. We do the work when we're in the middle of an upgrade or the first boot, since we have no choice. This saves about 200-400ms on package manager startup on a freshly wiped device with no app installs. Savings are likely to grow linearly with the number of installed apps. Bug: 22063656 Test: make + manual testing. Change-Id: I1b2bdc4df45f334620c1fb94d78276f0095d5ff8
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
3cd658e1a598e59738bc129c35eecf4cd0f20680 |
|
17-Aug-2016 |
Todd Kennedy <toddke@google.com> |
More refactoring * Break apart getSettingsWithBenefits() into separate methods for creating new settings and updating settings, etc... * Add more hooks to test equality of setting clones * Create tests for each subset of functionality Bug: 30219944 Change-Id: I1fb3d07bb9279f93ba81ada2ff802989ec2c5965
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
788c8423d19972389b82a23dec297eb27d819c86 |
|
10-Aug-2016 |
Todd Kennedy <toddke@google.com> |
More settings cleanup * While parsing the packages.xml file, don't call getPackagesLPw(); we'll never find a package unless something has gone horribly wrong. Instead, build the PackageSetting like a sane person and add it to internal structures. * Add methods to create a proper copy of the PackageSetting object and not just the data from one class in the middle of the hierarchy. * Stop converting Sets into Lists back into Sets when creating IntentFilterVerificationInfo objects * Remove the name argument when adding a package setting; it should always be the name in the package setting Bug: 30219944 Change-Id: I7fa2c540621fb5d70a59b15919bfd31d8465e25d
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
13715d521f340d24f1de6e06ceaaf2a945910c0d |
|
01-Aug-2016 |
Todd Kennedy <toddke@google.com> |
Break out static update method Simply getting package settings could changes stored state. Break out the majority of the method to modify local variables and not change any stored state. The top-level getPackageLPw() method will still mutate stored state. This will be changed in a future CL. Also add a set of tests to verify the behaviour of updatePackageSetting() Bug: 30219944 Change-Id: I3360a36ce238e816246ee8ca7ecabfbbcdf0b89d
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
8c57aeaa8f27423b843fa043fb86b0b57c906ead |
|
21-Apr-2016 |
Sudheer Shanka <sudheersai@google.com> |
Allow any app to silently uninstall the orphan packages. Bug: 28302564 Change-Id: If6f2111e35ec94c7eb5b80a08bbf63fd58698c27
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
4288419787120ce85a241a4b315d7d2123aa2d4a |
|
10-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Use inode numbers for CE storage. Certain operations, such as clearing/destroying app data, or just counting on-disk size, require us to know the CE storage directory of a particular app. To facilitate these operations, offer a method to get the inode of a CE directory, and accept that inode number for later operations. Collect and store the inode number in PackageUserState for future use when that user's CE storage is still locked. This design means it's safe to clear/destroy app data in both CE/DE storage at the same time. Move most installd-related methods to a uniform calling convention that accepts a single parent PackageParser.Package, and internally fans out to handle all "leaf" packages under that parent. In previous releases, we started installing apps using a new directory-based layout, where all app code, unpacked native libraries, and optimized code is bundled together. So now we only have a single path to measure for code size. This fixes several outstanding bugs that were causing sizes to be miscounted for apps supporting multiple architectures. Fix a subtle bug in PackageSettings that would cause "notLaunched" to be parsed incorrectly. Bug: 27828915, 27197819 Change-Id: Ia582cf3550553292bde4bb4313367111332913ec
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
d4041db120d7500e73e0132b03dfeffb84d402f5 |
|
09-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
More freezing of apps when doing surgery. We're still hearing rare reports of apps running while the system is trying to do surgery on app code/data. To fix this once and for all, start guarding all PackageManager critical sections by freezing and then killing the app before doing surgery. This is done by introducing a new PackageFreezer class which can be used in try-with-resources blocks. It also handles child packages uniformly, and it uses CloseGuard to defensively un-freeze packages if a caller leaks without closing. The set of frozen packages is now maintained outside of PackageSetting to support newly installed packages. Add docs for the various locks and method syntax conventions, including the new "LIF" syntax which indicates the caller is responsible for freezing the package being worked on. Bug: 27698554 Change-Id: I64c4c48123060ccb4d4c50c2fbf3ef223c01e659
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
39bfee5e3674faea992c32204abc1c03429b8cda |
|
24-Feb-2016 |
Todd Kennedy <toddke@google.com> |
Splits without restart In specific cases [as determined by the installer], we can install splits without restarting the application. The split must be purely additive [i.e. it should not modify class(es)/resource(s) defined in the base or other splits. Otherwise, the behaviour could be inconsistent [e.g. if a modified class was already loaded, the modified version won't be loaded until the process is restarted]. The platform does not perform any verification that the split is purely additive. Bug: 26463098 Change-Id: I3526c3b1b847a8e0afabc7a4787fa770422196b7
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
354cd3ce2213a1032d9138ea6fa1420f055ab08c |
|
17-Dec-2015 |
Svet Ganov <svetoslavganov@google.com> |
Multi packages per APK This change introduces the ability to have multiple packages per APK. The feature is currently restricted to privileged apps and updates to such apps. In essence the manifest can have multiple child package declarations. A child package can declare everything an Android package can except some tags or attributes that are not applicable and instead inherited from the parent when needed. For example, the target SDK of the parent applies to all children. A child package can be updated only through the parent package. A package with multiple child packages is installed, uninstalled atomically - no partial installs where some child packages are not installed. The remaining work is to ensure broadcasts are also sent for child packages. This will come in a subsequent change. Sample app:ag/848432 Design doc: https://docs.google.com/document/d/18nFWtJuZchLxrHf5SBbJW03-Ky9Rh_G0-OVB14b6u78 Change-Id: I6fd021d981bf5786290e0c53502724a14c97358c
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
1e2839188fb49575b86646d3aadb355c81ef9cc5 |
|
26-Nov-2015 |
Andrei Stingaceanu <stg@google.com> |
Wire call to suspend a package Adds APIs in DevicePolicyManager and PackageManager for allowing a device admin to suspend a package. PackageManagerService sets or unsets a new PackageUserState 'suspended' setting. Terminal command to suspend/unsuspend has been added via PackageManagerShellCommand (as root). Next steps: * use the new 'suspended' setting for denying access to start app (probably in ActivityStackSupervisor) * broadcast a PACKAGE_(UN)SUSPENDED intent for launchers to pick up * remove app from recents (go further and kill it if it is running) * erase existing notifications for this app Bug: 22776576 Change-Id: I718b3498f6a53cc0c6fdfb6d15031e53ddca4353
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
3b1c6e03f67ba8e4a4f4a98e996c7ceabf36affa |
|
31-Oct-2015 |
Jeff Sharkey <jsharkey@android.com> |
PackageSettingBase needs to copy volume UUID. When copying all fields from one PackageSettingBase to another, we also need to copy volumeUuid, which had previously been missed. Without this, packages using sharedUserId that are installed on adopted storage devices will be destroyed, since after reboot we think they actually belong on internal storage (where volumeUuid is null). Bug: 25334169 Change-Id: I223361bd1e19e7d5dd78626682ac7c5cbecb9fa1
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
b4faf9810d5b1cb01b4663cd48f13f6487edc64b |
|
09-Jul-2015 |
hyemin.hwang <hyemin.hwang@lge.com> |
Fix a bug disappearing installerPackageName info of packages after reboot. If user install apps from playstore, system has installerPackageName attribute of app. but, after reboot, some apps(have sharedUserID) installerPackageName attribute disappearing. because lack of copy routine. So, I added copy routine(installerPackageName). Testcase : 1. Install app(has sharedUserId, ex Lync2013) from market. 2. Confirm package info from packages.xml(exist installer info). 3. reboot. 4. Re-confirm package info from packages.xml(not exist installer info). Cherry-pick from AOSP master. Bug 22513758 Change-Id: I3fea3e573c056f6c2f574715d2ebef4df8b75a68
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
f0d6cb38c47ee37583034dc3a68238ed13c91742 |
|
11-Jul-2015 |
Christopher Tate <ctate@google.com> |
Prioritize most-recently-enabled link-handling app In the case when multiple apps handle a given web-link action, all of which have been marked as "launch the app instead of a browser" and so are otherwise ambiguous, always prefer the app that was most recently placed into the always-handle-links state. Bug 22051035 Change-Id: I3f43c19b0d7b74e9843445e41971bb5433affb1c
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
adc1cf46045ae756d3a9ccbccf6b0f894e4c1edd |
|
16-Jun-2015 |
Svet Ganov <svetoslavganov@google.com> |
Only grant runtime permissions to special components. Now runtime permissions are granted only to components that are part of the system or perform special system operations. For exmple, the shell UID gets its runtime permissions granted by default and the default phone app gets the phone permissions granted by default. bug:21764803 Change-Id: If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
e31b820dad4c5f2b19ee10479a675a139ad3c61e |
|
30-Apr-2015 |
Jeff Sharkey <jsharkey@android.com> |
New "frozen" state during app move/upgrade. This replaces mOperationPending, which was in an odd place. It adds a new PackageSetting.frozen flag that is a last-ditch effort to prevent ActivityManager from starting an app while it's being moved or upgraded. Also provides clearer guarding around all upgrades by freezing, killing, upgrading, then unfreezing. Bug: 20275579 Change-Id: I28bb0359a6f4e05080fb336b18dd2a249509d989
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
6227172310663e1267b1fabd68be890a1cb7e145 |
|
11-Apr-2015 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add Default Browser App support and relax Hosts validation for AppLinks - add private PackageManager APIs for setting/getting the default Browser App package name - serialize / deserialize the default Browser App package name per User Also relax the Hosts name validation for the AppLinls feature. Now we just care if the IntentFilter is having an HTTP or HTTPS scheme. Change-Id: I4436f66ac6beff57e14f7f3a2a00b0b582c03be9
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
b2b9ab8354da1485178cd8d8e9d89ac915b3f269 |
|
06-Apr-2015 |
Jeff Sharkey <jsharkey@android.com> |
Installing packages to expanded storage. PackageManager now offers to load/unload packages when expanded volumes are mounted/unmounted. Expanded storage volumes are still treated as FLAG_EXTERNAL_STORAGE from a public API point-of-view, but this change starts treating the INSTALL_EXTERNAL flag as exclusively meaning ASEC containers. Start tracking the UUID of the volume where a package is installed, giving us a quick way to find relevant packages. When resolving an install location, look across all expanded volumes and pick the one with the largest free space. When upgrading an existing package, continue preferring the existing volume. PackageInstaller now knows how to stage on these volumes. Add new movePackage() variant that accepts a target volume UUID as destination, it will eventually move data too. Expose this move command through "pm" command for testing. Automount expanded volumes when they appear. Bug: 19993667 Change-Id: I9ca2aa328b9977d34e8b3e153db4bea8b8d6f8e3
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
37f05184b5641366b59c540ad6bf3e3b2a1ac6ea |
|
01-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix clobbered shared user install permissions. The install permissions for a shared user were clobbered when a pending package for this user was matched to the shared user after reading the state from XML. The reason was that the copy code in PackageSettingBase was using the getter to get its settings state to which to copy the permissions for the pending package but this is the permissions state for the shared user instead of the package. Since the pending package has no permissions we ended up clobbering the permissions for the shared user. bug:19955926 Change-Id: Ia8d090883d50fc987a32ceeed6c7562c49698328
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
1c1b47125da018b44240739db75f8898e064a948 |
|
20-Nov-2014 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add IntentFilter auto verification The purpose of this feature is to prompt the Disambiguation dialog to Users as less as possible. - add the new "autoVerify" property to the IntentFilter class - add new APIs to PackageManager: verifyIntentFilter(int, int, List<String>), getIntentVerificationStatus(String, int), updateIntentVerificationStatus(String, int, int), getIntentFilterVerifications(String) for supporting IntentFilter verification - add support for multi-user - update PackageManager for IntentFilter verification: basically when we are installing a new package, ask for verification of all domains from the IntentFilters that have the "autoVerify" to true. This means that the PackageManager will send a well defined protected broadcast (with a new INTENT_FILTER_NEEDS_VERIFICATION action) to an IntentFilter verifier to do the real job of verification. We are passing in the broadcast Intent all the necessary data for doing the verification. The PackageManager will receive as response the result code of the domain verifications and, if needed, the list of domains that have failed the verification. - add a new INTENT_FILTER_VERIFICATION_AGENT permission that needs to be set by an intent filter verifier to be considered as a trustable party by the PackageManager. - add also a new BIND_INTENT_FILTER_VERIFIER permission for securing the binding between the PackageManager and a service doing the intent filter verifications. - add ResolveInfo filterNeedsVerification which is a boolean to knows if the IntentFilter is of a type that needs a verification (action VIEW, category BROWABLE, HTTP/HTTPS data URI) - add new "domain-preferred-apps" / "d" dump command for listing the prefered Apps for all domains - add new "intent-filter-verifiers" / "ivf" command for listing the IntentFilterVerifier used - introduce the IntentVerificationService which is a basic service for verifying IntentFilters. This service will send HTTPS requests to the domain declared in the IntentFilter(s) for doing the verification. This service has a low priority level so that it can be replaced by a more sophisticated one if needed. This service is updating the PackageManager intent verification states thru the updateIntentVerificationStatus(...) API. - update MockPackageManager Change-Id: I0bfed193d0bf1f7c7ac79f6c1b160b7ab93b5fb5
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
cf959f6e722ddd20033b7c98b3e04c7143f6438e |
|
27-Mar-2015 |
Svetoslav <svetoslavganov@google.com> |
Handle dynamic enable/disable of runtime permissions support. This change adds support for the case where we change the state of runtime permissions support via the system property. This was not working properly before because we did not handle system app permissions properly.: Change-Id: I66c5e6c823b8521999972b0432b1daaba38c9709
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
d5752bdc8fd39d4f0a508f9088c538e30e73044a |
|
26-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Properly handle system app permissions - for real. System apps targeting SDK greater than Lollipop MR1 get runtime permissions by default but if the user takes them away we should not regrant them. To do that we keep track for each package which user ids were handled in the last permissions update. If a new user id has appeared we grant runtime permissions for this user to the sys package. When we start clean (i.e. first boot) the sys packages were updated for no user so we grant the runtime perms for the owner. When reading a package from packages.xml we set the updated user ids to all users ids on the device as the state in the xml reflects the latest state before a shutdown, i.e. the last state when permissions were updated. Change-Id: I93135baa57950405a357b139c59f432cf02f0bc6
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
c6d1c345f41cf817bf2c07c97b97107d94296064 |
|
26-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Runtime permissions: per user permission tracking. Before all permissions were granted at install time at once, so the user was persented with an all or nothing choice. In the new runtime permissions model all dangarous permissions (nomal are always granted and signature one are granted if signatures match) are not granted at install time and the app can request them as necessary at runtime. Before, all granted permission to an app were identical for all users as granting is performed at install time. However, the new runtime model allows the same app running under two different users to have different runtime permission grants. This change refactors the permissions book keeping in the package manager to enable per user permission tracking. The change also adds the app facing APIs for requesting runtime permissions. Change-Id: Icbf2fc2ced15c42ca206c335996206bd1a4a4be5
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
33d3c53da021f0d044028860ace0f4ad817273f5 |
|
11-Feb-2015 |
Alex Klyubin <klyubin@google.com> |
resolved conflicts for merge of 517e0274 to lmp-mr1-dev-plus-aosp Change-Id: Ic20b6c8851458483dd73a144bd5ae6e8d141e62a
|
b9f8a5204a1b0b3919fa921e858d04124c582828 |
|
03-Feb-2015 |
Alex Klyubin <klyubin@google.com> |
Move hidden ApplicationInfo flags into a separate field. The public API field android.content.pm.ApplicationInfo.flags can support only 32 flags. This limit has been reached. As a short term workaround to enable new public flags to be added, this CL moves flags which are not public API into a separate new field privateFlags and renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED is now PRIVATE_FLAG_PRIVILEGED). The new privateFlags field is not public API and should not be used for flags that are public API. The flags that are moved out of ApplicationInfo.flags are: * FLAG_HIDDEN, * FLAG_CANT_SAVE_STATE, * FLAG_FORWARD_LOCK, and * FLAG_PRIVILEGED. NOTE: This changes the format of packages.xml. Prior to this CL flags were stored in the "flags" attribute. With this CL, the public flags are stored in a new "publicFlags" attribute and private flags are stored in a new "privateFlags" attribute. The old "flags" attribute is interpreted by using the old values of hidden/private flags. Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
9f837a99d48c5bb8ad7fbc133943e5bf622ce065 |
|
24-Oct-2014 |
Jeff Sharkey <jsharkey@android.com> |
Reduce PackageManager RAM usage: ArrayMap/Set. Transition PackageManager internals away from heavier HashMap/HashSet to use drop-in ArrayMap/ArraySet replacements. Saves ~38% RAM and thousands of objects on a typical device. Bug: 18115729 Change-Id: Ie107d2fee4b7baa4e3c3923231b4be877d1a5d2f
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
4903f64ba2478849e6c401f42f5a77c1d4f9f7df |
|
11-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Persist the cpuAbiOverride setting. If an app is installed with an ABI override (adb install -r --abi) we should remember this so that we don't revert to the scan derived ABI on the next reboot. bug: 16476618 Change-Id: I6085bc0099eb613dd9d3b07113c7c13859780697
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
e5bcff624fb58b6f95be8ddff7f5b6b3bf5d19c7 |
|
20-Jul-2014 |
Amith Yamasani <yamasani@google.com> |
Rename setApplicationBlocked to setApplicationHidden This corrects the expected behavior of the app state. Hidden apps can be installed by the store to be brought out of hidden state. Bug: 16191518 Change-Id: Id128ce971ceee99ba1dea14ba07ce03bd8d77335
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
84f1294a958b42000755dc6570e3eda72ab42140 |
|
11-Jul-2014 |
Jeff Sharkey <jsharkey@android.com> |
Always derive native library paths at runtime. Over time, we've unpacked native libraries at various places with respect to their source APK. Persisting this path in PackageSettings has caused more pain recently with the switch to supporting multiArch and cluster installs. This change switches us to always derive the native library paths at runtime based on the type of install. This also ensures that transitioning between a bundled system app and an upgraded system app will always build the right path. We still persist the last generated path into PackageSettings to make cleanup at uninstall time easier. Bug: 16208505, 16206748, 16212206 Change-Id: Ieb82a424ca4a92b5674983453c50ba4b695abfb0
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
ff110bd61a69f7ed8602ae14b27f7befec76b2e7 |
|
04-Jul-2014 |
Narayan Kamath <narayan@google.com> |
Multi-arch application installs. Each application now has two ABIs, the primary and the secondary. The app is always launched with the primary, but the secondary might be used by other apps that load the given applications code. This implies we must: - dex2oat the app both ways. - extract shared libraries for both abis. The former is relatively straightforward but the latter requires us to change the layout for shared libs that we unpack from applications. The bulk of this change deals with the latter. This change continues to fill in nativeLibraryPath during scans for backwards compatibility. This will be removed in a future patch. Change-Id: Ia943dd11ef815c5cbfc60f17929eaa2a652a385a
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
c13053bf1c05b980421611487ce67677c08db299 |
|
29-May-2014 |
Kenny Guy <kennyguy@google.com> |
Add package state to block uninstall. Add package state to allow profile or device owners to block uninstall of packages. Add API to DevicePolicyManager to set/get the state. Bug: 14127299 Change-Id: I03528819850b42df7bafa7747bb9e4558d20c4e6
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
57dcf5b177b56195421535938544f32d8b591b42 |
|
19-Jun-2014 |
Jeff Sharkey <jsharkey@android.com> |
Slow progress towards APK clusters. Differentiate between "split APKs" and "cluster packages". A cluster package is a directory containing zero or more APKs (base+splits), and a monolithic package is a single APK (base). PackageSetting will use the directory name as its codePath, so track the baseCodePath separately. Clarify documentation in several places. Require that all installers provide file:// URIs through existing hidden APIs; PackageInstaller hasn't been able to read content:// URIs for a long time. Bug: 14975160 Change-Id: I1c6fed1b55205c2474b09871161a98a26669d22e
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
34f6084bc21b07ae9112be6e7a8f50c49828ac9c |
|
30-Apr-2014 |
Narayan Kamath <narayan@google.com> |
Remove "required" prefix from ABI fields. As per a comment on an earlier code review. Change-Id: I3ae30f8a7bc90730068644f93b926e0e05a2cdfb
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|
f148f36d140e995ec8f755e60bbb0b37f33c3da7 |
|
10-Apr-2014 |
Narayan Kamath <narayan@google.com> |
am 9e289d70: am 1d26a3f1: am 09e13cc5: Merge "System services detect and register app CPU ABIs" * commit '9e289d70a8baaed0030413b5991653792e2a816d': System services detect and register app CPU ABIs
|
9e289d70a8baaed0030413b5991653792e2a816d |
|
10-Apr-2014 |
Narayan Kamath <narayan@google.com> |
am 1d26a3f1: am 09e13cc5: Merge "System services detect and register app CPU ABIs" * commit '1d26a3f1efd0d965e8751e8515608c31789bdbe2': System services detect and register app CPU ABIs
|
49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories * commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce': Move some system services to separate directories
|
9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories Refactored the directory structure so that services can be optionally excluded. This is step 1. Will be followed by another change that makes it possible to remove services from the build. Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/pm/PackageSettingBase.java
|