diff options
| author | Jeff Davidson <jpd@google.com> | 2015-08-05 14:33:17 -0700 |
|---|---|---|
| committer | Jeff Davidson <jpd@google.com> | 2015-08-05 14:33:17 -0700 |
| commit | 16ed6a45aed0e5d7332647559c3c76b977b705b4 (patch) | |
| tree | e621bb14cc537993b877fbbd8e9a811ab9c7fb39 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | db221acce269245d630e8eb456501c5c6241447b (diff) | |
Correctly propagate permissions when uninstalling updates.
In ag/733689, which was intended to fix this bug, the following lines
were removed:
// Propagate the permissions state as we do want to drop on the floor
// runtime permissions. The update permissions method below will take
// care of removing obsolete permissions and grant install permissions.
ps.getPermissionsState().copyFrom(disabledPs.getPermissionsState());
The intent with these lines seemed to be that we needed to copy
permissions from the application on /data, which is being uninstalled,
over to the copy on /system, which was disabled but is being
reenabled. However, it wasn't functional, because it incorrectly
copied from the copy on /system, not the copy on /data.
Restore this code, copying from newPs (the copy on /data) rather than
disbledPs (the copy on /system), and clarify the comment because we do
*not* want to drop runtime permissions on the floor.
Bug: 22665508
Change-Id: I6bae37e70b6df1043c9a2b49255b985707ba151a
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions