Derleme bağımlılıkları ekleme

Android Studio'daki Gradle derleme sistemi, derlemenize bağımlılık olarak harici ikili programlar veya diğer kitaplık modüllerini eklemenize olanak tanır. Bağımlılıklar makinenizde veya uzaktaki bir depoda bulunabilir ve belirttikleri tüm geçişli bağımlılıklar da otomatik olarak dahil edilir. Bu sayfada, Android Gradle eklentisine (AGP) özgü davranış ve yapılandırmalarla ilgili ayrıntılar da dahil olmak üzere bağımlılıkları Android projenizde nasıl kullanacağınız açıklanmaktadır. Gradle bağımlılıklarıyla ilgili daha ayrıntılı bir kavramsal kılavuz için Bağımlılık yönetimi için Gradle kılavuzunu da inceleyebilirsiniz. Ancak Android projenizin yalnızca bu sayfada tanımlanan bağımlılık yapılandırmalarını kullanması gerektiğini unutmayın.

Kitaplık veya eklenti bağımlılığı ekleme

Derleme bağımlılığı ekleyip yönetmenin en iyi yolu, yeni projelerin varsayılan olarak kullandığı yöntem olan sürüm kataloglarını kullanmaktır. Bu bölümde, Android projeleri için kullanılan en yaygın yapılandırma türleri ele alınmaktadır. Daha fazla seçenek için Gradle dokümanlarına bakın. Sürüm kataloglarını kullanan bir uygulama örneği için Artık Android'de bölümüne bakın. Sürüm katalogları olmadan oluşturulmuş derleme bağımlılıklarınız varsa ve çok modüllü bir projeniz varsa taşımanızı öneririz.

Yerel bağımlılıklar ekleme ve yönetme (yaygın değildir) hakkında bilgi için Yerel bağımlılıklar bölümüne bakın.

Aşağıdaki örnekte projemize bir uzak ikili bağımlılığı (Jetpack Macrobenchmark kitaplığı), yerel kitaplık modülü bağımlılığı (myLibrary) ve bir eklenti bağımlılığı (Android Gradle eklentisi) ekledik. Bu bağımlılıkları projenize eklemeye yönelik genel adımlar şunlardır:

  1. Sürüm katalog dosyasının [versions] bölümünde istediğiniz bağımlılık sürümü için bir takma ad ekleyin. Bu ad, Proje görünümündeki gradle dizininin altında veya Android görünümünde Gradle Komut Dosyaları'dır.libs.versions.toml

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

    Takma adlar kısa çizgi veya alt çizgi içerebilir. Bu takma adlar, derleme komut dosyalarında başvurabileceğiniz iç içe yerleştirilmiş değerler oluşturur. Referanslar, kataloğun adı olan libs.versions.toml öğesinin libs kısmıyla başlar. Tek sürüm kataloğu kullanırken varsayılan "libs" değerini korumanızı öneririz.

  2. libs.versions.toml dosyasının [libraries] (uzaktan ikili programlar veya yerel kitaplık modülleri için) veya [plugins] (eklentiler için) bölümlerinde bağımlılık için bir takma ad ekleyin.

    [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" }
    

    Bazı kitaplıklar, kitaplık ailelerini ve sürümlerini gruplandıran yayınlanmış bir Malzeme Listesi'nde (BOM) bulunur. Sürüm kataloğunuza ve derleme dosyalarınıza bir BOM ekleyebilir ve bu sürümleri sizin yerinize yönetmesine izin verebilirsiniz. Ayrıntılar için Malzeme Listesi'ni Kullanma bölümüne bakın.

  3. Bağımlılık gerektiren modüllerin derleme komut dosyasına bağımlılık takma adına bir referans ekleyin. Takma ada bir derleme komut dosyasından başvururken takma adın alt çizgi ve kısa çizgilerini noktalara dönüştürün. Modül düzeyinde oluşturma komut dosyamız şöyle görünür:

    Kotlin

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

    Eski

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

    Eklenti referanslarında, katalog adından sonra plugins yer alır. Sürüm referansları arasında, katalog adından sonra versions yer alır (sürüm referansları yaygın değildir; sürüm referanslarıyla ilgili örnekler için Aynı sürüm numaralarına sahip bağımlılıklar bölümüne bakın). Kitaplık referanslarında libraries niteleyicisi bulunmadığından kitaplık takma adının başında versions veya plugins kullanamazsınız.

Bağımlılıkları yapılandırma

dependencies blokunda, birkaç farklı bağımlılık yapılandırmasından (daha önce gösterilen implementation gibi) birini kullanarak bir kitaplık bağımlılığı tanımlayabilirsiniz. Her bağımlılık yapılandırması, Gradle'a bağımlılığın nasıl kullanılacağıyla ilgili farklı talimatlar sağlar. Aşağıdaki tabloda, Android projenizdeki bir bağımlılık için kullanabileceğiniz yapılandırmaların her biri açıklanmaktadır.

Yapılandırma Davranış
implementation Gradle, bağımlılığı derleme sınıf yoluna ekler ve bağımlılığı derleme çıkışına paketler. Modülünüz bir implementation bağımlılığı yapılandırdığında, modülün derleme sırasında bağımlılığı diğer modüllere sızdırmasını istemediğinizi Gradle'a bildirir. Yani bağımlılık, mevcut modüle bağlı diğer modüller tarafından kullanılamaz.

api yerine bu bağımlılık yapılandırmasının kullanılması, derleme sisteminin yeniden derlemesi gereken modüllerin sayısını azalttığı için derleme süresinde önemli artışlar sağlayabilir. Örneğin, bir implementation bağımlılığı API'sini değiştirirse Gradle yalnızca bu bağımlılığı ve ona doğrudan bağımlı olan modülleri yeniden derler. Çoğu uygulama ve test modülü bu yapılandırmayı kullanmalıdır.

api Gradle, derleme sınıf yoluna ve derleme çıkışına bağımlılığı ekler. Bir modül api bağımlılığı içerdiğinde, Gradle'a modülün bu bağımlılığı geçişli olarak diğer modüllere aktarmak istediğini ve böylece hem çalışma zamanında hem de derleme zamanında kullanılabilir olmasını sağlar.

Bu yapılandırmayı dikkatli bir şekilde ve yalnızca yukarı akış tüketicilerine geçişli olarak dışa aktarmanız gereken bağımlılıklarla kullanın. Bir api bağımlılığı harici API'sini değiştirirse Gradle, derleme sırasında bu bağımlılığa erişimi olan tüm modülleri yeniden derler. Çok sayıda api bağımlılığının bulunması, derleme süresini önemli ölçüde artırabilir. Bir bağımlılığın API'sini ayrı bir modüle sunmak istemiyorsanız kitaplık modüllerinin bunun yerine implementation bağımlılıklarını kullanması gerekir.

compileOnly Gradle, bağımlılığı yalnızca derleme sınıf yoluna ekler (yani derleme çıkışına eklenmez). Bu, bir Android modülü oluştururken ve derleme sırasında bağımlılığa ihtiyacınız olduğunda faydalıdır ancak çalışma zamanında mevcut olması isteğe bağlıdır. Örneğin, yalnızca derleme zamanı ek açıklamaları içeren (genellikle kod oluşturmak için kullanılır ancak çoğu zaman derleme çıktısına dahil edilmez) bir kitaplığa bağımlıysanız bu kitaplığı compileOnly olarak işaretleyebilirsiniz.

Bu yapılandırmayı kullanırsanız kitaplık modülünüzün, bağımlılığın kullanılabilir olup olmadığını kontrol etmek için bir çalışma zamanı koşulu içermesi ve daha sonra, sağlanmazsa yine de çalışabilmesi için davranışını incelikle değiştirmesi gerekir. Bu, kritik olmayan geçici bağımlılıkları eklemeyerek son uygulamanın boyutunu küçültmeye yardımcı olur.

Not: compileOnly yapılandırmasını Android Arşivi (AAR) bağımlılıklarıyla kullanamazsınız.

runtimeOnly Gradle, bağımlılığı çalışma zamanı boyunca kullanmak üzere yalnızca derleme çıkışına ekler. Yani, derleme sınıf yoluna eklenmez. Bu, Android'de nadiren kullanılır ancak günlük kaydı uygulamaları sağlamak için sunucu uygulamalarında yaygın olarak kullanılır. Örneğin, bir kitaplık uygulama içermeyen bir günlük kaydı API'si kullanabilir. Bu kitaplığın tüketicileri, kitaplığı bir implementation bağımlılığı olarak ekleyebilir ve gerçek günlük kaydı uygulamasının kullanması için bir runtimeOnly bağımlılığı ekleyebilir.
ksp
kapt
annotationProcessor

Bu yapılandırmalar, kodunuzdaki ek açıklamaları ve diğer simgeleri derlenmeden önce işleyen kitaplıklar sağlar. Bunlar genellikle kodunuzu doğrular veya ek kod oluşturarak yazmanız gereken kodu azaltır.

Böyle bir bağımlılığı eklemek için ksp, kapt veya annotationProcessor yapılandırmalarını kullanarak ek açıklama işlemcisi sınıf yoluna eklemeniz gerekir. Bu yapılandırmaların kullanılması, derleme sınıf yolunu ek açıklama işlemci sınıf yolundan ayırarak derleme performansını iyileştirir. Gradle, derleme sınıf yolunda ek açıklama işlemcileri bulursa derlemeden kaçınma özelliğini devre dışı bırakır ve bu durum, derleme süresini (derleme sınıf yolunda bulunan Gradle 5.0 ve üzeri yoksayma işlemcileri) olumsuz etkiler.

Android Gradle eklentisi JAR dosyası aşağıdaki dosyayı içeriyorsa bağımlılığın bir ek açıklama işlemcisi olduğunu varsayar:

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

Eklenti, derleme sınıf yolunda bir ek açıklama işlemcisi algılarsa derleme hatası oluşturur.

ksp, Kotlin Sembolü İşlemcisidir ve Kotlin derleyicisi tarafından çalıştırılır.

kapt ve apt, ek açıklamaları Kotlin veya Java derleyicileri yürütülmeden önce işleyen ayrı araçlardır.

Hangi yapılandırmayı kullanacağınıza karar verirken aşağıdakileri göz önünde bulundurun:

  • Bir işlemci, Kotlin Sembol İşlemci olarak mevcutsa bunu bir ksp bağımlılığı olarak kullanın. Kotlin Sembol İşlemcilerini kullanmayla ilgili ayrıntılar için kapt'tan ksp'ye geçiş konusuna bakın.
  • İşlemci, Kotlin Sembol İşlemcisi olarak yoksa:
    • Projeniz Kotlin kaynağı içeriyorsa (ancak Java kaynağını da içerebilir) dahil etmek için kapt kullanın.
    • Projeniz yalnızca Java kaynağını kullanıyorsa dahil etmek için annotationProcessor kullanın.

Ek açıklama işlemcileri kullanma hakkında daha fazla bilgi için Ek açıklama işlemcileri ekleme bölümüne bakın.

lintChecks

Android uygulama projenizi oluştururken Gradle'ın yürütmesini istediğiniz lint kontrollerini içeren bir kitaplık eklemek için bu yapılandırmayı kullanın.

lint.jar dosyası içeren AAR'ların söz konusu lint.jar dosyasında tanımlanan kontrolleri otomatik olarak çalıştıracağını unutmayın. Açık bir lintChecks bağımlılığı eklemeniz gerekmez. Bu sayede kitaplıkları ve ilişkili lint kontrollerini tek bir bağımlılıkta tanımlayabilirsiniz. Böylece, tüketiciler kitaplığınızı kullandığında kontrollerin çalıştırılmasını sağlayabilirsiniz.

lintPublish Gradle'ın AAR'nizde lint.jar dosyası ve paket halinde derlemesini istediğiniz lint kontrollerini eklemek için Android kitaplık projelerinde bu yapılandırmayı kullanın. Bu, AAR'nizi kullanan projelerin bu lint kontrollerini de uygulamasına neden olur. Daha önce yayınlanan AAR'ye lint kontrollerini dahil etmek için lintChecks bağımlılık yapılandırmasını kullandıysanız bu bağımlılıkları lintPublish yapılandırmasını kullanmak üzere taşımanız gerekir.

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"))
}

Eski

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

Belirli bir derleme varyantı için bağımlılıkları yapılandırma

Önceki yapılandırmaların tümü, tüm derleme varyantlarına bağımlılık uygular. Bunun yerine yalnızca belirli bir derleme varyantı kaynak grubu veya test kaynağı grubu için bağımlılık bildirmek isterseniz yapılandırma adının büyük harfle yazılması ve derleme varyantının ya da test kaynağı grubunun adının önüne eklenmesi gerekir.

Örneğin, implementation yapılandırmasını kullanarak yalnızca "ücretsiz" ürününüzün türüne uzak ikili program bağımlılığı eklemek için şunu kullanın:

Kotlin

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

Eski

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

Ancak bir ürün çeşidi ile derleme türünü birleştiren bir varyant için bağımlılık eklemek istiyorsanız yapılandırma adını ilk kullanıma hazırlamanız gerekir:

Kotlin

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

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

Eski

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

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

Yerel testleriniz ve araçlı testleriniz için implementation bağımlılıkları eklemek isterseniz şu şekilde görünür:

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.5.1")
}

Eski

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

Ancak belirli yapılandırmalar bu durumda anlamlı olmaz. Örneğin, diğer modüller androidTest ürününe bağlı olamayacağından androidTestApi yapılandırmasını kullanırsanız aşağıdaki uyarıyı alırsınız:

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

Bağımlılık sırası

Bağımlılıklarınızı listelediğiniz sıra, her birinin önceliğini gösterir: İlk kitaplık ikinciden daha önceliklidir, ikinci kitaplık üçüncüden daha önceliklidir ve sıralama bu şekilde devam eder. Kaynakların birleştirilmesi veya manifest öğelerinin kitaplıklardan uygulamanızla birleştirilmesi durumunda bu sıra önemlidir.

Örneğin, projenizde aşağıdakiler beyan ediliyorsa:

  • LIB_A ve LIB_B öğelerine bağımlılık (bu sırayla)
  • LIB_A, LIB_C ve LIB_D değerlerine bağlıdır (bu sırayla)
  • Ayrıca LIB_B, LIB_C metriğine de bağlıdır

Bu durumda sabit bağımlılık sırası aşağıdaki gibi olacaktır:

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

Bu sayede hem LIB_A hem de LIB_B, LIB_C öğesini geçersiz kılabilir. Ayrıca LIB_A, LIB_B öğesine göre daha yüksek önceliğe sahip olduğu için yine de LIB_B'dan daha yüksek önceliğe sahiptir.LIB_D

Farklı proje kaynaklarından/bağımlılıklarından gelen manifest'lerin nasıl birleştirildiği hakkında daha fazla bilgi edinmek için Birden çok manifest dosyasını birleştirme bölümüne bakın.

Play Console için bağımlılık bilgileri

AGP, uygulamanızı oluştururken, uygulamanızda derlenen kitaplık bağımlılıklarını tanımlayan meta verileri içerir. Play Console, uygulamanızı yüklerken SDK'larla ve uygulamanızın kullandığı bağımlılıklarla ilgili bilinen sorunlar hakkında uyarı sağlamak için bu meta verileri inceler ve bazı durumlarda bu sorunları çözmek için uygulanabilir geri bildirimler sağlar.

Veriler bir Google Play imzalama anahtarı ile sıkıştırılır, şifrelenir ve sürüm uygulamanızın imzalama bloğunda depolanır. Güvenli ve olumlu bir kullanıcı deneyimi için bu bağımlılık dosyasını saklamanızı öneririz. Modülünüzün build.gradle.kts dosyasına aşağıdaki dependenciesInfo bloğunu ekleyerek devre dışı bırakabilirsiniz.

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

Politikalarımız ve bağımlılıklarla ilgili olası sorunlar hakkında daha fazla bilgi için uygulamanızda üçüncü taraf SDK'ları kullanma ile ilgili destek sayfamıza bakın.

SDK analizleri

Android Studio, aşağıdaki sorunlar geçerli olduğunda sürüm katalog dosyasında ve Google Play SDK Dizini'ndeki herkese açık SDK'lar için Proje Yapısı İletişim Kutusu'nda lint uyarıları gösterir:

  • SDK'lar, yazarları tarafından "güncel değil" olarak işaretlenir.
  • SDK'lar, Play politikalarını ihlal ediyor.

Uyarılar, eski sürümlerin kullanılması gelecekte Google Play Console'da uygulama yayınlamanızı engelleyebileceği için bu bağımlılıkları güncellemeniz gerektiğini gösteren sinyallerdir.

Sürüm katalogları olmadan derleme bağımlılıkları ekleme

Bağımlılıkları eklemek ve yönetmek için sürüm kataloglarını kullanmanızı öneririz ancak basit projelerde bunlara ihtiyaç duyulmayabilir. Sürüm kataloglarının kullanılmadığı bir derleme dosyası örneğini burada bulabilirsiniz:

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"))
}

Eski

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

Bu derleme dosyası, "com.example.android" ad alanı grubu içinde "app-magic" kitaplığının 12.3 sürümüne yönelik bir bağımlılık bildiriyor. Uzak ikili bağımlılık bildirimi aşağıdaki ifadenin kısaltmasıdır:

Kotlin

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

Eski

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

Derleme dosyası ayrıca "mylibrary" adlı Android kitaplık modülüne de bağımlılık bildirir. Bu ad, settings.gradle.kts dosyanızda include: ile tanımlanan kitaplık adıyla eşleşmelidir. Uygulamanızı derlediğinizde derleme sistemi, kitaplık modülünü derler ve elde edilen derlenmiş içerikleri uygulamada paketler.

Derleme dosyası ayrıca Android Gradle eklentisine (com.application.android) bir bağımlılık öğrenir. Aynı eklentiyi kullanan birden fazla modülünüz varsa tüm modüllerde derleme sınıf yolunda eklentinin yalnızca tek bir sürümüne sahip olabilirsiniz. Modül derleme komut dosyalarının her birinde sürümü belirtmek yerine, eklenti bağımlılığını sürümle birlikte kök derleme komut dosyasına dahil etmeniz ve uygulamayacağınızı belirtmeniz gerekir. apply false eklenmesi, Gradle'a eklentinin sürümünü not etmesini ancak kök derlemede kullanmamasını söyler. Bu plugins bloğu dışında kök derleme komut dosyası genellikle boş olur.

Kotlin

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

Eski

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

Tek modüllü bir projeniz varsa sürümü modül düzeyindeki derleme komut dosyasında açıkça belirtebilir ve proje düzeyindeki derleme komut dosyasını boş bırakabilirsiniz:

Kotlin

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

Eski

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