Skip to content

Most visited

Recently visited

navigation

Configure variantes de compilação

Esta página elabora as informações fornecidas no artigo Configure a visão geral da sua compilação para mostrar como configurar variantes de compilação para criar diferentes versões do aplicativo em um só projeto e como gerenciar corretamente as dependências e configurações de assinatura.

Cada variante de compilação representa uma versão diferente do seu aplicativo que pode ser compilada. Por exemplo: você pode querer compilar uma versão gratuita do seu aplicativo, com uma quantidade limitada de conteúdo, e uma versão paga com mais conteúdo. Você também pode compilar versões do seu aplicativo que sejam direcionadas a diferentes dispositivos, com base no nível da API ou em outras variações de dispositivos. Entretanto, se quiser compilar versões diferentes com base na ABI do dispositivo ou na densidade da tela, use divisões de APK.

Variantes de compilação são o resultado do Gradle usar um conjunto específico de regras para combinar configurações, códigos e recursos configurados nos seus tipos de compilação e variações de produtos. Apesar de não ser necessário configurar as variantes de compilação diretamente, é preciso configura os tipos de compilação e as variações de produtos que as formam.

Por exemplo, uma variação de produto “demo” pode especificar diferentes recursos e requisitos de dispositivo, como código-fonte, recursos e níveis de API mínimos personalizados, enquanto um tipo de compilação “debug” aplica diferentes configurações de empacotamento e compilação, como opções de depuração e chaves de assinatura. A variante de compilação resultante é a versão “demoDebug” do aplicativo e ela contém uma combinação de configurações e recursos incluídos na variação de produto “demo”, no tipo de compilação “debug” e no conjunto de origem de main/.

Configure tipos de compilação

Você pode criar e configurar tipos de compilação no arquivo build.gradle do módulo dentro do bloco android {}. Quando você cria um novo módulo, o Android Studio cria os tipos de compilação de depuração e lançamento automaticamente para você. Apesar de o tipo de compilação de depuração não aparecer no arquivo de configuração da compilação, o Android Studio o configura com debuggable true. Isso permite depurar o aplicativo em dispositivos Android seguros e configura o APK, assinando-o com um repositório de chaves de depuração genéricas.

Você pode adicionar o tipo de compilação de depuração às suas configurações se desejar adicionar ou alterar certas configurações. O exemplo a seguir especifica um applicationIdSuffix para o tipo de compilação de depuração e configura um tipo de compilação "jnidebug" que é inicializado com as configurações do tipo de compilação de depuração.

android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

Observação: ao fazer alterações em um arquivo de configuração de compilação, o Android Studio exige a sincronização do projeto com a nova configuração. Para fazer isso, clique em Sync Now na barra de notificação exibida assim que fizer uma alteração ou em Sync Project na barra de ferramentas. Se o Android Studio perceber erros em sua configuração, a janela Messages será exibida com uma descrição do problema.

Para saber mais sobre todas as propriedades que podem ser configuradas com tipos de compilação, leia a referência de DSL do tipo de compilação.

Configure variações de produtos

A criação de variações de produto é semelhante à de tipos de compilação: é só adicioná-las ao bloco productFlavors {} e definir as configurações como quiser. As variações de produto têm compatibilidade com as mesmas propriedades que defaultConfig, isso porque defaultConfig pertence à classe ProductFlavor. Isso significa que você pode fornecer a configuração básica para todas as variações do bloco defaultConfig {} e cada uma delas pode substituir esses valores padrão, como o applicationId. Para saber mais sobre o ID do aplicativo, leia Definir o ID do aplicativo.

Observação: Ainda é necessário especificar um nome de pacote usando o atributo package no arquivo de manifesto de main/. Você também deve usar esse nome de pacote no código-fonte para fazer referências à classe R ou para resolver qualquer atividade relativa ou registro de serviço. Isso permite usar o applicationId para fornecer a cada variação de produto um ID exclusivo para empacotamento e distribuição sem precisar alterar o código-fonte.

O exemplo de código a seguir cria produtos de tipo “demo” e “full” que fornecem os próprios applicationIdSuffix e versionNameSuffix:

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

Observação: para distribuir o aplicativo usando Suporte para vários APKs do Google Play, atribua o mesmo valor de applicationId para todas as variantes e dê um versionCode diferente a cada uma delas. Para distribuir diferentes variantes do seu aplicativo separadamente no Google Play, você deve atribuir um applicationId diferente a cada uma delas.

Depois de criar e configurar suas variações de produtos, clique em Sync Now na barra de notificação. Quando a sincronização for concluída, o Gradle criará as variantes de compilação automaticamente com base nos tipos de compilação e nas variações de produto e dará nome a elas de acordo com <product-flavor><Build-Type>. Por exemplo, se você criou variações de produtos “demo” e “full” e manteve os tipos de compilação “debug” e “release”, o Gradle criará as seguintes variantes de compilação:

Você pode alterar a variante de compilação para a que você deseja compilar e executar. Para fazer isso, basta acessar Build > Select Build Variant e selecionar uma no menu suspenso. Para começar a personalizar cada variante de compilação com seus próprios recursos, você deverá saber como criar e gerenciar conjuntos de origem.

Combine diversas variações de produto

Em alguns casos, você pode querer combinar as configurações de diferentes variações de produto. Por exemplo, talvez você queira criar diferentes configurações para as variações “full” e “demo” que se baseiam no nível da API. Para fazer isso, o Android Plugin for Gradle permite criar grupos de variações de produto, chamados de dimensões de variação. Ao compilar o aplicativo, o Gradle combina a configuração de uma variação de produto de cada dimensão de variação que você definir, junto com a configuração de um tipo de compilação, para criar a variante de compilação final. O Gradle não combina variações de produto que pertençam à mesma dimensão de variação.

Dica: Para criar versões diferentes do seu aplicativo com base na ABI e na densidade da tela, você deve Configurar divisões do APK em vez de usar variações de produto.

O exemplo de código a seguir usa a propriedade flavorDimensions para criar uma dimensão de variação “mode” para agrupar as variações de produto “full” e “demo”, e uma dimensão “api” para agrupar as configurações das variações baseadas no nível da API:

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig {} block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

O número de variantes de compilação que o Gradle cria é igual ao produto do número de variações presente em cada dimensão de variação e do número de tipos de compilação que você configurar. Quando o Gradle dá nome a cada variante de compilação ou APK correspondente, as variações de produto que pertencem à dimensão de maior prioridade aparecem primeiro, seguidas das outras de menor prioridade e, por último, vêm os tipos de compilação. Usando a configuração de compilação acima como exemplo, o Gradle cria um total de 12 variantes de compilação com o seguinte esquema de nome:

Variante de compilação: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
APK correspondente: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
Por exemplo,
Variante de compilação: minApi24DemoDebug
APK correspondente: app-minApi24-demo-debug.apk

Além dos diretórios de conjunto de origem que você pode criar para cada variante de compilação e variação de produto, também é possível criar diretórios de conjunto de origem para cada combinação de variações. Por exemplo, é possível criar e adicionar fontes Java ao diretório src/demoMinApi24/java/ e o Gradle usa essas fontes somente para compilar uma variante que combina duas dessas variações. Os conjuntos de origem criados para combinações de variação de produto têm maior prioridade do que os que pertencem a cada variação de produto. Para saber mais sobre conjuntos de origem e como o Gradle combina recursos, leia a seção abaixo sobre como Criar conjuntos de origem.

Filtre variantes

O Gradle cria uma variante de compilação para cada combinação possível de variações de produto e tipos de compilação que você configurar. No entanto, podem haver certas variantes de compilação que são desnecessárias ou não fazem sentido no contexto do seu projeto. Você pode remover determinadas configurações de uma variante de compilação criando um filtro de variante no arquivo build.gradle do módulo.

Usando a configuração de compilação da seção anterior como exemplo, suponha que você planeja dar suporte somente a APIs de nível 23 e superior para a versão de demonstração do aplicativo. Você pode usar o bloco variantFilter {} para filtrar todas as configurações de uma variante de compilação que combina as variações de produto “minApi21” e “demo”:

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

Depois de adicionar um filtro de variante à configuração de compilação e clicar em Sync Now na barra de notificação, o Gradle ignora todas as variantes de compilação que atendem às condições que você especificar e, assim, elas não aparecerão mais no menu suspenso ao clicar em Build > Select Build Variant na barra de menu (ou Build Variants na barra da janela da ferramenta).

Crie conjuntos de origem

Por padrão, o Android Studio cria o conjunto de origem de main/ e diretórios para tudo que você queira compartilhar entre suas variantes de compilação. No entanto, você pode criar novos conjuntos de origem para determinar exatamente que arquivos o Gradle deve compilar e empacotar para tipos de compilação, variações de produtos (e combinações de variações de produto quando usa dimensões de variação) e variantes de compilação específicos. Por exemplo, é possível definir a funcionalidade básica do conjunto de origem de main/ e usar os conjuntos de origem de uma variação de produto para alterar o aspecto visual do seu aplicativo para diferentes clientes ou incluir permissões especiais e recursos de registro somente para variantes de compilação que usam a depuração como tipo de compilação.

O Gradle espera que você organize os arquivos e diretórios dos conjuntos de origem de uma forma específica, semelhante ao conjunto de origem de main/. Por exemplo, o Gradle espera que os arquivos de classe Java específicos do seu tipo de compilação “debug” estejam no diretório src/debug/java/.

O Android Plugin for Gradle disponibiliza uma tarefa muito útil do Gradle que mostra como organizar seus arquivos por tipo de compilação, variação de produto e variante de compilação. Por exemplo, a seção do relatório a seguir descreve onde o Grade espera encontrar certos arquivos para o tipo de compilação "debug":

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: compile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

Para gerar e visualizar esse relatório para sua configuração de compilação, faça o seguinte:

  1. Clique em Gradle no lado direito da janela do IDE.
  2. Acesse MyApplication > Tasks > android e clique duas vezes em sourceSets.
  3. Para ver o relatório, clique em Gradle Console na parte inferior da janela do IDE.

Observação: o relatório também mostra como organizar conjuntos de origem para os arquivos que você deseja usar para executar testes com o aplicativo, como os conjuntos de origem de teste de test/ e androidTest/.

Quando você cria uma nova variante de compilação, o Android Studio não cria os diretórios de conjuntos de origem para você, mas ele oferece algumas opções para ajudá-lo. Por exemplo, para criar somente o diretório java/ para o tipo de compilação “debug”:

  1. Abra o painel Project e selecione a vista Project no menu suspenso na parte superior do painel.
  2. Navegar para MyProject/app/src/.
  3. Clique com o botão direito do mouse no diretório src e selecione New > Folder > Java Folder.
  4. No menu suspenso ao lado de Target Source Set, selecione debug.
  5. Clique em Finish.

O Android Studio cria um diretório do conjunto de origem para o seu tipo de compilação de depuração e, em seguida, cria a pasta java/ dentro dele. Uma alternativa é fazer com que o Android Studio crie diretórios quando você criar um novo arquivo para uma variante de compilação específica do seu projeto. Por exemplo, para criar um arquivo XML de valores para o tipo de compilação "debug":

  1. Ainda no painel Project, clique com o botão direito do mouse no diretório src e selecione New > XML > Values XML File.
  2. Insira o nome do arquivo XML ou mantenha o nome padrão.
  3. No menu suspenso ao lado de Target Source Set, selecione debug.
  4. Clique em Finish.

Como o tipo de compilação "debug" foi especificado como o conjunto de origem de destino, o Android Studio cria os diretórios necessários automaticamente ao criar o arquivo XML. A estrutura de diretórios resultante deve ser semelhante à figura 2.

Figura 2. Novos diretórios de conjuntos de origem para o tipo de compilação de depuração.

Com o mesmo procedimento, também é possível criar diretórios de conjuntos de origem para variações de produtos, como src/demo/, e para variantes de compilação, como src/demoDebug/. Além disso, você pode criar conjuntos de origem para testes voltados para variantes de compilação específicas, como em src/androidTestDemoDebug/. Para saber mais, veja Como testar conjuntos de origem.

Altere configurações padrão dos conjuntos de origem

Se você tem códigos que não são organizados na estrutura padrão de arquivos de conjunto de origem que o Gradle espera, como descrito acima na seção sobre criar conjuntos de origem, use o bloco sourceSets {} para alterar a forma com que o Gradle entende a estrutura para coletar arquivos de cada componente de um conjunto de origem. Não é preciso realocar os arquivos, basta fornecer ao Gradle os caminhos, relativos ao arquivo build.gradle no nível do módulo, em que o Gradle deve esperar encontrar os arquivos de cada componente do conjunto de origem. Para saber que componentes podem ser configurados, e se você pode mapeá-los em diversos arquivos ou diretórios, leia o guia de referência de DSL do Android Plugin for Gradle.

O código de exemplo a seguir mapeia origens do diretório app/other/ em determinados componentes do conjunto de origem main e altera a pasta-raiz do conjunto de origem androidTest.

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you get an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: You should avoid specifying a directory which is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // You should specify either only the root 'other/res1' directory, or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

Compile com conjuntos de origem

Você pode usar os diretórios dos conjuntos de origem para armazenar o código e os recursos que deseja empacotar apenas com certas configurações. Por exemplo, se você estiver compilando a variante de compilação “demoDebug”, que é o produto combinado de uma variação de produto "demo" e um tipo de compilação “debug”, o Gradle examinará esses diretórios e concederá a eles as seguintes prioridades:

  1. src/demoDebug/ (conjunto de origem de variante de compilação)
  2. src/debug/ (conjunto de origem de tipo de compilação)
  3. src/demo/ (conjunto de origem de variação de produto)
  4. src/main/ (conjunto de origem principal)

Observação: Se você combinar diversas variações de produto, a prioridade entre elas será determinada pela dimensão a que pertencem. Ao classificar as dimensões de variação com a propriedade android.flavorDimensions, as variações de produto que pertencem à primeira dimensão listada terão maior prioridade do que as que pertencem à segunda dimensão e assim por diante. Além disso, os conjuntos de origem que você criar para combinações de variação de produto terão maior prioridade em relação aos conjuntos de origem que pertencem a cada variação de produto individualmente.

A ordem listada acima determina qual conjunto de origem tem mais prioridade quando o Gradle combina código e recursos. Como o diretório demoDebug/ do conjunto de origem provavelmente contém arquivos específicos dessa variante de compilação, se demoDebug/ contiver um arquivo também definido em debug/, o Gradle usará o arquivo do conjunto de origem de demoDebug/. De forma similar, o Gradle dá aos arquivos que se encontram nos conjuntos de origem de tipo de compilação e de variação de produto maior prioridade do que os mesmos arquivos presentes em main/. O Gradle considera essa ordem de prioridade ao aplicar as seguintes regras de compilação:

Declare dependências

O exemplo a seguir declara três tipos de dependências diretas no arquivo build.gradle do módulo de app/:

android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:27.0.2'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

Cada uma dessas dependências diretas é descrita abaixo.

Dependências de módulo
A linha compile project(':mylibrary') declara um módulo local da biblioteca Android chamado "mylibrary" como uma dependência e exige que o sistema de compilação compile e inclua o módulo local durante a compilação do aplicativo.
Dependências binárias remotas
A linha compile 'com.android.support:appcompat-v7:27.0.2' declara uma dependência na versão 27.0.2 da biblioteca de suporte do Android por meio da especificação de suas coordenadas no JCenter. Por padrão, o Android Studio configura os projetos para usar o JCenter Repository no arquivo de compilação de maior nível. O Gradle coleta a dependência do JCenter automaticamente quando você sincroniza seu projeto com os arquivos de configuração de compilação. Como alternativa, pode-se baixar e instalar certas dependências usando o SDK Manager.
Dependências binárias locais
A linha compile fileTree(dir: 'libs', include: ['*.jar']) instrui o sistema de compilação a incluir todo arquivo JAR que esteja dentro do diretório app/libs/ no classpath da compilação e no pacote final do aplicativo. Se você tiver módulos que exijam dependências binárias locais, copie os arquivos JAR dessas dependências para <moduleName>/libs dentro do seu projeto.

Algumas dependências diretas do módulo podem ter suas próprias dependências, que são chamadas de dependências transitivas do módulo. Em vez de precisar declarar manualmente cada dependência transitiva, o Gradle automaticamente as coleta e adiciona. O Android Plugin for Gradle disponibiliza uma tarefa muito útil que pode gerar uma árvore de dependências para cada variante de compilação e conjunto de origem de teste, possibilitando, assim, visualizar com facilidade as dependências diretas e transitivas do seu módulo. Para gerar esse relatório, faça o seguinte:

  1. Clique em Gradle no lado direito da janela do IDE.
  2. Navegue até MyApplication > Tasks > android e clique duas vezes em androidDependencies.
  3. Para ver o relatório, clique em Gradle Console na parte inferior da janela do IDE.

O exemplo de relatório a seguir mostra a árvore de dependências da variante de compilação de depuração e inclui a dependência do módulo local e a dependência remota do exemplo anterior.

Executing tasks: [androidDependencies]
:app:androidDependencies
debug
/**
 * Both the library module dependency and remote binary dependency are listed
 * with their transitive dependencies.
 */
+--- MyApp:mylibrary:unspecified
|    \--- com.android.support:appcompat-v7:27.0.2
|         +--- com.android.support:animated-vector-drawable:27.0.2
|         |    \--- com.android.support:support-vector-drawable:27.0.2
|         |         \--- com.android.support:support-v4:27.0.2
|         |              \--- LOCAL: internal_impl-27.0.2.jar
|         +--- com.android.support:support-v4:27.0.2
|         |    \--- LOCAL: internal_impl-27.0.2.jar
|         \--- com.android.support:support-vector-drawable:27.0.2
|              \--- com.android.support:support-v4:27.0.2
|                   \--- LOCAL: internal_impl-27.0.2.jar
\--- com.android.support:appcompat-v7:27.0.2
     +--- com.android.support:animated-vector-drawable:27.0.2
     |    \--- com.android.support:support-vector-drawable:27.0.2
     |         \--- com.android.support:support-v4:27.0.2
     |              \--- LOCAL: internal_impl-27.0.2.jar
     +--- com.android.support:support-v4:27.0.2
     |    \--- LOCAL: internal_impl-27.0.2.jar
     \--- com.android.support:support-vector-drawable:27.0.2
          \--- com.android.support:support-v4:27.0.2
               \--- LOCAL: internal_impl-27.0.2.jar
...

Para saber mais sobre como gerenciar as dependências no Gradle, consulte a seção Dependency Management Basics no guia do usuário do Gradle.

Configure dependências

Você pode usar certas palavras-chave de configuração para mostrar ao Gradle como e quando usar uma dependência, como a palavra-chave compile dos exemplos anteriores. A seguir descrevemos algumas das palavras-chave que podem ser usadas para configurar suas dependências:

compile
Especifica uma dependência de tempo de compilação. O Gradle adiciona dependências com essa configuração ao classpath e ao APK do aplicativo. Essa é a configuração padrão.
apk
Especifica uma dependência de somente tempo de execução que o Gradle precisa empacotar com o APK do aplicativo. Você pode usar essa configuração com dependências binárias JAR, mas não com outras dependências do módulo de biblioteca ou dependências AAR.
provided
Especifica uma dependência de tempo de compilação que o Gradle não empacota com o APK do aplicativo. Isso ajuda a reduzir do tamanho do APK se a dependência não for necessária durante o tempo de execução. Você pode usar essa configuração com dependências binárias JAR, mas não com outras dependências do módulo de biblioteca ou dependências AAR.

Além disso, pode-se configurar uma dependência para uma variante de compilação específica ou um conjunto de origem de teste ao aplicar o nome do variante ou do conjunto definido como a palavra-chave da configuração, conforme mostrado no exemplo a seguir.

dependencies {
    ...
    // Adds specific library module dependencies as compile time dependencies
    // to the fullRelease and fullDebug build variants.
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')

    // Adds a compile time dependency for local tests.
    testCompile 'junit:junit:4.12'

    // Adds a compile time dependency for the test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
}

Defina configurações de assinatura

O Gradle não assina o APK da sua compilação de lançamento a não ser que você defina explicitamente uma configuração de assinatura para a compilação. É fácil criar uma chave de lançamento e assinar seu tipo de compilação de lançamento usando o Android Studio.

Para definir manualmente as configurações de assinatura para seu tipo de compilação de lançamento usando as configurações de lançamento do Gradle:

  1. Crie um repositório de chaves. Repositório de chaves é um arquivo binário que contém um conjunto de chaves privadas. É necessário manter o repositório de chaves em um local seguro e protegido.
  2. Crie uma chave privada. Chave privada representa a entidade a ser identificada com o aplicativo, como uma pessoa ou empresa.
  3. Adicione a configuração de assinatura ao arquivo build.gradle do módulo:

    ...
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            release {
                storeFile file("myreleasekey.keystore")
                storePassword "password"
                keyAlias "MyReleaseKey"
                keyPassword "password"
            }
        }
        buildTypes {
            release {
                ...
                signingConfig signingConfigs.release
            }
        }
    }
    

Para gerar um APK assinado, selecione Build > Generate Signed APK na barra de menus. O pacote em app/build/apk/app-release.apk está agora assinado com a chave de lançamento.

Observação: a inclusão das senhas da chave de lançamento e do repositório de chaves dentro do arquivo de compilação não é uma prática recomendada. Como alternativa, você pode configurar o arquivo de compilação para obter essas senhas de variáveis de ambiente ou fazer com que o processo de compilação as solicite.

Para obter essas senhas de variáveis de ambiente:

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

Para que o processo de compilação solicite essas senhas se estiver chamando a compilação na linha de comando:

storePassword System.console().readLine("\nKeystore password: ")
keyPassword System.console().readLine("\nKey password: ")

Após a conclusão desse processo, você poderá distribuir o aplicativo e publicá-lo no Google Play.

Aviso: mantenha o repositório de chaves e a chave privada em local seguro e protegido e confirme se os respectivos backups estão protegidos. Se você publicar um aplicativo no Google Play e perder a chave com a qual o aplicativo foi assinado, não será possível publicar nenhuma atualização para o aplicativo, pois é preciso sempre assinar todas as versões do aplicativo com a mesma chave.

Como assinar aplicativos do Android Wear

Ao publicar aplicativos do Android Wear, você coloca o aplicativo wearable em um pacote dentro de um dispositivo portátil, pois os usuários não podem navegar e instalar aplicativos diretamente no dispositivo wearable. É preciso assinar os dois aplicativos. Para obter mais informações sobre a criação de pacotes e a assinatura de aplicativos do Android Wear, consulte Como criar de pacotes para aplicativos wearable.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)