Guide de migration du SDK Android Driver 5.0

Ce guide décrit les modifications nécessaires pour migrer vers la version 5.0.

Mises à jour de Gradle et du plug-in Android Gradle

Mettre à niveau les versions de Gradle et du plug-in Android Gradle

Commencez par mettre à niveau vos versions de Gradle et du plug-in Android Gradle. Cette mise à niveau offre une meilleure compatibilité avec certaines dépendances de SDK (y compris Kotlin 1.9), ainsi que des corrections de bugs critiques.

Cette version majeure du SDK nécessite les dépendances de version suivantes pour votre projet d'application Android:

  • une version Gradle d'au moins 7.5.0, mais pas supérieure à 7.6.0.
  • une version du plug-in Android Gradle (AGP) comprise entre v7.4.x.

Vous pouvez cibler une version supérieure des plug-ins. Toutefois, vous risquez de rencontrer des avertissements d'abandon ou certaines nouvelles fonctionnalités risquent de ne pas fonctionner.

Pour modifier la version Gradle, modifiez la ligne dans le fichier /gradle/wrapper/gradle-wrapper.properties de votre projet.

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

Pour modifier la version du plug-in Android Gradle, modifiez le fichier build.gradle contenant le bloc buildscript. Exemple :

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

Migration de la prise en charge des bibliothèques Java 7 vers Java 8

Étape 1 : Activez la prise en charge des bibliothèques Java 8

Source

Étant donné que le niveau d'API minimal du SDK est 23 et que la version d'AGP requise est 7.4 ou supérieure, la configuration est légèrement différente de la documentation source mentionnée.

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

Étape 2 : Migrer de ProGuard ou DexGuard vers R8

R8, source

La version 7.4 et ultérieure d'AGP utilise R8 comme outil de réduction, d'obscurcissement et d'optimisation par défaut pour le binaire. Aucune action spéciale n'est donc requise à ce stade.

Si le projet est migré à partir d'AGP 4.0 ou version ultérieure, AGP peut afficher les avertissements suivants concernant la suppression de fichiers:

  • Utilisation de useProguard true dans le fichier build.gradle
  • Utilisation de android.enableR8=false dans le fichier gradle.properties

La suppression de ces lignes permet généralement de résoudre ces problèmes.

Migration de Kotlin 1.6 vers la version 1.9

Étape 1 : Migrer vers le plug-in Kotlin Gradle 1.9.0

Source

Mettez à jour la version du plug-in Kotlin Gradle dans le fichier build.gradle du module de niveau supérieur de votre application. Veillez à ajouter org.jetbrains.kotlin:kotlin-gradle-plugin dans les dépendances du bloc buildscript au cas où il serait manquant.

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

Vous devez migrer votre application à partir de Kotlin-synthetics si vous utilisez le plug-in Kotlin Gradle 1.6.X ou 1.7.X. Pour en savoir plus, consultez le guide de migration officiel.

Étape 2 : Mettre à niveau kotlin-stdlib vers la version 1.9.0

Source

Mettez à niveau kotlin-stblib vers la version 1.9.0 dans le fichier build.gradle de votre application.

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

Veillez à supprimer toutes les références à kotlin-stdlib-jdk7 ou kotlin-stdlib-jdk8. Les deux dépendances ont été regroupées dans kotlin-stdlib à partir de Kotlin 1.8.0.

Abandon de StatusListener

L'interface StatusListener est désormais obsolète (à supprimer dans la version 6) au profit de DriverStatusListener.

Il s'agit principalement de trois modifications:

  1. Remplacez StatusListener par DriverStatusListener dans l'interface implements.
  2. Ajoutez un paramètre cause Nullable à updateStatus.
  3. Appelez DriverContextBuilder.setDriverStatusListener au lieu de setStatusListener.

DriverStatusListener partage la même structure que StatusListener. La principale différence entre les deux est que DriverStatusListener.updateStatus() utilise un paramètre supplémentaire nommé cause. Cela permet aux utilisateurs de comprendre la cause d'une mise à jour avec le niveau d'état d'erreur.

En règle générale, vous devez utiliser cause pour récupérer le code d'erreur renvoyé par Fleet Engine en cas d'échec de la mise à jour de la position.

L'exemple suivant montre comment implémenter 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());

Voici un exemple d'implémentation 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());

Implémenter DriverStatusListener en tant qu'interface fonctionnelle

DriverStatusListener est compatible avec les interfaces fonctionnelles Java, tout comme son prédécesseur. Voici un exemple:

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