Questa guida descrive le modifiche necessarie per eseguire la migrazione alla versione 5.0.
Aggiornamenti per Gradle e il plug-in Android Gradle
Esegui l'upgrade delle versioni del plug-in Gradle e Android Gradle
Innanzitutto, esegui l'upgrade delle versioni del plug-in Gradle per Gradle e Android. Questo upgrade include una migliore compatibilità con determinate dipendenze dell'SDK (incluso Kotlin 1.9), oltre ad alcune correzioni di bug critici.
Questa release principale dell'SDK richiede le seguenti dipendenze di versione per il tuo Progetto app Android:
- Una versione Gradle almeno alla v7.5.0 ma non successiva alla v7.6.0.
- una versione del plug-in Android Gradle (AGP) nella gamma v7.4.x.
Puoi scegliere come target una versione successiva dei plug-in; ma potresti eseguire agli avvisi di ritiro, oppure alcune nuove funzionalità potrebbero non funzionare.
Per modificare la versione Gradle, modifica la riga nel
File /gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
Per modificare la versione del plug-in Android Gradle, modifica il file build.gradle
che
contiene il blocco buildscript
. Ad esempio:
buildscript {
repositories {
google()
mavenCentral()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:7.4.1'
}
}
Migrazione da Java 7 a Java 8
Passaggio 1: attiva il supporto della libreria Java 8
Poiché il livello API minimo dell'SDK è 23 e la versione AGP richiesta è 7.4 o successive, il è leggermente diversa dalla documentazione dell'origine menzionata.
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'
}
Passaggio 2 - Migrazione da ProGuard o Dexguard a R8
AGP 7.4+ utilizza R8 come strumento predefinito di riduzione, offuscamento e ottimizzazione per il file binario, quindi a questo punto non è necessaria alcuna azione speciale.
Se viene eseguita la migrazione del progetto da AGP 4.0 o versioni successive, AGP potrebbe visualizzare i seguenti avvisi informazioni sulle rimozioni di file:
- Utilizzo di
useProguard true
inbuild.gradle
file - Utilizzo di
android.enableR8=false
ingradle.properties
file
La rimozione di queste righe in genere risolve i problemi.
Migrazione dalla versione 1.6 alla versione 1.9 di Kotlin
Passaggio 1 - Migrazione al plug-in Kotlin Gradle 1.9.0
Aggiorna la versione del plug-in Kotlin Gradle nel modulo di primo livello dell'applicazione
il file build.gradle. Assicurati di aggiungere org.jetbrains.kotlin:kotlin-gradle-plugin
nelle dipendenze del blocco buildscript nel caso in cui mancasse.
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.9.0"
}
}
Se partecipi, devi eseguire la migrazione della tua applicazione dai sintetici Kotlin dal plug-in Kotlin Gradle 1.6.X o 1.7.X. Consulta il documento ufficiale sulla migrazione per ulteriori informazioni.
Passaggio 2 - Esegui l'upgrade di kotlin-stdlib alla versione 1.9.0
Esegui l'upgrade di kotlin-stblib
alla versione 1.9.0 nel file build.gradle dell'applicazione.
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib:1.9.0"
}
Assicurati di rimuovere tutti i riferimenti a kotlin-stdlib-jdk7
o
kotlin-stdlib-jdk8
. Entrambe le dipendenze sono state consolidate
kotlin-stdlib
che inizia a Kotlin
1.8.0.
Ritiro di StatusListener
L'interfaccia StatusListener
è stata ritirata (da rimuovere nella versione 6)
di DriverStatusListener
.
Ci sono principalmente tre cambiamenti:
- Cambia l'interfaccia di
implements
daStatusListener
aDriverStatusListener
. - Aggiungi un parametro
Nullable
cause
aupdateStatus
. - Chiama il
DriverContextBuilder.setDriverStatusListener
anziché ilsetStatusListener
.
DriverStatusListener
condivide la stessa struttura di StatusListener
. Il principale
differenza tra loro è che DriverStatusListener.updateStatus()
prende
parametro aggiuntivo denominato cause
. Fornisce agli utenti approfondimenti sulla causa di un
vengono aggiornate con il livello di stato di errore.
In genere, si utilizza cause
per recuperare il codice di errore restituito dal parco risorse
Motore per aggiornamenti della posizione non riusciti.
L'esempio seguente illustra come implementare 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());
Di seguito è riportata un'implementazione di esempio di 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());
Implementa DriverStatusListener
come interfaccia funzionale
DriverStatusListener
supporta le interfacce funzionali Java come
precedente. Ecco un esempio:
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.
}
}
});