В этом руководстве описаны изменения, необходимые для перехода на версию 5.0.
Обновления плагина Gradle и Android Gradle
Обновите версии плагина Gradle и Android Gradle.
Сначала обновите версии плагина Gradle и Android Gradle. Это обновление включает улучшенную совместимость с некоторыми зависимостями SDK (включая Kotlin 1.9), а также исправление некоторых критических ошибок.
Для этого основного выпуска SDK требуются следующие зависимости версий для вашего проекта приложения Android:
- версия Gradle не ниже v7.5.0, но не выше v7.6.0.
- версия плагина Android Gradle (AGP) в диапазоне v7.4.x.
Вы можете настроить таргетинг на более позднюю версию плагинов; однако вы можете столкнуться с предупреждениями об устаревании или некоторые новые функции могут не работать.
Чтобы изменить версию Gradle, измените строку в файле /gradle/wrapper/gradle-wrapper.properties
вашего проекта.
distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
Чтобы изменить версию плагина Android Gradle, измените файл build.gradle
, содержащий блок buildscript
. Например:
buildscript {
repositories {
google()
mavenCentral()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:7.4.1'
}
}
Библиотека Java 7 на Java 8 поддерживает миграцию
Шаг 1. Включите поддержку библиотеки Java 8.
Поскольку минимальный уровень API SDK — 23, а необходимая версия AGP — 7.4+, конфигурация немного отличается от упомянутой исходной документации.
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'
}
Шаг 2. Миграция с Proguard или Dexguard на R8
AGP v7.4+ использует R8 в качестве инструмента сжатия, обфускации и оптимизации двоичного файла по умолчанию, поэтому никаких специальных действий на этом этапе не требуется.
Если проект перенесен с AGP 4.0+, AGP может выдать следующие предупреждения об удалении файлов:
-
useProguard true
в файлеbuild.gradle
-
android.enableR8=false
использование в файлеgradle.properties
Удаление этих строк обычно решает эти проблемы.
Миграция с Kotlin 1.6 на 1.9
Шаг 1. Переход на плагин Kotlin Gradle 1.9.0
Обновите версию плагина Kotlin Gradle в файле build.gradle модуля верхнего уровня вашего приложения. Обязательно добавьте org.jetbrains.kotlin:kotlin-gradle-plugin
в зависимости из блока buildscript на случай, если он отсутствует.
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.9.0"
}
}
Вы должны перенести свое приложение из Kotlin-Synthetics, если вы используете плагин Kotlin Gradle 1.6.X или 1.7.X. Дополнительную информацию можно найти в официальном руководстве по миграции .
Шаг 2. Обновите kotlin-stdlib до версии 1.9.0.
Обновите kotlin-stblib
до версии 1.9.0 в файле build.gradle вашего приложения.
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib:1.9.0"
}
Обязательно удалите все ссылки на kotlin-stdlib-jdk7
или kotlin-stdlib-jdk8
. Обе зависимости были объединены в kotlin-stdlib
начиная с Kotlin 1.8.0 .
Прекращение поддержки StatusListener
Интерфейс StatusListener
теперь устарел (будет удален в версии 6) в пользу DriverStatusListener
.
В основном есть 3 изменения:
- Измените интерфейс
implements
сStatusListener
наDriverStatusListener
. - Добавьте параметр
cause
Nullable
вupdateStatus
. - Вызовите
DriverContextBuilder.setDriverStatusListener
вместоsetStatusListener
.
DriverStatusListener
имеет ту же структуру, что и StatusListener
. Основное различие между ними заключается в том, что DriverStatusListener.updateStatus()
принимает дополнительный параметр с именем cause
. Это дает пользователям представление о причине обновления с уровнем статуса ошибки.
Обычно вы используете cause
для получения кода ошибки, возвращаемого Fleet Engine в случае неудачного обновления местоположения.
Следующий пример иллюстрирует, как реализовать 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());
Ниже показан пример реализации 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());
Реализуйте DriverStatusListener
как функциональный интерфейс.
DriverStatusListener
поддерживает функциональные интерфейсы Java, как и его предшественник. Вот пример:
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.
}
}
});