Derleme çeşitlerini yapılandırma

Bu sayfada, tek bir projeden uygulamanızın farklı sürümlerini oluşturmak için derleme varyantlarını nasıl yapılandırabileceğiniz ve bağımlılıklarınızı ve imzalama yapılandırmalarınızı nasıl düzgün bir şekilde yönetebileceğiniz açıklanmaktadır.

Her derleme varyantı, uygulamanızın oluşturabileceğiniz farklı bir sürümünü temsil eder. Örneğin, uygulamanızın sınırlı içeriklere sahip ücretsiz bir sürümünü ve daha fazla içerik barındıran ücretli bir sürümünü oluşturmak isteyebilirsiniz. Ayrıca, API düzeyine veya diğer cihaz varyasyonlarına göre farklı cihazları hedefleyen farklı uygulama sürümleri de oluşturabilirsiniz.

Derleme varyantları, Gradle'ın derleme türlerinizde ve ürün çeşitlerinizde yapılandırılan ayarları, kodu ve kaynakları birleştirmek için belirli bir kural kümesini kullanmasının sonucudur. Derleme çeşitlerini doğrudan yapılandırmasanız da bunları oluşturan derleme türlerini ve ürün çeşitlerini yapılandırırsınız.

Örneğin, bir "demo" ürün çeşidi, özel kaynak kodu, kaynaklar ve minimum API düzeyleri gibi belirli özellikleri ve cihaz gereksinimlerini belirtebilir. "Hata ayıklama" derleme türü ise hata ayıklama seçenekleri ve imzalama anahtarları gibi farklı derleme ve paketleme ayarları uygular. Bu ikisini birleştiren derleme varyantı, uygulamanızın "demoDebug" sürümüdür ve "demo" ürün çeşnisinde, "debug" derleme türünde ve main/ kaynak kümesinde yer alan yapılandırmaların ve kaynakların bir kombinasyonunu içerir.

Derleme türlerini yapılandırma

Modül düzeyindeki build.gradle.kts dosyasının android bloğunda derleme türleri oluşturup yapılandırabilirsiniz. Yeni bir modül oluşturduğunuzda Android Studio, hata ayıklama ve yayın derleme türlerini otomatik olarak oluşturur. Hata ayıklama derleme türü, derleme yapılandırma dosyasında görünmese de Android Studio bunu debuggable true ile yapılandırır. Bu sayede uygulamada güvenli Android cihazlarda hata ayıklayabilir ve uygulama imzalamayı genel bir hata ayıklama anahtar deposuyla yapılandırabilirsiniz.

Belirli ayarları eklemek veya değiştirmek istiyorsanız yapılandırmanıza hata ayıklama derleme türünü ekleyebilirsiniz. Aşağıdaki örnekte, hata ayıklama derleme türü için bir applicationIdSuffix belirtilir ve hata ayıklama derleme türündeki ayarlar kullanılarak başlatılan bir "hazırlama" derleme türü yapılandırılır:

Kotlin

android {
    defaultConfig {
        manifestPlaceholders["hostName"] = "www.example.com"
        ...
    }
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
        }

        getByName("debug") {
            applicationIdSuffix = ".debug"
            isDebuggable = true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        create("staging") {
            initWith(getByName("debug"))
            manifestPlaceholders["hostName"] = "internal.example.com"
            applicationIdSuffix = ".debugStaging"
        }
    }
}

Groovy

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

Not: Bir derleme yapılandırma dosyasında değişiklik yaptığınızda Android Studio, projenizi yeni yapılandırmayla senkronize etmenizi gerektirir. Projenizi senkronize etmek için değişiklik yaptığınızda görünen bildirim çubuğunda Şimdi Senkronize Et'i tıklayın veya araç çubuğundan Projeyi Senkronize Et'i tıklayın. Android Studio, yapılandırmanızda herhangi bir hata fark ederse sorunu açıklamak için Messages (Mesajlar) penceresi gösterilir.

Derleme türleriyle yapılandırabileceğiniz tüm özellikler hakkında daha fazla bilgi edinmek için BuildType referansını inceleyin.

Ürün varyantlarını yapılandırma

Ürün aromaları oluşturmak, derleme türleri oluşturmaya benzer. Ürün çeşitlerini derleme yapılandırmanızdaki productFlavors bloğuna ekleyin ve istediğiniz ayarları dahil edin. Ürün çeşitleri, defaultConfig defaultConfig aslında ProductFlavor sınıfına ait olduğundan defaultConfig ile aynı özellikleri destekler. Bu, defaultConfig bloğundaki tüm varyantlar için temel yapılandırmayı sağlayabileceğiniz ve her varyantın applicationId gibi varsayılan değerleri değiştirebileceği anlamına gelir. Uygulama kimliği hakkında daha fazla bilgi edinmek için Uygulama kimliğini ayarlama başlıklı makaleyi inceleyin.

Not: main/ manifest dosyasında package özelliğini kullanarak paket adını belirtmeniz gerekir. Ayrıca, R sınıfına başvurmak veya göreli etkinlik ya da hizmet kaydını çözmek için kaynak kodunuzda bu paket adını kullanmanız gerekir. Bu sayede, kaynak kodunuzu değiştirmeniz gerekmeden her ürün aromasına paketleme ve dağıtım için benzersiz bir kimlik vermek üzere applicationId öğesini kullanabilirsiniz.

Tüm aromalar, adlandırılmış bir aroma boyutuna (ürün aromaları grubu) ait olmalıdır. Tüm lezzetleri bir lezzet boyutuna atamanız gerekir. Aksi takdirde aşağıdaki derleme hatasını alırsınız.

  Error: All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

Belirli bir modülde yalnızca bir varyant boyutu belirtiliyorsa Android Gradle eklentisi, modülün tüm varyantlarını otomatik olarak bu boyuta atar.

Aşağıdaki kod örneğinde "version" adlı bir varyant boyutu oluşturulur ve "demo" ile "full" ürün varyantları eklenir. Bu aromalar kendi applicationIdSuffix ve versionNameSuffix'lerini sağlar:

Kotlin

android {
    ...
    defaultConfig {...}
    buildTypes {
        getByName("debug"){...}
        getByName("release"){...}
    }
    // Specifies one flavor dimension.
    flavorDimensions += "version"
    productFlavors {
        create("demo") {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension = "version"
            applicationIdSuffix = ".demo"
            versionNameSuffix = "-demo"
        }
        create("full") {
            dimension = "version"
            applicationIdSuffix = ".full"
            versionNameSuffix = "-full"
        }
    }
}

Groovy

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

Not: Google Play'de APK'ler kullanarak dağıttığınız eski bir uygulamanız (Ağustos 2021'den önce oluşturulmuş) varsa uygulamanızı Google Play'de birden fazla APK desteğini kullanarak dağıtmak için tüm varyantlara aynı applicationId değerini atayın ve her varyanta farklı bir versionCode verin. Uygulamanızın farklı varyantlarını Google Play'de ayrı uygulamalar olarak dağıtmak için her varyanta farklı bir applicationId atamanız gerekir.

Ürün çeşitlerinizi oluşturup yapılandırdıktan sonra bildirim çubuğunda Şimdi Senkronize Et'i tıklayın. Senkronizasyon tamamlandıktan sonra Gradle, derleme türlerinize ve ürün çeşitlerinize göre otomatik olarak derleme varyantları oluşturur ve bunları <product-flavor><Build-Type>'ya göre adlandırır. Örneğin, "demo" ve "full" ürün çeşitleri oluşturduysanız ve varsayılan "debug" ile "release" derleme türlerini koruduysanız Gradle aşağıdaki derleme varyantlarını oluşturur:

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

Hangi derleme varyantının oluşturulacağını ve çalıştırılacağını seçmek için Build (Derle) > Select Build Variant (Derleme Varyantı Seç) seçeneğine gidin ve menüden bir derleme varyantı seçin. Her derleme varyantını kendi özellikleri ve kaynaklarıyla özelleştirmeye başlamak için bu sayfada açıklandığı gibi kaynak kümeleri oluşturup yönetmeniz gerekir.

Derleme varyantları için uygulama kimliğini değiştirme

Uygulamanız için bir APK veya AAB oluşturduğunuzda derleme araçları, uygulamayı aşağıdaki örnekte gösterildiği gibi build.gradle.kts dosyasındaki defaultConfig bloğunda tanımlanan uygulama kimliğiyle etiketler. Ancak uygulamanızın Google Play Store'da ayrı girişler olarak gösterilecek farklı sürümlerini (ör. "ücretsiz" ve "pro" sürümü) oluşturmak istiyorsanız her biri farklı bir uygulama kimliğine sahip ayrı derleme varyantları oluşturmanız gerekir.

Bu durumda, her derleme varyantını ayrı bir ürün aroması olarak tanımlayın. productFlavors bloğundaki her bir varyant için applicationId özelliğini yeniden tanımlayabilir veya bunun yerine applicationIdSuffix kullanarak varsayılan uygulama kimliğine bir segment ekleyebilirsiniz.

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
        }
    }
}

Groovy

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    productFlavors {
        free {
            applicationIdSuffix ".free"
        }
        pro {
            applicationIdSuffix ".pro"
        }
    }
}

Bu durumda, "free" ürün çeşidi için uygulama kimliği "com.example.myapp.free" olur.

Ayrıca, applicationIdSuffix simgesini kullanarak derleme türünüze göre bir segment ekleyebilirsiniz.

Kotlin

android {
    ...
    buildTypes {
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }
}

Groovy

android {
    ...
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

Gradle, derleme türü yapılandırmasını ürün çeşnisinden sonra uyguladığından "free debug" derleme varyantının uygulama kimliği "com.example.myapp.free.debug" olur. Aynı cihazda hem hata ayıklama hem de yayın derlemesini kullanmak istediğinizde bu yöntem faydalıdır. Çünkü iki uygulamanın aynı uygulama kimliğine sahip olması mümkün değildir.

Google Play'de APK kullanarak dağıttığınız eski bir uygulamanız (Ağustos 2021'den önce oluşturulmuş) varsa ve API düzeyi gibi farklı cihaz yapılandırmalarını hedefleyen birden fazla APK dağıtmak için aynı uygulama listelemesini kullanmak istiyorsanız her derleme varyantı için aynı uygulama kimliğini kullanmanız ancak her APK'ya farklı bir versionCode vermeniz gerekir. Daha fazla bilgi için Birden fazla APK desteği hakkında bilgi edinin. Varsayılan olarak tek bir sürüm kodu ve uygulama kimliği kullanan tek bir yapıyı kullandığından, AAB'ler kullanılarak yayınlama etkilenmez.

İpucu: Manifest dosyanızda uygulama kimliğine referans vermeniz gerekiyorsa herhangi bir manifest özelliğinde ${applicationId} yer tutucusunu kullanabilirsiniz. Gradle, derleme sırasında bu etiketi gerçek uygulama kimliğiyle değiştirir. Daha fazla bilgi için Derleme değişkenlerini manifeste yerleştirme başlıklı makaleyi inceleyin.

Birden fazla ürün aromasını aroma boyutlarıyla birleştirme

Bazı durumlarda, birden fazla ürün çeşidinin yapılandırmalarını birleştirmek isteyebilirsiniz. Örneğin, API düzeyine dayalı olarak "full" ve "demo" ürün çeşitleri için farklı yapılandırmalar oluşturmak isteyebilirsiniz. Bunu yapmak için Android Gradle eklentisi, ürün aromalarının birden fazla grubunu aroma boyutları olarak oluşturmanıza olanak tanır.

Gradle, uygulamanızı oluştururken tanımladığınız her aroma boyutundan bir ürün aroması yapılandırmasını, bir derleme türü yapılandırmasıyla birleştirerek nihai derleme varyantını oluşturur. Gradle, aynı aroma boyutuna ait ürün aromalarını birleştirmez.

Aşağıdaki kod örneğinde, "tam" ve "demo" ürün çeşitlerini gruplandırmak için "mod" çeşidi boyutu oluşturmak üzere flavorDimensions özelliği, API düzeyine göre ürün çeşidi yapılandırmalarını gruplandırmak için ise "api" çeşidi boyutu kullanılmaktadır:

Kotlin

android {
  ...
  buildTypes {
    getByName("debug") {...}
    getByName("release") {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions += listOf("api", "mode")

  productFlavors {
    create("demo") {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension = "mode"
      ...
    }

    create("full") {
      dimension = "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    create("minApi24") {
      dimension = "api"
      minSdk = 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.
      versionCode = 30000 + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi24"
      ...
    }

    create("minApi23") {
      dimension = "api"
      minSdk = 23
      versionCode = 20000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi23"
      ...
    }

    create("minApi21") {
      dimension = "api"
      minSdk = 21
      versionCode = 10000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi21"
      ...
    }
  }
}
...

Groovy

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.

      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion 23
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion 21
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

Gradle'ın oluşturduğu derleme varyantlarının sayısı, her bir aroma boyutundaki aroma sayısıyla yapılandırdığınız derleme türlerinin sayısının çarpımına eşittir. Gradle, her derleme varyantını veya karşılık gelen yapıları adlandırırken önceliği daha yüksek olan aroma boyutuna ait ürün aromaları önce, ardından önceliği daha düşük olan boyutlara ait olanlar ve son olarak derleme türü görünür.

Önceki derleme yapılandırması örnek olarak kullanıldığında Gradle, aşağıdaki adlandırma şemasıyla toplam 12 derleme varyantı oluşturur:

  • Derleme varyantı: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
  • İlgili APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
  • Örneğin,
    Derleme varyantı: minApi24DemoDebug
    İlgili APK: app-minApi24-demo-debug.apk

Her bir ürün aroması ve derleme varyantı için oluşturabileceğiniz kaynak kümesi dizinlerine ek olarak, ürün aromalarının her bir kombinasyonu için de kaynak kümesi dizinleri oluşturabilirsiniz. Örneğin, src/demoMinApi24/java/ dizininde Java kaynakları oluşturup ekleyebilirsiniz. Gradle, bu kaynakları yalnızca bu iki ürün çeşnisini birleştiren bir varyant oluştururken kullanır.

Ürün aroması kombinasyonları için oluşturduğunuz kaynak kümeleri, her bir ürün aromasına ait kaynak kümelerinden daha yüksek önceliğe sahiptir. Kaynak kümeleri ve Gradle'ın kaynakları nasıl birleştirdiği hakkında daha fazla bilgi edinmek için kaynak kümeleri oluşturma bölümünü okuyun.

Varyantları filtreleme

Gradle, yapılandırdığınız ürün aromalarının ve derleme türlerinin olası her kombinasyonu için bir derleme varyantı oluşturur. Ancak, ihtiyacınız olmayan veya projenizin bağlamında anlamlı olmayan belirli derleme varyantları olabilir. Belirli derleme varyantı yapılandırmalarını kaldırmak için modül düzeyindeki build.gradle.kts dosyanızda bir varyant filtresi oluşturun.

Önceki bölümdeki derleme yapılandırmasını örnek olarak kullanarak uygulamanın demo sürümünde yalnızca API düzeyi 23 ve sonraki sürümlerin destekleneceğini varsayalım. "minApi21" ve "demo" ürün varyantlarını birleştiren tüm derleme varyantı yapılandırmalarını filtrelemek için variantFilter bloğunu kullanabilirsiniz:

Kotlin

android {
  ...
  buildTypes {...}

  flavorDimensions += listOf("api", "mode")
  productFlavors {
    create("demo") {...}
    create("full") {...}
    create("minApi24") {...}
    create("minApi23") {...}
    create("minApi21") {...}
  }
}

androidComponents {
    beforeVariants { variantBuilder ->
        // To check for a certain build type, use variantBuilder.buildType == "<buildType>"
        if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) {
            // Gradle ignores any variants that satisfy the conditions above.
            variantBuilder.enable = false
        }
    }
}
...

Groovy

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

Derleme yapılandırmanıza bir varyant filtresi ekleyip bildirim çubuğunda Şimdi Senkronize Et'i tıkladığınızda Gradle, belirttiğiniz koşulları karşılayan tüm derleme varyantlarını yoksayar. Menü çubuğundan Build > Select Build Variant'ı (Derleme > Derleme Varyantı Seç) veya araç penceresi çubuğunda Build Variants'ı (Derleme Varyantları) tıkladığınızda derleme varyantları artık menüde görünmüyor.

Kaynak kümeleri oluşturma

Android Studio, varsayılan olarak tüm derleme varyantlarınız arasında paylaşmak istediğiniz her şey için main/ kaynak kümesi ve dizinleri oluşturur. Ancak, Gradle'ın belirli derleme türleri, ürün çeşitleri, ürün çeşitlerinin kombinasyonları (çeşit boyutları kullanılırken) ve derleme varyantları için hangi dosyaları derleyip paketleyeceğini tam olarak kontrol etmek üzere yeni kaynak kümeleri oluşturabilirsiniz.

Örneğin, main/ kaynak grubunda temel işlevleri tanımlayabilir ve farklı müşteriler için uygulamanızın markasını değiştirmek üzere ürün çeşidi kaynak gruplarını kullanabilir veya yalnızca hata ayıklama derleme türünü kullanan derleme varyantları için özel izinler ve günlük kaydı işlevleri ekleyebilirsiniz.

Gradle, kaynak grubu dosyalarının ve dizinlerinin main/ kaynak grubuna benzer şekilde belirli bir düzende olmasını bekler. Örneğin, Gradle, "hata ayıklama" derleme türünüze özel Kotlin veya Java sınıf dosyalarının src/debug/kotlin/ ya da src/debug/java/ dizinlerinde bulunmasını bekler.

Android Gradle eklentisi, her bir derleme türü, ürün çeşidi ve derleme varyantı için dosyalarınızı nasıl düzenleyeceğinizi gösteren yararlı bir Gradle görevi sağlar. Örneğin, görev çıkışındaki aşağıdaki örnekte, Gradle'ın "debug" derleme türü için belirli dosyaları nerede bulmayı beklediği açıklanmaktadır:

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: debugCompile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Kotlin sources: [app/src/debug/kotlin, app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

Bu çıkışı görüntülemek için aşağıdaki adımları uygulayın:

  1. Araç penceresi çubuğunda Gradle'ı tıklayın.
  2. MyApplication > Tasks > android'e gidin ve sourceSets'i çift tıklayın.

    Görevler klasörünü görmek için Gradle'ın senkronizasyon sırasında görev listesini oluşturmasına izin vermeniz gerekir. Bunun için, aşağıdaki adımları uygulayın:

    1. Dosya > Ayarlar > Deneysel'i (macOS'te Android Studio > Ayarlar > Deneysel) tıklayın.
    2. Gradle senkronizasyonu sırasında Gradle görev listesi oluşturma'nın seçimini kaldırın.
  3. Gradle görevi yürüttükten sonra, çıkışı görüntülemek için Çalıştır penceresi açılır.

Not: Görev çıktısında, uygulamanız için test çalıştırmak üzere kullanmak istediğiniz dosyalarla ilgili kaynak kümelerini (ör. test/ ve androidTest/ test kaynak kümeleri) nasıl düzenleyeceğiniz de gösterilir.

Yeni bir derleme varyantı oluşturduğunuzda Android Studio, kaynak kümesi dizinlerini sizin için oluşturmaz ancak size yardımcı olacak birkaç seçenek sunar. Örneğin, "debug" derleme türünüz için yalnızca java/ dizinini oluşturmak istiyorsanız:

  1. Proje bölmesini açın ve bölmenin üst kısmındaki menüden Proje görünümünü seçin.
  2. MyProject/app/src/ adresine gidiş rotasını izle.
  3. src dizinini sağ tıklayın ve Yeni > Dizin'i seçin.
  4. Gradle Source Sets (Gradle Kaynak Kümeleri) bölümündeki menüden full/java'yı seçin.
  5. Enter tuşuna basın.

Android Studio, hata ayıklama derleme türünüz için bir kaynak grubu dizini oluşturur ve ardından bu dizinin içinde java/ dizinini oluşturur. Alternatif olarak, Android Studio, belirli bir derleme varyantı için projenize yeni bir dosya eklediğinizde dizinleri sizin için oluşturabilir.

Örneğin, "hata ayıklama" derleme türünüz için bir değerler XML dosyası oluşturmak üzere:

  1. Proje bölmesinde, src dizinini sağ tıklayın ve Yeni > XML > Değerler XML Dosyası'nı seçin.
  2. XML dosyası için adı girin veya varsayılan adı kullanmaya devam edin.
  3. Hedef Kaynak Kümesi'nin yanındaki menüden debug'ı seçin.
  4. Son'u tıklayın.

"Debug" derleme türü hedef kaynak kümesi olarak belirtildiğinden Android Studio, XML dosyasını oluştururken gerekli dizinleri otomatik olarak oluşturur. Elde edilen dizin yapısı, Şekil 1'deki gibi görünür.

1.şekil "Hata ayıklama" derleme türü için yeni kaynak grubu dizinleri.

Etkin kaynak kümelerinin simgesinde, etkin olduklarını gösteren yeşil bir gösterge bulunur. debug kaynak kümesi, main kaynak kümesiyle birleştirileceğini göstermek için [main] ile sonlandırılır.

Aynı prosedürü kullanarak ürün çeşitleri (ör. src/demo/) ve derleme varyantları (ör. src/demoDebug/) için de kaynak kümesi dizinleri oluşturabilirsiniz. Ayrıca, src/androidTestDemoDebug/ gibi belirli derleme varyantlarını hedefleyen test kaynak kümeleri de oluşturabilirsiniz. Daha fazla bilgi edinmek için kaynak kümelerini test etme hakkında bilgi edinin.

Varsayılan kaynak grubu yapılandırmalarını değiştirme

Kaynak kümeleri oluşturma ile ilgili önceki bölümde açıklandığı gibi, Gradle'ın beklediği varsayılan kaynak kümesi dosyası yapısında düzenlenmemiş kaynaklarınız varsa sourceSets bloğunu kullanarak Gradle'ın bir kaynak kümesinin her bileşeni için dosya toplamak üzere baktığı yeri değiştirebilirsiniz.

sourceSets bloğu, android bloğunda olmalıdır. Kaynak dosyaları taşımanız gerekmez. Gradle'a yalnızca, Gradle'ın her kaynak grubu bileşeni için dosyaları bulabileceği, modül düzeyindeki build.gradle.kts dosyasına göre göreli yolları sağlamanız gerekir. Hangi bileşenleri yapılandırabileceğinizi ve bunları birden fazla dosya ya da dizinle eşleyip eşleyemeyeceğinizi öğrenmek için Android Gradle eklentisi API referansına bakın.

Aşağıdaki kod örneği, app/other/ dizinindeki kaynakları main kaynak kümesinin belirli bileşenleriyle eşler ve androidTest kaynak kümesinin kök dizinini değiştirir:

Kotlin

android {
  ...
  // Encapsulates configurations for the main source set.
  sourceSets.getByName("main") {
    // Changes the directory for Java sources. The default directory is
    // 'src/main/java'.
    java.setSrcDirs(listOf("other/java"))

    // If you list multiple directories, Gradle uses all of them to collect
    // sources. Because Gradle gives these directories equal priority, if
    // you define the same resource in more than one directory, you receive an
    // error when merging resources. The default directory is 'src/main/res'.
    res.setSrcDirs(listOf("other/res1", "other/res2"))

    // Note: Avoid specifying a directory that is a parent to one
    // or more other directories you specify. For example, avoid the following:
    // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
    // Specify either only the root 'other/res1' directory or only the
    // nested 'other/res1/layouts' and 'other/res1/strings' directories.

    // For each source set, you can specify only one Android manifest.
    // By default, Android Studio creates a manifest for your main source
    // set in the src/main/ directory.
    manifest.srcFile("other/AndroidManifest.xml")
    ...
  }

  // Create additional blocks to configure other source sets.
  sourceSets.getByName("androidTest") {
      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot("src/tests")
      ...
  }
}
...

Groovy

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you receive an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: Avoid specifying a directory that is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // Specify either only the root 'other/res1' directory or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

Kaynak dizinin yalnızca bir kaynak kümesine ait olabileceğini unutmayın. Örneğin, aynı test kaynaklarını hem test hem de androidTest kaynak kümeleriyle paylaşamazsınız. Bunun nedeni, Android Studio'nun her kaynak kümesi için ayrı IntelliJ modülleri oluşturması ve kaynak kümeleri arasında yinelenen içerik köklerini destekleyememesidir.

Kaynak kümeleriyle geliştirme

Yalnızca belirli yapılandırmalarla paketlenmesini istediğiniz kodu ve kaynakları içeren kaynak grubu dizinlerini kullanabilirsiniz. Örneğin, "demo" ürün aroması ile "debug" derleme türünün çapraz ürünü olan "demoDebug" derleme varyantını oluşturuyorsanız Gradle bu dizinlere bakar ve aşağıdaki önceliği verir:

  1. src/demoDebug/ (derleme varyantı kaynak grubu)
  2. src/debug/ (derleme türü kaynak grubu)
  3. src/demo/ (ürün türü kaynak grubu)
  4. src/main/ (ana kaynak grubu)

Ürün aromalarının kombinasyonları için oluşturulan kaynak kümeleri, tüm aroma boyutlarını içermelidir. Örneğin, derleme varyantı kaynak kümesi, derleme türü ve tüm aroma boyutlarının birleşimi olmalıdır. Birden fazla ancak tüm varyant boyutlarını kapsamayan klasörleri içeren kod ve kaynakların birleştirilmesi desteklenmez.

Birden fazla ürün aromasını birleştirirseniz ürün aromaları arasındaki öncelik, ait oldukları aroma boyutuyla belirlenir. android.flavorDimensions özelliğiyle aroma boyutlarını listelerken, listelediğiniz ilk aroma boyutuna ait ürün aromaları, ikinci aroma boyutuna ait olanlara göre daha yüksek önceliğe sahiptir. Bu durum diğer aroma boyutları için de geçerlidir. Ayrıca, ürün aromalarının kombinasyonları için oluşturduğunuz kaynak kümeleri, tek bir ürün aromasına ait kaynak kümelerine göre daha yüksek önceliğe sahiptir.

Öncelik sırası, Gradle kodu ve kaynakları birleştirirken hangi kaynak grubunun daha yüksek önceliğe sahip olduğunu belirler. demoDebug/ kaynak grubu dizini büyük olasılıkla bu derleme varyantına özel dosyalar içerdiğinden demoDebug/, debug/ içinde de tanımlanmış bir dosya içeriyorsa Gradle, demoDebug/ kaynak grubundaki dosyayı kullanır. Benzer şekilde, Gradle, derleme türü ve ürün aroması kaynak kümelerindeki dosyalara main/ içindeki aynı dosyalardan daha yüksek öncelik verir. Gradle, aşağıdaki derleme kurallarını uygularken bu öncelik sırasını dikkate alır:

  • kotlin/ veya java/ dizinlerindeki tüm kaynak kodu, tek bir çıkış oluşturmak için birlikte derlenir.

    Not: Belirli bir derleme varyantı için Gradle, aynı Kotlin veya Java sınıfını tanımlayan iki veya daha fazla kaynak grubu diziniyle karşılaşırsa derleme hatası verir. Örneğin, hata ayıklama uygulaması oluştururken hem src/debug/Utility.kt hem de src/main/Utility.kt tanımlayamazsınız. Çünkü Gradle, derleme işlemi sırasında bu dizilerin her ikisine de bakar ve "duplicate class" (sınıfı çoğalt) hatası verir. Farklı derleme türleri için Utility.kt dosyasının farklı sürümlerini istiyorsanız her derleme türü, dosyanın kendi sürümünü tanımlamalı ve bunu main/ kaynak kümesine dahil etmemelidir.

  • Manifestler tek bir manifestte birleştirilir. Öncelik, önceki örnekteki listede yer alan sırayla verilir. Yani, derleme türü için manifest ayarları, ürün çeşnisi için manifest ayarlarını geçersiz kılar. Daha fazla bilgi edinmek için manifest birleştirme hakkında bilgi edinin.
  • values/ dizinlerindeki dosyalar birleştirilir. İki dosya aynı ada sahipse (ör. iki strings.xml dosyası) öncelik, önceki örnekteki listede olduğu sırayla verilir. Yani, derleme türü kaynak kümesindeki bir dosyada tanımlanan değerler, aynı dosyada bir ürün çeşnisinde tanımlanan değerleri geçersiz kılar.
  • res/ ve asset/ dizinlerindeki kaynaklar birlikte paketlenir. İki veya daha fazla kaynak grubunda aynı ada sahip kaynaklar varsa öncelik, önceki örnekteki listede olduğu gibi aynı sırayla verilir.
  • Gradle, uygulamayı oluştururken kitaplık modülü bağımlılıklarıyla birlikte gelen kaynaklara ve manifestlere en düşük önceliği verir.

Bağımlılıkları bildirme

Belirli bir derleme varyantı veya test kaynağı grubu için bağımlılık yapılandırmak üzere, aşağıdaki örnekte gösterildiği gibi Implementation anahtar kelimesinden önce derleme varyantının veya test kaynağı grubunun adını ekleyin:

Kotlin

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    "freeImplementation"(project(":mylibrary"))

    // 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("com.android.support.test.espresso:espresso-core:3.6.1")
}

Groovy

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // 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 'com.android.support.test.espresso:espresso-core:3.6.1'
}

Bağımlılıkları yapılandırma hakkında daha fazla bilgi için Derleme bağımlılıkları ekleme başlıklı makaleyi inceleyin.

Varyanta duyarlı bağımlılık yönetimini kullanma

Android Gradle eklentisinin 3.0.0 ve sonraki sürümlerinde, bir kitaplık kullanılırken varyantları otomatik olarak eşleştiren yeni bir bağımlılık mekanizması bulunur. Bu, bir uygulamanın debug varyantının bir kitaplığın debug varyantını otomatik olarak kullandığı anlamına gelir. Bu işlev, farklı varyantlar kullanılırken de çalışır: Bir uygulamanın freeDebug varyantı, bir kitaplığın freeDebug varyantını kullanır.

Eklentinin varyantları doğru şekilde eşleştirebilmesi için doğrudan eşleşmenin mümkün olmadığı durumlarda aşağıdaki bölümde açıklandığı gibi eşleşen yedekler sağlamanız gerekir.

Örneğin, uygulamanızın "staging" adlı bir derleme türünü yapılandırdığını ancak kitaplık bağımlılıklarından birinin bunu yapmadığını varsayalım. Eklenti, uygulamanızın "hazırlama" sürümünü oluşturmaya çalıştığında hangi kitaplık sürümünün kullanılacağını bilemez ve aşağıdakine benzer bir hata mesajı görürsünüz:

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

Varyant eşleşmesiyle ilgili derleme hatalarını düzeltme

Eklenti, Gradle'ın bir uygulama ile bağımlılık arasında doğrudan varyant eşleşmesinin mümkün olmadığı durumlarda sorunları nasıl çözeceğini kontrol etmenize yardımcı olacak DSL öğeleri içerir.

Aşağıda, varyant duyarlı bağımlılık eşleştirme ile ilgili sorunların ve bu sorunların DSL özellikleri kullanılarak nasıl çözüleceğinin listesi verilmiştir:

  • Uygulamanız, kitaplık bağımlılığının içermediği bir derleme türü içeriyor.

    Örneğin, uygulamanızda "staging" (hazırlama) derleme türü bulunuyor ancak bir bağımlılık yalnızca "debug" (hata ayıklama) ve "release" (yayın) derleme türlerini içeriyor.

    Kitaplık bağımlılığı, uygulamanızın içermediği bir derleme türü içerdiğinde sorun oluşmadığını unutmayın. Bunun nedeni, eklentinin hiçbir zaman bağımlılıktan bu derleme türünü istememesidir.

    Belirli bir derleme türü için alternatif eşleşmeleri belirtmek üzere matchingFallbacks kullanın. Örneğin:

    Kotlin

    // In the app's build.gradle.kts file.
    android {
        buildTypes {
            getByName("debug") {}
            getByName("release") {}
            create("staging") {
                // Specifies a sorted list of fallback build types that the
                // plugin can try to use when a dependency does not include a
                // "staging" build type. You may specify as many fallbacks as you
                // like, and the plugin selects the first build type that's
                // available in the dependency.
                matchingFallbacks += listOf("debug", "qa", "release")
            }
        }
    }

    Groovy

    // In the app's build.gradle file.
    android {
        buildTypes {
            debug {}
            release {}
            staging {
                // Specifies a sorted list of fallback build types that the
                // plugin can try to use when a dependency does not include a
                // "staging" build type. You may specify as many fallbacks as you
                // like, and the plugin selects the first build type that's
                // available in the dependency.
                matchingFallbacks = ['debug', 'qa', 'release']
            }
        }
    }
  • Hem uygulamada hem de kitaplık bağımlılığında bulunan belirli bir varyant boyutu için uygulamanız, kitaplığın içermediği varyantları içeriyor.

    Örneğin, hem uygulamanız hem de kitaplık bağımlılıkları "tier" (katman) adlı bir varyant boyutunu içeriyor. Ancak uygulamadaki "katman" boyutu "ücretsiz" ve "ücretli" seçeneklerini içerirken bir bağımlılık aynı boyut için yalnızca "demo" ve "ücretli" seçeneklerini içerir.

    Hem uygulamada hem de kitaplık bağımlılıklarında bulunan belirli bir aroma boyutu için, kitaplık uygulamanızın içermediği bir ürün aroması içerdiğinde sorun oluşmadığını unutmayın. Bunun nedeni, eklentinin hiçbir zaman bağımlılıktan bu türü istememesidir.

    Uygulamanın "ücretsiz" ürün çeşidi için alternatif eşleşmeleri belirtmek üzere matchingFallbacks karakterini kullanın. Örneğin:

    Kotlin

    // In the app's build.gradle.kts file.
    android {
        defaultConfig{
        // Don't configure matchingFallbacks in the defaultConfig block.
        // Instead, specify fallbacks for a given product flavor in the
        // productFlavors block, as shown below.
      }
        flavorDimensions += "tier"
        productFlavors {
            create("paid") {
                dimension = "tier"
                // Because the dependency already includes a "paid" flavor in its
                // "tier" dimension, you don't need to provide a list of fallbacks
                // for the "paid" flavor.
            }
            create("free") {
                dimension = "tier"
                // Specifies a sorted list of fallback flavors that the plugin
                // can try to use when a dependency's matching dimension does
                // not include a "free" flavor. Specify as many
                // fallbacks as you like; the plugin selects the first flavor
                // that's available in the dependency's "tier" dimension.
                matchingFallbacks += listOf("demo", "trial")
            }
        }
    }

    Groovy

    // In the app's build.gradle file.
    android {
        defaultConfig{
        // Don't configure matchingFallbacks in the defaultConfig block.
        // Instead, specify fallbacks for a given product flavor in the
        // productFlavors block, as shown below.
      }
        flavorDimensions 'tier'
        productFlavors {
            paid {
                dimension 'tier'
                // Because the dependency already includes a "paid" flavor in its
                // "tier" dimension, you don't need to provide a list of fallbacks
                // for the "paid" flavor.
            }
            free {
                dimension 'tier'
                // Specifies a sorted list of fallback flavors that the plugin
                // can try to use when a dependency's matching dimension does
                // not include a "free" flavor. Specify as many
                // fallbacks as you like; the plugin selects the first flavor
                // that's available in the dependency's "tier" dimension.
                matchingFallbacks = ['demo', 'trial']
            }
        }
    }
  • Kitaplık bağımlılığı, uygulamanızda bulunmayan bir varyant boyutu içeriyor.

    Örneğin, bir kitaplık bağımlılığı "minApi" boyutu için varyantlar içeriyor ancak uygulamanız yalnızca "tier" boyutu için varyantlar içeriyor. Uygulamanızın "freeDebug" sürümünü oluşturmak istediğinizde eklenti, bağımlılığın "minApi23Debug" veya "minApi18Debug" sürümünü kullanıp kullanmayacağını bilmiyor.

    Uygulamanızda, kitaplık bağımlılığında bulunmayan bir lezzet boyutu varsa sorun olmadığını unutmayın. Bunun nedeni, eklentinin yalnızca bağımlılıkta bulunan boyutların varyantlarıyla eşleşmesidir. Örneğin, bir bağımlılık ABI'ler için bir boyut içermiyorsa uygulamanızın "freeX86Debug" sürümü, bağımlılığın "freeDebug" sürümünü kullanır.

    Aşağıdaki örnekte gösterildiği gibi, defaultConfig bloğunda missingDimensionStrategy kullanarak eklentinin her eksik boyuttan seçebileceği varsayılan aromayı belirtin. Ayrıca, productFlavors bloğundaki seçimlerinizi geçersiz kılabilirsiniz. Böylece, her aroma eksik bir boyut için farklı bir eşleştirme stratejisi belirtebilir.

    Kotlin

    // In the app's build.gradle.kts file.
    android {
        defaultConfig{
        // Specifies a sorted list of flavors that the plugin can try to use from
        // a given dimension. This tells the plugin to select the "minApi18" flavor
        // when encountering a dependency that includes a "minApi" dimension.
        // You can include additional flavor names to provide a
        // sorted list of fallbacks for the dimension.
        missingDimensionStrategy("minApi", "minApi18", "minApi23")
        // Specify a missingDimensionStrategy property for each
        // dimension that exists in a local dependency but not in your app.
        missingDimensionStrategy("abi", "x86", "arm64")
        }
        flavorDimensions += "tier"
        productFlavors {
            create("free") {
                dimension = "tier"
                // You can override the default selection at the product flavor
                // level by configuring another missingDimensionStrategy property
                // for the "minApi" dimension.
                missingDimensionStrategy("minApi", "minApi23", "minApi18")
            }
            create("paid") {}
        }
    }

    Groovy

    // In the app's build.gradle file.
    android {
        defaultConfig{
        // Specifies a sorted list of flavors that the plugin can try to use from
        // a given dimension. This tells the plugin to select the "minApi18" flavor
        // when encountering a dependency that includes a "minApi" dimension.
        // You can include additional flavor names to provide a
        // sorted list of fallbacks for the dimension.
        missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
        // Specify a missingDimensionStrategy property for each
        // dimension that exists in a local dependency but not in your app.
        missingDimensionStrategy 'abi', 'x86', 'arm64'
        }
        flavorDimensions 'tier'
        productFlavors {
            free {
                dimension 'tier'
                // You can override the default selection at the product flavor
                // level by configuring another missingDimensionStrategy property
                // for the 'minApi' dimension.
                missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
            }
            paid {}
        }
    }

Daha fazla bilgi için Android Gradle eklentisi DSL referansındaki matchingFallbacks ve missingDimensionStrategy bölümlerine bakın.

İmzalama ayarlarını yapılandırma

Gradle, bu derleme için açıkça bir imzalama yapılandırması tanımlamadığınız sürece yayın derlemenizin APK'sını veya AAB'sini imzalamaz. Henüz bir imzalama anahtarınız yoksa Android Studio'yu kullanarak yükleme anahtarı ve anahtar deposu oluşturun.

Gradle derleme yapılandırmalarını kullanarak yayın derleme türünüz için imzalama yapılandırmalarını manuel olarak yapılandırmak üzere:

  1. Bir anahtar deposu oluşturun. Anahtar deposu, bir dizi özel anahtar içeren ikili dosyadır. Anahtar deponuzu güvenli bir yerde saklamanız gerekir.
  2. Özel anahtar oluşturun. Özel anahtar, uygulamanızı dağıtım için imzalamak üzere kullanılır ve hiçbir zaman uygulamaya dahil edilmez veya yetkisiz üçüncü taraflara açıklanmaz.
  3. İmzalama yapılandırmasını modül düzeyindeki build.gradle.kts dosyasına ekleyin:

    Kotlin

    ...
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            create("release") {
                storeFile = file("myreleasekey.keystore")
                storePassword = "password"
                keyAlias = "MyReleaseKey"
                keyPassword = "password"
            }
        }
        buildTypes {
            getByName("release") {
                ...
                signingConfig = signingConfigs.getByName("release")
            }
        }
    }

    Groovy

    ...
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            release {
                storeFile file("myreleasekey.keystore")
                storePassword "password"
                keyAlias "MyReleaseKey"
                keyPassword "password"
            }
        }
        buildTypes {
            release {
                ...
                signingConfig signingConfigs.release
            }
        }
    }

Not: Yayın anahtarınızın ve anahtar deponuzun şifrelerini derleme dosyasına eklemek iyi bir güvenlik uygulaması değildir. Bunun yerine, derleme dosyasını bu şifreleri ortam değişkenlerinden alacak veya derleme sürecinde bu şifreleri girmeniz istenecek şekilde yapılandırın.

Bu şifreleri ortam değişkenlerinden almak için:

Kotlin

storePassword = System.getenv("KSTOREPWD")
keyPassword = System.getenv("KEYPWD")

Groovy

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

Alternatif olarak, anahtar deposunu yerel bir özellikler dosyasından da yükleyebilirsiniz. Güvenlik nedeniyle bu dosyayı kaynak denetimine eklemeyin. Bunun yerine, her geliştirici için yerel olarak ayarlayın. Daha fazla bilgi edinmek için Derleme dosyalarınızdan imza bilgilerini kaldırma başlıklı makaleyi inceleyin.

Bu işlemi tamamladıktan sonra uygulamanızı dağıtabilir ve Google Play'de yayınlayabilirsiniz.

Uyarı: Anahtar deponuzu ve özel anahtarınızı güvenli bir yerde saklayın ve bunların güvenli yedeklerini aldığınızdan emin olun. Play Uygulama İmzalama'yı kullanıyorsanız ve yükleme anahtarınızı kaybederseniz Play Console'u kullanarak sıfırlama isteğinde bulunabilirsiniz. Play Uygulama İmzalama olmadan uygulama yayınlıyorsanız (Ağustos 2021'den önce oluşturulan uygulamalar için) ve uygulama imzalama anahtarınızı kaybederseniz uygulamanızın tüm sürümlerini her zaman aynı anahtarla imzalamanız gerektiğinden uygulamanıza güncelleme yayınlayamazsınız.

Wear OS uygulamalarını imzalama

Wear OS uygulamaları yayınlarken hem kol saati APK'sı hem de isteğe bağlı telefon APK'sı aynı anahtarla imzalanmalıdır. Wear OS uygulamalarını paketleme ve imzalama hakkında daha fazla bilgi için Wear uygulamalarını paketleme ve dağıtma başlıklı makaleyi inceleyin.