186f29b6d8f00dfc16288b4972d43e874a805229 |
|
13-Apr-2016 |
Bernard Chau <bernardchau@google.com> |
Includes both direct boot aware and unaware apps in Apps default view The view should be showing a combined list of "downloaded" + "visible in launcher" apps. However, if FBE and work callenge are enabled, after a reboot the direct boot unaware apps are filtered. Reason is that PackageUserState#isMatch assumes at least one of the flags are specified and expects system to derive the aware/unaware flags according to the user's lock state if neither of them is specified. Bug: 28004355 Change-Id: Ia05edb0530023597fd219eb5e59cd71752efd279
/frameworks/base/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.java
|
8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback. Mostly consists of removing the word "encryption" from most APIs, since we can't actually make promises about the data being encrypted. Bug: 27531029 Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
2bd31dbd023a11d90061c7b6831dd06454c928af |
|
10-Jan-2016 |
Jeff Sharkey <jsharkey@android.com> |
Install non-EA providers once user is unlocked. When starting encryption-aware apps while the device is locked, we can only spin up ContentProviders that have been marked as encryption-aware. Once the user is unlocked, we need to go back and install non-encryption-aware providers in already running apps. Fix bugs in getPackageInfo() where only one of the various MATCH_ flags was being consulted (!). Move matching logic to single unified location in PackageUserState so we have consistent behavior. Fix another class of bugs where Safe Mode wasn't correctly filtering package details (!). These bugs are fixed by splicing in the new MATCH_SYSTEM_ONLY flag as part of state-based flag mutation that was added for encryption. Bug: 25944787 Change-Id: I39c8da74b1f9ba944cc817176983f50ba322329c
/frameworks/base/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.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/core/java/android/content/pm/PackageUserState.java
|
655d0e2029e6ae77a47e922dce4c4989818b8dd1 |
|
12-Jun-2013 |
Amith Yamasani <yamasani@google.com> |
Single-user restrictions Introduces a new "blocked" state for each package. This is used to temporarily disable an app via Settings->Restrictions. PIN creation and challenge activities for use by Settings and other apps. PIN is stored by the User Manager and it manages the interval for retry attempts across reboots. Change-Id: I4915329d1f72399bbcaf93a9ca9c0d2e69d098dd
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
3fa3c28a356108a6558b6b54a0b10e1a5cc4f1b6 |
|
27-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Keep track of who has disabled applications. Change-Id: I2640d3dc2200b589e2beb42a43cc93efd090f06e
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
4a9f071f3d3fdd20615167cda6f22da912bc60c7 |
|
03-Oct-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7272775: Auto Start Apps Not Starting Bad defaults were causing stopped state to be set at each boot. Change-Id: I49b04e9c62f6ac391054201b508fddb6c7985615
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
d4ac8d7b3de27a9f0e4c6af2496ca71d794e42d1 |
|
28-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7211769 and #7244492, thrash around on #7226656. Issue #7211769: Crash dialog from background user has non-working "report" The report button now launches the issue reporter for the correct user. Also for crashes on background users, either disable the report button, or simply don't show the dialog depending on the build config. Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything Now they do. Issue #7226656: second user seeing primary user's apps I haven't had any success at reproducing this. I have tried to tighten up the path where we create the user to ensure nothing could cause the user's applications to be accessed before the user it fully created and thus make them installed... but I can't convince myself that is the actual problem. Also tightened up the user switch code to use forground broadcasts for all of the updates about the switch (since this is really a foreground operation), added a facility to have BOOT_COMPELTED broadcasts not get launched for secondary users and use that on a few key system receivers, fixed some debug output. Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
8832c18d8b63367929c2d394c9c508f56003d400 |
|
18-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix API review bugs. 7173152 API REVIEW: android.content.pm.PackageUserState 7172969 API REVIEW: android.app.PendingIntent 7172730 API REVIEW: android.content.Context 7172726 API REVIEW: android.manifest.permission Change-Id: Iad470256d3b5ca5596487f6a699ec1871457c3b5
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|
7767eac3232ba2fb9828766813cdb481d6a97584 |
|
24-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Keep track of whether an app is installed for each user. This add a new per-user state for an app, indicating whether it is installed for that user. All system apps are always installed for all users (we still use disable to "uninstall" them). Now when you call into the package manager to install an app, it will only install the app for that user unless you supply a flag saying to install for all users. Only being installed for the user is just the normal install state, but all other users have marked in their state for that app that it is not installed. When you call the package manager APIs for information about apps, uninstalled apps are treated as really being not visible (somewhat more-so than disabled apps), unless you use the GET_UNINSTALLED_PACKAGES flag. If another user calls to install an app that is already installed, just not for them, then the normal install process takes place but in addition that user's installed state is toggled on. The package manager will not send PACKAGE_ADDED, PACKAGE_REMOVED, PACKAGE_REPLACED etc broadcasts to users who don't have a package installed or not being involved in a change in the install state. There are a few things that are not quite right with this -- for example if you go through a full install (with a new apk) of an app for one user who doesn't have it already installed, you will still get the PACKAGED_REPLACED messages even though this is technically the first install for your user. I'm not sure how much of an issue this is. When you call the existing API to uninstall an app, this toggles the installed state of the app for that user to be off. Only if that is the last user user that has the app uinstalled will it actually be removed from the device. Again there is a new flag you can pass in to force the app to be uninstalled for all users. Also fixed issues with cleaning external storage of apps, which was not dealing with multiple users. We now keep track of cleaning each user for each package. Change-Id: I00e66452b149defc08c5e0183fa673f532465ed5
/frameworks/base/core/java/android/content/pm/PackageUserState.java
|