Migrationsanleitung für Android Driver SDK 5.0

In diesem Leitfaden werden die Änderungen beschrieben, die für die Migration zu Version 5.0 erforderlich sind.

Aktualisierungen von Gradle und dem Android-Gradle-Plug-in

Gradle- und Android-Gradle-Plug-in-Versionen aktualisieren

Führen Sie zuerst ein Upgrade der Gradle- und Android-Gradle-Plug-in-Versionen durch. Dieses Upgrade bietet eine bessere Kompatibilität mit bestimmten SDK-Abhängigkeiten (einschließlich Kotlin 1.9) sowie einige wichtige Fehlerkorrekturen.

Für diese Hauptversion des SDK sind die folgenden Versionsabhängigkeiten für Ihr Android-Anwendungsprojekt erforderlich:

  • eine Gradle-Version von mindestens 7.5.0, aber nicht höher als 7.6.0.
  • ein Android-Gradle-Plug-in (AGP) der Version 7.4.x

Sie können auch eine höhere Version der Plug-ins anvisieren. Möglicherweise erhalten Sie dann jedoch Warnungen zur Einstellung oder einige neue Funktionen funktionieren nicht.

Wenn Sie die Gradle-Version ändern möchten, ändern Sie die Zeile in der /gradle/wrapper/gradle-wrapper.properties-Datei Ihres Projekts.

distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip

Wenn Sie die Version des Android-Gradle-Plug-ins ändern möchten, ändern Sie die Datei build.gradle, die den Block buildscript enthält. Beispiel:

buildscript {
    repositories {
        google()
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:7.4.1'
    }
}

Migration von Java 7-Bibliotheken zu Java 8

Schritt 1: Unterstützung für Java 8-Bibliothek aktivieren

Quelle

Da das minimale API-Level des SDK 23 ist und die erforderliche AGP-Version 7.4 oder höher ist, unterscheidet sich die Konfiguration geringfügig von der genannten Quelldokumentation.

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'
}

Schritt 2: Von ProGuard oder Dexguard zu R8 migrieren

R8, Quelle

AGP v7.4 und höher verwendet R8 als Standard-Tool zum Schrumpfen, Verschleieren und Optimieren des Binärcodes. Daher sind derzeit keine besonderen Maßnahmen erforderlich.

Wenn das Projekt von AGP 4.0 oder höher migriert wird, werden in AGP möglicherweise die folgenden Warnungen zu Dateientfernungen ausgegeben:

  • useProguard true-Nutzung in der build.gradle-Datei
  • android.enableR8=false-Nutzung in der gradle.properties-Datei

In der Regel lassen sich diese Probleme durch Entfernen dieser Zeilen beheben.

Migration von Kotlin 1.6 auf 1.9

Schritt 1: Zum Kotlin Gradle-Plug-in 1.9.0 migrieren

Quelle

Aktualisieren Sie die Version des Kotlin-Gradle-Plug-ins in der Datei „build.gradle“ des Moduls auf der obersten Ebene Ihrer Anwendung. Fügen Sie org.jetbrains.kotlin:kotlin-gradle-plugin gegebenenfalls den Abhängigkeiten aus dem Block „buildscript“ hinzu.

buildscript {
  dependencies {
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.9.0"
  }
}

Wenn Sie das Kotlin Gradle-Plug-in 1.6.X oder 1.7.X verwenden, müssen Sie Ihre Anwendung von Kotlin-Synthesen migrieren. Weitere Informationen finden Sie in der offiziellen Migrationsanleitung.

Schritt 2: kotlin-stdlib auf Version 1.9.0 aktualisieren

Quelle

Aktualisieren Sie kotlin-stblib in der Datei „build.gradle“ Ihrer Anwendung auf 1.9.0.

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.9.0"
}

Entfernen Sie alle Verweise auf kotlin-stdlib-jdk7 oder kotlin-stdlib-jdk8. Beide Abhängigkeiten wurden ab Kotlin 1.8.0 in kotlin-stdlib zusammengeführt.

Einstellung von StatusListener

Die StatusListener-Benutzeroberfläche wird eingestellt und in Version 6 entfernt. Stattdessen wird DriverStatusListener verwendet.

Es gibt hauptsächlich drei Änderungen:

  1. Ändern Sie die implements-Benutzeroberfläche von StatusListener in DriverStatusListener.
  2. Fügen Sie updateStatus einen Nullable cause-Parameter hinzu.
  3. Rufen Sie DriverContextBuilder.setDriverStatusListener anstelle von setStatusListener auf.

DriverStatusListener hat dieselbe Struktur wie StatusListener. Der Hauptunterschied besteht darin, dass DriverStatusListener.updateStatus() einen zusätzlichen Parameter namens cause annimmt. So erhalten Nutzer Informationen zur Ursache eines Updates mit Fehlerstatusebene.

Normalerweise verwenden Sie cause, um den Fehlercode abzurufen, der von Fleet Engine für fehlgeschlagene Standortaktualisierungen zurückgegeben wird.

Das folgende Beispiel zeigt, wie StatusListener implementiert wird:

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());

Im Folgenden finden Sie ein Beispiel für eine DriverStatusListener-Implementierung:

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());

DriverStatusListener als funktionale Schnittstelle implementieren

DriverStatusListener unterstützt Java-Funktionsschnittstellen genau wie sein Vorgänger. Hier ein Beispiel:

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.
    }
  }
});