GitLab

[DO NOT MERGE] Bring back overlay warning in permissions UI. am: 92d61dd6 am: 8fd7c428 am: 385ae0e0
am: cd522256  -s ours

* commit 'cd522256':
  [DO NOT MERGE] Bring back overlay warning in permissions UI.

Change-Id: I3444645bc42e1216c612ae7c58cb88cb2dae0a4b

am: 385ae0e0

* commit '385ae0e0':
  [DO NOT MERGE] Bring back overlay warning in permissions UI.

Change-Id: I31099952c886c9d1a9b543df2dc3a91843d6da40

am: 8fd7c428

* commit '8fd7c428':
  [DO NOT MERGE] Bring back overlay warning in permissions UI.

Change-Id: Iff9da3860811b41b657b507481fa9620a2dd2c42

am: 92d61dd6

* commit '92d61dd6':
  [DO NOT MERGE] Bring back overlay warning in permissions UI.

Change-Id: Ibc14501ef88b52d7c60b261e9b29176ada8623d4

The package installer has a special event handling when
the user tries to interact with it and an overlay window
intersects the installer one. We show a warning that an
overlay was detected and point the user to settings. This
regressed and nothing happened when the users click the
allow button.

bug:28572707
bug:26677796

Change-Id: I617595e7cd5277576ccb9915946b77082a1c2b9e

Manual formatting is to complicated to do.

Fixes: 28852429
Change-Id: Ibab723b82a2b14ad94a3038dffccc96f86ba8ee4

Auto-generated-cl: translation import

Bug: 28857042
Change-Id: Ib70f0138d98cc3a8b41c88418b3b45f2a80630e4

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

Change-Id: Ia9dfddda6ce5d05a552e1d7008a2b3f66ec996b4
Auto-generated-cl: translation import

Fixes: 28746698
Change-Id: I3a742ce5afb6020bd24bfd0d9bfec59873f1e7d6

Bug: 28746698
Change-Id: Id4bdbad5efd4dba71a62a8afb22324a1236d675b

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

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

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

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

Auto-generated-cl: translation import

Bug: 28463229
Change-Id: I5385aa26a60096b2d8767051d5759aa508ae8519

This reverts commit 294b6406.

Change-Id: Ifb48eb1fbdb0499743f4ca88adbd5ed77cfa4cf8

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

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

Change-Id: I48ae3be30615adcda2be3941c11b9dfab28ff404
Auto-generated-cl: translation import

Change-Id: I2628855332d49ef28c1ae0954122ff7f7cb8dcbf
Auto-generated-cl: translation import

Bug: 28358465
Change-Id: I01220261b60b7047fa8eed5868cbad9636e7ad92