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