Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of external aapt for building apk #1774

Closed
bingqiao opened this Issue Apr 18, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@bingqiao
Copy link
Contributor

bingqiao commented Apr 18, 2018

I have apktool embedded in a Spring Boot executable jar so that some extra processing is done before apktool is called to rebuild an apk.

Sometimes apktool fails to use the internal aapt (still investigating) and falls back to using the external one (by setting "aapt" in the command array instead of absolute path to the temp file generated from the internal aapt). The external aapt however doesn't work. I tried various aapt binaries from different versions of built-tools but none worked.

I went through this thread #1520 and believe I'm getting the same error "First type is not attr!".

I understand the internal aapt is patched and would like some clarification on whether non-patched aapt is no longer supported? Or if this is a temporary fix. But either way, it could be helpful to mention this in the documentation regarding the use of --aapt option.

Many thanks

@iBotPeaches

This comment has been minimized.

Copy link
Owner

iBotPeaches commented Apr 18, 2018

Non-patched app is supported, but you are working with an application built in aapt2 and attempting to build with aapt1 (external). That is the reason you are getting that "first type is not attr" issue. There is nothing apktool can do there with a non-patched aapt1 binary in the context of a decoded aapt2 application.

There is 1 solution. Take the patched aapt for your system and add it to the system PATH, so that executing "aapt" runs the prebuilt patched binary. That should resolve your issue.

I'll leave this open until I read the docs about that parameter and check if it needs some additional information.

@iBotPeaches

This comment has been minimized.

Copy link
Owner

iBotPeaches commented Apr 18, 2018

Updated docs: 36e7f74

@bingqiao

This comment has been minimized.

Copy link
Contributor Author

bingqiao commented Apr 18, 2018

Thanks for the explanation. The docs for --use-aapt2 seems wrong (https://ibotpeaches.github.io/Apktool/documentation/).

Does apktool choose the right version of aapt when rebuilding the apk (it doesn't look so in the source code and I see calls to aapt1Package in verbose mode)? Does this option need (have) to be used for both decoding and rebuilding of an apk that was built using aapt2? If I rebuild my apk (built by gradle plugin 3) without using external aapt, it works. But would you not recommend doing this?

In addition, "aapt2 version" gives a text slightly different prior to android sdk 26.0.2.
"Android Asset Packaging Tool (aapt) 2.16"
There is no colon in that text so the following check fails:
if (version.startsWith("Android Asset Packaging Tool (aapt) 2:")) { return 2; } else if (version.startsWith("Android Asset Packaging Tool, v0.")) { return 1; }

Thank you

@iBotPeaches

This comment has been minimized.

Copy link
Owner

iBotPeaches commented Apr 18, 2018

Thanks, I'll add the version check for older aapt2 versions. I haven't found a reliable way to determine an application built in aapt2, so the build system cannot determine which one to use.

@iBotPeaches iBotPeaches reopened this Apr 18, 2018

@iBotPeaches

This comment has been minimized.

Copy link
Owner

iBotPeaches commented Apr 19, 2018

Okay patched with version detection - 3a33bfc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.