Redesigned Bitrise Android scanner, steps, and workflows to make it simpler and better

Bitrise
5 min readJun 1, 2018

--

Quite a few things were changed for the more convenient for our Android users. Check out how we made the Android setup smarter, what new steps replace the old Gradle Runner step and how the new default workflows look on Bitrise.

New steps

We are announcing a couple of new steps that refresh and refurbish our family of Android steps. Earlier you had to compile the Gradle task yourself and run it 3 times with different configs. In addition, Gradle only supported APK export, while Lint reports and Unit Test results had to be exported manually.

From now on, instead of choosing what to have your the Gradle step do, you have to choose the right step and fill the 3 inputs and that is all. Cool, huh? 😎

This step generates and exports an APK and a mapping file (if you have deobfuscation enabled).

No surprise here, this step generates and exports a Lint report.

And this one will generate and export the Unit Test Results.

(Soon we’ll release another new step: the Android Espresso UI Test, which is currently in progress. It will generate the two required APKs for itself and test them so you won’t need to build and test them separately.)

New logic for inputs

From now on we’re handling Android tasks from a different point of view: instead of Gradle’s, we’ll follow Android Studio’s structure, so we designed a totally different structure for required inputs. This means that all the new Android steps are configurable the same way as in Android Studio:

  1. You need to “open” a project (Project Location)
  2. Test or build a variant in a module (Variant and Module)

Variants in build logs

After you’ve configured these steps, you might still encounter some difficulties selecting the correct variant in the correct module. To help you with this, we re-designed the configuration logging as well to see in the build logs which modules have which variants set:

Outputs

After running the test build, it is important being able to track the generated outputs. To keep it as simple as possible we’ve changed the logging as well:

No need to find your results or APK, etc. from now on, the step will automatically collect and export them, as needed by the type of the step and the task’s output. So the Build step will export APKs and mapping files, the Lint step will export reports, and so on…

Updated scanner and workflows

Scanner for newly added apps

We have updated the scanner to generate the initial workflows using the new Android steps. Let’s see the steps one by one.

1. Choose a Bitrise account

You can choose your account or an org that you are a member of. This is where the new app will belong to.

2. Choose a repository

3. Setup repository access (Add SSH key)

4. Choose branch

Pick one from your repo. ;)

5. Validation is running…

Quick coffee break or some emailing time. Or a short walk? Or a power nap? Just kidding, it’s already over.

6. Project build configuration

Please note that your project might have more Variants both for testing and building than my test project. 😉

  • Select Variant for building

Pick one or select empty (on the top) for building all.

(I chose Release.)

  • Select Variant for testing

Pick one or select empty for all.

(I chose Debug.)

  • Confirm (or edit) settings

7. Webhook setup

8. Your first build in now running!

Click on this huge green button to see the details of your build:

Workflows

Once the scanner has finished adding your app, it’ll have the totally redefined Android workflows.

The primary workflow will

  • run Lint
  • run Unit tests on your project
  • export the test results.

The deploy workflow has changed more:

  • It will increment the versionCode of your app automatically with the Change Android versionCode and versionName step (This can be removed any time, just remove the step from the workflow.)
  • It will run Lint and Unit tests for your project and build it as well.
  • We’ve put a Sign APK step in the workflow as well and it works in a smart, automatic way: it will run only if you have already uploaded your keystore on the code signing tab.

This way you will have either a debug (if the selected variant is debug) or an unsigned APK if you haven’t uploaded a keystore file. In case you’ve uploaded it, you will have a signed APK exported to your artifacts.

Built-in help with Android keystore

We used our biggest info panel in the Workflow editor to help you get started with your Android keystore and running the deploy workflow.
So as soon as you select the deploy workflow in the Workflow editor, you will see this little help section there:

The new Android steps are automatically available to all Android apps added as new, but you can convert any old workflow to this new one. (Detailed guide coming soon.)

We hope you’ll 💚 these new features, let us know what you think!

Orignially published on the Bitrise Blog.

--

--

Bitrise

Build better mobile applications, faster: Mobile Continuous Integration and Delivery with +330 of integrations for your favorite services. 🚀 https://bitrise.io