Apktool building not working on 2.4.0 with Java 8 32bit

[weathondev]

Information

I tried decompiling and building multiple apks, on multiple machines (it works on some, on some it doesn't, all windows 10). It doesn't work (see stacktrace) with 2.4.0 but it works with 2.3.4...)

1. Apktool Version (2.4.0) -
2. Operating System (Windows 10) -
3. APK From? (Selfmade) -

Stacktrace/Logcat

I: Using Apktool 2.4.0
I: Smaling smali folder into classes.dex...
I: Building resources...
brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code = -1073741515): [C:\Users\user\AppData\Local\Temp\brut_util_Jar_1931288203282772305.tmp, p, --forced-package-id, 127, --min-sdk-version, 21, --target-sdk-version, 29, --version-code, 1, --version-name, 0.1, --no-version-vectors, -F, C:\Users\user\AppData\Local\Temp\APKTOOL2912424743621301431.tmp, -0, arsc, -0, png, -0, arsc, -I, C:\Users\user\AppData\Local\apktool\framework\1.apk, -S, C:\Users\user\Desktop\test\test5\res, -M, C:\Users\user\Desktop\test\test5\AndroidManifest.xml]

Steps to Reproduce

1. apktool d "input.apk" -o "outputFolder"
2. apktool b "outputFolder" -f -o "output.apk"

Frameworks

default framework

APK

https://anonymousfiles.io/f9PSu1ez/

Questions to ask before submission

1. Have you tried apktool d, apktool b without changing anything?
   Yes
2. If you are trying to install a modified apk, did you resign it?
   n.a.
3. Are you using the latest apktool version?
   Yes

[Mimi8298]

Installing the 64 bit version of java allowed me to fix the problem.

[weathondev]

@Mimi8298 Yep, that's it, fixed it for me. Thanks!
@iBotPeaches Is this intended? If so you should add it to the requirements (not only stating java 8, but java 8 64bit)

[yefuchao]

change java 8 to 64bit also work for me .

[iBotPeaches]

@weathondev 32bit libraries exist for Windows, so this doesn't appear to be intended. I might just remove all 32bit and prevent use if still on 32 bit. That might solve these issues.

[iBotPeaches]

Yeah this doesn't make sense. The bitness of java must be misleading the system to selecting the wrong binary for aapt.

IE - Users must be using 32bit Java on 64bit OS, leading Apktool to selecting a 32bit aapt binary. So maybe complete removal of 32bit from Apktool would be best solution.

• 32bit - https://github.com/iBotPeaches/Apktool/blob/master/brut.apktool/apktool-lib/src/main/resources/prebuilt/windows/aapt.exe
• 64bit - https://github.com/iBotPeaches/Apktool/blob/master/brut.apktool/apktool-lib/src/main/resources/prebuilt/windows/aapt_64.exe

Could try executing those on your system to see if they load (just run in Terminal - Windows only). Then report back with OS bitness and Java bitness.

[iBotPeaches]

Thank you everyone for the heads up. I've finally confirmed with 32 bit aapt binaries on both aapt1/aapt2.

The code execution cannot proceed because libwinpthread-1.dll was not found. Reinstalling the problem may fix this problem.

I will investigate.

[iBotPeaches]

I am dropping Windows 32 bit support. I cannot figure this out how to statically compile libwinpthread into aapt1 & 2. Outside my knowledge gap. I'll leave this for a few days for someone to step up if interested.

Otherwise removal of Windows 32 bit.

[liang530]

my solve 2105

[parind]

@iBotPeaches , Is APKTool running a modified aapt ? Because I am on W32 using APKTool 2.4.0 with modified aapt statistically linked to libwinpthread-1, still I cant compile the resources.

[iBotPeaches]

@parind - Yes we use a custom aapt binary. Custom options are disabled when leveraged with -a though.

[parind]

Okay. So I guess that is what doesn't let me compile using a prebuilt aapt. And what are the modifications you are using to build aapt ? I could try to build with linking the libwinpthread.

[iBotPeaches]

@parind I've been working on this master branch here - https://github.com/iBotPeaches/platform_frameworks_base/commits/master

If you are able to figure out the linking with 32bit builds for libwinpthread, that would be very helpful! I was planning on removing 32bit support since it didn't seem possible in my limited build knowledge

[parind]

Sure, I will do some tests, and push commits, if successful.

[parind]

iBotPeaches, do you have a makefile for aapt alone ? The blueprint files require ndk, and I am using mingw64 to compile.

[parind]

@iBotPeaches Hey, I haven't got the time to look closely and perform changes to prevent libwinpthread-1, but found a temporary solution. The solution is to use the dll from mingw in a PATH env, and use apktool. It did allow me to compile the apk.

I am attaching the dll from mingw.
libwinpthread-1.zip

[xparadoxical]

The solution is to use the dll from mingw in a PATH env, and use apktool. It did allow me to compile the apk.

It works. Thanks a lot @parind

[parind]

It's totally strange, I am not able to pinpoint the problem yet. Found some similar situations on the web. It mostly happens when using cross-compile on Linux, this causes win64 to build correctly, but has win32 binary with a dependency on this dll. It might work, if mingw64 is used on windows to build with win32 threads instead of posix. I have yet to try this, but can't due to storage issues, as building aapt requires the whole android platform base and it's dependency.

[iBotPeaches]

Thanks to Furniel, we have fixed 32bit binaries. I'll have a test release up later today to confirm for this ticket, then I'll merge them into master.