Configurar o plug-in da biblioteca do Android Gradle para KMP

O plug-in do Gradle com.android.kotlin.multiplatform.library é a ferramenta oficial para adicionar um destino do Android a um módulo de biblioteca do Kotlin Multiplatform (KMP). Ele simplifica a configuração do projeto, melhora a performance do build e oferece uma melhor integração com o Android Studio.

O uso do plug-in com.android.library para o desenvolvimento de KMP depende de APIs do Plug-in do Android para Gradle que foram descontinuadas e exigem ativação no Plug-in do Android para Gradle 9.0 e versões mais recentes (quarto trimestre de 2025). Essas APIs vão ser removidas no Plug-in do Android para Gradle 10.0 (segundo semestre de 2026).

Para aplicar esse plug-in, consulte a seção Aplicar o plug-in Android-KMP. Se você precisar migrar das APIs legadas, consulte o Guia de migração.

Para receber ajuda com a migração do AGP 9.0+, use a habilidade do agente criada pela JetBrains para apps KMP. Para mais informações sobre o uso de habilidades no Android Studio, consulte Ampliar o Modo Agente com habilidades. Lembre-se de que os resultados da IA não são totalmente previsíveis.

Principais recursos e diferenças

O plug-in Android-KMP é adaptado especificamente para projetos KMP e difere do plug-in com.android.library padrão em vários aspectos importantes:

  • Arquitetura de variante única:o plug-in usa uma única variante, removendo o suporte a variações de produtos e tipos de build, o que simplifica a configuração e melhora o desempenho do build.

  • Otimizado para KMP:o plug-in foi projetado para bibliotecas KMP, com foco em código Kotlin compartilhado e interoperabilidade, omitindo o suporte a builds nativos específicos do Android, AIDL e RenderScript.

  • Testes desativados por padrão:os testes de unidade e de dispositivo (instrumentação) são desativados por padrão para aumentar a velocidade do build. É possível ativá-los, se necessário.

  • Sem extensão do Android de nível superior:a configuração é processada com um bloco android na DSL do KMP do Gradle, mantendo uma estrutura de projeto KMP consistente. Não há um bloco de extensão android de nível superior.

  • Ativação da compilação Java:a compilação Java está desativada por padrão. Use withJava() no bloco android para ativá-lo. Isso melhora os tempos de build quando a compilação Java não é necessária.

Benefícios do plug-in da biblioteca Android-KMP

O plug-in Android-KMP oferece os seguintes benefícios para projetos KMP:

  • Melhoria no desempenho e na estabilidade do build:ele foi projetado para otimizar as velocidades de build e melhorar a estabilidade em projetos KMP. O foco nos fluxos de trabalho do KMP contribui para um processo de build mais eficiente e confiável.

  • Integração aprimorada com o ambiente de desenvolvimento integrado:oferece melhor preenchimento de código, navegação, depuração e experiência geral do desenvolvedor ao trabalhar com bibliotecas do Android para KMP.

  • Configuração simplificada do projeto:o plug-in simplifica a configuração para projetos KMP, removendo complexidades específicas do Android, como variantes de build. Isso resulta em arquivos de build mais limpos e fáceis de manter. Antes, o uso do plug-in com.android.library no projeto KMP podia criar nomes de conjuntos de origem confusos, como androidAndroidTest. Essa convenção de nomenclatura era menos intuitiva para desenvolvedores familiarizados com as estruturas de projeto padrão do KMP.

Soluções alternativas para recursos incompatíveis

Em comparação com a integração do KMP com o plug-in com.android.library, alguns recursos estão ausentes no plug-in com.android.kotlin.multiplatform.library. Confira as soluções alternativas para os recursos incompatíveis:

  • Variantes de build

    Não há suporte para tipos de build e variações de produtos. Isso ocorre porque o novo plug-in usa uma arquitetura de variante única, que simplifica a configuração e melhora o desempenho do build.

    Se você precisar de variantes de build, recomendamos criar um módulo de biblioteca do Android independente usando o plug-in com.android.library, configurar tipos de build e variações de produto nesse módulo e, em seguida, consumi-lo como uma dependência de projeto padrão do conjunto de origem androidMain da biblioteca multiplataforma do Kotlin. Para mais detalhes, consulte Criar uma biblioteca Android e Configurar variantes de build.

  • Vinculação de dados e vinculação de visualizações

    Esses são recursos do framework de interface específicos do Android, que estão intimamente ligados ao sistema de visualização do Android e aos layouts XML. Com o novo plug-in de biblioteca do Android-KMP, recomendamos que você processe a interface usando um framework multiplataforma, como o Compose Multiplatform. A vinculação de dados e de visualizações são consideradas detalhes de implementação de um app Android final, não uma biblioteca compartilhável.

  • Suporte nativo para builds

    O novo plug-in se concentra em produzir um AAR padrão para o destino do Android. A integração de código nativo no Kotlin Multiplatform é processada diretamente pelos destinos nativos do KMP (como androidNativeArm64 e androidNativeX86) e pela interoperabilidade com C. Se você precisar incluir código nativo em C/C++, defina-o como parte de um conjunto de origem comum ou nativo e configure a interoperabilidade em C no bloco kotlin, em vez de usar o mecanismo externalNativeBuild específico do Android.

    Como alternativa, se você precisar de suporte a build nativo via externalNativeBuild, nossa recomendação é criar um módulo com.android.library independente em que você possa integrar o código nativo e consumir essa biblioteca independente do conjunto de origem androidMain do projeto de biblioteca do Kotlin Multiplatform. Para mais detalhes, consulte Criar uma biblioteca do Android e Adicionar código C e C++ ao seu projeto.

  • Classe BuildConfig (link em inglês)

    O recurso BuildConfig é mais útil em ambientes com diversas variantes. Como o novo plug-in da biblioteca multiplataforma do Kotlin é independente de variantes e não oferece suporte a tipos de build e variações de produtos, esse recurso não está implementado. Como alternativa, recomendamos o uso do plug-in BuildKonfig ou de soluções semelhantes da comunidade para gerar metadados para todos os destinos.

Pré-requisitos

Para usar o plug-in com.android.kotlin.multiplatform.library, seu projeto precisa ser configurado com as seguintes versões mínimas ou mais recentes:

  • Plug-in do Android para Gradle (AGP): 8.10.0
  • Plug-in do Kotlin para Gradle (KGP): 2.0.0

Aplicar o plug-in Android-KMP a um módulo atual

Para aplicar o plug-in Android-KMP a um módulo de biblioteca KMP, siga estas etapas:

  1. Declare plug-ins no catálogo de versões. Abra o arquivo TOML do catálogo de versões (geralmente gradle/libs.versions.toml) e adicione a seção de definições de plug-ins:

    # To check the version number of the latest Kotlin release, go to
# https://kotlinlang.org/docs/releases.html

[versions]
androidGradlePlugin = "9.4.0"
kotlin = "KOTLIN_VERSION"

[plugins]
kotlin-multiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
android-kotlin-multiplatform-library = { id = "com.android.kotlin.multiplatform.library", version.ref = "androidGradlePlugin" }

  2. Aplique a declaração do plug-in no arquivo de build raiz. Abra o arquivo build.gradle.kts localizado no diretório raiz do projeto. Adicione os aliases do plug-in ao bloco plugins usando apply false. Isso disponibiliza os aliases do plug-in para todos os subprojetos sem aplicar a lógica do plug-in ao projeto raiz.

    Kotlin

    // Root build.gradle.kts file

plugins {
   alias(libs.plugins.kotlin.multiplatform) apply false

   // Add the following
   alias(libs.plugins.android.kotlin.multiplatform.library) apply false
}

    Groovy

    // Root build.gradle file

plugins {
   alias(libs.plugins.kotlin.multiplatform) apply false

   // Add the following
   alias(libs.plugins.android.kotlin.multiplatform.library) apply false
}

  3. Aplique o plug-in em um arquivo de build do módulo de biblioteca do KMP. Abra o arquivo build.gradle.kts no módulo da biblioteca KMP e aplique o plug-in na parte de cima do arquivo, dentro do bloco plugins:

    Kotlin

    // Module-specific build.gradle.kts file

plugins {
   alias(libs.plugins.kotlin.multiplatform)

   // Add the following
   alias(libs.plugins.android.kotlin.multiplatform.library)
}

    Groovy

    // Module-specific build.gradle file

plugins {
   alias(libs.plugins.kotlin.multiplatform)

   // Add the following
   alias(libs.plugins.android.kotlin.multiplatform.library)
}

  4. Configurar o destino do KMP para Android. Configure o bloco do Kotlin Multiplatform (kotlin) para definir o destino do Android. No bloco kotlin, especifique o destino do Android usando android:

    Kotlin

    kotlin {
   android {
       namespace = "com.example.kmpfirstlib"
       compileSdk = 33
       minSdk = 24

       withJava() // enable java compilation support
       withHostTestBuilder {}.configure {}
       withDeviceTestBuilder {
           sourceSetTreeName = "test"
       }

       compilerOptions.configure {
           jvmTarget.set(
               org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8
           )
       }
   }

   sourceSets {
       androidMain {
           dependencies {
               // Add Android-specific dependencies here
           }
       }
       getByName("androidHostTest") {
           dependencies {
           }
       }

       getByName("androidDeviceTest") {
           dependencies {
           }
       }
   }
   // ... other targets (JVM, iOS, etc.) ...
}

    Groovy

    kotlin {
   android {
       namespace = "com.example.kmpfirstlib"
       compileSdk = 33
       minSdk = 24

       withJava() // enable java compilation support
       withHostTestBuilder {}.configure {}
       withDeviceTestBuilder {
           it.sourceSetTreeName = "test"
       }

       compilerOptions.options.jvmTarget.set(
           org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8
       )
   }

   sourceSets {
       androidMain {
           dependencies {
           }
       }
       androidHostTest {
           dependencies {
           }
       }
       androidDeviceTest {
           dependencies {
           }
       }
   }
   // ... other targets (JVM, iOS, etc.) ...
}

  5. Implementar mudanças Depois de aplicar o plug-in e configurar o bloco kotlin, sincronize o projeto do Gradle para aplicar as mudanças.

Migrar do plug-in legado

Este guia ajuda você a migrar do plug-in legado com.android.library para o plug-in com.android.kotlin.multiplatform.library.

1. Mover fontes

O plug-in legado permitia usar os conjuntos de origem src/main, src/test e src/androidTest, além de src/androidMain, src/androidHostTest e src/androidDeviceTest. O novo plug-in usa apenas os diretórios de origem mais recentes. Portanto, você precisará mover as origens de src/main para src/androidMain, de src/test para src/androidHostTest e de src/androidTest para src/androidDeviceTest.

2. Configurar diretórios de origem e de recursos personalizados

Se você tiver origens ou recursos em diretórios não padrão, eles foram configurados anteriormente usando o bloco sourceSets. Com o novo plug-in, use a extensão androidComponents para adicionar diretórios de origem estáticos à variante.

Com o novo plug-in, o método addStaticSourceDirectory adiciona o diretório à lista de diretórios de origem. Com o plug-in legado, o método setSrcDirs substitui a lista, enquanto o método srcDir adiciona a ela.

Android-KMP

Com o novo plug-in, use o bloco onVariants para interagir com as origens da variante.

// build.gradle.kts

androidComponents {
    onVariants { variant ->
        // Add a directory for Kotlin sources
        variant.sources.kotlin?.addStaticSourceDirectory("other/kotlin")

        // Add a directory for Android assets
        variant.sources.assets?.addStaticSourceDirectory("other/assets")
    }
}

Plug-in legado

Com o plug-in com.android.library, o bloco sourceSets era usado para definir ou adicionar diretórios de origem.

// build.gradle.kts

android {
    sourceSets {
        getByName("main") {
            // Replaces the directory for Kotlin sources.
            kotlin.setSrcDirs(listOf("other/kotlin"))

            // Appends a directory for assets.
            assets.srcDir("other/assets")
        }
    }
}

3. Declarar dependências

Uma tarefa comum é declarar dependências para conjuntos de origem específicos do Android. O novo plug-in exige que eles sejam colocados explicitamente no bloco sourceSets, ao contrário do bloco geral dependencies usado anteriormente.

Android-KMP

O novo plug-in promove uma estrutura mais limpa ao agrupar as dependências do Android no conjunto de origem androidMain. Além do conjunto de origem principal, há dois conjuntos de origem de teste, que são criados sob demanda: androidDeviceTest e androidHostTest (consulte Configurar testes de host e dispositivo para mais informações).

// build.gradle.kts

kotlin {
    android {}
    //... other targets

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")
        }

        // Dependencies are now scoped to the specific Android source set
        androidMain.dependencies {
            implementation("androidx.appcompat:appcompat:1.7.0")
            implementation("com.google.android.material:material:1.11.0")
        }
    }
}

Os conjuntos de origem têm compilações do Kotlin correspondentes chamadas main, deviceTest e hostTest. Os conjuntos de origem e as compilações podem ser configurados no script de build desta forma:

// build.gradle.kts

kotlin {
    android {
        compilations.getByName("deviceTest") {
            kotlinOptions.languageVersion = "2.0"
        }
    }
}

Plug-in legado

Com o plug-in legado, era possível declarar dependências específicas do Android no bloco de dependências de nível superior, o que às vezes podia ser confuso em um módulo multiplataforma.

// build.gradle.kts

kotlin {
  androidTarget()
  //... other targets
}

// Dependencies for all source sets were often mixed in one block
dependencies {
  // Common dependencies
  commonMainImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")

  // Android-specific dependencies
  implementation("androidx.appcompat:appcompat:1.7.0")
  implementation("com.google.android.material:material:1.11.0")
}

4. Ativar recursos do Android

O suporte a recursos do Android (pastas res) não é ativado por padrão com o novo plug-in para otimizar o desempenho do build. Para usar, é preciso fazer a ativação. Essa mudança ajuda a garantir que os projetos que não exigem recursos específicos do Android não sejam sobrecarregados pela sobrecarga de build associada.

Android-KMP

É preciso ativar explicitamente o processamento de recursos do Android. Os recursos precisam ser colocados em src/androidMain/res.

// build.gradle.kts

kotlin {
  android {
    // ...
    // Enable Android resource processing
    androidResources {
      enable = true
    }
  }
}

// Project Structure
// └── src
//     └── androidMain
//         └── res
//             ├── values
//             │   └── strings.xml
//             └── drawable
//                 └── icon.xml

Plug-in legado

O processamento de recursos foi ativado por padrão. Você pode adicionar imediatamente um diretório res em src/main e começar a adicionar drawables XML, valores etc.

// build.gradle.kts

android {
    namespace = "com.example.library"
    compileSdk = 34
    // No extra configuration was needed to enable resources.
}

// Project Structure
// └── src
//     └── main
//         └── res
//             ├── values
//             │   └── strings.xml
//             └── drawable
//                 └── icon.xml

5. Configurar testes de host e de dispositivo

Por padrão, o novo plug-in desativa os testes do Android do lado do host (unidade) e do lado do dispositivo (instrumentados). É necessário ativar explicitamente a criação dos conjuntos de origem e das configurações de teste, enquanto o plug-in legado os criava automaticamente.

Esse modelo de ativação ajuda a verificar se o projeto permanece enxuto e inclui apenas a lógica de build e os conjuntos de origem que você usa ativamente.

Android-KMP

Com o novo plug-in, você ativa e configura testes dentro do bloco kotlin.android. Isso torna a configuração mais explícita e evita a criação de componentes de teste não utilizados. O conjunto de origem androidUnitTest se torna androidHostTest (o diretório de teste muda de src/androidUnitTest para src/androidHostTest), e androidInstrumentedTest se torna androidDeviceTest (o diretório de teste muda de src/androidInstrumentedTest para src/androidDeviceTest).

// build.gradle.kts

kotlin {
  android {
    // ...

    // Opt-in to enable and configure host-side (unit) tests
    withHostTest {
      isIncludeAndroidResources = true
    }

    // Opt-in to enable and configure device-side (instrumented) tests
    withDeviceTest {
      instrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
      execution = "HOST"
    }
  }
}

// Project Structure (After Opt-in)
// └── src
//     ├── androidHostTest
//     └── androidDeviceTest

Plug-in legado

Com o plug-in com.android.library, os conjuntos de origem androidUnitTest e androidInstrumentedTest são criados por padrão. Configure o comportamento deles dentro do bloco android, normalmente usando a DSL testOptions.

// build.gradle.kts

android {
  defaultConfig {
    // Runner was configured in defaultConfig
    testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
  }

  testOptions {
    // Configure unit tests (for the 'test' source set)
    unitTests.isIncludeAndroidResources = true

    // Configure device tests (for the 'androidTest' source set)
    execution = "HOST"
  }
}

// Project Structure (Defaults)
// └── src
//     ├── test
//     └── androidTest

6. Ativar a compilação de origem Java

Se a biblioteca KMP precisar compilar fontes Java para o destino do Android, ative explicitamente essa funcionalidade com o novo plug-in. Isso ativa a compilação para arquivos Java localizados diretamente no projeto, não para as dependências dele. O método para definir a versão de destino da JVM do compilador Java e Kotlin também muda.

Android-KMP

É preciso ativar a compilação do Java chamando withJava(). O destino da JVM agora é configurado diretamente dentro do bloco kotlin { android {} } para uma configuração mais unificada. Definir jvmTarget aqui se aplica à compilação do Kotlin e do Java para o destino do Android.

// build.gradle.kts

kotlin {
  android {
    //  Opt-in to enable Java source compilation
    withJava()
    // Configure the JVM target for both Kotlin and Java sources
    compilerOptions {
      jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8)
    }
  }
  // ...
}

// Project Structure:
// └── src
//     └── androidMain
//         ├── kotlin
//         │   └── com/example/MyKotlinClass.kt
//         └── java
//             └── com.example/MyJavaClass.java

Plug-in legado

A compilação Java foi ativada por padrão. O destino da JVM para as origens Java e Kotlin foi definido no bloco android usando compileOptions.

// build.gradle.kts

android {
  // ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

kotlin {
  androidTarget {
    compilations.all {
      kotlinOptions.jvmTarget = "1.8"
    }
  }
}

7. Interagir com variantes de build usando androidComponents

A extensão androidComponents ainda está disponível para interagir com artefatos de build de forma programática. Embora grande parte da API Variant permaneça igual, a nova interface AndroidKotlinMultiplatformVariant é mais limitada porque o plug-in produz apenas uma única variante.

Consequentemente, as propriedades relacionadas a tipos de build e variações de produto não estão mais disponíveis no objeto de variante.

Android-KMP

O bloco onVariants agora itera em uma única variante. Ainda é possível acessar propriedades comuns, como name e artifacts, mas não as específicas do tipo de build.

// build.gradle.kts

androidComponents {
  onVariants { variant ->
      val artifacts = variant.artifacts
  }
}

Plug-in legado

Com várias variantes, é possível acessar propriedades específicas do tipo de build para configurar tarefas.

// build.gradle.kts

androidComponents {
  onVariants(selector().withBuildType("release")) { variant ->
    // ...
  }
}

8. Selecionar variantes de dependências da biblioteca do Android

Sua biblioteca KMP produz uma única variante para Android. No entanto, você pode depender de uma biblioteca Android padrão (com.android.library) que tenha várias variantes (por exemplo, variações de produto free/paid). Controlar como o projeto seleciona uma variante dessa dependência é um requisito comum.

Android-KMP

O novo plug-in centraliza e esclarece essa lógica no bloco kotlin.android.localDependencySelection. Isso deixa muito mais claro quais variantes de dependências externas serão selecionadas para sua biblioteca KMP de variante única.

// build.gradle.kts
kotlin {
  android {
    localDependencySelection {
      // For dependencies with multiple build types, select 'debug' first, and 'release' in case 'debug' is missing
      selectBuildTypeFrom.set(listOf("debug", "release"))

      // For dependencies with a 'type' flavor dimension...
      productFlavorDimension("type") {
        // ...select the 'typeone' flavor.
        selectFrom.set(listOf("typeone"))
      }
    }
  }
}

Plug-in legado

Você configurou estratégias de seleção de dependências dentro dos blocos buildTypes and productFlavors. Isso geralmente envolvia o uso de missingDimensionStrategy para fornecer uma variação padrão para uma dimensão que sua biblioteca não tinha ou matchingFallbacks em uma variação específica para definir uma ordem de pesquisa.

Consulte Resolver erros de correspondência para mais informações detalhadas sobre o uso da API.

9. Adicionar dependências de prévia do Compose

Normalmente, queremos ter bibliotecas específicas com escopo para nosso ambiente de desenvolvimento local para evitar que ferramentas internas vazem para o artefato publicado final. Isso se torna um desafio com o novo plug-in do Android para KMP, porque ele remove a arquitetura de tipo de build usada para separar as dependências de desenvolvimento do código de lançamento.

Android-KMP

Para adicionar uma dependência apenas para desenvolvimento e teste locais, adicione-a diretamente à configuração do caminho de classe de execução (no bloco dependencies de nível superior) da compilação principal do Android. Isso ajuda a garantir que a dependência esteja disponível no momento da execução (por exemplo, para ferramentas como Compose Preview), mas não faça parte do caminho de classe de compilação ou da API publicada da sua biblioteca.

// build.gradle.kts
dependencies {
  "androidRuntimeClasspath"(libs.androidx.compose.ui.tooling)
}

Plug-in legado

Os projetos multiplataforma do Kotlin que usam o plug-in com.android.library para o destino do Android precisam usar a configuração debugImplementation, que define o escopo da dependência para o tipo de build de depuração e impede que ela seja incluída na variante de lançamento da biblioteca usada pelos consumidores.

// build.gradle.kts
dependencies {
  debugImplementation(libs.androidx.compose.ui.tooling)
}

10. Configurar o destino da JVM para o destino do Android do KMP

O plug-in do Android para KMP define o destino da JVM usando android.compilerOptions.jvmTarget, que se aplica ao Java e ao Kotlin, simplificando a configuração em comparação com os blocos compileOptions e kotlinOptions separados em projetos puros do Android.

Android-KMP

Ao trabalhar com um projeto do Kotlin Multiplatform (KMP) que inclui um destino do Android, há várias maneiras de configurar a versão de destino da JVM para os compiladores Kotlin e Java. Entender o escopo e a hierarquia dessas configurações é fundamental para gerenciar a compatibilidade de bytecode do seu projeto.

Confira as três principais maneiras de definir o destino da JVM, ordenadas da menor para a maior precedência. Os valores de destino da JVM que têm maior precedência se aplicam a um subconjunto menor dos alvos configurados e substituem os valores que têm menor precedência. Isso significa que é possível definir diferentes versões da JVM para diferentes destinos e compilações dentro de destinos no seu projeto.

Como usar o conjunto de ferramentas do Kotlin (menor precedência)

A maneira mais geral de definir o destino da JVM é especificando o conjunto de ferramentas no bloco kotlin do arquivo build.gradle.kts. Essa abordagem define o destino para as tarefas de compilação do Kotlin e do Java em todos os destinos baseados em JVM no seu projeto, incluindo o Android.

// build.gradle.kts
kotlin {
    jvmToolchain(21)
}

Essa configuração faz com que kotlinc e javac segmentem a JVM 21. Essa é uma ótima maneira de estabelecer uma referência consistente para todo o projeto.

Como usar as opções do compilador de nível de destino do Android (prioridade média)

É possível especificar o destino da JVM especificamente para o destino do KMP do Android no bloco android. Essa configuração substitui a configuração jvmToolchain em todo o projeto e se aplica a todas as compilações do Android.

// build.gradle.kts
kotlin {
    android {
        compilerOptions {
            jvmTarget.set(JvmTarget.JVM_11)
        }
    }
}

Nesse caso, mesmo que um jvmToolchain seja definido como uma versão diferente, o código Kotlin e Java do destino do Android será compilado para segmentar a JVM 11.

Como usar opções do compilador no nível da compilação (precedência mais alta)

Para ter o controle mais granular, configure as opções do compilador por compilação (por exemplo, apenas em androidMain ou androidHostTest). Isso é útil se uma compilação específica precisar segmentar uma versão diferente da JVM. Essa configuração substitui o conjunto de ferramentas do Kotlin e as opções de nível de destino do Android.

// build.gradle.kts
kotlin {
    android {
        compilations.all {
            compileTaskProvider.configure {
                compilerOptions.jvmTarget.set(JvmTarget.JVM_11)
            }
        }
    }
}

Essa configuração ajuda a garantir que todas as compilações no destino do Android usem a JVM 11, oferecendo um controle detalhado.

Plug-in legado

Em um projeto KMP que usa o plug-in padrão da biblioteca do Android (com.android.library), a configuração é um pouco diferente de quando você usa o plug-in do Android para KMP, mas conceitualmente semelhante.

Como usar o conjunto de ferramentas do Kotlin

O método kotlin.jvmToolchain() funciona de maneira idêntica, definindo sourceCompatibility e targetCompatibility para Java e jvmTarget para Kotlin. Recomendamos o uso dessa abordagem.

// build.gradle.kts
kotlin {
    jvmToolchain(21)
}

compileOptions e kotlinOptions

Se você não usar o conjunto de ferramentas do Kotlin, vai precisar configurar os destinos da JVM usando blocos separados para Java e Kotlin.

// build.gradle.kts
android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    kotlinOptions {
        jvmTarget = "11"
    }
}

11. Publicar regras de retenção do consumidor

Se a biblioteca KMP precisar enviar regras de manutenção do consumidor (como regras do ProGuard para o R8) para os consumidores, será necessário ativar explicitamente a publicação com o novo plug-in. Antes, as regras de retenção do consumidor eram publicadas por padrão, se especificadas.

Android-KMP

Com o novo plug-in, é necessário definir optimization.consumerKeepRules.publish = true e especificar arquivos de regras no bloco consumerKeepRules para publicar regras de manutenção do consumidor.

// build.gradle.kts
kotlin {
  android {
    optimization {
      consumerKeepRules.apply {
        publish = true
        file("consumer-proguard-rules.pro")
      }
    }
  }
}

Plug-in legado

Com com.android.library, todos os arquivos de regras especificados com consumerProguardFiles em android.defaultConfig são publicados nos artefatos da biblioteca por padrão.

// build.gradle.kts
android {
  defaultConfig {
    consumerProguardFiles("consumer-proguard-rules.pro")
  }
}

12. Publicar sua biblioteca no Maven

Se você planeja publicar sua biblioteca KMP no Maven para consumo por outros projetos, o processo varia dependendo se você está usando o novo plug-in Android-KMP ou o plug-in legado.

Android-KMP

O plug-in com.android.kotlin.multiplatform.library se integra aos mecanismos de publicação padrão do Kotlin Multiplatform. Não há etapas específicas do Android além do processo padrão de publicação da biblioteca KMP.

Para publicar sua biblioteca, siga a documentação oficial da JetBrains: Configurar a publicação de uma biblioteca multiplataforma (link em inglês).

Plug-in legado

Ao usar com.android.library para o destino do Android em um projeto KMP, siga o guia padrão de publicação de bibliotecas do Android para preparar e publicar o artefato específico do Android (.aar).

Para instruções detalhadas, consulte Preparar sua biblioteca para lançamento.

Referência da API do plug-in

O novo plug-in tem uma plataforma de API diferente de com.android.library. Para informações detalhadas sobre a nova DSL e as interfaces, consulte as referências da API:

Problemas conhecidos com o plug-in da biblioteca Android-KMP

Estes são os problemas conhecidos que podem ocorrer ao aplicar o novo plug-in com.android.kotlin.multiplatform.library: