Useful tools in Android Studio

    Quite a lot of time has passed since the presentation of Android Studio, and for sure many have accumulated a lot of knowledge, nuances and chips, often used in work. I would like to share this. I'll start, and you continue ...
    • SSD
    • Filling layout with test data
    • Auto-increment version and change build name
    • Creating various build options
    • Pipette
    • View code block history


    Gradle collector collects for a long time. If on a simple project, the assembly time takes up to 10 seconds, then on a large one, with many modules, up to two minutes. Taking into account the fact that a project is assembled dozens of times a day during a day of work, a big time leak comes out and irritability appears (the computer sometimes goes into ANR, it’s even impossible to use a browser). The problem is solved simply by switching back to Eclipse by installing an SSD drive. The issue price is $ 100. Profit - plus 5-25 minutes per day.
    The results of my testing of SSDs:
    1. ANR Windows disappeared
    2. The assembly time of complex projects decreased from a maximum of two minutes to a maximum of 20 seconds.
    3. Buying an SSD allows you to painlessly use genymotion in conjunction with the studio.
    Comparison of the speeds of HDD (top) and SSD (bottom) connected via SATA 1:

    Filling layout with test data

    The prefix “tools:” in addition to the Lint functions allows filling the layout with test data without consequences for the application. "Everything that happens in Vegas remains in Vegas . " Everything that is marked with this prefix is ​​displayed in the layout and deleted during assembly.

    Even such things are possible:

    More details here - .
    You can familiarize yourself with additional features for using the “tools:” prefix here - .

    Auto-increment version and change build name

    Gradle fully automates the assembly and allows you to collect various builds with one click. Below is the code from build.gradle, which allows you to remember to raise the version of the application and renames the build based on the version and date - appname-release_v50_2014-11-04
    import java.util.regex.Pattern
    android {
        buildTypes {
            debug {
                applicationIdSuffix '.debug'
                debuggable true
                runProguard false
                jniDebugBuild false
            release {
                signingConfig signingConfigs.release
                applicationVariants. { variant ->
                    def file = variant.outputFile;
                    def newName ="release.apk", "release_v" + getVersionCode() + "_" + getDate() + ".apk");
                    variant.outputFile = new File(file.parent, newName)
                runProguard true
                proguardFile file("")
                debuggable false
                jniDebugBuild false
    def getDate() {
        def date = new Date()
        def formattedDate = date.format('yyyy-MM-dd')
        return formattedDate
    def getVersionCode() {
        println "getVersionCode"
        def manifestFile = file("AndroidManifest.xml")
        def pattern = Pattern.compile("versionCode=\"(\\d+)\"")
        def manifestText = manifestFile.getText()
        def matcher = pattern.matcher(manifestText)
        def version = ++Integer.parseInt(
        println sprintf("Returning version %d", version)
        return version
    task incrementVersionCode << {
        println(":incrementVersionCode - Incrementing Version Code...")
        def manifestFile = file("src/main/AndroidManifest.xml")
        def patternVersionCode = Pattern.compile("versionCode=\"(\\d+)\"")
        def manifestText = manifestFile.getText()
        def matcherVersionCode = patternVersionCode.matcher(manifestText)
        def mVersionCode = Integer.parseInt(
        def mNextVersionCode = mVersionCode + 1
        def manifestContent = matcherVersionCode.replaceAll("versionCode=\"" + mNextVersionCode + "\"")
        println(":incrementVersionCode - current versionCode=" + mVersionCode);
        println(":incrementVersionCode - next versionCode=" + mNextVersionCode);
    task incrementVersionName << {
        println(":incrementVersionName - Incrementing Version Name...")
        def manifestFile = file("src/main/AndroidManifest.xml")
        def patternVersionNumber = Pattern.compile("versionName=\"(\\d+)\\.(\\d+)\"")
        def manifestText = manifestFile.getText()
        def matcherVersionNumber = patternVersionNumber.matcher(manifestText)
        def majorVersion = Integer.parseInt(
        def minorVersion = Integer.parseInt(
        def mVersionName = majorVersion + "." + minorVersion
        def mNextVersionName = majorVersion + "." + (minorVersion + 1)
        def manifestContent = matcherVersionNumber.replaceAll("versionName=\"" + mNextVersionName + "\"")
        println(":incrementVersionName - current versionName=" + mVersionName);
        println(":incrementVersionName - new versionName=" + mNextVersionName);
    task release << {
        println(":release - Build and Version Increment")
    task debug << {
        println(":debug - Build")
    incrementVersionName.mustRunAfter build
    incrementVersionCode.mustRunAfter build
    debug.dependsOn assembleDebug
    release.dependsOn assembleRelease
    release.dependsOn incrementVersionCode
    release.dependsOn incrementVersionName

    Then it remains to run the release command of the main module of the project.

    Creating various build options

    I think one of the simplest and most popular options for using this feature is to create a free and paid version of the application or version for the release and test server.

    Below is an example on this topic
    Specify the build options - free and paid, and the corresponding parameters in build.gradle
      productFlavors {
            free {
                packageName "by.yegorov.communal"
                buildConfigField "boolean", "PAID", "false"
            paid {
                packageName ""
                buildConfigField "boolean", "PAID", "true"

    In the case of a release and test server:
    productFlavors {
            debugServer {
                buildConfigField "String", "SERVER_PATH", "\"\""
            releaseServer {
                buildConfigField "String", "SERVER_PATH", "\"\""

    Then we create folders in src with the corresponding names. The following project structure will be obtained:

    In the resources we indicate the differing data. For example, various keys for google analytics, crittercism, google backup service, etc.
    In the code we do checks on BuildConfig.PAID to implement the logic.


    The eyedropper allows you to find out the color code from any area on the screen. Many simply do not notice it and use paint in order to find out the color code from the picture. Pay attention to the upper left corner. This dialog box is called from colors.xml when clicking on a color.

    View code block history

    Agree, the standard situation when working in a team. I don’t know how long this solution exists and whether it is in the eclipse, but the thing is really useful:

    Thanks to all! Waiting for your comments.

    Only registered users can participate in the survey. Please come in.

    Your attitude to Android Studio:

    • 14.1% Not tried 15
    • 1.8% Tried, returned to Eclipse 2
    • 83.9% Tried and stayed 89

    Also popular now: