Scribd
Upload
19 views3 pages

Deploying Signed APK to Bitrise

This document outlines the configuration for an Android project using Bitrise, detailing workflows for deploying and signing APKs. It includes steps for setting up the environment, installing necessary tools, and triggering builds based on Git events. The document also provides instructions for manually running the deploy workflow and the required inputs for signing the APK.

Uploaded by

ajainlola
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
19 views3 pages

Deploying Signed APK to Bitrise

This document outlines the configuration for an Android project using Bitrise, detailing workflows for deploying and signing APKs. It includes steps for setting up the environment, installing necessary tools, and triggering builds based on Git events. The document also provides instructions for manually running the deploy workflow and the required inputs for signing the APK.

Uploaded by

ajainlola
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

---

format_version: '6'
default_step_lib_source: [Link]
project_type: android
trigger_map:
- push_branch: "*"
workflow: primary
- pull_request_source_branch: "*"
workflow: primary
workflows:
deploy:
description: |
## How to get a signed APK

This workflow contains the **Sign APK** step. To sign your APK all you have
to do is to:

1. Click on **Code Signing** tab


1. Find the **ANDROID KEYSTORE FILE** section
1. Click or drop your file on the upload file field
1. Fill the displayed 3 input fields:
1. **Keystore password**
1. **Keystore alias**
1. **Private key password**
1. Click on **[Save metadata]** button

That's it! From now on, **Sign APK** step will receive your uploaded files.

## To run this workflow

If you want to run this workflow manually:

1. Open the app's build list page


2. Click on **[Start/Schedule a Build]** button
3. Select **deploy** in **Workflow** dropdown input
4. Click **[Start Build]** button

Or if you need this workflow to be started by a GIT event:

1. Click on **Triggers** tab


2. Setup your desired event (push/tag/pull) and select **deploy** workflow
3. Click on **[Done]** and then **[Save]** buttons

The next change in your repository that matches any of your trigger map event
will start **deploy** workflow.
steps:
- cache-pull@2.0.1: {}
- script@1.1.5:
title: Install newer cmake
inputs:
- content: |-
#!/bin/bash
set -ex
sudo apt remove cmake -y
sudo apt purge --auto-remove cmake -y
sudo apt install ninja-build -y
version=3.10
build=2
mkdir ~/temp
cd ~/temp
wget [Link]
x86_64.sh
sudo mkdir /opt/cmake
sudo sh cmake-$version.$build-Linux-x86_64.sh --prefix=/opt/cmake
--skip-license --exclude-subdir
envman add --key PATH --value "/opt/cmake/bin:$PATH"
- install-missing-android-tools@2.3.3:
inputs:
- gradlew_path: "$PROJECT_LOCATION/gradlew"
- change-android-versioncode-and-versionname@1.1.1:
inputs:
- build_gradle_path: "$PROJECT_LOCATION/$MODULE/[Link]"
- android-lint@0.9.5:
inputs:
- project_location: "$PROJECT_LOCATION"
- module: "$MODULE"
- variant: "$TEST_VARIANT"
- android-unit-test@0.9.3:
inputs:
- project_location: "$PROJECT_LOCATION"
- module: "$MODULE"
- variant: "$TEST_VARIANT"
- android-build@0.9.5:
inputs:
- project_location: "$PROJECT_LOCATION"
- module: "$MODULE"
- variant: "$BUILD_VARIANT"
- sign-apk@1.2.3:
run_if: '{{getenv "BITRISEIO_ANDROID_KEYSTORE_URL" | ne ""}}'
- deploy-to-bitrise-io@1.3.18: {}
- cache-push@2.0.5: {}
primary:
steps:
- cache-pull@2.0.1: {}
- script@1.1.5:
title: Install newer cmake
inputs:
- content: |-
#!/bin/bash
set -ex
sudo apt remove cmake -y
sudo apt purge --auto-remove cmake -y
sudo apt install ninja-build -y
version=3.10
build=2
mkdir ~/temp
cd ~/temp
wget [Link]
x86_64.sh
sudo mkdir /opt/cmake
sudo sh cmake-$version.$build-Linux-x86_64.sh --prefix=/opt/cmake
--skip-license --exclude-subdir
envman add --key PATH --value "/opt/cmake/bin:$PATH"
- install-missing-android-tools@2.3.3:
inputs:
- gradlew_path: "$PROJECT_LOCATION/gradlew"
- android-lint@0.9.5:
inputs:
- project_location: "$PROJECT_LOCATION"
- module: "$MODULE"
- variant: "$TEST_VARIANT"
- android-build@0.9.5:
inputs:
- variant: Debug
- project_location: "$PROJECT_LOCATION"
- deploy-to-bitrise-io@1.3.18: {}
- cache-push@2.0.5: {}
app:
envs:
- opts:
is_expand: false
PROJECT_LOCATION: src/android
- opts:
is_expand: false
MODULE: app
- opts:
is_expand: false
BUILD_VARIANT: Release
- opts:
is_expand: false
TEST_VARIANT: Debug

Common questions

Powered by AI

Cache management is crucial in the described workflows to optimize build times and resource usage. It is implemented through 'cache-pull' and 'cache-push' steps which restore and store build caches, respectively. These caches include artifacts or dependencies that do not change between builds, allowing subsequent builds to reuse these resources without re-downloading or re-compiling every time. This efficiency is particularly beneficial in CI/CD pipelines to increase the speed of the build and decrease cost .

Potential challenges include ensuring that all environment variables and inputs are correctly configured, managing dependencies and cache to prevent build failures, and integrating version and signing configurations robustly. These can be addressed by thoroughly testing each component of the workflow, incrementally integrating the workflow steps, and consulting documentation to adapt the reusable parts of the configuration to specific project needs .

The configuration accommodates different Android build and test variants by using environment variables like 'BUILD_VARIANT' and 'TEST_VARIANT'. These are specified in the 'app' section where specific strings are assigned to these variables. This flexibility allows for different build types (such as 'Release' for the build variant and 'Debug' for the test variant), ensuring that different configurations can be tested or deployed within the same CI/CD pipeline .

The 'deploy' workflow in the described bitrise project configuration is primarily responsible for generating a signed APK. It involves signing the APK with a designated keystore file and then deploying it. The workflow includes steps such as pulling cache, installing necessary Android tools, building the APK, signing it, and finally deploying to bitrise.io. This process ensures that the APK is ready for release or distribution while maintaining a Continuous Integration/Continuous Deployment (CI/CD) pipeline .

A developer might utilize the 'change-android-versioncode-and-versionname' step to automatically update the version code and version name in the 'build.gradle' file. This step is important to ensure that new builds reflect the correct application version, which is necessary for app store submissions and user expectations. This automation reduces manual errors and ensures consistency across builds and deployments .

The signing of an APK in this workflow is handled by the 'Sign APK' step, which is executed only if the 'BITRISEIO_ANDROID_KEYSTORE_URL' environment variable is set. The required inputs include the keystore file (uploaded through the Code Signing tab), keystore password, keystore alias, and the private key password. This step ensures that the APK is properly signed with the developer's credentials, which is essential for deployment to app stores or distribution to users .

Manually triggering the 'deploy' workflow involves the following steps: opening the app's build list page, clicking on 'Start/Schedule a Build', selecting 'deploy' in the workflow dropdown, and clicking 'Start Build'. A developer might choose to manually trigger the workflow to test new configurations or changes before automatic triggers are set, ensuring that everything works as intended and reducing the risk of errors in automated processes .

The 'install-missing-android-tools' step is crucial for ensuring all necessary Android SDK tools and dependencies are installed before the build process begins. This step checks for and installs any missing components specified in the 'gradlew' script, which is critical in preventing build errors caused by missing tools. This ensures that the build process is not halted due to missing dependencies, leading to a smoother pipeline operation .

GIT events can be used to automatically trigger the 'deploy' workflow by setting up triggers in the 'Triggers' tab. Developers can configure the workflow to start on events such as push, tag, or pull requests. This automation offers several benefits, including continuous integration where every code change is automatically validated, reducing manual intervention, ensuring up-to-date deployments, and catching issues early in the development process .

The configuration ensures that a specific version of CMake is installed by scripting the removal of any existing CMake versions, installing 'ninja-build', and subsequently installing CMake version 3.10 from a downloaded script. By specifying the exact version and build number, the configuration controls the build environment's consistency, reducing risks of incompatibility or unexpected behavior due to different CMake versions. This approach is critical in environments where reliable and reproducible builds are essential .

You might also like