Este guia descreve as mudanças necessárias para migrar para a versão 5.0.
Atualizações do Gradle e do Plug-in do Android para Gradle
Fazer upgrade das versões do Gradle e do Plug-in do Android para Gradle
Primeiro, faça upgrade das versões do Gradle e do Plug-in do Android para Gradle. Esse upgrade inclui melhor compatibilidade com algumas dependências do SDK (incluindo o Kotlin 1.9), além de algumas correções de bugs importantes.
Esta versão principal do SDK requer as seguintes dependências de versão para seu projeto de aplicativo Android:
- uma versão do Gradle pelo menos v7.5.0, mas não superior à v7.6.0.
- uma versão do Plug-in do Android para Gradle (AGP, na sigla em inglês) na faixa v7.4.x.
Você pode segmentar uma versão superior dos plug-ins; No entanto, é possível executar em avisos de descontinuação ou alguns recursos novos podem não funcionar.
Para modificar a versão do Gradle, modifique a linha no arquivo
/gradle/wrapper/gradle-wrapper.properties
arquivo
distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
Para modificar a versão do Plug-in do Android para Gradle, modifique o arquivo build.gradle
que
contém o bloco buildscript
. Exemplo:
buildscript {
repositories {
google()
mavenCentral()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:7.4.1'
}
}
Migração de suporte da biblioteca Java 7 para Java 8
Etapa 1: ativar o suporte à biblioteca Java 8
Como o nível mínimo da API do SDK é 23 e a versão necessária do AGP é 7.4 ou mais recente, a configuração é um pouco diferente da documentação de origem mencionada.
buildscript {
repositories {
google()
mavenCentral()
jcenter()
maven {
url = uri("https://storage.googleapis.com/r8-releases/raw")
}
}
dependencies {
classpath 'com.android.tools:r8:8.0.46'
classpath 'com.android.tools.build:gradle:7.4.1'
}
}
android {
compileOptions {
// Flag to enable support for the new language APIs
coreLibraryDesugaringEnabled true
// Sets Java compatibility to Java 8
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs_nio:2.0.3'
}
Etapa 2: migrar do Proguard ou Dexguard para o R8
A AGP v7.4 ou mais recente usa o R8 como a ferramenta de redução, ofuscação e otimização padrão para o binário. Portanto, nenhuma ação especial é necessária neste momento.
Se o projeto for migrado do AGP 4.0 ou versões mais recentes, o AGP poderá emitir os seguintes avisos sobre remoções de arquivos:
- Uso de
useProguard true
no arquivobuild.gradle
- Uso de
android.enableR8=false
no arquivogradle.properties
A remoção dessas linhas geralmente resolve esses problemas.
Migração do Kotlin 1.6 para 1.9
Etapa 1: migrar para o plug-in do Gradle para Kotlin 1.9.0
Atualizar a versão do plug-in do Gradle para Kotlin no módulo de nível superior do seu aplicativo
build.gradle do módulo. Não se esqueça de adicionar org.jetbrains.kotlin:kotlin-gradle-plugin
nas dependências do bloco buildscript, caso ele esteja ausente.
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.9.0"
}
}
Você precisa migrar seu aplicativo de Kotlin-synthetics caso esteja usando o Plug-in do Kotlin para Gradle 1.6.X ou 1.7.X. Consulte o guia oficial de migração para mais informações.
Etapa 2: fazer upgrade da kotlin-stdlib para a versão 1.9.0
Faça upgrade da kotlin-stblib
para a versão 1.9.0 no arquivo build.gradle do app.
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib:1.9.0"
}
Remova todas as referências a kotlin-stdlib-jdk7
ou
kotlin-stdlib-jdk8
. As duas dependências foram consolidadas em
kotlin-stdlib
a partir do Kotlin
1.8.0.
Descontinuação do StatusListener
A interface StatusListener
foi descontinuada (será removida na v6) e substituída
de DriverStatusListener
.
Há três mudanças principais:
- Mude a interface
implements
deStatusListener
paraDriverStatusListener
- Adicione um parâmetro
cause
Nullable
aupdateStatus
. - Chame
DriverContextBuilder.setDriverStatusListener
em vez desetStatusListener
.
DriverStatusListener
compartilha a mesma estrutura de StatusListener
. O principal
a diferença entre eles é que DriverStatusListener.updateStatus()
usa uma
parâmetro extra chamado cause
. Isso fornece aos usuários insights sobre a causa de uma
atualização com nível de status de erro.
Normalmente, você usaria cause
para recuperar o código de erro retornado pelo Fleet
Engine para atualizações de local com falha.
O exemplo a seguir ilustra como implementar StatusListener
:
class MyStatusListener implements StatusListener {
/** Called when background status is updated during actions such as location reporting. */
@Override
public void updateStatus(
StatusLevel statusLevel, StatusCode statusCode, String statusMsg) {
// Implementation
}
}
// Inject StatusListener into DriverContext.
DriverContextBuilder.setStatusListener(new MyStatusListener());
Confira a seguir um exemplo de implementação de DriverStatusListener
:
class MyStatusListener implements DriverStatusListener {
/** Called when background status is updated during actions such as location reporting. */
@Override
public void updateStatus(
StatusLevel statusLevel, StatusCode statusCode, String statusMsg, @Nullable Throwable cause) {
// Existing implementation
if (cause != null && cause instanceof StatusRuntimeException) {
if (Status.NOT_FOUND.getCode().equals(cause.getStatus().getCode())) {
// NOT_FOUND gRPC exception thrown by Fleet Engine.
}
}
}
}
DriverContextBuilder.setStatusListener(new MyStatusListener());
Implementar DriverStatusListener
como uma interface funcional
O DriverStatusListener
é compatível com interfaces funcionais Java, assim como as
predecessor. Aqui está um exemplo:
DriverContextBuilder.setDriverStatusListener((statusLevel, statusCode, statusMsg, cause) -> {
if (cause != null && cause instanceof StatusRuntimeException) {
if (Status.NOT_FOUND.getCode().equals(cause.getStatus().getCode())) {
// NOT_FOUND gRPC exception thrown by Fleet Engine.
}
}
});