filename or extension is too long when recompile apk #1272
Comments
|
A couple things going on here. If a file has no extension and it needs to be inserted in an unpacked mode, then we record the extension so we can skip compression on such files. However, these files have no extension so we record the file path. Then since Unity has a ton of these files, the command to execute just gets longer and longer and thus exceeds the limit of Windows. There is no easy fix for this yet. We either have to stage the commands, but that is hard because aapt executes once and done. Use Unix if you need an immediate fix. |
|
Copying some comments I made in here
|
|
Same issue with unity. |
|
We just ran into this issue. What’s the likelihood of this being fixed in the next couple of months? |
|
Hey @mkilling, Since you've helped out in some tickets here before, I'll take a look tomorrow to see if this is feasible to patch into aapt1 or aapt2 without rewriting too much of apktool. I'm not aware of a way in Java to reliable determine the max command length so I'll just have to find the shortest minimum and lock it at that. |
|
Hey Connor, did you find something out? |
|
The command is being executed by cmd and cmd has an 8kb limit on the command line size. There is no way for this to work with the given command. Either the execution needs to be driven from apktool (not through cmd.exe) or the assets (there are 800+ in your command line) need to be collapsed into a file and passed as an argument to the program. |
|
I'm not aware of the ability/feature for myself to pass a file of the arguments to aapt. Unless this is a feature/ability of basic command lines. I just finished up a large feature (aapt2), so looping back to this today/tomorrow. My goal is to tweak the aapt1 stage (and probably aapt2) to do things in steps. aapt1 has the The problem I have now though is I've been sending relative filepaths to the aapt binary for extensions that are sometimes deflated or stored. This builds a massive tree like The problem being, the files are added to the application its just the command that dictates extensions or filepaths that should not be compressed that is too long, thus causing these errors. I'm not sure how these applications are building initially if one extension is sometimes deflated and stored in the asset folder, but that doesn't matter. If I'll update in here shortly on that research. |
|
In my u8sdk build tool , I removed unknown resources items under [doNotCompress] node in apktool.yml to avoid this issue. And provided a custom way to [compress or not compress] these unknown resources. |
|
Sorry for bugging you with this - did you find out more? We’re currently trying to decide whether we want to start looking into this issue ourselves. |
|
I did some research on aapt1. Which is as follows.
This causes Unity to crash because it expects them in the STORED format.
So we cannot use
This correctly stores them in the final application: So we need to read the file length of the AAPT2 research is unknown at current time with this issue. |
|
Hey Connor @iBotPeaches |
|
@stone-SJH, If the issue is tied to AAPT2, then i don't believe that there is a workaround for it but, @iBotPeaches can only state this for sure. :-) |
|
Hey @iBotPeaches, do you have any plans to fix this? |
|
The plan is above. Haven't gotten around to it. |
|
@Octolus Correct. There is no planned fix for this anymore. Due to reasons above, I cannot fix this without breaking Apktool. |
|
Isn't the 8K limit specific to cmd.exe? Why not just use PowerShell? |
|
It appears that this behavior has become more common in v2.3.3 and later. It seems that now 9-Patch (.9.png) files are being listed in the doNotCompress section in apktool.yaml even though there is a general exclusion for 'png'. As a result the aapt command for apks that include the app-compat support libraries is much longer than it used to be. I think the specific issues raised in #1935, #1938, #1953, and #1996 would be resolved by fixing the redundant .9.png arguments. I believe this was introduced by this commit 061ddb8 As an aside, the Windows CreateProcess character limit is 32,768. The 8192 character limit only applies to the cmd.exe shell as far as I can tell. |
|
Thanks for the details. Perhaps we can adjust the logic to handle double extension files, though I believe we patched this and broke other things due to general exclusions of file extensions being stored in applications differently. IE a png being STORED and DEFLATED in different portions of the application. |
Coming back to this suggestion: It appears to be true that aapt doesn't support that so far. But since apktool ships with a custom aapt binary anyway, it should be relatively easy to add a new command line argument, that reads these parameters from a file. Correct? That would fix the issue of the command line being too long and it shouldn't break anything else, since we're not really changing how the files are processed by aapt. @iBotPeaches Do you think that would work, or do you see any issues with this idea? I'm happy to work on a PR once I managed to check out the AOSP sources... |
|
You may find the following link helpful regarding this topic... https://ibotpeaches.github.io/Apktool/documentation/ It covers the way to specify the AAPT/AAPT2 commands manually. Good Luck! :-) ~Ibuprophen |
Information
apktool -version) - 2.1.1Stacktrace/Logcat
1、I used [apktool d] to decompile the apk with the latest version(2.1.1)
2、then change nothing, just to use [apktool b] to recompile it, but failed with the upper error.
3、the apk you can download from here:test.apk
Thanks!!!
The text was updated successfully, but these errors were encountered: