diff options
| author | 2020-02-07 10:15:14 +0900 | |
|---|---|---|
| committer | 2020-02-07 13:20:13 +0900 | |
| commit | a5948019990ac2e0f7b88185f7803b46f16a21b9 (patch) | |
| tree | 8ba69a50e4d8e69ca770c74dc4bc8acb216b176f /java/java.go | |
| parent | 22b08b4af6673944e4beb6351afa7c98eab065b6 (diff) | |
Don't use apexName where apexBundleName is expected
With I63f8a1de463011c6e0b97f5f6eee83103e22bc30, a flattened APEX is
installed to /system/apex/<apexBundleName> not /system/apex/<apexName>.
The change was to be in sync with the non-flattened APEXes that are
installed to /system/apex/<apexBundleName>.apex.
apexName is from the 'name' property while apexBundleName is from the
'apex_name' property. The two names are mostly the same, but can be
different, notably for the ART and the VNDK APEXes. e,g apexName =
com.android.art, apexBundleName = com.android.art.release.
However, there was a bug in the fix; we haven't updated the path for the
flattened APEXes in other places: filecontexts and symlinks. As a
result, the files for the APEXes where apexName is different from
apexBundleName were incorrectly labeled and caused a boot loop.
Fixing the bug.
Bug: 140136207
Bug: 149013536
Test: m
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m; then inspect the built
system.img to verify that
/system/apex/com.android.vndk.current/lib/libcrypto.so is correctly
labeled as system_lib_file.
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
(cherry picked from commit be95e6b245adf9133af17beeed625efd8f5a111d)
Change-Id: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
Diffstat (limited to 'java/java.go')
0 files changed, 0 insertions, 0 deletions