Save the date! Android Dev Summit is coming to Sunnyvale, CA on Oct 23-24, 2019.

Configurar variantes de compilação

Esta página usa as informações fornecidas no artigo Visão geral da configuração da sua compilação para mostrar como configurar variantes de compilação na criação de 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, compile vários APKs.

Variantes de compilação são o resultado do Gradle usar um conjunto específico de regras para combinar configurações, código 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 configurar 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. 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/.

Configurar 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 "staging" que é inicializado com as configurações do tipo de compilação de depuração.

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property allows you to copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

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 isso, clique em Sync Now na barra de notificação exibida a cada 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.

Configurar variações de produtos

A criação de variações de produtos é semelhante à de tipos de compilação: basta adicioná-las ao bloco productFlavors e definir as configurações como quiser. As variações de produtos 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 código exclusivo de empacotamento e distribuição sem precisar alterar o código-fonte.

Todas as variações precisam pertencer a uma dimensão de variação nomeada, que é um grupo de variações de produtos. Você precisa atribuir variações a uma dimensão de variação, mesmo que pretenda usar somente uma única dimensão. Caso contrário, o seguinte erro de compilação será exibido:

  Error:All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

O seguinte exemplo de código cria uma dimensão de variação chamada "version” e adiciona variações de produtos "demo" e "full”. Esses variações fornecem os próprios applicationIdSuffix e versionNameSuffix:

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // This property is optional if you are using only one dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            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:

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

É possível alterar a variante de compilação para aquela que você quer compilar e executar. Para fazer isso, basta acessar Build > Select Build Variant e selecionar uma opção no menu suspenso. No entanto, para começar a personalizar cada variante de compilação com os próprios recursos, você precisará saber como criar e gerenciar conjuntos de origem. criar e gerenciar recursos de origem.

Combinar diversas variações de produtos com dimensões de variação

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 produtos, 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 compilar vários APKs 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:

Variação de compilação: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
APK correspondente: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
Por exemplo,
Variação 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 de produto. 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 de produto. 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.

Filtrar 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 variantes 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 ignorará todas as variantes de compilação que atenderem às condições especificadas. 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 de ferramenta).

Criar conjuntos de origem

Por padrão, o Android Studio criará o conjunto de origem de main/ e diretórios para tudo que você quiser 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 geração de registros 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, o exemplo de saída da tarefa a seguir descreve onde o Gradle 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 visualizar essa saída, 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. Depois que o Gradle executar a tarefa, a janela Run deverá ser aberta para exibir a saída.
  3. Caso a exibição não esteja no modo de texto mostrado acima, clique em Toggle view no lado esquerdo da janela Run.

Observação: a saída da tarefa 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 visualização Project no menu suspenso na parte superior do painel.
  2. Navegue 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 à imagem 2.

Imagem 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.

Alterar as configurações do conjunto de origem padrão

Se você tem origens que não são organizadas 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 o diretório 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'
      ...
    }
  }
}
...

Compilar 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 atribuirá 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:

  • Todo código-fonte dos diretórios java/ é compilado junto para gerar uma única saída.

    Observação: para determinada variante de compilação, o Gradle aciona um erro de compilação se encontrar dois ou mais diretórios de conjuntos de origem que tenham definido a mesma classe Java. Por exemplo, ao compilar um APK de depuração, você não pode definir src/debug/Utility.java e src/main/Utility.java juntos. Isso se deve ao fato de que o Gradle examina ambos os diretórios durante o processo de compilação e aciona um erro "duplicate class". Se você quer ter diferentes versões do Utility.java para diferentes tipos de compilação, é possível fazer com que cada tipo de compilação defina sua própria versão do arquivo e não incluí-la no conjunto de origem de main/.

  • Os manifestos são combinados em um único manifesto. A prioridade é concedida na mesma ordem da lista acima. Ou seja, as configurações de manifesto para um tipo de compilação substituem as configurações de manifesto para uma variação de produto e assim por diante. Para saber mais, leia sobre a combinação de manifestos.
  • De forma parecida, os arquivos dos diretórios values/ são combinados. Se dois arquivos tiverem o mesmo nome, por exemplo, dois arquivos strings.xml, a prioridade será concedida na mesma ordem da lista acima. Ou seja, os valores definidos em um arquivo no conjunto de origem do tipo de compilação substituem os valores definidos no mesmo arquivo em uma variação de produto e assim por diante.
  • Os recursos dos diretórios res/ e asset/ são empacotados juntos. Se houver recursos com o mesmo nome definidos em dois ou mais conjuntos de origem, a prioridade é concedida na ordem da lista acima.
  • Por fim, o Gradle fornece aos recursos e manifestos incluídos com dependências de módulo de biblioteca na menor prioridade ao compilar o APK.

Declarar dependências

Você pode configurar uma dependência para uma variante de compilação ou um conjunto de origem de teste específico usando o nome da variante ou desse conjunto como prefixo antes da palavra-chave Implementation, como mostrado no exemplo a seguir.

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

Para mais informações, consulte Adicionar dependências de compilação.

Definir 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 ela. É 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 de assinatura dele, não será possível publicar nenhuma atualização para o aplicativo. Isso ocorre poque é preciso sempre assinar todas as versões do aplicativo com a mesma chave.

Assinatura de aplicativos do Wear OS

Na publicação de aplicativos do Wear OS, o APK do relógio e o APK opcional do telefone precisam ser assinados. Para obter mais informações sobre o empacotamento e a assinatura de aplicativos do Wear OS, consulte Empacotar aplicativos de wearables.