- when using aapt and debug flag, we remove the 'debuggable' attribute from AndroidManifest and aapt adds it back. (see issue 1621)
- when using aapt2 and debug flag, we add and set the value of 'debuggable' attribute ourselves.
* The empty test file needs to be STORED in the testapp, so put it on
the initial doNotCompress list.
* It needs to have a file extension that matches the NO_COMPRESS_PATTERN.
* assertNotSame tests for object equality, which doesn't work for String
comparisons.
We do not want one empty file to cause all files with that extension to
not be compressed, so we always put the full filename on the doNotCompress
list in this case.
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
This old issue prevented the package to be renamed from com.miui.core to miui, making it impossible to recompile, as all attributes are refefred to as miui:*/*. This fixes it permanently.
- 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
This non-standard behavior is rare, but quite annoying.
The solution is simple - replacing the reference value with the actual value from integers.xml, just like Apktool already does for versionName.
This non-standard behavior is rare, but quite annoying.
The solution is simple - replacing the reference value with the actual value from integers.xml, just like Apktool already does for versionName.
This Apktool issue has existed for a long time and is especially prevalent with ROMs with multiple frameworks.
The issue happens because Apktool treats reference values inside XMLs (like layouts) as raw text values, and doesn't resolve them during decompile time. This causes some values to be misformed, but more importantly, this causes values referencing to secondary frameworks to not be resolved with their source frameworks, which also means the framework ID won't be added to usesFramework.ids in apktool.yml, and that breaks recompiling.
The interesting thing is that reference values are actually being resolved when they are located in value resources, like styles, thus presenting an inconsistent behavior.
This simple mod eliminates the "rawValue" for reference values, and that forces the "value" (resource ID) to resolve against the respective frameworks, fixing misformed values in the process.
BEFORE:
I: Using Apktool 2.4.0-896569-SNAPSHOT on Notes.apk
I: Loading resource table...
I: Decoding Shared Library (miui), pkgId: 16
I: Decoding Shared Library (miui.system), pkgId: 18
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: bin\framework\1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Loading resource table from file: bin\framework\16.apk
I: Decoding Shared Library (androidhwext), pkgId: 15
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
Some comparisons before and after the fix:
https://i.imgur.com/2gTllT0.pnghttps://i.imgur.com/KzJUeQt.png
AFTER:
I: Using Apktool 2.4.0-896569-SNAPSHOT on Notes.apk
I: Loading resource table...
I: Decoding Shared Library (miui), pkgId: 16
I: Decoding Shared Library (miui.system), pkgId: 18
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: bin\framework\1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Loading resource table from file: bin\framework\16.apk
I: Decoding Shared Library (androidhwext), pkgId: 15
I: Loading resource table from file: bin\framework\18.apk
I: Decoding Shared Library (miui), pkgId: 16
I: Decoding Shared Library (android.miui), pkgId: 17
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
Somehow Google manages to compile MiuiSystemUI.apk (and a few other APKs I encountered) with a misformed pip_dismiss_scrim.9.png.
Either way, every time I encountered such 9.patch images, the missing lines always indicated a single full div or padding.
Apktool already fills missing padding lines, now it can also fill missing divs.
Starting with the version 28.0.3 of the Android SDK build tools,
the internal ids of the items of an array bag seems to have changed.
Because of those changes, array resources were no longer decoded correctly.
They were decoded as style resources.
Instead of using the id of the first item within a resource bag,
the name of the res type spec is now used to choose the correct
resource bag value to create.
Note: a list of "legal names" for resource types can be found in the source code of aapt2.
build: force windows onto the bash environment
build: update permission (+x) of clean-test file
build: "bat" instead of "exe" extension
build: attempt to support long-path names on windows
build: another attempt at long filepaths on windows
build: force +x on scripts prior to execution
build: exit with return code of last command
build: dump out current path
build: dump out current path - part 2
fix: remove 5 chars from path to drop down from 260 windows max path
build: correct gradlew.bat path and remove unneeded lines
fix: remove long path global configuration
fix: restore PATH setting for windows env
build: PATH resets between scripts, fix for windows
When I am decompiling an apk, I got this exception:
Exception in thread "main" java.lang.NullPointerException
at brut.androlib.res.data.ResResSpec.<init>(ResResSpec.java:42)
- Add a --no-crunch/-nc flag to apktool which gets passed through to aapt
- This allows apktool to make a byte-for-byte copy of resource files
- refs: #1232
- refs: #244
- Regular expressions are not the way to fix this. Too many situations
in smali where patterns won't work. Correct fix would be to hook dexlib
- split from aapt1/aapt2 (those that do building)
- tests that just test decode (no aapt) split
- categories for androlib/encdoers/util for various others
- 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
