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.

Updates für Gradle- und Android-Gradle-Plug-ins

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

Führen Sie zuerst ein Upgrade Ihrer 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 kritische Fehlerkorrekturen.

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

  • Gradle-Version mindestens 7.5.0, aber nicht höher als 7.6.0.
  • Eine Version des Android Gradle-Plug-ins (AGP) im Bereich v7.4.x.

Sie können eine höhere Version der Plug-ins als Ziel festlegen. Es kann dann jedoch zu Einstellungswarnungen kommen oder einige neue Funktionen funktionieren nicht.

Um die Gradle-Version zu ändern, ä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

Um die Version des Android-Gradle-Plug-ins zu ändern, bearbeiten Sie die Datei build.gradle, die den buildscript-Block enthält. Beispiel:

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

Unterstützung der Migration von Java 7-zu Java 8-Bibliotheken

Schritt 1: Unterstützung der Java 8-Bibliotheken aktivieren

Quelle

Da das API-Level des SDK mindestens 23 ist und die erforderliche AGP-Version 7.4 oder höher ist, unterscheidet sich die Konfiguration geringfügig von der erwähnten 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+ verwendet R8 als Standardtool für Verkleinerung, Verschleierung und Optimierung für das Binärprogramm, sodass an dieser Stelle keine besonderen Maßnahmen erforderlich sind.

Wenn das Projekt von AGP 4.0 oder höher migriert wird, gibt AGP möglicherweise die folgenden Warnungen zum Entfernen von Dateien aus:

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

Wenn Sie diese Zeilen entfernen, werden diese Probleme in der Regel behoben.

Migration von Kotlin 1.6 zu 1.9

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

Quelle

Aktualisieren Sie die Version des Kotlin-Gradle-Plug-ins in der Build.gradle-Datei Ihrer App auf oberster Ebene. Fügen Sie den Abhängigkeiten aus dem Buildscript-Block org.jetbrains.kotlin:kotlin-gradle-plugin hinzu, falls dieser fehlt.

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

Für den Fall, dass Sie von Kotlin Gradle-Plug-in 1.6.X oder 1.7.X stammen, müssen Sie Ihre Anwendung von Kotlin-synthetics migrieren. Weitere Informationen finden Sie im offiziellen Migrationsleitfaden.

Schritt 2: Upgrade von kotlin-stdlib auf 1.9.0 durchführen

Quelle

Aktualisiere kotlin-stblib in deiner build.gradle-Datei 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 konsolidiert.

Einstellung von StatusListener

Die Schnittstelle StatusListener wurde eingestellt (wird in Version 6 entfernt) zugunsten von DriverStatusListener.

Es gibt im Wesentlichen drei Änderungen:

  1. Ändern Sie die Schnittstelle implements von StatusListener zu DriverStatusListener.
  2. Fügen Sie updateStatus den Parameter Nullable cause hinzu.
  3. Rufen Sie DriverContextBuilder.setDriverStatusListener anstelle von setStatusListener auf.

DriverStatusListener hat die gleiche 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.

In der Regel verwenden Sie cause, um den von Fleet Engine zurückgegebenen Fehlercode für fehlgeschlagene Standortaktualisierungen abzurufen.

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

Hier sehen 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 funktionale Java-Schnittstellen 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.
    }
  }
});