| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Fixes: 29260288
Change-Id: Iaa309f362ae6a296f7ba365e418d4a6f55b23f0c
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
... at least unless we want to show a progress dialog.
Fixes: 29094372
Change-Id: I45e0bbf32355a93635c773c526151b849bc1e8a3
|
|/
|
|
|
|
|
|
|
|
|
|
| |
The first bug was that we were starting the install before
having the package info for the installed app. The second
was that we were calling the permission review UI despite
we were there before the user selected to install. i.e. the
user already reviewed the permissions.
bug:29197887
Change-Id: I2fac4d014dde7f7744a6b831c2b0ff510e29e8e8
|
|
|
|
|
|
|
|
|
| |
This change fixes a regression where we stopped showing
a confirmation UI for an app side-loading.
bug:28551937
Change-Id: Ia2114d273473d6e00696f9de8c523190a1b444ad
|
|
|
|
|
|
|
| |
Manual formatting is to complicated to do.
Fixes: 28852429
Change-Id: Ibab723b82a2b14ad94a3038dffccc96f86ba8ee4
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We made a change to the PackageInstaller to start settings for
a result to allow partners to return OK to continue the install
flow, otherwise requiring the user to start install again (the
desired behavior on Nexus). This change finishes the package
installer activity if settings does not return success to
continue the install flow.
bug:28838075
Change-Id: I4ff1b1a713d46a8584baf66f379ab070226c125f
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change fixes a regression where we endup installing apps
even if unknown sources is disabled - missing else statement.
bug:28551937
Change-Id: I05dd28a28eb9ffd9eda8a6ee2fdccd501d2e08d1
|
|\ \
| | |
| | |
| | | |
nyc-dev
|
| | |
| | |
| | |
| | |
| | | |
Bug: 26677796
Change-Id: I563541f0a42564b854af0f8037c1d4741c79a2ac
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change ensures the app name is properly bolded in
the premissions request UI even if it is a substring
of "Allow" :)
bug:28719607
Change-Id: I5a313f67c19a2d882732b1c97f0dbee5782b22f5
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Please note that the labels stay unbadged. I.e. The label will always be
"Contacts" instead of "Work Contacts".
Fixes: 28403737
Change-Id: Ib994db946b07098a8c0f95eab5787fb30532fe62
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the user does not want to enable "unknown sources" and clicks
"cancel" the whole installation should finish.
Fixes: 28683865
Change-Id: I2582141ea777e5b2e14dd690b3c3fb8039cff2d4
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes two screens in the case no permissions are required.
- Do not remove tabs, just make them invisible. This is required to push
the "OK" and "CANCEL" button to the bottom
- Show spacer under text as this looks prettier.
Fixes: 28746145
Change-Id: Ia312b476c7e3944709ed3f8fd71d12268559257f
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A regression was introduced when we added support for
installing apps from content URIs. Since we stage the
APK in the cache folder we changed the flow to wipe
the cached version when the PackageInstallerActivity
finishes or gets an installation result, so we started
the InstallAppProgress activity for result but the latter
may be called with the forward result flag which is
incompatible with start activity for result. This change
delegates clearing the staging file in the cache folder
to the InstallAppProgress activity.
bug:28551937
Change-Id: I0d9978aff60b7fab6b64fe7bf889ef30f9b2fd7c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This does not implement correct onDestroy->onCreate behavior but mends
it for the common case.
We now handle all configurations changes, hence onDestroy->onCreate is
very rare. We also just abort quickly if we actually had a
onDestroy->onCreate instead of crashing.
This is a temporary fix.
Bug: 28588511
Change-Id: Ief56c8b866f2561b13253f66a7f79517fc2132cb
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 294b6406798c59e9db5ffa99d042f9b8c6ca6f90.
Change-Id: Ifb48eb1fbdb0499743f4ca88adbd5ed77cfa4cf8
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If an app requests a permission in a group we were auto granting it all
permissions from the group declared as used by the app. The intended
behavior is that we grant only the requested permission and requesting
a permission from a group where a permission is already granted results
in an auto-grant. The intended behavior was to prevent coding around
permission groups which a volatile by design. Now if apps target SDK
above M we provide the intended behavior, otherwise for apps targeting
M we provide an unchenged behavior.
bug:28347872
Change-Id: I493714b2c2581340b01b12ce6fedf80f9d3deec5
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The only permissions a user can control for a legacy app in
runtime style without crashing the app are the ones defined
by the platform because we have app ops only for these and
also we contorl the access to data guarded by them.
bug:27102458
Change-Id: I63d02e169dc82e9f3638b8e8f99ed8d95ae7d325
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We were returing a null PermissionGroup object to a place
where this was not expected by design. The reason for that
was an incorrect fix for b/28241097. This CL reverts the
introduced regression and adds a null check just in case.
bug:27102458
Change-Id: I78f8107d0adf6bb2da5d8e11c5f3cf3c00fe36a2
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PackageInstaller app manages side-loading apps as well
as permission management. It should be updatable, hence
should rely on system APIs to talk to the platform. This
is the first step of defining an API boundary.
Change-Id: I37aea1e5cc3195b8b636af6790af45fe5a9765cd
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The message now depends on the state of mAllUsers flag in
UninstallAppProgress activity:
- This app is required for some users or profiles and was uninstalled for
others (if mAllUsers==true)
- This app is needed for your work profile and can't be uninstalled
(if mAllUsers==false)
Bug: 28240714
Change-Id: Ia060aebd112d3e4c5fcaee02a777140f085abf87
|
| |
| |
| |
| |
| |
| |
| | |
IPackageManager.
Bug: 28207146
Change-Id: Idc75427005c7998de4edd30245fa00a68ba816ba
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reworked all the permission UIs on TV to mesh with the rest of the
settings rendered as leanback-styled side panels with title bars.
The permissions consist of the following components:
* Each individual app permission listing
** Listing of all the permissions together with the apps using
those permissions
Bug: 27344882
Bug: 22481180
Change-Id: I4ab05efd9a4ea6fab7971b89f13d65591a2be8ee
|
| |
| |
| |
| | |
Change-Id: Iba35b172c03e971d2ef9864ddb86534f163b5993
|
| |
| |
| |
| |
| |
| |
| |
| | |
This actually covers most apps and flashing a screen for such a short
time is just flicker.
Bug: 24263165
Change-Id: I82469cad8277599677a5cf11ef975492d22f6d8d
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 26932948
Change-Id: I7552eaad562c2772c02cfa6f13cb044b6db17a19
|
|\ \ \
| |/ /
|/| | |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Added a menu item to link for the help center article for app
permissions.
Bug: b/22096093
Change-Id: Ic810bbcc64b20ab6ee21140f0bb3ea055c10813a
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 26932948
Change-Id: Ic8bcec523fc6cd0db847a4575724fbe465e65c5d
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Checked the wording of the content of the dialogs and I think the
title does not add any information. Design guidelines discourage
dialog titles.
- Removed unused dialog type
- Removed now unused strings
- Spell corrected a string
Bug: 5526317
Change-Id: I7d125d92ef3a2fb3fd6fd402af8d2422c0d8b869
|
|/ /
| |
| |
| |
| |
| | |
bug:21891813
Change-Id: Id9a694d14ecd80c8c04dc28b34cdda3e9119bfb3
|
|\ \
| |/
|/|
| | |
nyc-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apps can define permissions in the platform groups. If a legacy app
deifines a permission in a platform group we were showing the permission
twice because we failed to group the custom permission in the platform
group when building the UI.
bug:26142772
Change-Id: I263bff8631e14395c9000e5e54b0e160969e1eb2
|
|\| |
|
| |
| |
| |
| |
| |
| | |
bug:23899558
Change-Id: I37bf080d54fc4fff5dfcc9f8240b95c82fed56d2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a permission review mode we show UI for the user to review
new permissions for apps that do not support the new runtime
permission model. The review is shown on an app launch. It is
possible for the user to modify permissions in the settings
UI before launching an app.
This change ensures that the default value in the review UI
reflects the user choice in settings. Specifically, the review
UI shows the permission toggle in a granted state if the user
expressed no opinion or granted the pemrission in settings
(initially permissions are shown as revoked in settings as a
review is pending - granting a permission from settings doesn't
void the pending review). However, if the user grants and then
revokes a permission in settings, (expresses an opinion the
pemrission should be revoked) the default state of the
permission
toggle is off.
bug:26741436
Change-Id: I021175df00e334e73aa01363d2c5645e2fe16b90
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 437a6bfedb33daf66592bbed8595025f3e707850.
Change-Id: I5a46f94aadb0ab6dcbe85761f3b1390749b8b1cf
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In a permission review mode we show UI for the user to review
new permissions for apps that do not support the new runtime
permission model. The review is shown on an app launch. It is
possible for the user to modify permissions in the settings
UI before launching an app.
This change ensures that the default value in the review UI
reflects the user choice in settings. Specifically, the review
UI shows the permission toggle in a granted state if the user
expressed no opinion or granted the pemrission in settings
(initially permissions are shown as revoked in settings as a
review is pending - granting a permission from settings doesn't
void the pending review). However, if the user grants and then
revokes a permission in settings, (expresses an opinion the
pemrission should be revoked) the default state of the permission
toggle is off.
bug:26741436
Change-Id: Iae6ae497dfba46ba1399fbf66fb60e70c37f0420
|