This makes a few changes which allow for users to patch APK files via Docker.
Suggested in: #528
Notable Changes
Dockerfile was added
The Docker file first creates a container with all the required dependencies and packages needed to download the tools (aapt, apktool, etc).
It then downloads the official android command line tools and downloads all the required tools from the sdkmanager.
Since the command line tools and build tools contain a bunch of extra binaries, the Dockerfile creates a new container and only copies in the required binaries to reduce overall container size.
Notes: While the user can build the entire thing themselves, it would probably be better to build the final image and upload that to the hub so users can pull it directly.
The pypi objection package should be updated to reflect the changes as the docker container will use pip to install the latest version of objection.
Make command was added to build docker. --platform linux/amd64 was added to ensure it also works on Mac silicon
Set objection to use aapt2 by default
The step that runs empty-framework-dir was removed. This was causing a lot of issues and preventing apktool from rebuilding the apk. This should only be required if the user is using a v1 version of apktool and never ran this command after updating to v2. If there's another use case for this that im not aware of, I can add it back.
While there is ways to use adb from within the container to query the device for architecture, I felt like it could possibly introduce a bunch of other issues and add to the complexity. For this reason, the architecture type must be passed in along with the docker run command. Adb is still on the final image to make it easier to add that feature later on.
Other changes are just overall formatting, variable names, and other small fixes. (I have auto format enabled, can disable it and change formatting back if you want)
Patching APK
Once the container is pulled/built, patching the APK should be straight forward.
docker run --rm -it --platform linux/amd64 -v <local_dir_with_apk>:/app/build objection:latest "objection patchapk -s /app/build/<APK_name>.apk -a <target_arch>"
Example:
Note: The container could take a while to patch the apk (~5-20 min). One way to check to see if its not stuck somewhere is to use the docker stats command and see if the containers cpu usage is fluctuating.
You should then see the patched apk in the same folder as the original APK.
This makes a few changes which allow for users to patch APK files via Docker. Suggested in: #528
Notable Changes
Dockerfile was added
Make command was added to build docker. --platform linux/amd64 was added to ensure it also works on Mac silicon
Set objection to use aapt2 by default
The step that runs empty-framework-dir was removed. This was causing a lot of issues and preventing apktool from rebuilding the apk. This should only be required if the user is using a v1 version of apktool and never ran this command after updating to v2. If there's another use case for this that im not aware of, I can add it back.
While there is ways to use adb from within the container to query the device for architecture, I felt like it could possibly introduce a bunch of other issues and add to the complexity. For this reason, the architecture type must be passed in along with the docker run command. Adb is still on the final image to make it easier to add that feature later on.
Other changes are just overall formatting, variable names, and other small fixes. (I have auto format enabled, can disable it and change formatting back if you want)
Patching APK
Once the container is pulled/built, patching the APK should be straight forward.
Example:
Note: The container could take a while to patch the apk (~5-20 min). One way to check to see if its not stuck somewhere is to use the
docker statscommand and see if the containers cpu usage is fluctuating.You should then see the patched apk in the same folder as the original APK.