دليل نقل حزمة تطوير البرامج (SDK) لنظام التشغيل Android 5.0

يوضّح هذا الدليل التغييرات اللازمة لنقل البيانات إلى الإصدار 5.0.

تحديثات Gradle و"المكوّن الإضافي لنظام Gradle المتوافق مع Android"

ترقية إصدارَي Gradle والمكوّن الإضافي لنظام Gradle المتوافق مع Android

أولاً، عليك ترقية إصدارات المكوّن الإضافي Gradle ونظام Gradle المتوافق مع Android. هذه الترقية يتضمّن توافقًا أفضل مع بعض تبعيات حزمة تطوير البرامج (SDK) (بما في ذلك Kotlin 1.9)، بالإضافة إلى بعض الإصلاحات للأخطاء البالغة الأهمية.

يتطلّب الإصدار الرئيسي لحزمة تطوير البرامج (SDK) هذه الإصدارات الملحقة التالية لمشروع تطبيق Android:

  • إصدار Gradle 7.5.0 على الأقل ولكن ليس أعلى من 7.6.0
  • إصدار مكوّن إضافي لنظام Gradle المتوافق مع Android (AGP) في نطاق الإصدار 7.4.x.

يمكنك استهداف إصدار أحدث من المكوّنات الإضافية، ولكن قد تتلقّى تحذيرات بشأن إيقافها نهائيًا، أو قد لا تعمل بعض الميزات الجديدة.

لتعديل إصدار Gradle، عدّل السطر في جدول مشروعك ملف /gradle/wrapper/gradle-wrapper.properties

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

لتعديل إصدار مكوّن Gradle المتوافق مع Android، عدِّل ملف build.gradle الذي يحتوي على الكتلة buildscript. على سبيل المثال:

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

نقل بيانات مكتبة Java 7 إلى Java 8

الخطوة الأولى: تفعيل دعم مكتبة Java 8

المصدر

بما أنّ الحد الأدنى لمستوى واجهة برمجة التطبيقات في حزمة 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

R8، المصدر

يستخدم الإصدار 7.4 من AGP والإصدارات الأحدث أداة R8 كأداة التصغير والتشويه والتحسين التلقائية للملف الثنائي، لذلك ليس عليك اتّخاذ أي إجراء خاص في هذه المرحلة.

في حال نقل المشروع من الإصدار 4.0 من AGP أو الإصدارات الأحدث، قد يُصدر AGP التحذيرات التالية بشأن عمليات إزالة الملفات:

  • استخدام useProguard true في ملف build.gradle
  • استخدام android.enableR8=false في ملف gradle.properties

وتؤدي إزالة هذه الأسطر عادةً إلى حلّ هذه المشاكل.

نقل البيانات من الإصدار 1.6 إلى 1.9 من Kotlin

الخطوة 1: نقل البيانات إلى الإصدار 1.9.0 من مكوّن Kotlin Gradle الإضافي

المصدر

عدِّل إصدار مكوّن Kotlin Gradle الإضافي في ملف build.gradle الخاص بالوحدة على مستوى التطبيق. يجب الحرص على إضافة org.jetbrains.kotlin:kotlin-gradle-plugin في التبعيات من كتلة نص الإصدار في حالة فقدها.

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

يجب نقل بيانات تطبيقك من أدوات Kotlin الاصطناعيّة في حال كنت تستخدم الإصدار 1.6.X أو 1.7.X من Kotlin Gradle Plugin. يُرجى الرجوع إلى دليل نقل البيانات الرسمي للحصول على مزيد من المعلومات.

الخطوة 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 تغييرات رئيسية:

  1. تغيير واجهة implements من StatusListener إلى DriverStatusListener
  2. أضِف مَعلمة cause Nullable إلى updateStatus.
  3. يمكنك طلب الرقم DriverContextBuilder.setDriverStatusListener بدلاً من setStatusListener

يتشارك DriverStatusListener البنية نفسها مع StatusListener. المصدر الرئيسي الفرق بينهما هو أن DriverStatusListener.updateStatus() يأخذ معلمة إضافية باسم cause. يوفّر هذا القسم للمستخدمين إحصاءات عن سبب التحديث مع مستوى حالة الخطأ.

يتم عادةً استخدام cause لاسترداد رمز الخطأ الذي يعرضه Fleet. محرّك البحث لتنفيذ تحديثات الموقع الجغرافي غير الناجحة.

يوضّح النموذج التالي كيفية تطبيق 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.
    }
  }
});