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/PackageSetting.java
|
c5967e9862489024c932b0c7fcb84ed0af2a7fd7 |
|
08-Jan-2016 |
Jeff Sharkey <jsharkey@android.com> |
More progress on triaging PackageManager callers. Catch a bunch of simple cases where the PackageManager flags are obvious. Add the ability to use the MATCH_SYSTEM_ONLY flag on PackageInfo and ApplicationInfo queries. Re-examine recent tasks after a user is unlocked, since some of the activities may now be available and runnable. Bug: 26471205, 26253870 Change-Id: I989d9f8409070e5cae13202b47e2c7de85bf4a5b
/frameworks/base/services/core/java/com/android/server/pm/PackageSetting.java
|
d2cf3aec6087ba53dcbb55eb38c8e7f385ac4cbd |
|
03-Apr-2015 |
Svetoslav <svetoslavganov@google.com> |
Do not clear a shared user's permissions on an app install. When regranting permissions for an app during an install if that app is in a shared user we should not clear the permissions as the permissions for the shared user are additive and go away when apps requesting them are uninstalled. bug:20050689 Change-Id: I82aa70669fc25a45e7020a1545b093db5525f5cf
/frameworks/base/services/core/java/com/android/server/pm/PackageSetting.java
|
12a692a5e8244cad6ae634cc0821e4e3590cfef6 |
|
29-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix runtime permissinos toggling and relax XML parsing. 1. Fixed the case where runtime permissons can be toggled by a developer via a system property. 2. Relaxed the runtime permission XML parsing to be more fault toelrant and consistent wiht the reset of the package manager parse code. 3. Fixed a deadlock due to calling in to the activity manager with the package manager lock held to kill an app. Change-Id: I11dfb57ad4d8119baea79227dc2a3fe5e2208515
/frameworks/base/services/core/java/com/android/server/pm/PackageSetting.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/PackageSetting.java
|
eeea67b8c3678d882d3774edc41242c63daa60fa |
|
24-Feb-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Extracted a separate class to run dexopt on packages performDexOptLibsLI and related methods were extracted to PackageDexOptimizer class. Minor refactoring of PackageManagerService. This is a non-functional change. It should simplify further work to allow storing OAT files inside package dir. Change-Id: I3494a2da70605362bb6fb4625ffbee1cbe1cd457
/frameworks/base/services/core/java/com/android/server/pm/PackageSetting.java
|
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/PackageSetting.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/PackageSetting.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/PackageSetting.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/PackageSetting.java
|
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
|
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/PackageSetting.java
|