Skip to main content

Running lint checks for your Android apps

Abstract

On Bitrise, you can run lint checks with our dedicated Step called Android Lint. It runs the same lint function that is built into Android Studio. To perform lint checks, you don't need to write test cases or execute your app.

Android Studio provides a code scanning tool called lint that can help you identify and correct problems with the structural quality of your code. When using Android Studio, configured lint checks run automatically when building your app. Lint checks don't require test cases.

On Bitrise, you can run lint checks with our dedicated Step called Android Lint. To do so:

Workflow Editor

bitrise.yml

  1. Add the Android Lint Step to your Android app's Workflow.

    It should come before any Step that builds your app (for example, Android Build), if you have such a Step in your Workflow.

  2. Make sure the Project Location input points to the root directory of your Android project, where the top level build.gradle file is located.

  3. In the Module and Variant inputs, specify the module and variant of the app you want to check.

    android-lint.png

    If you are unsure about the exact names of modules and variants in your project, you can check them in the Project view in Android Studio.

  4. In the Options input group, the Report location pattern input allows you to specify where the lint report should be found once the Step has run.

    The input accepts asterisks as a wildcard. You can set the input to return the results either as html or xml.

  5. In the Options input group, the Additional Gradle Arguments input allows you to pass arguments to the Gradle task.

  1. In the bitrise.yml file, add the android-lint Step to your Android app's Workflow.

    It should come before any Step that builds your app (for example, Android Build), if you have such a Step in your Workflow.

    my-workflow:
  steps:
    - git-clone: {}
    - android-lint:

  2. Make sure the project_location input points to the root directory of your Android project, where the top level build.gradle or build.gradle.kts file is located.

    my-workflow:
  steps:
    - git-clone: {}
    - android-lint:
        inputs:
        - project_location: $BITRISE_SOURCE_DIR

  3. In the module and variant inputs, specify the module and variant of the app you want to check.

    If you are unsure about the exact names of modules and variants in your project, you can check them in the Project view in Android Studio.

    my-workflow:
  steps:
    - git-clone: {}
    - android-lint:
        inputs:
        - module: module
        - variant: variant
        - project_location: $BITRISE_SOURCE_DIR

  4. The report_path_pattern input allows you to specify where the lint report should be found once the Step has run.

    The input accepts asterisks as a wildcard. You can set the input to return the results either as html or xml.

    my-workflow:
  steps:
    - git-clone: {}
    - android-lint:
        inputs:
        - module: module
        - variant: variant
        - report_path_pattern: '*/build/reports/lint-results*.xml'
        - project_location: $BITRISE_SOURCE_DIR

  5. The argument input allows you to pass arguments to the Gradle task.

    my-workflow:
  steps:
    - git-clone: {}
    - android-lint:
        inputs:
        - module: module
        - variant: variant
        - report_path_pattern: '*/build/reports/lint-results*.xml'
        - argument: arg
        - project_location: $BITRISE_SOURCE_DIR
In this section:

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

An app on Bitrise represents a Git repository that stores source code and has been connected to Bitrise to be able to run builds on it. As such, a Bitrise app isn't necessarily an actual application: it's just the code on which you run builds with Bitrise.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.

The bitrise.yml file stores your entire build configuration for an app. It specifies your stack and the build triggers, and defines the Workflows of the app. When you make changes on the graphical UI of our Workflow Editor, you actually modify the bitrise.yml file.