إضافة تبعيات إلى الإصدار

يتيح لك نظام الإصدار Gradle في "استوديو Android" تضمين ملفات ثنائية خارجية أو وحدات مكتبة أخرى في إصدارك كعناصر تابعة. يمكن أن تكون التبعيات موجودة على جهازك أو في مستودع بعيد، وأي تبعيات انتقالية يتم تضمينها تلقائيًا أيضًا. توضّح هذه الصفحة كيفية استخدام التبعيات مع مشروع Android، بما في ذلك تفاصيل حول السلوكيات والإعدادات الخاصة بالمكوّن الإضافي Android Gradle‏ (AGP). للحصول على دليل مفاهيمي أكثر تفصيلاً حول تبعيات Gradle، يُرجى الاطّلاع على دليل Gradle لإدارة التبعيات، ولكن تذكَّر أنّ مشروع Android يجب أن يستخدم فقط إعدادات التبعية المحدّدة في هذه الصفحة.

إضافة تبعية لمكتبة أو مكوّن إضافي

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

للحصول على إرشادات حول إضافة التبعيات الأصلية وإدارتها (غير شائعة)، يُرجى الاطّلاع على التبعيات الأصلية.

في المثال التالي، تتم إضافة تبعية ثنائية عن بُعد (مكتبة Jetpack Macrobenchmark) وتبعية وحدة المكتبة المحلية (myLibrary) وتبعية مكوّن إضافي (المكوّن الإضافي لنظام Gradle المتوافق مع Android) إلى المشروع. فيما يلي الخطوات العامة لإضافة هذه التبعيات إلى مشروعك:

  1. أضِف اسمًا بديلاً لإصدار الاعتمادية الذي تريده في قسم [versions] من ملف قائمة الإصدارات، والذي يُسمى libs.versions.toml (ضمن دليل gradle في عرض المشروع أو نصوص Gradle في عرض Android):

    [versions]
    agp = "8.3.0"
    androidx-macro-benchmark = "1.2.2"
    my-library = "1.4"
    
    [libraries]
    ...
    
    [plugins]
    ...
    

    يمكن أن تتضمّن الأسماء البديلة شرطات أو شرطات سفلية. تنشئ هذه الأسماء المستعارة قيمًا متداخلة يمكنك الرجوع إليها في نصوص الإنشاء البرمجية. تبدأ المراجع باسم الكتالوج، وهو الجزء libs من libs.versions.toml. عند استخدام كتالوج إصدار واحد، ننصحك بالاحتفاظ بالقيمة التلقائية "libs".

  2. أضِف اسمًا بديلاً للاعتمادية في قسمَي [libraries] (للملفات الثنائية البعيدة أو وحدات المكتبة المحلية) أو [plugins] (للمكوّنات الإضافية) في ملف libs.versions.toml.

    [versions]
    ...
    
    [libraries]
    androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
    my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }
    
    [plugins]
    androidApplication = { id = "com.android.application", version.ref = "agp" }
    

    تتوفّر بعض المكتبات في قائمة مواد (BOM) منشورة تجمع مجموعات المكتبات وإصداراتها. يمكنك تضمين قائمة مواد في كتالوج الإصدارات وملفات الإصدار، والسماح لها بإدارة هذه الإصدارات نيابةً عنك. لمزيد من التفاصيل، يُرجى الاطّلاع على استخدام قائمة المواد.

  3. أضِف مرجعًا إلى الاسم المستعار للاعتمادية في نص الإصدار البرمجي للوحدات التي تتطلب الاعتمادية. تحويل الشرطات السفلية والشرطات في الاسم المستعار إلى نقاط عند الإشارة إليه من نص برمجي للإصدار. سيبدو نص التصميم البرمجي على مستوى الوحدة على النحو التالي:

    Kotlin

    plugins {
      alias(libs.plugins.androidApplication)
    }
    
    dependencies {
      implementation(libs.androidx.benchmark.macro)
      implementation(libs.my.library)
    }

    أنيق

    plugins {
      alias 'libs.plugins.androidApplication'
    }
    
    dependencies {
      implementation libs.androidx.benchmark.macro
      implementation libs.my.library
    }

    تتضمّن مراجع المكوّنات الإضافية plugins بعد اسم الكتالوج، وتتضمّن مراجع الإصدارات versions بعد اسم الكتالوج (مراجع الإصدارات غير شائعة، ويمكنك الاطّلاع على التبعيات التي تتضمّن أرقام الإصدارات نفسها للحصول على أمثلة على مراجع الإصدارات). لا تتضمّن مراجع المكتبة معرّف libraries، لذا لا يمكنك استخدام versions أو plugins في بداية اسم مستعار للمكتبة.

ضبط التبعيات

داخل كتلة dependencies، يمكنك الإعلان عن تبعية مكتبة باستخدام واحد من عدة تكوينات تبعية مختلفة (مثل implementation الموضحة سابقًا). يوفّر كل إعداد تبعية لـ Gradle تعليمات مختلفة حول كيفية استخدام التبعية. يوضّح الجدول التالي كلّ إعداد يمكنك استخدامه لتبعية في مشروع Android.

الإعداد السلوك
implementation يضيف Gradle التبعية إلى مسار فئة التجميع ويحزم التبعية إلى مخرجات الإصدار. عندما تضبط الوحدة اعتمادية implementation، فإنّها تُعلم Gradle بأنّك لا تريد أن تسرّب الوحدة الاعتمادية إلى وحدات أخرى في وقت التجميع. أي أنّ التبعية لا تكون متاحة للوحدات الأخرى التي تعتمد على الوحدة الحالية.

يمكن أن يؤدي استخدام إعداد التبعية هذا بدلاً من api إلى تحسينات كبيرة في وقت الإنشاء لأنه يقلل من عدد الوحدات التي يحتاج نظام الإنشاء إلى إعادة تجميعها. على سبيل المثال، إذا غيّرت اعتمادية implementation واجهة برمجة التطبيقات الخاصة بها، يعيد Gradle تجميع هذه الاعتمادية والوحدات التي تعتمد عليها مباشرةً فقط. يجب أن تستخدم معظم وحدات التطبيقات والاختبار هذه الإعدادات.

api يضيف Gradle التبعية إلى مسار فئة التجميع ومخرجات الإصدار. عندما تتضمّن وحدة اعتمادية api، فإنّها تُعلم Gradle بأنّ الوحدة تريد تصدير هذه الاعتمادية بشكل مؤقت إلى وحدات أخرى، بحيث تكون متاحة لها في كل من وقت التشغيل ووقت التجميع.

يُرجى استخدام هذه الإعدادات بحذر وفقط مع التبعيات التي تحتاج إلى تصديرها بشكل انتقالي إلى مستهلكين آخرين في المراحل السابقة. إذا غيّرت اعتمادية api واجهة برمجة التطبيقات الخارجية، يعيد Gradle تجميع جميع الوحدات التي يمكنها الوصول إلى هذه الاعتمادية في وقت التجميع. قد يؤدي وجود عدد كبير من تبعيات api إلى زيادة وقت الإنشاء بشكل كبير. ما لم تكن تريد عرض واجهة برمجة تطبيقات تابعة لوحدة منفصلة، يجب أن تستخدم وحدات المكتبة العناصر التابعة implementation بدلاً من ذلك.

compileOnly يضيف Gradle الاعتمادية إلى مسار فئة التجميع فقط (أي لا تتم إضافتها إلى مخرجات الإصدار). ويكون ذلك مفيدًا عند إنشاء وحدة Android وكنت بحاجة إلى التبعية أثناء عملية التجميع، ولكن من الاختياري توفّرها في وقت التشغيل. على سبيل المثال، إذا كنت تعتمد على مكتبة تتضمّن فقط تعليقات توضيحية لوقت التجميع، والتي تُستخدم عادةً لإنشاء الرموز البرمجية ولكن لا يتم تضمينها غالبًا في مخرجات الإصدار، يمكنك وضع علامة على هذه المكتبة compileOnly.

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

ملاحظة: لا يمكنك استخدام الإعداد compileOnly مع تبعيات أرشيف Android ‏ (AAR).

runtimeOnly تضيف Gradle التبعية إلى ناتج الإصدار فقط، لاستخدامها أثناء وقت التشغيل. أي أنّه لا تتم إضافته إلى مسار فئة التجميع. نادرًا ما يتم استخدام هذه الواجهة على Android، ولكنها تُستخدم عادةً في تطبيقات الخادم لتوفير عمليات تسجيل. على سبيل المثال، يمكن أن تستخدم مكتبة واجهة برمجة تطبيقات لتسجيل الدخول لا تتضمّن عملية تنفيذ. ويمكن لمستخدمي هذه المكتبة إضافتها كعنصر تابع لـ implementation وتضمين عنصر تابع لـ runtimeOnly من أجل استخدام عملية تنفيذ التسجيل الفعلية.
ksp
kapt
annotationProcessor

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

لإضافة مثل هذه التبعية، يجب إضافتها إلى مسار فئة معالج التعليقات التوضيحية باستخدام الإعدادات ksp أو kapt أو annotationProcessor. يؤدي استخدام هذه الإعدادات إلى تحسين أداء عملية الإنشاء من خلال فصل مسار فئة التجميع عن مسار فئة معالج التعليقات التوضيحية. إذا عثر Gradle على معالجات التعليقات التوضيحية في مسار فئة التجميع، سيتم إيقاف ميزة تجنُّب التجميع، ما يؤثر سلبًا في وقت الإنشاء (يتجاهل الإصدار 5.0 من Gradle والإصدارات الأحدث معالجات التعليقات التوضيحية التي يتم العثور عليها في مسار فئة التجميع).

يفترض المكوّن الإضافي لنظام Gradle المتوافق مع Android أنّ التبعية هي معالج تعليقات توضيحية إذا كان ملف JAR الخاص بها يحتوي على الملف التالي:

META-INF/services/javax.annotation.processing.Processor

إذا رصد المكوّن الإضافي معالج تعليقات توضيحية في مسار فئة التجميع، سيؤدي ذلك إلى حدوث خطأ في الإصدار.

ksp هو معالج رموز Kotlin، ويتم تشغيله بواسطة برنامج تجميع Kotlin.

‫kapt وapt هما أداتان منفصلتان تعالجان التعليقات التوضيحية قبل أن تنفّذها برامج تجميع Kotlin أو Java.

عند اختيار الإعدادات التي تريد استخدامها، يجب مراعاة ما يلي:

  • إذا كان المعالج متاحًا كمعالج Kotlin Symbol Processor، استخدِمه كاعتمادية ksp. يمكنك الاطّلاع على النقل من kapt إلى ksp لمعرفة تفاصيل حول استخدام معالِجات رموز Kotlin.
  • إذا لم يكن المعالج متاحًا كمعالج Kotlin Symbol Processor:
    • إذا كان مشروعك يتضمّن مصدر Kotlin (ويمكن أن يتضمّن أيضًا مصدر Java)، استخدِم kapt لتضمينه.
    • إذا كان مشروعك يستخدم مصدر Java فقط، استخدِم annotationProcessor لتضمينه.

لمزيد من المعلومات حول استخدام معالجات التعليقات التوضيحية، يُرجى الاطّلاع على إضافة معالجات التعليقات التوضيحية.

lintChecks

استخدِم هذه الإعدادات لتضمين مكتبة تحتوي على عمليات التحقّق من Lint التي تريد أن ينفّذها Gradle عند إنشاء مشروع تطبيق Android.

يُرجى العِلم أنّ ملفات AAR التي تحتوي على ملف lint.jar ستُجري تلقائيًا عمليات التحقّق المحدّدة في ملف lint.jar هذا، ولست بحاجة إلى إضافة تبعية lintChecks صريحة. يتيح لك ذلك تحديد المكتبات وعمليات التحقّق من الأخطاء المرتبطة بها في تبعية واحدة، ما يضمن إجراء عمليات التحقّق عندما يستخدم المستهلكون مكتبتك.

lintPublish استخدِم هذا الإعداد في مشاريع مكتبات Android لتضمين عمليات التحقّق من أداة Lint التي تريد أن يجمعها Gradle في ملف lint.jar ويضمّنها في ملف AAR. يؤدي ذلك إلى تطبيق عمليات التحقّق من الأخطاء على المشاريع التي تستخدم ملف AAR. إذا كنت تستخدم في السابق إعدادات التبعية lintChecks لتضمين عمليات التحقّق من الأخطاء في ملف AAR المنشور، عليك نقل هذه التبعيات لاستخدام إعدادات lintPublish بدلاً من ذلك.

Kotlin

dependencies {
  // Executes lint checks from the ":checks" project at build time.
  lintChecks(project(":checks"))
  // Compiles lint checks from the ":checks-to-publish" into a
  // lint.jar file and publishes it to your Android library.
  lintPublish(project(":checks-to-publish"))
}

أنيق

dependencies {
  // Executes lint checks from the ':checks' project at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish' into a
  // lint.jar file and publishes it to your Android library.
  lintPublish project(':checks-to-publish')
}

ضبط التبعيات لتنويعة تصميم معيّنة

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

على سبيل المثال، لإضافة تبعية ثنائية عن بُعد إلى صيغة المنتج "المجانية" فقط باستخدام الإعداد implementation، استخدِم ما يلي:

Kotlin

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

أنيق

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

ومع ذلك، إذا أردت إضافة تبعية لصيغة تجمع بين صيغة منتج ونوع إصدار، عليك إعداد اسم الإعداد:

Kotlin

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

أنيق

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

لإضافة تبعيات implementation للاختبارات المحلية واختبارات قياس حالة التطبيق، يبدو الأمر كالتالي:

Kotlin

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
}

أنيق

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.6.1'
}

ومع ذلك، لا تكون بعض الإعدادات منطقية في هذه الحالة. على سبيل المثال، بما أنّ الوحدات الأخرى لا يمكنها الاعتماد على androidTest، سيظهر لك التحذير التالي إذا استخدمت إعدادات androidTestApi:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

ترتيب التبعية

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

على سبيل المثال، إذا كان مشروعك يعرّف ما يلي:

  • الاعتماد على LIB_A وLIB_B (بهذا الترتيب)
  • ويعتمد ‎LIB_A على ‎LIB_C و‎LIB_D (بهذا الترتيب)
  • ويعتمد ‎LIB_B أيضًا على ‎LIB_C

بعد ذلك، سيكون ترتيب التبعية الثابت على النحو التالي:

  1. LIB_A
  2. LIB_D
  3. LIB_B
  4. LIB_C

يضمن ذلك إمكانية تجاوز كل من LIB_A وLIB_B لـ LIB_C، ولا يزال LIB_D يحظى بأولوية أعلى من LIB_B لأنّ LIB_A (الذي يعتمد عليه) يحظى بأولوية أعلى من LIB_B.

لمزيد من المعلومات حول كيفية دمج ملفات البيان من مصادر أو تبعيات مختلفة للمشروع، يُرجى الاطّلاع على دمج ملفات بيان متعددة.

معلومات التبعية في Play Console

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

يتم ضغط البيانات وتشفيرها باستخدام مفتاح توقيع Google Play وتخزينها في مجموعة التوقيع الخاصة بإصدار تطبيقك. ننصحك بالاحتفاظ بملف التبعيات هذا لضمان تجربة مستخدم آمنة وإيجابية. يمكنك إيقاف هذه الميزة من خلال تضمين مجموعة الرموز البرمجية التالية dependenciesInfo في ملف build.gradle.kts الخاص بالوحدة.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

لمزيد من المعلومات حول سياساتنا والمشاكل المحتملة المتعلّقة بالتبعيّات، يُرجى الاطّلاع على صفحة الدعم حول استخدام حِزم تطوير البرامج (SDK) التابعة لجهات خارجية في تطبيقك.

إحصاءات حِزم تطوير البرامج (SDK)

يعرض "استوديو Android" تحذيرات Lint في ملف قائمة الإصدارات ومربّع حوار بنية المشروع لحِزم SDK المتاحة للجميع في Google Play SDK Index عند حدوث المشاكل التالية:

  • يضع مؤلفو حِزم SDK علامة عليها بأنّها قديمة.
  • تنتهك حِزم SDK سياسات Google Play.
  • تحتوي حِزم تطوير البرامج (SDK) على ثغرات أمنية معروفة.
  • أوقف مطوّرو حِزم SDK هذه الحِزم نهائيًا.

تُعدّ التحذيرات إشارات إلى ضرورة تحديث هذه التبعيات، لأنّ استخدام إصدارات قديمة قد يمنعك من النشر على Google Play Console في المستقبل.

إضافة تبعيات الإصدار بدون كتالوجات الإصدارات

ننصح باستخدام كتالوجات الإصدارات لإضافة التبعيات وإدارتها، ولكن قد لا تحتاج إليها المشاريع البسيطة. في ما يلي مثال على ملف إصدار لا يستخدم كتالوجات الإصدارات:

Kotlin

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

أنيق

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

يُعلن ملف الإصدار هذا عن تبعية للإصدار 12.3 من مكتبة "app-magic" ضمن مجموعة مساحة الاسم "com.example.android". يُعدّ تعريف التبعية الثنائية عن بُعد اختصارًا لما يلي:

Kotlin

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

أنيق

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

يعلن ملف الإصدار أيضًا عن تبعية وحدة مكتبة Android باسم "mylibrary"، ويجب أن يتطابق هذا الاسم مع اسم المكتبة المحدّد باستخدام include: في ملف settings.gradle.kts. عند إنشاء تطبيقك، يجمّع نظام التصميم وحدة المكتبة ويحزم المحتوى المجمّع الناتج في التطبيق.

يعلن ملف الإصدار أيضًا عن تبعية للمكوّن الإضافي لنظام Gradle المتوافق مع Android (com.application.android). إذا كانت لديك وحدات متعددة تستخدم المكوّن الإضافي نفسه، يمكنك استخدام إصدار واحد فقط من المكوّن الإضافي في مسار فئة الإصدار على مستوى جميع الوحدات. بدلاً من تحديد الإصدار في كل نص برمجي لإنشاء الوحدات، يجب تضمين تبعية المكوّن الإضافي في النص البرمجي لإنشاء الجذر مع الإصدار، والإشارة إلى عدم تطبيقه. تؤدي إضافة apply false إلى إعلام Gradle بتسجيل إصدار المكوّن الإضافي ولكن عدم استخدامه في عملية الإنشاء الجذرية. عادةً ما يكون النص البرمجي لإنشاء الجذر فارغًا باستثناء مجموعة plugins هذه.

Kotlin

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

أنيق

plugins {
    id 'com.android.application' version '8.3.0-rc02' apply false
}

إذا كان لديك مشروع يتضمّن وحدة واحدة، يمكنك تحديد الإصدار صراحةً في النص البرمجي للتصميم على مستوى الوحدة وترك النص البرمجي للتصميم على مستوى المشروع فارغًا:

Kotlin

plugins {
    id("com.android.application") version "8.3.0"
}

أنيق

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}