| 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
|