13 KiB
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.
- Bitbucket Downloads
- Github Releases - Since
2.2.1
. - 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.
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:
- Image of release for featured image when reshared on socials.
- Quick sentence or two for SEO to describe the meat of this release.
- Commit count and total for this release with author names.
- Changelog linking to the bugs that were fixed.
- Download including the md5/sha256 hash.
- 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:
Apktool Website
The Apktool project website has a few locations to update:
- The homepage intro
- The download link in header
- The changelog page
- 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 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 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
source build/envsetup.sh
lunch sdk-eng
make LOCAL_MULTILIB=64 USE_NINJA=false aapt
strip out/host/linux-x86/bin/aapt
strip out/host/linux-x86/bin/aapt_64
Windows
source build/envsetup.sh
lunch sdk-eng
make LOCAL_MULTILIB=64 USE_NINJA=false aapt
strip out/host/windows-x86/bin/aapt.exe
strip out/host/windows-x86/bin/aapt_64.exe
Mac
source build/envsetup.sh
lunch sdk-eng
make LOCAL_MULTILIB=64 USE_NINJA=false aapt
strip out/host/darwin-x86/bin/aapt_64
32/64 bit binaries will be built for Unix and Mac.
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
make LOCAL_MULTILIB=64 USE_NINJA=false aapt2
strip out/host/linux-x86/bin/aapt2
strip out/host/linux-x86/bin/aapt2_64
Windows
make PRODUCT-sdk-win_sdk USE_NINJA=false
strip out/host/windows-x86/bin/aapt2.exe
strip out/host/windows-x86/bin/aapt2_64.exe
Mac
export ANDROID_JAVA_HOME=/Path/To/Jdk
source build/envsetup.sh
make LOCAL_MULTILIB=64 USE_NINJA=false aapt2
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 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