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. Este upgrade inclui melhor compatibilidade com determinadas dependências do SDK (incluindo o Kotlin 1.9), assim como algumas correções de bugs essenciais.
Esta versão principal do SDK exige as seguintes dependências de versão para seu Projeto do app Android:
- uma versão do Gradle no mínimo v7.5.0 e 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 é a 7.4 ou mais recente, 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
O AGP v7.4 ou versões mais recentes usa o R8 como a ferramenta padrão de redução, ofuscação e otimização. para o binário, então nenhuma ação especial é necessária nesse momento.
Se o projeto for migrado do AGP 4.0+, o AGP poderá emitir os seguintes avisos sobre a remoção 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 do Kotlin-synthetics para o caso do Plug-in do Kotlin para Gradle 1.6.X ou 1.7.X. Consulte a documentação de migração guia 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 será 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 dosetStatusListener
.
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 um
com o nível de status de erro.
Normalmente, use cause
para extrair o código do erro retornado pela frota.
Engine para atualizações de localização com falha.
O exemplo abaixo 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.
}
}
});