1.base on AOSP's frameworks/base/tools/aapt/Package.cpp: NO_COMPRESS_PATTERN = Pattern.compile("(jpg|jpeg|png|gif|wav|mp2|mp3|ogg|aac|mpg|mpeg|mid|midi|smf|jet|rtttl|imy|xmf|mp4|" +
"m4a|m4v|3gp|3gpp|3g2|3gpp2|amr|awb|wma|wmv|webm|mkv)$"); specifically this rule include 9patch files.
2.file has not ext
3.the compressive type is store
warning:
even if there are the same type of files, they are compressive type may different, just like this example:
-rw---- 1.0 fat 8343 b- 0% stor 80-Jan-01 08:00 assets/resources/assets/effect/common/ctp_trail15_1_tex.unity3d
-rw---- 1.0 fat 11526 b- 0% stor 80-Jan-01 08:00 assets/resources/assets/effect/common/ctp_trail15_tex.unity3d
-rw---- 2.0 fat 2483 bl 19% defN 80-Jan-01 08:00 assets/resources/assets/effect/common/cw_310300_cylq_ql01_mat.unity3d
-rw---- 2.0 fat 9467 bl 17% defN 80-Jan-01 08:00 assets/resources/assets/effect/common/cw_310300_cylq_ql03_fbx.unity3d
ctp_trail15_1_tex.unity3d and ctp_trail15_tex.unity3d are uncompressed, but cw_310300_cylq_ql01_mat.unity3d and cw_310300_cylq_ql03_fbx.unity3d are compressed.
That is why I modified recordUncompressedFiles Method.
Windows has its limits, even Windows 10, at least on older versions before the max path length restriction was removed.
Because apktool failed to recognize the .9.png extension as a variety of the .png extension, those .9.png files were piling up in apktool.yml and then passed to aapt, which would fail to run on Windows because of an immense command length.
This fix makes a special exception for the .png exception and will allow the .9.png one to pass as another .png extension.
Before: http://dpaste.com/2BC3RRB
After: http://dpaste.com/177CVZQ
- add APK file containing a simple app that tries to use coroutines every 2 seconds, and would fail with earlier versions of APKTool
- add unit test for decoding the app
- add unit test for building a decoded app
- add APK file containing a simple app that tries to use coroutines every 2 seconds, and would fail with earlier versions of APKTool
- add unit test for decoding the app
- we destroy the "compile" stage item after a link, but keep the pending directory
- apktool then cannot complete link stage
- if aapt2 is used, lie to system and re-process
- todo: rethink this
When apktool creates a DexBuilder class, it creates it without specifying a minimum api level. This causes the DexBuilder class to assume api level 20 by default. This is not ideal since in some cases, the concrete minimum api level is required.
One such case is in smali's DexWriter class which implements a workaround for a bug in Dalvik that was fixed in Android 4.2 (https://code.google.com/p/android/issues/detail?id=35304) that causes apps that call the Method.getParameterAnnotations api to crash in some cases (see bug report for more details). The workaround that smali implements is only triggered if the minimum api level is below 17 (Android 4.2). But since apktool effectively sets the minimum api level to 20, this code is never triggered causing apktool to create apk files that crash on devices below Android 4.2.
This change passes the minimum api level to the smali library.
