ARM64 and ARMv7 support

[oSumAtrIX]

Apktool currently packages no binaries for ARM. The reason for this is probably that AAPT is unsupported on these architectures. An open-source project has managed to get it to work on ARM, both ARM64 and ARMv7 with Apktool: https://github.com/revanced/aapt2

The repository clones the submodules from official sources, applies some patches to it and builds the binaries.
It is not a standard build system but could act as a PoC for Apktool. The specific patch that fixed ARMv7 was ReVanced/aapt2@8285e73. This is nowhere an official fix but a workaround that has fixed AAPT2 on ARMv7. Compiling for ARMv64 was achieved vi the other patches. The submodules are based on slightly older versions than the latest one, so some updates may be wanted.

[iBotPeaches]

This does look enticing especially how it appears to cut down on the massive resources needed when you compile aapt/aapt2 from pure AOSP. I'd always hoped the group feature of repo would allow me to pull down "tools" for a smaller download, but alas the tool group does not mean consumer grade tools, but build chain.

My fear is this looks like a little complex repository including tons of chunks I'm not familiar with at all. As new AOSP versions come out - I'd feel at present not much confidence in the ability to move this forward. Either way though, I'm pulling it down to explore/learn.

[oSumAtrIX]

Hi, your concerns are justified. The repo is composed by very little bits of knowledge in this field so it must be taken with a grain of salt. A workflow is present as a point of reference to build aapt2 for all architectures. The repo itself is "hacked" together though and may need some proper attention, but I hope it is somewhat useful to you.

On a related note, there are emerging solutions to aapt2 in pure Java, both officially by Android and unofficial. Android has a library that can read and write ARSC files in a low level manner according to spec.

https://github.com/REAndroid/ARSCLib on the other hand can do the same, but has some high level APIs that seem extremely suitable for ApkTool. It supports the split architecture as well. The high level APIs allow to easily decompile an APKs resources and recompile them, all in pure Java and very quickly (10s in total). The user has also created a CLI frontend for it to easily decompile and build the APK. Currently he is working on adding support for dex/smali by rewriting smali from scratch, also in arsclib. If ApkTool manages to make use of this library it means:

A. No more resource decoding and compiling bugs
B. No more bloated platform specific AAPT binaries
C. Pure Java
D. Fast and efficient decoding and compiling of resources
E. Split APK support

If you library can be used in ApkTool this means, you can get rid of a big portion of code on ApkTool, thus reduce the amount of maintenance cost and offshore it to the maintainers of the library, originally contribute to it or fork if needed with minimal changes.

All in all it's something worth to research into as it seems to only come with positive side effects that would solve the biggest issues with ApkTool.

[iBotPeaches]

I do like watching ARSCLib evolve, but honestly if I ripped out internals of Apktool for the features (+ future) of ARSCLib of source + resource - I'd argue Apktool doesn't deserve to exist anymore as it would be the CLI for ARSCLib, much like ApkEditor is.

The rewritten aapt(2) support is also enticing if you scope to just that, but personally with ARSCLib with little tests - I need to see how another year plays out.

Also who will build support to reverse apkeditor "protect" mode if Apktool just embeds arsclib :)

[oSumAtrIX]

Hi. Protect abuses side effects that break decoding according to spec. Both the current ApkTool implementation and arsclib follow the spec for decompilation and would break by protect. So it doesn't matter if you use arsclib or not.

I see the maturity problem though, so time will tell. After all arsclib is just maintained by an individual, it is not something you would want to rely on necessarily.