18211fd8f6ff4a70a4b8b16fab642783d536102b |
|
06-Jun-2017 |
Todd Kennedy <toddke@google.com> |
Passing callingUid to internal methods Sometimes callers want to clear the calling identity [to avoid permission calls]. In this case, allow passing the original calling identity to internal methods. Test: Manual; create profile account and observe launcher still works cross profile Test: bit FrameworksServicesTests:com.android.server.pm.ShortcutManagerTest{1..10} Change-Id: I73f8ad4b2dc1895227c3fcb14f3f1f18f600562f Fixes: 38349978
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
3051caac52729c8c059eb538805f4d274a9945a5 |
|
24-May-2017 |
Todd Kennedy <toddke@google.com> |
System installed launcher can see instant apps Change-Id: I97f791b61f9b4f7ed33305345bf3d92394b40ae4 Fixes: 38202759 Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Test: Manual. Create sample app that replaces the launcher to test ability to see ephemeral apps.
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
ad623015a119efe9b63f594af9c4703f40a0c27b |
|
15-May-2017 |
Makoto Onuki <omakoto@google.com> |
Restrict access to instant app data in usage stats - Events are obfuscated based on whether the app was instant or not at the time each event was logged. - UsageStats are obfuscated based on whether each app is instant or not at the moment. Bug 38202133 Test: Manual test using UsageStatsTest and instant apps Change-Id: I3c74309196b88d010d317cb0dd6749bf4624e876
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
301663a61bda0e2eb863d6518de882cf805abcf7 |
|
27-Apr-2017 |
Makoto Onuki <omakoto@google.com> |
Merge "Change IMPORTANCE_PERCEPTIBLE_DEPRECATED to IMPORTANCE_PERCEPTIBLE_PRE_26" into oc-dev
|
e92f79450a0e3a55586eb2992577d09fc997761a |
|
26-Apr-2017 |
Makoto Onuki <omakoto@google.com> |
Change IMPORTANCE_PERCEPTIBLE_DEPRECATED to IMPORTANCE_PERCEPTIBLE_PRE_26 Also make sure to return the legacy value from RunningAppProcessInfo.importance. Bug: 37636026 Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsAppTestCases -t 'android.app.cts.ActivityManagerTest#testGetRunningAppProcesses' Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsAppTestCases -t 'android.app.cts.ActivityManagerTest#testGetMyMemoryState' Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsAppTestCases -t 'android.app.cts.AlertWindowsTests' Change-Id: Ie04e4dfa40c28ea391ae5ce3c769c6f8ee70a43d
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
0606861de50995e997d7c117e3bab1eb5db06da8 |
|
06-Apr-2017 |
Chad Brubaker <cbrubaker@google.com> |
Allow apps to provide the Instant App installer extra information Apps may want to provide additional context information to the instant app installer in order to allow the installer to make smarter choices about the context of the launch. This CL adds a bundle to ActivityOptions that is sent to the Installer (if an Instant App is launched) but not to any other application if something else on the device handles the Intent instead. Bug: 35180854 Test: manual Change-Id: Ifc69a420a9c68041b39acd8a4b83db8a789822a6
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
51b3aaccfe7f8d7a97fb1218c40a37428f26a6a1 |
|
31-Mar-2017 |
Todd Kennedy <toddke@google.com> |
Implement service filtering Instant apps can no longer see services that haven't been exposed to them via the visibleToInstantApps attribute. Change-Id: I6fd78067d1253825668d67b9e17dd3a0703f5d57 Fixes: 35871716 Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
cd181e63ff1a03aff38041e6f30e23cfa27f5c72 |
|
30-Mar-2017 |
Chad Brubaker <cbrubaker@google.com> |
Merge "Track isolated process owners" into oc-dev
|
0f28a80d8e80a3546fe0776999b2deaa3dc2157c |
|
29-Mar-2017 |
Chad Brubaker <cbrubaker@google.com> |
Track isolated process owners This fixes two issues: 1) Isolated processes spawned by Instant Apps do not get full access to package lists as those spawned by normal apps do 2) Package manager considers the isolated process the same app as the Instant App that created it when determining what packages are exposed. Bug: 34087569 Test: Webview works Test: Isolated apps cannot access package info of other apps via start an isolated service. Change-Id: Ib26280b87fb46dc66f1f25ee6209427a095342b0
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
61ae34afe3473909f5e6f0d90a889757d99ea12f |
|
28-Mar-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Intercept direct launch of instant app installer" into oc-dev
|
b21be12d9db5d0d85afa26e401813eaa360bd2e0 |
|
24-Mar-2017 |
Todd Kennedy <toddke@google.com> |
Intercept direct launch of instant app installer The instant app installer is not designed to be launched directly by 3p apps. Instead, intercept the launch and make it look like a "normal" instant app launch. cherry-picked from I89c9b8c56865e260a2b92f8c2312a305a74f9cf5 Bug: 33073524 Test: Built and notice poorly behaving apps [*cough* keep *cough*] now launch instant apps Change-Id: I5401aa8423042f54f1478409065b0d6b25cebe89
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
2cbfa1ec746fa4b3c385ab5c2f707895dd4ecf50 |
|
28-Mar-2017 |
Amith Yamasani <yamasani@google.com> |
Catch IllegalArgumentException to avoid SyncManager crash When SyncManager's scheduling races with an app with a sync adapter being uninstalled, it can get an IAE from PackageManager. Catch this exception and skip over the job. Bug: 36658118 Test: Manual Change-Id: I0a63a3e0aa19cb5685aa18c7c6c9d6dd6ccfd60a
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
4d1de7da79010be3e1f0eb85aa50b6002a8241fd |
|
23-Feb-2017 |
Todd Kennedy <toddke@google.com> |
Add new internal resolve method Instant apps are unique in that any application can start them with a VIEW/BROWSABLE while only very few apps can see an instant app using queryIntentActivites, etc... In order to support this dichotomy, we need an internal hook to resolution for activity start. Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Bug: 25119046 Change-Id: If6974c09c733ff0417ef72cabb9d9e9aca86c37c
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
e991022423c2e5b4386553af7ef3b54da7c54be1 |
|
22-Feb-2017 |
Todd Kennedy <toddke@google.com> |
Load splits on-demand A split may be declared in an application's base manifest, but, defined in a feature split. When resolving such a component, invoke the installer to download and install the necessary split(s) At the moment, this only works for instant apps. However, the implementation is generic and could be applied to any application. Bug: 25119046 Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Change-Id: I6598abb34becfd049fc03199813226736e5057b1
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
b1e7776e2ca348ad734fdddc68d9bda6eb17c5e0 |
|
13-Feb-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #35309312: Background start not allowed: service... ...Intent { flg=0x100 cmp=com.android.systemui/.SystemUIService } to com.android.systemui/.SystemUIService from pid=28245 uid=1000 pkg=android Rework the persistent app check to just directly look at the package manager (but as efficiently as possible). My idea for trying to keep this in the UidRecord was stupid. :p Test: manually tested it boots Change-Id: I5a88717a27fa3529048d37a853518a3ec04055db
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
096d304ae3d85c1bfcda1a1d9cd4eb13d0815500 |
|
31-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add instant cookie APIs This change adds APIs for instant apps to store cookie data that is presisted across instant installs and across the upgrade from an instant to a standard app. Standard apps can use the cookie APIs but when they are uninstalled the cookie is also deleted. The cookies are kept longer than the instant apps as they are much smaller - 16KB by default. We can change the cookie size via a system setting i.e. after we ship we can increase size if needed. We also add internal APIs to surface information about installed and uninstalled instant apps which should be used for showing them in the UI. For this puporse we store the icon, permissions, and label of uninstalled apps. If the app is re-installed we drop this meta-data but keep the cookie around. If we have cookie data stored and the signing cert of the app changes when it gets re-intalled we wipe the cookie. Test: CTS tests pass; hiddent APIs tested manually Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
eabc9e95768e7ac9acc3b32dc9ac2edf99c9e2c5 |
|
15-Dec-2015 |
MÃ¥rten Kongstad <marten.kongstad@sonymobile.com> |
OMS: introduce the OverlayManagerService Add a new system service to manage Runtime Resource Overlays. This will offload the PackageManagerService and allow administration of overlay packages while affected packages continue to execute. Overlays can be enabled or disabled during runtime. Running applications will re-create their ResourcesImpl objects and restart their activities via the usual activity life cycle. The order in which a set of overlays is loaded may also be changed during runtime. The underlying mechanics are the same as for when an overlay is enabled or disabled. When an overlay changes state, e.g. becomes enabled, the OverlayManagerService will broadcast one of the new intents android.intent.action.OVERLAY_ADDED, *_CHANGED, *_REMOVED or *.OVERLAYS_REORDERED. Clients that wish to read information about overlays for users other than themselves are required to hold the android.permission.INTERACT_ACROSS_USERS_FULL permission. This mirrors the protection level of PackageManager.getPackageInfo. Clients that wish to change the information are required to hold the permission android.permission.CHANGE_OVERLAY_PACKAGES. Each pair of overlay package and corresponding target package is respresented by a new OverlayInfo class. This class mirrors the existing PackageInfo class. Overlay packages are handled per Android user. The data is persisted in /data/system/overlays.xml. Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com> Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com> Bug: 31052947 Test: run tests from 'OMS: tests for OverlayManagerService' Change-Id: I15325e173193df3240b8dc0a58c852fd7a3d5916
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
aef2513c7157a28236d097a81fe74d7ba6b710c9 |
|
24-Jan-2017 |
Suprabh Shukla <suprabh@google.com> |
Adding an api for apps to check whether they can install apps Some apps may want to check whether they are trusted to install apps on the device, so they can prompt the user to go to settings and mark them as trusted before they do an intensive operation like downloading an apk. Test: cts-tradefed run cts -m CtsExternalSourcesTestCases Bug: 31002700 Change-Id: Icd9d04daa157e6733decba245ec251ce4acd4122
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
4c0659f5313bcc70be704a3808af9e670f467ee6 |
|
20-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Enable background restrictions"
|
42a386b7717300bf6d75cbd3b4f7ad00f294be0d |
|
07-Nov-2016 |
Christopher Tate <ctate@google.com> |
Enable background restrictions Apps that target O+ are always subject to background restrictions. Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND app op. Apps with these properties are exempted from background restrictions: - persistent process - currently on the idle battery whitelist - global whitelist for things like bluetooth services Bug 30953212 Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
0e989d00ed1e95be0ccb77c29846ee0b6ac33356 |
|
13-Jan-2017 |
Todd Kennedy <toddke@google.com> |
Grant access to ephemeral metadata When an ephemeral application explicitly accesses an installed application, it grants access to its package metadata. The ephemeral application effectively stays hidden if it doesn't explicitly connect to any activity, service or provider [i.e. implicit connections using an ACTION_VIEW/CATEGORY_BROWSABLE intent will not expose its metadata]. Bug: 34123112 Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest Change-Id: I7e1680902599b3ada0d4fba5998af30566017051
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
9e83cbbc10014b3ed560b3181f594868cd89f9ae |
|
19-Jan-2017 |
Chris Tate <ctate@android.com> |
Revert "Enable background restrictions" This reverts commit 21f778060badb1e78bffde05e8de7662d275003d. Change-Id: I65586f9739da84fb32b51b0ea166b8288c41d1b3
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
21f778060badb1e78bffde05e8de7662d275003d |
|
07-Nov-2016 |
Christopher Tate <ctate@google.com> |
Enable background restrictions Apps that target O+ are always subject to background restrictions. Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND app op. Apps with these properties are exempted from background restrictions: - persistent process - currently on the idle battery whitelist - global whitelist for things like bluetooth services Bug 30953212 Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
e080da9ee027fcd030aa92ea26fd0ed9f031674f |
|
22-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Settings recovery support This change allows the system to perform iterative reset of changes to settings in order to recover from bad a state such as a reboot loop. To enable this we add the notion of a default value. The default can be set by any package but if the package that set it is a part of the system, i.e. trusted, then other packages that are not a part of the system, i.e. untrusted, cannot change the default. The settings setter APIs that do not take a default effectively clear the default. Putting a setting from a system component always makes it the default and if the package in not trusted then value is not made the default. The rationale is that the system is tested and its values are safe but third-party components are not trusted and their values are not safe. The reset modes from the least intrusive are: untrusted defaults - reset only settings set by untrusted components to their defaults or clear them otherwise; untrusted clear - clear settings set by untrusted components (or snap to default if provided by the system); trusted defaults - reset all settings to defaults set by the system or clear them otherwise. Also a package can reset to defaults changes it made to the global and secure settings. It is also possible to associate a setting with an optional token which can then be used to reset settings set by this package and associated with the token allowing parallel experiments over disjoint settings subsets. The default values are also useful for experiment (or more precisely iterative tuning of devices' behavior in production) as the stable configuration can be set to the "graduated" safe defaults and set the values to the experimental ones to measure impact. Test: tests pass Change-Id: I838955ea3bb28337f416ee244dff2fb1199b6943
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
cb67dc9eadf6c6aaa343f48e24b2b43914639c05 |
|
13-Dec-2016 |
Michal Karpinski <mkarpinski@google.com> |
Fix javadoc for PackageManager#getNameForUid() Change-Id: Ia4fbd6948ab0703c7df9dceae99170ffb8c96ddb
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
3e12f413d40e55da3d8a964740bc2aa9899c622b |
|
17-Nov-2016 |
Todd Kennedy <toddke@google.com> |
Merge "Implement 2-phase resolution"
|
01ad0c7e403794b272494f187d91f57bdfa07c9d |
|
12-Nov-2016 |
Todd Kennedy <toddke@google.com> |
Implement 2-phase resolution Bug: 25119046 Test: build & install the sample resolver and run 'adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://www.tripadvisor.com/Tourism-g33020-San_Jose_California-Vacations.html"' Change-Id: I624b9028061aad35db80e0d51bfe0a39fb81806c
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
e07641d4fbdd0528c18305213e861a6e1aff4a3b |
|
10-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Start implementing background restrictions for eph apps. This implements the additional intended path for checking allowed background operations, APP_START_MODE_DISABLED, which doesn't allow an app to launch in the background at all. Also change the semantics of delivering broadcasts to manifest receivers to always restrict those, not changing based on whether the app is currently idle. This is the desired intended behavior for apps as they explicitly update to work with bg check. And now that we have ephemerality associated with the uid state in the activity manager, we can propagate this through the relevant callbacks in IUidObserver so things watching these changes can immediately determine whether they should do their more aggressive shut down work for the uid rather than having to walk through all their state looking for package associated with that uid and whether they should be shut down. Also remove the "lenient" bg check mode, since that was just an early experiment that we won't actually use. Add a new "make-idle" activity manager command to immediately put a uid into the idle state (if possible) to make it easier to test. Test: manually against an eph app Change-Id: I43a138ff281f69a9251d3f29ab6e13f48cff8ad6
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
f77ee4f1b79929a77f603e5e879f3616ae464e3e |
|
12-Oct-2016 |
Michal Karpinski <mkarpinski@google.com> |
[DPM] Management and retrieval of network logs This CL follows up on ag/1530343 and adds: 1) Various network events. 2) Retrieval method in DPM and APIs in DeviceAdminReceiver. 3) Extension of NetworkLogger and it's NetworkLoggingHandler. Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/NetworkEventTest.java Bug: 29748723 Change-Id: I42a1a477e7c75c109a3982f809c22732b814e8b2
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
700e1e7ee8e4ed491768a35ed692a4e8f0ff0d4b |
|
28-Sep-2016 |
Nicolas Prevot <nprevot@google.com> |
Don't allow the shell to change admin-locked app permissions. BUG:27432532 Change-Id: I67f8794ea923edb5024033bb2a4474a1fb6d5fd9
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
973edd19db752483f5958f974068c89fead1371b |
|
09-Sep-2016 |
Svet Ganov <svetoslavganov@google.com> |
Don't show account access request UI until app launched. Sync adapters that don't have account access cannot run until the user explicitly approves in the UI. This is spammy given the user may not use the app right away. This change doesn't show the notificaiton until the app has run. bug:31162498 Change-Id: I1f4f2d2e9426f78763590e8aa542b94d6e93e488
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
9d48a731d0a7c016b58bc9c1afc4acd94200650f |
|
24-Jun-2016 |
Steven Ng <stevenckng@google.com> |
Disallow disable / hide device provision app + Rename functions in ProtectedPackages. + Add a Set in ProtectedPackages to store protected package. Bug: 29116229 Change-Id: Ib7dd93a158c09ebbf70f4d57c1afbd2c5102edbd
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
c29f62c7388f550da2c7368c5dbc0aec7d1564fe |
|
07-Jun-2016 |
Makoto Onuki <omakoto@google.com> |
Push DO/PO package names from DPMS to PM Bug 29126573 Change-Id: I95ea1559f6acf5d2f0e1b0953568cdfc938e83b9
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
2d5b465fa9235e66ec176f6d6ffaaa0c18143e41 |
|
12-Mar-2016 |
Makoto Onuki <omakoto@google.com> |
Implement the launcher side permission. Only the default launcher can call the LauncherApps shortcut APIs. Bug 27548047 Change-Id: I6d597fcad80c5201a2f93b8cbecd567fc79926d8
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.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/core/java/android/content/pm/PackageManagerInternal.java
|
726c45970e35e3fff3eeb4d86c3b772db73adcc7 |
|
18-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Stop granting default Contacts permission to IMEs. This partially reverts the previous commit [1], which allowed special components to be granted some pre-configured default permissions. With this CL, we no longer grant Contacts permissions to pre-installed IMEs. Rationals are: 1. Even without this CL, not the all pre-installed IMEs are granted Contacts permission by default, because it was done during the boot time where InputMethodManagerService is not yet completely initialized. The current behavior is confusing not only for users but also for developers. 2. In almost all the cases, IMEs are supposed to be able to work without Contacts permission. Hence it is not too late to ask users to grant the permission to the IME after the initial setup is completed. 3. It is difficult to add new features such as File-Based Encryption (FBE) with keeping the current implementation, because currently we dynamically call mSettings.setCurrentUserId(userId) just to enumerate what IMEs will be enabled for a given user. Adding another condition (whether the user has already unlocked the device or not) would make things more complicated. Note that LatinIME has already support the case where Contacts permission is not granted by default. It does not ask users for anything until Setup-Wizard is completed, and requests Contacts permission only when the user taps a message in the suggestion strip that suggests users to use contacts name for typing suggestions. [1] If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9 adc1cf46045ae756d3a9ccbccf6b0f894e4c1edd Bug: 24756974 Bug: 26743676 Change-Id: Ief2a40b5971b3eb97d765f934d20ce7f2ef25665
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
9c165d76010d9f79f5cd71978742a335b6b8d1b4 |
|
02-Dec-2015 |
Svet Ganov <svetoslavganov@google.com> |
Add optional permission review for legacy apps - framework For some markets we have to allow the user to review permissions for legacy apps at runtime despite them not supporting the new permission model. This is achieved by showing a review UI before launching any app component. If an update is installed the user should see a permission review UI for the newly requested permissions. To allow distinguishing which permissions need a review we set a special flag in the permission flags that a review is required. This flag is set if a runtime permission is granted to a legacy app and the system does not launch any app components until this flag is cleared. Since install permissions are shared across all users the dangerous permissions for legacy apps in review mode are represented as always granted runtime permissions since the reivew requirement is on a per user basis. Whether the build supports permission review for legacy apps is determined by a build constant allowing us to compile away the unnecessary code for markets that do not require a permissions review. If an app launches an activity in another app that has some permissions needing review, we launch the permissions review UI and pass it a pending intent to launch the activity after the review is completed. If an app sends a broadcast to another app that has some permissions needing review, we do not deliver the broadcast and if the sending app is in the foreground plus the broadcast is explicit (has a component) we launch the review UI giving it a pending intent to send the broadcast after the review is completed. If an app starts a service in another app that has some permissions needing review, we do not start the service and if the calling app is in the foreground we launch the review UI and pass it a pending intent to start the service after the review is completed. If an app binds to a service in another app that has some permissions needing review, we schedule the binding but do not spin the target service's process and we launch the review UI and pass it a callback to invoke after the review is completed which spins the service process and completes the binding. If an app requests a content provider in another app that has some permissions needing review we do not return the provider and if the calling app is in the foreground we show the review UI. Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
cb6fd80721253ffa9dcab5cf8c2f4e9b9cd17ccc |
|
05-Nov-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Added keep-uninstalled-packages DO policy This policy allows DO to specify a list of apps to cache even without being installed on any user. Bug: 23938464 Change-Id: I2eeab7f148409739fc23a5c44e955ad12b63fd04
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
cf85562bc9a0f01db51b4088e72f05a8089fc7f1 |
|
29-Jul-2015 |
Sailesh Nepal <sail@google.com> |
Default permissions for sim call manager This CL adds the following permissions by default to the SIM call manager: - microphone - phone BUG: 22790160 Change-Id: Icaf1db6c6943b3ddbd16a946a81d1bfb734d761f
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
0010b70beae6fafd3faf06e1b02291f59f9f85db |
|
01-Jul-2015 |
Svetoslav <svetoslavganov@google.com> |
Grant permissions to headless system calendar/contacts sync adapters. bug:21861781 Change-Id: I5f9905a23ba1b23e387adf2cea842172d34207b0
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.java
|
cdfd230a392d0f0557a3a5bada221b7a05113392 |
|
26-Jun-2015 |
Svetoslav <svetoslavganov@google.com> |
Grant default permissons to the default SMS, Phone, Browser app. The default SMS, Phone, Browser are selected in the UI and we grant default permissions to these. We do this regardless if they are on the system image as the user has made an explicit choice in the UI and the permission we grant are considered essential for such type of a core app to operate properly. bug:22104986 Change-Id: Ide8caeb524b43dde11a20460666cf34c4d35f84b
/frameworks/base/core/java/android/content/pm/PackageManagerInternal.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/core/java/android/content/pm/PackageManagerInternal.java
|