diff options
| author | Zim <zezeozue@google.com> | 2020-02-07 15:14:58 +0000 |
|---|---|---|
| committer | Nandana Dutt <nandana@google.com> | 2020-02-14 14:33:51 +0000 |
| commit | 3ce38499e47e5a3f3847b2b7d47dca63f22318a6 (patch) | |
| tree | 8ddbfeadb8ef247474797440774025cdf6f75f45 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | b14fba21d3a07cbea11b67e5df3f0389af8b532d (diff) | |
Enforce the preserveLegacyExternalStorage manifest attribute
In Q, a manifest flag requestLegacyExternalStorage was
introduced to grant legacy apps full access to external storage.
This flag was sticky across app updates so an app already installed on
a users device would typically always have the legacy_storage appop
even if it received an update to stop requesting the manifest flag.
With the R scoped storage model, we would like to break this
stickiness for 2 reasons:
1. Increase the impact of the storage restrictions
2. Ease testing. Because of the stickyness it is difficult
for apps targeting R to actually lose their legacy_storage appop
Unfortunately, we have to still provide a path for apps who care about
migirating their data on external storage from unreachable locations
on R devices. The canonical example is an app with 3 versions:
(1) Qcannot_migrate, (2) Qcan_migrate, (3) Rcannot_migrate
An update from: 1 -> 2 -> 3 will be fine because (2) will migrate the
apps data. However, apps can very well update from (1) - (3) thereby
losing access to their data in unreachable storage locations on R devices.
To facilitate this migration, apps (targeting R) can explicitly
request the preserveLegacyExternalStorage manifest flag. This will
ensure that if they get updated on a device with a previous version of
their app with the legacy_storage appop, they'll keep legacy_storage
status. Of course, fresh installs (of target R apps) will not have the
legacy_storage appop even if they have requestLegacyExternalStorage
and preserveLegacyExternalStorage flags.
By default, this new flag will be false, legacy status will *not* be
preserved (the legacy_storage appop will *not* be sticky). But apps
that care about migrating data can set the flag to true and
will preserve whatever legacy status they had on an existing install.
Test: atest RestrictedPermissionsTest
Test: atest RestrictedStoragePermissionSharedUidTest
Bug: 148944140
Change-Id: Ifd3410ed1a60f4c0e8414fce904139b539e13ad8
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions