Apktool 2.0.0 Beta 7 Released
This is the first public release of Apktool 2, a major change over the previous Apktool 1.5.2.
I'd like to get one version public before we release 2.0 final. With that out of the way, let me say "Apktool 2 requires Java 7". We used the FileSystems of NIO2 along with the FileWalker. Unfortunately these changes cannot be built to JRE6 compatibility due to the NIO2 library. Our hope is to convert the remaining JRE7 back to JRE6 before the final release of Apktool2.
This version has been under development for almost a year and there are a couple of key people I'd like to thank for the creation of this product.
- Ryszard Wiśniewski (brut.alll)
- Original creator of Apktool and made a brief reapperance to fix some long-running Apktool bugs.
- Dmitry Skiba
- Creator of AXmlParser class that is a major component of Apktool
- Ben Gruver (JesusFreke)
- Smali creator, basically 1/2 of Apktool.
Key Features
Some of the key features in 2.0, I'd like to cover briefly.- AAPT binary are included to give us finer grained control over build procedure.
- Redone usage output / parameter use
- Smali Debugging
- Smali/baksmali 2.0
- Unknown file handling
- Bug fixes
Changelog
- Updated to smali/baksmali to v2.0.0
- Updated to Gradle 1.8
- Fixed (issue #8) - Correctly uses -c to retain original manifest and META-INF. (Thanks M1cha)
- Fixed (issue #63) - Correctly handles apk's that have unknown files outside of the standard aapt allowed resources.
- Fixed (issue #202) - Includes modified aapt to force package id on build. (Thanks M1cha)
- Fixed (issue #403) - Uses new usage output to cleanup organization of features.
- Fixed (issue #359) - Correctly handles malformed 9patch images. (Thanks Felipe Richards)
- Fixed (issue #401) - Uses versionInfo meta to correctly parse versionName and versionCode.
- Fixed (issue #440) - Include aapt binaries within Apktool to have closer control over build.
- Fixed (issue #439) - Correctly handles apk's that have have the general access bit enabled for encryption.
- Fixed (issue #339) - Re-enables debug mode ( -d flag) to fix smali debugging. (Thanks Ryszard)
- Fixed (issue #177) - Adapted output of smali to make breakpoint setting easier in different IDEs. (Thanks Ryszard)
- Fixed (issue #391) - Fixes characters (& and <) from being double escaped in <item>'s of arrays.xml
- Fixed (issue #260) - Fixes "Multiple substitution" errors with positional and exactly 1 non-positional argument.
- Fixed (issue #427) - Correctly handles `--frame-path` on [b]uild
- Fixed (issue #396) - Correctly handle android:debuggable while in debug mode.
- Fixed (issue #340) - Fixed superclass errors on debug mode.
- Fixed (issue #458) - Fixed pkg id not being correctly set in framework files.
- Fixed (issue #469) - Added (-m / --match-original)
- Fixed (issue #326) - Fixed PNG increasing brightness on build (Thanks Christiaan)
- Fixed (issue #448) - Merge smali2 into Apktool
- Fixed (issue #496) - Fixes Windows builds caused by java.nio problems
- Fixed (issue #510) - Any error output is sent stderr instead of stdout
- Fixed (issue #426) - Filename too long (JesusFreke)
- Fixed (issue #524) - INSTALL_FAILED_DEXOPT fix (JesusFreke)
- Fixed (issue #473) - multiple package frameworks are treated correctly.
- Added output to list Apktool version to help debugging.
- Updated known bytes for configurations to 38 (from addition of layout direction)
- Fixed NPE when handling odex apks even with --no-src specified. (Thanks Rodrigo Chiossi)
A currently updating Wiki page regarding 2.0 can be found here: https://code.google.com/p/android-apktool/wiki/MigrationInstructions
FAQ
Q: Why are you so slow at developing? A: Full time student + part time job = no time.Q: Why did you choose to use JRE7?
A: To be honest, I didn't even know the powerful features of JRE7 until Ryszard committed a JRE7 block of code. I started using it without thinking of the complications with doing so.
Q: Isn't including AAPT a bad idea as Apktool needs an update every AAPT update?
A: It's becoming more and more difficult to support recompiling of all APKs. AAPT is to blame for most of this. By including our own and reverting some patches we maintain full control over the build procedure (also adding some features of our own).
Q: What if we use Apktool for analysis and don't care about recompilation?
A: -m / --match-original on decode. All functions that mess with the APK are not run. The APK is simply decoded and disassembled.
Q: Why won't this company (Huawei, ZTE, other) / ROM not work on Apktool?
A: Changing the qualifiers of a ROM requires two changes. One in AAPT and another in the framework. These changes change the size of the ResConfig headers. (Currently we are 38 bytes as of 4.3). These changes don't conform to standards and adding them into Apktool would cause problems on future Android versions and create a very hacky and ugly Apktool. Feel free to "fork" and create specialized Apktool versions for these ROMs and Companies, but they cannot be included in the main Apktool for risk of damaging the greater population.
Q: but you include MIUI support? you lied to us!!
A: While I'm not happy that MIUI modified the resources. They didn't add a new category, they added their changes to an already existing qualifier category and choose ID values that were 10+ off the previous. So even 8 more Android AOSP releases wouldn't conflict with their change. Also because MIUI has a huge porting community where Apktool is required, it only makes sense to include this change.
Q: I have an idea!
A: IRC Freenode / #apktool
Q: I have a bug!
A: https://code.google.com/p/android-apktool/issues/list (Search first!)
Q: I need support!
A: http://forum.xda-developers.com/showthread.php?t=1755243 (Read thread rules)
Q: I want to help code Apktool!
A: https://github.com/iBotPeaches/Apktool/tree/wip-2.0
Download
- Apktool 2.0.0b7
- md5: 1e43099bbae27b78bc51b2b4926c8ee9