Apktool/INTERNAL.md

Releasing a new version.

The steps taken for slicing an official release of Apktool.

Ensuring proper license headers

Before we build a release, its a good practice to ensure all headers in source files contain proper licenses.

./gradlew licenseMain && ./gradlew licenseTest

If any license violations were found you can automatically fix them with either

./gradlew licenseFormatMain
./gradlew licenseFormatTest

Like described, one formats the src/main directory, while the other formats the src/test directory.

Tagging the release.

Inside build.gradle there are two lines.

apktoolversion_major
apktoolversion_minor

The major variable should be left unchanged. If done correctly, it will already be the version you are about to release. In this case 2.2.2. The minor variable should read SNAPSHOT as the 2.2.2 release up until this point was SNAPSHOT releases (Unofficial).

We need to remove the SNAPSHOT portion and leave the minor version blank. An example can be found here.

After we remove SNAPSHOT we need to make the version commit. Organization and following patterns is crucial here. This commit should have 1 change only - the change above. Now commit this change with the commit message - version bump (x.x.x).

At this point we now have the commit of the release, but we need to tag it using the following message.

git tag -a vx.x.x -m "changed version to vx.x.x"

For example for the 2.2.1 release.

git tag -a v2.2.1 -m "changed version to v2.2.1"

Building the binary.

In order to maintain a clean slate. Run gradlew clean to start from a clean slate. Now lets build the new version. We should not have any new commits since the tagged commit.

./gradlew build shadowJar proguard release

The build should tell you what version you are building and it should match the commits you made previously.

➜ Apktool git:(master) ./gradlew build shadowJar proguard release
Building RELEASE (master): 2.2.2

Testing the binary.

Now the release binary is built in the same location as all other builds. Run this version against some of the fixed bugs in this release. This is a simple test to ensure the build had no errors.

Copy the jar to any location to prep for uploading. The pattern we name the jars is

apktool_x.x.x.jar

Or in the case of the last release - apktool_2.2.1.jar

Once you have the jar in this form. Record the md5 hash of it. This can be done using md5sum.

This can be shown for the 2.2.2 release like so

➜  Desktop md5sum apktool_2.2.2.jar
1e6be08d3f9bb4b442bb85cf4e21f1c1  apktool_2.2.2.jar

Remember this hash. This is the local hash. This is our master hash. All others (Bitbucket, Backup) must match this.

Lets get uploading.

Lets make sure we actually pushed these release changes to the repo (Both Github & Bitbucket)

git push origin master
git push origin vx.x.x

git push bitbucket master
git push bitbucket vx.x.x

We upload the binaries into 3 places.

1. Bitbucket Downloads
2. Github Releases - Since 2.2.1.
3. Backup Mirror

Bitbucket

This one is pretty easy. Head to the URL attached to the hyperlink #1 above. There will be a "Add Files" button on the top right of the page. Upload the apktool_x.x.x.jar file.

After it is uploaded. Immediately visit the page and download it. Check the md5 for a match.

GitHub

This option will not work until the tag is pushed. You can head to this page to draft a new release. The Tag version dropdown will have the new tag. In this case v2.2.2.

Select that option and make the title Apktool vx.x.x. There will be a description field on this release. Hold tight, we link the release blog post in this field, but we can edit the release after the fact to add this.

Upload the binary apktool_x.x.x.jar and submit the release.

Backup Server

Access to this server is probably limited so this option may not be possible. SSH into the connortumbleson.com server with username connor. Head to public_html/apktool and upload the apktool_x.x.x.jar to it.

Now re-generate the md5 hashes for these files.

md5sum *.jar > md5.md5sum

Check the md5.md5sum file for the hashes. The file will look something like this.

6de3e097943c553da5db2e604bced332  apktool_1.4.10.jar
...
1e6be08d3f9bb4b442bb85cf4e21f1c1  apktool_2.2.2.jar

The hashes match so we have uploaded the binaries to all 3 locations. Time to get writing the release post.

We currently blog the releases on the Connor Tumbleson personal blog. This may change and the formatting of these release posts change over time.

Some recent releases for understanding the pattern can be found below.

1. 2.2.1
2. 2.2.0
3. 2.0.2
4. 2.0.0

So write the post. I tend to always include the following:

1. Image of release for featured image when reshared on socials.
2. Quick sentence or two for SEO to describe the meat of this release.
3. Commit count and total for this release with author names.
4. Changelog linking to the bugs that were fixed.
5. Download including the md5 hash.
6. Link dump to Project Site, GitHub, Bug Tracker and XDA Thread.

Now that you've written this post. We need to go post it in places and update places where Apktool is released.

XDA Thread

We have a thread on XDA Developers. This thread follows the same pattern for all releases.

When writing a response to the XDA thread we follow another pattern of release notes. These examples can be found below:

1. 2.2.2
2. 2.2.1
3. 2.0.0

Apktool Website

The Apktool project website has a few locations to update:

1. The homepage intro
2. The download link in header
3. The changelog page
4. The footer of homepage with history of releases.

The easiest way to describe this is to just link to a previous release.

Update Milestones

Now that we've released a version, we should hopefully have no more tickets in the release just published. If there are, move those tickets to the next milestone.

You can head to milestones to close the just released version and create another.

I tend to create the next release (In this case 2.2.3) with an ETA of 3 months in the future. This is just a guideline but helps me to release a new version every 3 months.

Social Spam

The final step is to send this release into the wild via some social posting. Head to the blog where the release post was and send that link to Twiter, Google and whatever else you use.

Relax and watch the bug tracker.

Building aapt binaries.

The steps taken for building our modified aapt binaries for apktool.

Getting the modified frameworks/base repo.

First step is using the platform_frameworks_base repo.

While previously unorganized, the repo now follows the branch naming convention depending on the current Android version. So apktool_7.1 corresponds to the 7.1 Android release. This branch should work for all android-7.1.x tags for AOSP.

We didn't follow this naming convention until Android 7.1. So don't go looking for older versions.

This repo has a variety of changes applied. These changes range from disabling optimizations to lessening the rules that aapt regularly has. We do this because apktool's job is to not fix apks, but rather keep them as close to the original as they were.

First we need the AOSP source

As cheesy as it is, just follow this downloading link in order to get the source downloaded. This is no small download, expect to use 40-60GB.

After that, you need to build AOSP via this documentation guide. Now we aren't building the entire AOSP package, the initial build is to just see if you are capable of building it.

We check out a certain tag. Currently we use android-7.1.2_r11.

Including our modified frameworks/base package.

There is probably a more automated way to do this, but for now just remove all the files in frameworks/base. Now you can clone the modified repo from first step into this directory.

Building the aapt binary.

The steps below are different per flavor and operating system. For cross compiling the Windows binary on Unix, we lose the ability to quickly build just the aapt binary. So the Windows procedure builds the entire Sdk.

Unix 32

1. source build/envsetup.sh
2. lunch sdk-eng
3. make OUT_DIR=out-x32 LOCAL_MULTILIB=32 USE_NINJA=false aapt
4. strip out-x32/host/linux-x86/bin/aapt

Unix 64

1. source build/envsetup.sh
2. lunch sdk-eng
3. make OUT_DIR=out-x64 LOCAL_MULTILIB=64 USE_NINJA=false aapt
4. strip out-x64/host/linux-x86/bin/aapt

Windows

1. source build/envsetup.sh
2. lunch sdk-eng
3. make PRODUCT-sdk-win_sdk USE_NINJA=false
4. strip out/host/windows-x86/bin/aapt.exe

Mac 32

1. source build/envsetup.sh
2. lunch sdk-eng
3. make OUT_DIR=out-x32 LOCAL_MULTILIB=32 USE_NINJA=false aapt

Mac 64

1. source build/envsetup.sh
2. lunch sdk-eng
3. make OUT_DIR=out-x64 LOCAL_MULTILIB=64 USE_NINJA=false aapt

Gradle Tips n Tricks

./gradlew build shadowJar proguard -x test

This skips the testing suite (which currently takes 2-4 minutes). Use this when making quick builds and save the testing suite before pushing to GitHub.

./gradlew build shadowJar proguard -Dtest.debug

This enables debugging on the test suite. This starts the debugger on port 5005 which you can connect with IntelliJ.

./gradlew :brut.apktool:apktool-lib:test ---tests "*BuildAndDecodeTest"

This runs the library project of Apktool, selecting a specific test to run. Comes in handy when writing a new test and only wanting to run that one. The asterisk is used to the full path to the test can be ignored. You can additionally match this with the debugging parameter to debug a specific test. This command can be found below.

./gradlew :brut.apktool:apktool-lib:test --tests "*BuildAndDecodeTest" -Dtest.debug