Closed ravener closed 2 years ago
Why don't you pkg upgr
?😊
On a second thought this might be a bug in apktool itself, i'll do some more research and try opening an issue in their repo instead maybe.
Try this Apktool work without any error.
@switchroute I just gave it a try, it actually worked, thanks!
That seems to use a newer version 2.6.2-SNAPSHOT so I guess the bug might've been fixed upstream already? Or did he apply any patches?
I tried build apktool from source but it didn't work. I guess there is a certain patch.
This is aapt issue. Apktool from termuxs repos can't build for some reason. But the actual x86 or x64 binaries in the apktools jar file works great. You have to run it through qemu . its statically linked binary . I use it that way. https://github.com/iBotPeaches/Apktool/issues/2772
@switchroute check in termux packages . you just have to run ./gradlew build -X test I guess. And this issue is related to the aapt.
Can't we alternatively patch the jar file's aapt binaries to include a working one from termux? @xtkoba
Might get a lil messy though.
这是来自QQ邮箱的假期自动回复邮件。你好,我最近正在休假中,无法亲自回复你的邮件。我将在假期结束后,尽快给你回复。
@ravener that's how it was managed but but wasn't working well with the termux provided aapt. it had to use the aapt binary it came with. I made a little workaround tho.
Yes, that is the point.
@xtkoba well hope they add the arm/arm64 binary with the package in the future. And are the patches the aapt workaround this repo had got completely removed? Or still I can find somewhere?
@Anonymous2716 IIRC You can find our build recipe preserved under aapt
binaries included in the upstream JAR is for GNU/Linux which do not execute on Termux regardless of architectures. Hence the QEMU workaround./disabled-packages/
.
[EDIT] Ah, statically linked, including libc?
IIRC upstream does not provide the source files for aapt
binary bundled in the JAR file. aapt
binary from our aapt
package does not work with apktool
. Thus wontfix.
@xtkoba thanks for the info.
I've been using https://github.com/rendiix/termux-apktool and it works fine, maybe worth inspecting the aapt in there and what they did?
@ravener arm eabi5 / arm64 binary (dynamically linked) provided.
@ravener arm eabi5 / arm64 binary (dynamically linked) provided.
Yeah so what's stopping us to have an apk tool package like them?
Yeah so what's stopping us to have an apk tool package like them?
We build packages from source, we do not re-package binaries from elsewhere
I asked the author of that project and he says he also packages aapt from source with cmake. And I have just a guess not sure that the problem is in the aapts jar file. Tests will be needed to confirm.
Yeah so what's stopping us to have an apk tool package like them?
We build packages from source, we do not re-package binaries from elsewhere
I think you misunderstood me, I didn't mean to package their debs here, but to find out what they are doing and replicating it in our build.
IBotPeaches' aapt tool is modified and looks like it's based on Cyanogenmod's aapt. It had stuff like the --forced-package-id option and MIUI support added by M1cha. https://github.com/iBotPeaches/android_frameworks_base/commit/76fb330762c3d204f9ae45e444e18a2f82535bc0 https://github.com/iBotPeaches/android_frameworks_base/commit/ef6019690754fd0aea3aa080d1b2776a8cad72cf
It also looks like, by proxy they're using a lot of stuff from the TMobile themes platform framework: https://github.com/tmobile/themes-platform-frameworks-base/tree/44ffc93b4d3ab81bf4df569839e409bae0c8695a/tools/aapt
With APKtool, I also find that using 'sh -x $PREFIX/bin/[Command to run]' is very helpful for tracking down errors. IIRC, it also doesn't do well with spaces in paths either even normally running on a computer.
There also seems to be an issue with the '-e' option, even though it's mentioned in current APKtool sources. EDIT for additional information: This flag is a custom one meant to extend the command line length. According to https://github.com/iBotPeaches/Apktool/blob/50226e50c1a4e2c60a0547427bd9e637c2f35ef9/brut.apktool/apktool-lib/src/main/java/brut/androlib/AaptInvoker.java#L189 and https://github.com/iBotPeaches/Apktool/blob/50226e50c1a4e2c60a0547427bd9e637c2f35ef9/brut.apktool/apktool-lib/src/main/java/brut/androlib/AaptInvoker.java#L311
Also, if it isn't possible to get everything working as the tool expects by bundling APKtool inside of it, there is a workaround. APKtool has the ability to run AAPT from outside the binary with the '--aapt' flag pointing to it. So, we can modify the initial script to incorporate this by default. We'll need the libraries anyways, requiring installation of AAPT and AAPT2, unless static linking is allowed for the bins in the APKtool jar. As a side effect, this will also disable the '--forced-package-id' (and -e) option, which isn't needed unless you're building system and framework apps.
You will also need to use the flag '--use-aapt2' if you get the error 'First type is not attr! Aborted' since there is a possibility the app was originally built with AAPT2 and it contains invalid resource directory names for AAPT. This will use the internal AAPT2 binary within APKtool.
I've been using https://github.com/rendiix/termux-apktool and it works fine, maybe worth inspecting the aapt in there and what they did?
Is there a apktool version 2.9.3?
Problem description
What steps will reproduce the bug?
What is the expected behavior?
Builds apk successfully
System information
termux-info: