Configurar variações 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 para criar diferentes versões do app 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 app que pode ser criada. Por exemplo: você pode querer criar uma versão gratuita do app, com uma quantidade limitada de conteúdo, e uma versão paga com mais conteúdo. Você também pode criar versões do app que sejam direcionadas a diferentes dispositivos, com base no nível da API ou em outras variações de dispositivos. Entretanto, se quiser criar versões diferentes com base na ABI do dispositivo ou na densidade da tela, crie 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 produto que as formam.

Por exemplo, uma variação de produto "demo" (demonstração) 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" (depuração) 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 seu app e ela contém uma combinação das configurações e dos recursos incluídos na variação de produto “demo”, no tipo de compilação "debug" e no conjunto de origem 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 automaticamente para você os tipos de compilação de depuração e de lançamento. Apesar de o tipo de compilação de depuração não aparecer no arquivo de configuração, o Android Studio o configura com debuggable true. Isso permite depurar o app em dispositivos Android seguros e configura o APK, assinando-o com um keystore de depuração genérico.

É possível adicionar o tipo de compilação de depuração às suas configurações se você quiser adicionar ou alterar determinadas 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 de "preparo" que é inicializado usando 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 que aparece a cada alteração ou em Sync Project na barra de ferramentas. Se o Android Studio perceber erros na 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 (link em inglês).

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 você quiser. As variações de produtos têm compatibilidade com mesmas propriedades que defaultConfig, já que 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 modificar 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 main/. Você também precisa 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 applicationId para fornecer a cada variação de produto um código exclusivo para empacotamento e distribuição sem precisar alterar o código-fonte.

Todas as variações precisam pertencer a uma dimensão nomeada, que é um grupo de variações de produtos. É preciso atribuir variações a uma dimensão, mesmo que você pretenda usar somente uma 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 exemplo de código a seguir cria uma dimensão de variação chamada "versão" e adiciona variações de produto "demo" e "full" (completa). Esses tipos 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 seu app usando a compatibilidade com vários APKs no 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 app como apps separados no Google Play, você precisa atribuir um applicationId diferente a cada variante.

Depois de criar e configurar suas variações de produtos, clique em Sync Now na barra de notificações. Após a conclusão da sincronização, o Gradle cria variantes de compilação automaticamente com base nos seus tipos de compilação e nos tipos de produtos, e as nomeia de acordo com <product-flavor><Build-Type>. Por exemplo, se você criou as variações de produto "demo" e "full" e manteve os tipos de compilação padrão "debug" e "release" (lançamento), 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 criar e executar. Para fazer isso, basta acessar Build > Select Build Variant e selecionar uma opção no menu suspenso. Para começar a personalizar cada variante de compilação com os recursos dela, você precisará saber como criar e gerenciar conjuntos de origem.

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

Em alguns casos, você pode combinar as configurações de diferentes variações de produto. Por exemplo, recomendamos criar diferentes configurações para as variações de produto "full" e "demo" de acordo com o nível da API. Para fazer isso, o plug-in do Android para Gradle permite criar vários grupos de variações de produtos, chamados de dimensões de variação. Ao criar o app, 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.

Dica: para criar versões diferentes do seu app com base na ABI e na densidade da tela, você precisa criar 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" (modo) para agrupar as variações de produto "full" e "demo" e uma dimensão de variação "api" para agrupar as configurações de variação de produto de acordo com o 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, dos 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 nomenclatura:

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 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 criar 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 prioridade mais alta 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 das variações de produto e tipos de compilação que você configurar. No entanto, é possível que algumas variantes sejam desnecessárias ou não façam sentido no contexto do seu projeto. Você pode remover algumas configurações de variantes 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 compatibilidade somente com APIs de nível 23 e posterior para a versão de demonstração do app. É possível usar o bloco variantFilter para filtrar todas as configurações de variantes de compilação que combinam 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ções, 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 quando você clicar em Build > Select Build Variant na barra de menu (ou Build Variants na barra da janela de ferramentas).

Criar conjuntos de origem

Por padrão, o Android Studio cria o conjunto de origem 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 quais arquivos o Gradle precisa compilar e empacotar para tipos de compilação, variações de produtos (e combinações de variações de produtos ao usar dimensões de variação) e variantes de compilação específicos. Por exemplo, você pode definir funcionalidades básicas no conjunto de origem main/ e usar os conjuntos de origem da variação de produto para alterar a marca do seu app para diferentes clientes ou para incluir permissões especiais e funcionalidades de registro apenas para variantes de compilação que utilizem o tipo de compilação de depuração.

O Gradle espera que você organize os arquivos de conjuntos de origem e os diretórios de maneira específica, semelhante ao conjunto de origem main/. Por exemplo: o Gradle espera que os arquivos de classe Java específicos ao tipo de compilação "debug" estejam localizados no diretório src/debug/java/.

O plug-in do Android para 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. O exemplo de saída da tarefa a seguir descreve onde o Gradle espera encontrar determinados 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 ver essa saída, faça o seguinte:

  1. Clique em Gradle no lado direito da janela do ambiente de desenvolvimento integrado.
  2. Navegue até MyApplication > Tasks > android e clique duas vezes em sourceSets. Depois que o Gradle executar a tarefa, a janela Run 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ê quer usar para executar testes com o app, como os conjuntos de origem de teste de test/ e androidTest/.

Ao criar uma nova variante de compilação, o Android Studio não cria os diretórios de conjuntos de origem para você, mas oferece algumas opções que podem ajudar. Por exemplo, para criar apenas o diretório java/ para seu 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 até 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 de conjunto de origem para seu tipo de compilação de depuração e, em seguida, cria o diretório 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. No mesmo 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 criará os diretórios necessários automaticamente ao criar o arquivo XML. A estrutura de diretórios resultante será semelhante à Figura 2.

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

Usando 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, é possível criar conjuntos de origem para testes direcionados a variantes de compilação específicas, como 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 estão organizadas na estrutura padrão de arquivos de conjunto de origem que o Gradle espera, como descrito acima na seção sobre como criar conjuntos de origem, use o bloco sourceSets para alterar a forma como 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 espera encontrar os arquivos de cada componente do conjunto de origem. Para saber quais 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 plug-in Android para Gradle (link em inglês).

O exemplo de código a seguir mapeia as origens do diretório app/other/ para determinados componentes do conjunto de origem main e altera o diretório raiz do conjunto de 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 quer empacotar apenas com determinadas configurações. Por exemplo, se você estiver criando 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 da variante de compilação)
  2. src/debug/ (conjunto de origem do tipo de compilação)
  3. src/demo/ (conjunto de origem da 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 prioridade mais alta 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 prioridade mais alta 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 maior prioridade quando o Gradle combina código e recursos. Como o diretório do conjunto de origem demoDebug/ provavelmente contém arquivos específicos dessa variante de compilação, se demoDebug/ incluir um arquivo que também é definido em debug/, o Gradle usará o arquivo que se encontra no conjunto de origem demoDebug/. De forma similar, o Gradle atribui aos arquivos que se encontram nos conjuntos de origem de tipo de compilação e de variação de produto prioridade mais alta do que os mesmos arquivos presentes em main/. O Gradle considera essa ordem de prioridade ao aplicar as seguintes regras de compilação:

  • Todo o código-fonte nos diretórios java/ é compilado em conjunto para gerar uma só saída.

    Observação: para determinada variante de compilação, o Gradle gera 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 criar um APK de depuração, você não pode definir src/debug/Utility.java e src/main/Utility.java. Isso porque o Gradle examina ambos os diretórios durante o processo de compilação e gera um erro "duplicate class" (classe duplicada). Se você quiser ter diferentes versões do Utility.java para diferentes tipos de compilação, é possível fazer com que cada tipo de compilação defina a própria versão do arquivo e não a inclua no conjunto de origem main/.

  • Manifestos são mesclados em um único manifesto. A prioridade é dada 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 mesclagem de manifestos.
  • Da mesma forma, os arquivos nos diretórios values/ são mesclados. Se dois arquivos tiverem o mesmo nome, como 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.
  • Recursos nos 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 será concedida na ordem da lista acima.
  • Por fim, o Gradle fornece aos recursos e manifestos incluídos dependências de módulo de biblioteca na menor prioridade ao criar o APK.

Declarar dependências

Você pode configurar uma dependência para uma variante de compilação específica ou um conjunto de origem de teste prefixando o nome da variante ou testando o conjunto de origem 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 saber mais, 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 essa 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 compilação do Gradle:

  1. Crie um keystore. Um keystore é um arquivo binário que contém um conjunto de chaves privadas. É necessário manter o keystore em um local seguro e protegido.
  2. Crie uma chave privada. Uma chave privada representa a entidade a ser identificada com o app, 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 menu. 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 keystore dentro do arquivo de compilação não é uma prática de segurança recomendada. Como alternativa, você pode configurar o arquivo de compilação para receber essas senhas de variáveis de ambiente ou fazer com que o processo de compilação as solicite.

Para receber 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 você estiver invocando 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 seu app e publicá-lo no Google Play.

Aviso: mantenha o keystore e a chave privada em local seguro e protegido e confirme se os respectivos backups estão protegidos. Se você publicar um app no Google Play e perder a chave de assinatura dele, não será possível publicar nenhuma atualização. Isso ocorre porque é preciso sempre assinar todas as versões do app com a mesma chave.

Assinatura de apps do Wear OS

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