mirror of
https://github.com/revanced/Apktool.git
synced 2024-09-06 06:25:32 +02:00
* build: update aapt/aapt2 with win/linux binaries * docs: add note for specific aapt tag * test: test for grammatical inflection * build: update aapt/aapt2 with mac binaries * build: update aapt/aapt2 with mac binaries (static libstl)
339 lines
13 KiB
Markdown
339 lines
13 KiB
Markdown
# Releasing a new version.
|
|
|
|
The steps taken for slicing an official release of Apktool.
|
|
|
|
### Ensuring proper license headers
|
|
|
|
_Currently broken after movement to kotlin dsl._
|
|
|
|
### 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](https://github.com/iBotPeaches/Apktool/commit/96b70d0be7513c5a1e5d3a3b9a75e4e2b076ad79).
|
|
|
|
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"
|
|
|
|
### Prepare for publishing.
|
|
|
|
New to Apktool is publishing releases to Maven, so plugin authors can directly integrate. You
|
|
need a `gradle.properties` file in root with the structure:
|
|
|
|
```
|
|
signing.keyId={gpgKeyId}
|
|
signing.password={gpgPassphrase}
|
|
signing.secretKeyRingFile={gpgSecretKingRingLocation}
|
|
|
|
ossrhUsername={sonatypeUsername}
|
|
ossrhPassword={sonatypePassword}
|
|
```
|
|
|
|
Release with maven with `./gradlew build shadowJar release publish`.
|
|
|
|
### Building the binary.
|
|
|
|
In order to maintain a clean slate. Run `gradlew clean` to start from a clean slate. Now lets build
|
|
the new binary 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](https://bitbucket.org/iBotPeaches/apktool/downloads)
|
|
2. [Github Releases](https://github.com/iBotPeaches/Apktool/releases) - Since `2.2.1`.
|
|
3. [Backup Mirror](https://connortumbleson.com/apktool/)
|
|
4. [Sonatype (Maven)](https://oss.sonatype.org)
|
|
|
|
#### 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](https://github.com/iBotPeaches/Apktool/releases/new)
|
|
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 are good with the backup server.
|
|
|
|
#### Sonatype
|
|
|
|
You'll want to log in and view the Staging repositories and confirm you see the recently made build. You'll want to:
|
|
|
|
* Close it (Wait for audit report email)
|
|
* Release it (Drop the staging repository)
|
|
* Wait 20min - 2 hours for it to appear [here](https://mvnrepository.com/artifact/org.apktool/apktool-lib)
|
|
|
|
With those done, time to get writing the release post.
|
|
|
|
We currently blog the releases on the [Connor Tumbleson personal blog](https://connortumbleson.com/).
|
|
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](https://connortumbleson.com/2016/10/18/apktool-v2-2-1-released/)
|
|
2. [2.2.0](https://connortumbleson.com/2016/08/07/apktool-v2-2-0-released/)
|
|
3. [2.0.2](https://connortumbleson.com/2015/10/12/apktool-v2-0-2-released/)
|
|
4. [2.0.0](https://connortumbleson.com/2015/04/20/apktool-v2-0-0-released/)
|
|
|
|
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](https://forum.xda-developers.com/showthread.php?t=1755243) 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](https://forum.xda-developers.com/showpost.php?p=70687935&postcount=4635)
|
|
2. [2.2.1](http://forum.xda-developers.com/showpost.php?p=69188139&postcount=4478)
|
|
3. [2.0.0](http://forum.xda-developers.com/showpost.php?p=60255972&postcount=3063)
|
|
|
|
### Apktool Website
|
|
|
|
The Apktool project website has a few locations to update:
|
|
|
|
1. The homepage intro
|
|
2. The download link in header
|
|
3. Migrating `unreleased.mx` to a new blog post.
|
|
|
|
The easiest way to describe this is to just link to a [previous release](https://github.com/iBotPeaches/Apktool/pull/3146/files).
|
|
|
|
### 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](https://github.com/iBotPeaches/Apktool/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](https://github.com/iBotPeaches/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](https://source.android.com/source/downloading.html) link in order
|
|
to get the source downloaded. This is no small download, expect to use 150-250GB.
|
|
|
|
Some optimization techniques for a smaller clone:
|
|
|
|
* `~/bin/repo init -u https://android.googlesource.com/platform/manifest -b master --partial-clone` - Partial clone
|
|
* `repo sync -c` - Only current branch
|
|
|
|
After that, you need to build AOSP via this [documentation](https://source.android.com/source/building.html) 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 - `android-14.0.0_r2`.
|
|
* aapt1 - `android-14.0.0_r2`.
|
|
|
|
### Including our modified `frameworks/base` package.
|
|
|
|
There is probably a more automated way to do this, but for now:
|
|
|
|
1. `cd frameworks/base`
|
|
2. `git remote add origin git@github.com:iBotPeaches/platform_frameworks_base.git`
|
|
3. `git fetch origin -v`
|
|
4. `git checkout origin/master`
|
|
|
|
#### Mac Patch
|
|
|
|
Normally you'll be building this on a recent Mac OS that isn't supported. You'll want to follow these steps:
|
|
|
|
1. `vim build/soong/cc/config/darwin_host.go`
|
|
2. Find `darwinSupportedSdkVersions` array.
|
|
3. Add number that corresponds to output of: `find /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs -iname "*.sdk"`
|
|
|
|
### Building the aapt1 (Legacy) binary.
|
|
|
|
The steps below are different per flavor and operating system.
|
|
|
|
#### Linux / Windows
|
|
1. `source build/envsetup.sh`
|
|
2. `lunch sdk-eng`
|
|
3. `m aapt`
|
|
4. `strip out/host/linux-x86/bin/aapt`
|
|
5. `strip out/host/linux-x86/bin/aapt_64`
|
|
6. `strip out/host/windows-x86/bin/aapt.exe`
|
|
7. `strip out/host/windows-x86/bin/aapt_64.exe`
|
|
|
|
#### Mac
|
|
1. `source build/envsetup.sh`
|
|
2. `m aapt`
|
|
3. `strip out/host/darwin-x86/bin/aapt_64`
|
|
|
|
32/64 bit binaries will be built for Linux and Windows.
|
|
|
|
### Building the aapt2 binary.
|
|
|
|
The steps below are different per flavor and operating system.
|
|
|
|
#### Linux / Windows
|
|
1. `m aapt2`
|
|
2. `strip out/host/linux-x86/bin/aapt2`
|
|
3. `strip out/host/linux-x86/bin/aapt2_64`
|
|
4. `strip out/host/windows-x86/bin/aapt2.exe`
|
|
5. `strip out/host/windows-x86/bin/aapt2_64.exe`
|
|
|
|
#### Mac
|
|
1. `export ANDROID_JAVA_HOME=/Path/To/Jdk`
|
|
2. `source build/envsetup.sh`
|
|
3. `m 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
|