Skip to content

Latest commit

 

History

History
317 lines (205 loc) · 12.7 KB

INTERNAL.md

File metadata and controls

317 lines (205 loc) · 12.7 KB
Raw

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 & sha256 hash of it. This can be done using md5sum and sha256sum on unix systems.

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

➜  Desktop sha256sum apktool-2.2.2.jar
1f1f186edcc09b8677bc1037f3f812dff89077187b24c8558ca2a89186ea3251  apktool-2.2.2.jar

Remember these hashes. These are the local hashes. These are our master hashes. All others (Bitbucket, Backup) must match these. If they do not - they are invalid.

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/sha256 hashes for these files.

md5sum *.jar > md5.md5sum
sha256 *.jar > sha256.shasum

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

Additionally check the sha256.shasum file for the hashes. This file will look almost identical to the above except for containing sha256 hashes.

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

For obtaining commit authors and counts. The following command does the legwork:

git shortlog -s -n --all --no-merges --since="05 Sept 2018"

Obviously replacing the date with the release date of the last version.

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/sha256 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 Twitter, 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. The current version is apktool-9.0.0, which corresponds to the Android 9.0 (Pie) release.

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 80-100GB.

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 or branch. Currently we use

  • aapt2 - master.
  • aapt1 - master.

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 aapt1 (Legacy) 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

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

Windows

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

Mac

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

32/64 bit binaries will be built for Unix and Windows.

Building the aapt2 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 aapt2 binary. So the Windows procedure builds the entire Sdk.

Unix

  1. make LOCAL_MULTILIB=64 USE_NINJA=false aapt2
  2. strip out/host/linux-x86/bin/aapt2
  3. strip out/host/linux-x86/bin/aapt2_64

Windows

  1. make PRODUCT-sdk-win_sdk USE_NINJA=false
  2. strip out/host/windows-x86/bin/aapt2.exe
  3. strip out/host/windows-x86/bin/aapt2_64.exe

Mac

  1. export ANDROID_JAVA_HOME=/Path/To/Jdk
  2. source build/envsetup.sh
  3. make LOCAL_MULTILIB=64 USE_NINJA=false aapt2
  4. strip out/host/darwin-x86/bin/aapt2_64

Confirming aapt/aapt2 builds are static

There are some issues with some dependencies (namely libc++) in which they are built in the shared state. This is alright in the scope and context of AOSP/Android Studio, but once you leave those two behind and start using aapt on its own, you encounter some issues. The key is to force libc++ to be built statically which takes some tweaks with the AOSP build systems as that dependency isn't standard like libz and others.

You can test the finalized project using tools like ldd (unix) and otool -L (mac) for testing the binaries looking for shared dependencies.

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 test --debug-jvm

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" --debug-jvm