Closed IgorEisberg closed 1 year ago
Thanks for the spot. I've added a regression test for now while I dig into the regression. Should make it easier to prevent this from happening in future - https://github.com/iBotPeaches/Apktool/pull/3201
Okay thanks - tracked it down. While its true I regressed it during some ARSC reworks. It wasn't even technically right back then. It was just prior looking for TYPE -> SPEC chunk order, but that is not consistent with a sparse resource build out.
The AOSP commit points at the true criteria of needing at least 1,000 resources (so I pulled the AOSP sample) and sets the type flag - https://github.com/aosp-mirror/platform_frameworks_base/commit/c8f71aa67ea599cb80205496cb67e9e7a121299c#diff-089747e8c6864df42a7a3136c532d62afd64a0938a1fc6f3ef686d98faa635e4R349
Another issue that seems to be a regression since 2.8.0:
sparseResources
in apktool.yml is forced totrue
regardless of whether the original APK used sparse or not. It's easy to reproduce: 1) Decompile any APK:sparseResources
istrue
in apktool.yml. 2) SetsparseResources
tofalse
in apktool.yml. 3) Recompile the APK. 4) Decompile the rebuilt APK:sparseResources
istrue
in apktool.yml again.This wasn't the behavior in Apktool 2.7.1-SNAPSHOT and prior. While it would still work when rebuilding APKs on an Android 13 ROM, no such luck on Android 10 (other versions might be affected as well), as it causes a nasty boot failure: