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.
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
- 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
It is possible to create a an AndroidStudio project that uses the following
nonsense settings:
defaultConfig {
minSdkVersion 15
maxSdkVersion 19
targetSdkVersion 25
}
The application is successfully built by Android Studio, and the APK
works when installed on the relevant devices, however the app cannot
be re-built with Apktool afterwards.
This patch works around the problem by explicitly setting the
targetSdkVersion to the max of the maxSdkVersion and min of the minSdkVersion
only if these are specified.
Some APKs' arsc has additional payload data (like TYPE 8 chunks and/or padding) in the TYPE chunk. After the ARSCDecoder read such kind of chunk, it acts erratically. Most of the time, it just stops parsing the ARSC, therefore, some resources are not decoded because they are not in the apktool's resources' spec table.
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.
This replaces the custom LittleEndianDataInputStream with
guava's implementation. To do this, I had to fix ExtDataInput
to better handle the case where skipBytes doesn't skip all the
bytes (the tests failed without this, and succeed with it). This
appears to be the main difference between the two implementations.
Guava's implementation is preferred because it is already a
dependency and because its license is clearer (the previous
implementation had a vague "public domain" comment in the thread
which may not be legally sufficient).
Fixes#1166
When reference string is used for versionName in AndroidManifest.xml,
fetch the literal value of the referened string in the output apk.
This patch doesnt modify the original apk.
* Drop LEDataInputStream (which had a restrictive license)
with LittleEndianDataInputStream, which is public domain.
A minor change has been made to the new class, removing
the interitance of InputStream.
This makes it's behaviour indentical to the previous implementation,
and unit tests pass.
Fixes#1166
Source: http://www.peterfranza.com/2008/09/26/little-endian-input-stream/
Reduces the time it takes to parse the Android framework by ~50%.
The synthesized name now has no leading zeroes, but this doesn't appear to matter since the numeric part of the name isn't used anywhere.
Handles large int values in AndroidManifest.xml, by prefixing
with `\ ` which aapt treats a string. This prevents truncation
from overflow.
Superseeds PR#1007 - thanks to gio73 for initial research &
MarchMil for continued investigation.
Prior to this change, APKs usually went Package -> TypeSpec -> Config (all) -> Entries.
Reading all configs under that TypeSpec. Now we have packages that go
Package -> TypeSpec -> Config (single) -> Entries.
So we have to read this correctly to make sure we can correctly decode sparse and packed
Resource tables.
- Moves Config --> Type
- Moves Type -> TypeSpec
- ResType -> ResTypeSpec
- ResConfig -> ResType
This is to match AOSP and ease the transitions/updates of new AOSP drops
- Frameworks between froyo and honeycomb have mnc001, etc
- A size check of ResConfig header for less than 32 (honeycomb) uses old decode method
- Greater than 32 bytes moves to new decode method of mnc# vs mnc###
This is the list of files (resources, assets, etc) that are stored in
the .apk uncompressed.
For apps that use AssetFileDescriptor.openFd(), the adding compression
will break the call.
Maintains support for the resourcesAreCompressed key, but no longer
records it when decompiling (it instead records resources.arsc in the
doNotCompress list).
Previously in 4882396163, strings that
resembled a filepath (ie res/foo/file), would be assigned to a
ResFileValue, which when attempted to be casted to ResScalarValue would
error out.
Attempting to check the filesystem for such files, slowed apktool's
execution majorly. In order to prevent this, the ClassCastException
and other checks related to checking ResFileValue when type is string
was added.
This allows bogus strings such as (res/foo/file) to be added, but the
exception is caught and allows decoding to continues. Fixes#921.
Since all frameworks are decoded the same via readPackage(), reading
a framework that was a sharedLibrary would throw the sharedLibrary
flag for the apk. Since packageName isn't set until after the first
decode, we check the values to make sure we only set this variable on
the first apk decoded. Refs #936
