[core] Error loading apk

[amspeople]

Checks before report

• check latest unstable build

Describe error When I try to decompile the apk, the PC freezes, the load is 100% on the processor. After 7 minutes no result (blank window). This was not the case before. The latest version that does not have this problem is b1451, if I'm not mistaken.

Test apk - https://www.apkmirror.com/apk/huami/amazfit-watch/amazfit-watch-5-7-2-play-release/zepp-formerly-amazfit-5-7-2-play-android-apk-download/

[alissonlauffer]

How much memory have you allocated for Jadx? Since the target apk is way too large (~75 MB of dex files and ~704 MB when dex files are disassembled into smali), it becomes difficult to decompile without Jadx becoming out of memory, even with 6 GB of allocated memory.

[amspeople]

I have allocated 5GB of memory. This volume has always been sufficient. The problem appeared recently after version b1451.

[jpstotz]

If I did not made a mistake in counting the commits b1451 should be commit d39849ad00f8c18ac6ccfedb43ebdb8a298a23a2.

@amspeople In your error description you talked about "decompilation" do you mean the full text decompilation and indexing or are you referring to the initial loading phase?

Because I just tried the APK myself using Java 11 and 9GB max heap and disabled automatic background decompilation and the loading phase was as you described. After some minutes the memory consumption went up to the maximum and Jadx was frozen (using the latest version).

If I use the commit I mentioned then Jadx the APK is loaded and requires without decompilation and indexing ~1.1GB RAM (after performing a GC). With allc classes decompiled and indexed RAM usage is about 2.5GB.

Therefore I can fully reproduce the described problem and it is unrelated to the RAM usage.

Edit: I tested some other commits to identify the commit when this problem first occurred.

• 80a879bddfc6e44cbe6614c1205a83f2aacaf82b no error
• b54b2d47e9a70762b34293d47dd8d99a2e9e895f no error
• 3bbb6b1058b81828eb83aa05333a2cea81526c27 error

It seems to be related to the deobfuscation map.

[amspeople]

@jpstotz

In your error description you talked about "decompilation" do you mean the full text decompilation and indexing or are you referring to the initial loading phase?

Initial loading phase.

PS. Thanks for helping me find the problematic commit.

[jpstotz]

@amspeople I finally managed to load the APK you posted in Jadx using the latest version. But using Java 11 it requires setting the maximum heap size to 13G! And it took several minutes to load the apk.

It seems like the deobfuscator renames a lot more elements in the recent version of Jadx and therefore requires a lot more heap. With smaller heap size settings I noticed, right before Jadx starts blocking, a "flood" of several million HashMap entries in the memory overview of VisualVM.

[amspeople]

@jpstotz Yes, 13G of dedicated memory is enough to download the apk. But further work with class decompilation requires even more memory. I think this is definitely a bug, and it is necessary to explicitly bring the memory consumption to the previous values.

[skylot]

I made some improvements, so jadx is faster and uses less memory now. The main cause was a really big count of override related methods for some interface methods from kotlin library, like kotlin.jvm.functions.Function0.invoke() method was overridden more than 10K times. Hope this change doesn't break deobfuscation and renaming. Anyway, please check this change :)

[amspeople]

@skylot At first glance, the problem has been solved. 5GB of memory, as before, is enough even for complete deobfuscation of the test apk. Thank you!

[skylot]

@amspeople thanks for confirm!