diff options
| author | Nikita Ioffe <ioffe@google.com> | 2021-07-22 01:37:20 +0100 |
|---|---|---|
| committer | Nikita Ioffe <ioffe@google.com> | 2021-07-22 12:05:41 +0100 |
| commit | db9892300e9233557d47cf43c5975357419a9d8c (patch) | |
| tree | f0a7a7c498dabe2ce3e3b8df3692cb3d4faafa82 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | e501fd8379b1849cd3ae4f7a0485c7890aa87179 (diff) | |
Reject non-staged APEX install if there is staged install of same APEX
There is a interesting interaction between staged and non-staged
installs of the same APEX. Let's say an installer staged v1 -> v2 APEX
update, and then does a non-staged update to v3. After device is
rebooted, apexd will apply the staged v1 -> v2 session, silently
downgrading an APEX from v3.
For apks, this problem is solved by storing an expected version. When an
APK session is being applied during boot, Package Manager will check if
the currently installed version is equal to the expected one stored in
the staged session. If they mismatch, an install is failed.
Unfortunately, implementing the same logic in apexd will require a
non-trivial refactoring which is too late to do in S. Instead we are
just going to fail the non-staged installation.
Test: atest StagedInstallInternalTest
Bug: 187864524
Change-Id: I9000f40cede9a324a5059a09deb8eb5be13b21f9
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions