Android Studio Önizlemesi'ndeki yeni özellikler

Bu sayfada, Android Studio önizleme sürümlerinde sunulan yeni özellikler listelenmektedir. Önizleme derlemeleri, Android Studio'daki en son özelliklere ve iyileştirmelere erken erişim sağlar. Bu önizleme sürümlerini buradan indirebilirsiniz. Android Studio'nun önizleme sürümünü kullanırken herhangi bir sorunla karşılaşırsanız lütfen bize bildirin. Hata raporlarınız Android Studio'nun iyileştirilmesine yardımcı olur.

Her bir önizleme sürümündeki önemli düzeltmelerin listesi de dahil olmak üzere Android Studio önizleme sürümleriyle ilgili en son haberler için Android Studio blogundaki Sürüm Güncellemeleri'ne bakın.

Android Studio'nun güncel sürümleri

Aşağıdaki tabloda Android Studio'nun mevcut sürümleri ve ilgili kanalları listelenmiştir.

Sürüm Kanal
Android Studio Zürafa | 1.3.2022 Kararlı
Android Gradle eklentisi 8.1.0 Kararlı
Android Studio Kirpi | 1.1.2023 Beta
Android Studio İguana | 2.2.2023 Canary

Android Gradle eklenti önizlemeleriyle uyumluluk

Android Studio'nun her önizleme sürümü, Android Gradle eklentisinin (AGP) karşılık gelen bir sürümüyle birlikte yayınlanır. Studio'nun önizleme sürümleri, AGP'nin uyumlu tüm kararlı sürümüyle çalışmalıdır. Ancak, AGP'nin önizleme sürümünü kullanıyorsanız Studio'nun karşılık gelen önizleme sürümünü kullanmanız gerekir (örneğin, AGP 7.2.0-alpha07 yüklü Android Studio Chipmunk Canary 7). Farklı sürümleri kullanma denemeleri (örneğin, AGP 7.2.0-alpha07 ile Android Studio Chipmunk Beta 1) senkronizasyon hatasına neden olur ve sonuçta AGP'nin ilgili sürümüne güncelleme istemi görüntülenir.

Android Gradle eklentisi API için kullanımdan kaldırma ve kaldırma işlemlerinin ayrıntılı günlüğü için Android Gradle eklentisi API güncellemeleri'ne bakın.

Android Studio Kirpi | 1.1.2023

Aşağıdakiler, Android Studio Hedgehog'daki yeni özelliklerdir.

Çoklu önizleme şablonları oluşturma

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ yeni Multipreview API şablonlarını kullanıma sunuyor: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark ve @PreviewDynamicColors. Böylece sık karşılaşılan senaryolarda Compose kullanıcı arayüzünüzü tek bir ek açıklamayla önizleyebilirsiniz.

JDK yolunu belirtmek için yeni makro

Android Studio Hedgehog Canary 10, JDK yolunu belirtmek için yeni bir makro (#GRADLE_LOCAL_JAVA_HOME) kullanıma sunuyor. Bu, projenizde Gradle arka plan programı (arka plan işlemi) yürütmesi için kullanılan Java ana sayfa yolunu belirtmeyi daha güvenli ve kolay hale getirir. Yol seçimi, .gradle/config.properties dosyasındaki java.home alanında saklanır. Bu alanı, Android Studio'daki Gradle JDK ayarlarından (Dosya veya Android Studio > Ayarlar > Derleme, Yürütme, Dağıtım > Derleme Araçları > Gradle) ayarlayın.

Yeni projelerde varsayılan olarak #GRADLE_LOCAL_JAVA_HOME kullanılacak. Hâlihazırda #JAVA_HOME gibi bir makro kullanmıyorsanız mevcut projeler, başarılı bir senkronizasyondan sonra otomatik olarak yeni makroya taşınır.

Yeni makronun başlıca avantajları şunlardır:

  • Önce projenizi açmadan senkronizasyonu tetiklemek için JDK yolunu manuel olarak değiştirebilirsiniz.
  • Gradle JDK seçiminizin tek bir doğruluk kaynağı olduğundan uyumsuz Gradle ve proje JDK sürümleriyle ilgili daha az hata vardır.

Uygulama Kalitesi Analizleri ile Android vitals'ı analiz etme

Uygulama Kalitesi Analizleri artık Android vitals verilerini içermektedir. Böylece, Google Play tarafından toplanan temel metriklere daha kolay erişebilir ve kullanıcı deneyiminizi iyileştirebilirsiniz. Google Play'de uygulamanızın kalitesini iyileştirmeye yardımcı olması için uygulama kararlılığı ile ilgili sorunları gidermek üzere Android vitals'ı kullanın.

Uygulama Kalitesi Analizleri aracı penceresinde Android vitals sorunlarını görüntüleyebilir, filtreleyebilir ve yığın izlemeden kodlamaya geçiş yapabilirsiniz. Başlamak için şu adımları uygulayın:

  1. Android Studio'da, araç çubuğunun sonundaki profil simgesini kullanarak geliştirici hesabınızda oturum açın.
  2. Android Studio'daki araç penceresini veya Görünüm > Araç Pencereleri > Uygulama Kalitesi Analizleri'ni tıklayarak Uygulama Kalitesi Analizleri'ni açın.
  3. Uygulama Kalitesi Analizleri'nde Android vitals sekmesini tıklayın.

Android vitals ve Crashlytics arasında farklı sayılar

Android vitals ve Crashlytics'in aynı kilitlenme ile ilişkili kullanıcı ve etkinlik sayısı için farklı değerler rapor edebileceğini unutmayın. Bu tutarsızlıklar, Play ve Crashlytics'in farklı zamanlarda ve farklı kullanıcılar için kilitlenmeleri yakalayabilmesinden kaynaklanır. Play ve Crashlytics sayılarının farklılık göstermesinin bazı nedenleri şunlardır:

  • Play, kilitlenmeleri başlatma zamanından itibaren yakalarken Crashlytics, Crashlytics SDK başlatıldıktan sonra oluşan kilitlenmeleri yakalar.
  • Bir kullanıcı yeni telefonu aldığında kilitlenme raporlamasını devre dışı bırakırsa bu kilitlenmeler Play'e bildirilmez. Ancak Crashlytics, kilitlenmeleri bir uygulamanın kendi gizlilik politikasına göre yakalar.

Cihaz yansıtma

Artık fiziksel cihazınızı Android Studio'daki Çalışan Cihazlar penceresinde yansıtabilirsiniz. Cihazınızın ekranını doğrudan Android Studio'ya aktararak, uygulamaları başlatma ve uygulamalarla etkileşimde bulunma, ekranı döndürme, telefonu katlama ve açma, ses düzeyini değiştirme ve daha pek çok işlemi doğrudan Studio IDE'den yapma gibi sık yapılan işlemleri gerçekleştirebilirsiniz.

Cihaz yansıtma, bilgisayara bağlı ve USB veya kablosuz hata ayıklama etkinleştirilmiş cihazlar olduğunda her zaman kullanılabilir. Çalışan Cihazlar penceresini veya Cihaz Yöneticisi'ni (Görünüm > Araç Pencereleri > Cihaz Yöneticisi) kullanarak yansıtmayı başlatabilir ve durdurabilirsiniz. Ayrıca, cihaz yansıtma etkinleştirildiğinde ayarları da özelleştirebilirsiniz (Ayarlar > Araçlar > Cihaz Yansıtma).

Çalışan Cihazlar Kullanıcı Arayüzü

Bilinen sorun: Bazı cihazlar, cihaz yansıtmasını desteklemek için yeterli bit hızında kodlama yapamayabilir. Bu tür durumlarda, Çalışan Cihazlar penceresinde ve aşağıda gösterilene benzer günlüklerde bir hata görebilirsiniz.

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

Gizlilik uyarısı

Cihaz yansıtması etkinse Android Studio, bağlı ve eşlenmiş tüm cihazlar için cihaz yansıtmasını otomatik olarak başlatır. Yansıtma bilgileri ve komutlar şifrelenmemiş bir kanal üzerinden iletildiği için bu, adb tcpip komutuna bağlanan cihazlar için bilgilerin açıklanmasına neden olabilir. Buna ek olarak, Android Studio adb sunucusuyla iletişim kurmak için şifrelenmemiş bir kanal kullanır. Böylece, yansıtma bilgileri, ana makine makinenizdeki diğer kullanıcılar tarafından engellenebilir.

Cihazları doğrudan Çalışan Cihazlar penceresinden yönetme

Artık + simgesini tıklayıp bir cihaz seçerek doğrudan Çalışan Cihazlar penceresinden bir Android Sanal Cihazı (AVD) başlatabilir veya fiziksel bir cihazı yansıtmaya başlayabilirsiniz. Fiziksel bir cihazın ortalama görüntüleme süresini veya yansıtmasını durdurmak için cihaz sekmesini kapatın.

Çalışan Cihazlar'daki Cihaz açılır menüsü

Hata ayıklayıcıda durum bilgilerini oluşturma

Compose kullanıcı arayüzünüzün bazı bölümleri beklenmedik bir şekilde yeniden oluşturulduğunda bazen bunun nedenini anlamak zor olabilir. Hata ayıklayıcı, oluşturulabilir bir işlevde ayrılma noktası ayarlarken artık beste öğesinin parametrelerini ve durumlarını listeler. Böylece yeniden derlemeye hangi değişikliklerin neden olmuş olabileceğini daha kolay şekilde belirleyebilirsiniz. Örneğin, bir beste dosyasını duraklattığınızda, hata ayıklayıcı hangi parametrelerin tam olarak "Değiştirildi" veya "Değiştirilmedi" olarak kaldığını bildirebilir. Böylece, yeniden derlemenin nedenini daha verimli bir şekilde araştırabilirsiniz.

Android Studio'yu Güvenli Mod'da Başlat

Android Studio Hedgehog, Android Studio'yu Güvenli Mod'da başlatma olanağını sunuyor. Bu mod, belirli özelliklerin çalışmadığı veya IDE'nin tamamının başlatılamadığı durumlarla karşılaşıyorsanız faydalı olabilir. Bu durum bazen Android Studio ile uyumsuz olan özel yapılandırmalar, ortam değişkenleri veya eklentilerden kaynaklanabilir.

Güvenli Mod'un kullanılması, IDE'yi geçici olarak başlatılmasına izin verebilecek bir dizi varsayılan yapılandırmaya döndürür. Böylece, sorunu tespit edip işlevselliği geri yüklemek için sorunu buradan giderebilirsiniz. Güvenli Mod, aşağıdakiler gibi işlemler yaparak Android Studio'yu sınırlı işlevlerle açmaya çalışır:

  • Üçüncü taraf eklentilerini devre dışı bırakır
  • Paket hâlinde sunulan Kotlin eklentisini, Studio ile birlikte başlangıçta verilen sürüme geri yükler
  • Yapılandırmaları geçici olarak sıfırlar (örneğin, studio.vmoptions dosyasında)
  • Başlatmayı engelleyebilen JRE_HOME ve TMP gibi ortam değişkenlerini doğrular
  • Gerekirse JRE'yi uyumlu bir sürüme geri döndürür.

Android Studio'yu Güvenli Mod'da başlatmak için aşağıdaki adımları uygulayın:

  1. Güvenli Mod komut dosyasını bulun.
    • Windows'da AndroidStudio/bin bölümüne gidip studio_safe.bat komut dosyasını bulun.
    • macOS'te Android Studio/Contents/bin adresine gidip studio_safe.sh komut dosyasını bulun.
    • Linux'ta android-studio/bin konumuna gidip studio_safe.sh komut dosyasını bulun.
  2. Komut dosyasını çalıştırın: komut satırını açın ve studio_safe.bat (macOS veya Linux için studio_safe.sh) yazıp Enter tuşuna basın.

Yerleştirilmiş Düzen Denetleyici

Android Studio Hedgehog Canary 2'den başlayarak Layout Inspector'ı doğrudan Çalışan Cihazlar araç penceresinden çalıştırabilirsiniz. Bu deneysel özellik, ekran alanını korur ve kullanıcı arayüzü hata ayıklama iş akışınızı tek bir araç penceresinde düzenlemenize yardımcı olur. Yerleşik modda bir görünüm hiyerarşisi gösterebilir, her görünümün özelliklerini inceleyebilir ve diğer yaygın Layout Inspector özelliklerine erişebilirsiniz. Seçeneklerin tamamına erişmek için yine de Layout Inspector'ı bağımsız bir pencerede çalıştırmanız gerekir (Windows'da Dosya > Ayarlar > Deneysel > Layout Inspector veya macOS'te Android Studio > Ayarlar > Deneysel > Layout Inspector).

Yerleştirilmiş Layout Inspector'ın bir sınırlaması, 3D modunun yalnızca anlık görüntülerde kullanılabilmesidir.

Yerleşik Layout Inspector'ı iyileştirmemize yardımcı olmak için lütfen bize geri bildirim gönderin.

Firebase Test Lab cihazlarını Gradle Yönetilen Cihazlarla kullanma

AGP 8.2.0-alpha03 veya daha yeni bir sürüm kullanırken, Gradle Yönetilen Cihazları kullanırken otomatik donanımlı testlerinizi Firebase Test Lab cihazlarında geniş ölçekte çalıştırabilirsiniz. Test Lab, testlerinizi hem fiziksel hem de sanal cihazlardaki çok çeşitli Android cihazlarda aynı anda çalıştırmanızı sağlar. Bu testler uzak Google veri merkezlerinde yürütülür. Gradle Yönetilen Cihazların (GMD) desteğiyle, derleme sistemi artık projenizin Gradle dosyalarındaki yapılandırmalara dayanarak bu Test Lab cihazlarında çalışan testleri tamamen yönetebilir.

Gradle tarafından yönetilen Firebase Test Lab cihazlarını kullanmaya başlayın

Aşağıdaki adımlarda, Firebase Test Lab cihazlarını GMD ile nasıl kullanmaya başlayacağınız açıklanmaktadır. Bu adımlar, kullanıcı kimlik bilgilerini sağlamak için gcloud KSA'yı kullanır. Bu, tüm geliştirme ortamları için geçerli olmayabilir. İhtiyaçlarınız için hangi kimlik doğrulama işlemini kullanacağınıza dair daha fazla bilgiyi Uygulama Varsayılan Kimlik Bilgilerinin işleyiş şekli bölümünde bulabilirsiniz.

  1. Firebase projesi oluşturmak için Firebase konsoluna gidin. Proje oluşturmak için Proje ekle'yi tıklayın ve ekrandaki talimatları uygulayın. Proje kimliğinizi unutmayın.

  2. Google Cloud KSA'yı yüklemek için gcloud KSA'yı yükleme başlıklı makaledeki adımları uygulayın.

  3. Yerel ortamınızı yapılandırın.

    1. gcloud'daki Firebase projenize bağlayın:

      gcloud config set project FIREBASE_PROJECT_ID

    2. API erişimi için kullanıcı kimlik bilgilerinizin kullanılmasına izin verin. Modül düzeyindeki derleme komut dosyasında DSL'yi kullanarak Gradle'a hizmet hesabı JSON dosyası ileterek yetkilendirme yapmanızı öneririz:

      Kotlin

      firebaseTestLab {
  ...
  serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
}

      Modern

      firebaseTestLab {
  ...
  serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
}

      Alternatif olarak aşağıdaki terminal komutunu kullanarak manuel olarak yetkilendirebilirsiniz:

      gcloud auth application-default login

    3. İsteğe bağlı: Firebase projenizi kota projesi olarak ekleyin. Bu adım yalnızca Test Lab için ücretsiz kotayı aşarsanız gerekir.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. Gerekli API'leri etkinleştirin.

    Google Developers Console API Kitaplığı sayfasında, bu API adlarını konsolun üst tarafındaki arama kutusuna yazıp her API'nin genel bakış sayfasında API'yi etkinleştir'i tıklayarak Cloud Testing API ve Cloud Tool Results API'yi etkinleştirin.

  5. Android projenizi yapılandırın.

    1. Firebase Test Lab eklentisini üst düzey derleme komut dosyasına ekleyin:

      Kotlin

      plugins {
  ...
  id("com.google.firebase.testlab") version "0.0.1-alpha03" apply false
}

      Modern

      plugins {
  ...
  id 'com.google.firebase.testlab' version '0.0.1-alpha03' apply false
}

    2. gradle.properties dosyasında özel cihaz türlerini etkinleştir:

      android.experimental.testOptions.managedDevices.customDevice=true

    3. Modül düzeyindeki derleme komut dosyasına Firebase Test Lab eklentisini ekleyin:

      Kotlin

      plugins {
 ...
 id "com.google.firebase.testlab"
}

      Modern

      plugins {
 ...
 id 'com.google.firebase.testlab'
}

Gradle tarafından yönetilen Firebase Test Lab cihazında testler oluşturun ve çalıştırın

Modül düzeyindeki derleme komut dosyasında uygulamanızı test etmek üzere kullanmak için Gradle'a bir Firebase Test Lab cihazı belirtebilirsiniz. Aşağıdaki kod örneği, ftlDevice adlı Gradle tarafından yönetilen Test Lab cihazı olarak API düzeyi 30'u çalıştıran bir Pixel 3 oluşturur. firebaseTestLab {} blokunu, modülünüze com.google.firebase.testlab eklentisini uyguladığınızda kullanabilirsiniz. Desteklenen minimum Android Gradle Eklentisi sürümü 8.2.0-alpha01'dir.

Kotlin

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Modern

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Testlerinizi, yapılandırdığınız Gradle tarafından yönetilen Test Lab cihazlarını kullanarak çalıştırmak için aşağıdaki komutu kullanın. device-name, Gradle derleme komut dosyanızda yapılandırdığınız cihazın adıdır (ör. ftlDevice). BuildVariant ise test etmek istediğiniz uygulamanızın derleme varyantıdır. Gradle'ın paralel olarak test çalıştırmadığını ve Test Lab cihazları için diğer Google Cloud KSA yapılandırmalarını desteklemediğini unutmayın.

Windows'da:

gradlew device-nameBuildVariantAndroidTest

Linux veya macOS'te:

./gradlew device-nameBuildVariantAndroidTest

Test çıkışı, test raporunu içeren bir HTML dosyasının yolunu içerir. Ayrıca, IDE'de Çalıştır > Test Geçmişi'ni tıklayarak test sonuçlarını daha ayrıntılı analiz için Android Studio'ya aktarabilirsiniz.

Testleri bir cihaz grubunda oluşturma ve çalıştırma

Testinizi ölçeklendirmek için bir cihaz grubuna birden fazla Gradle tarafından yönetilen Firebase Test Lab cihazı ekleyin ve ardından tek bir komutla bu cihazların hepsinde test çalıştırın. Aşağıdaki şekilde ayarlanmış birden fazla cihazınız olduğunu varsayalım:

firebaseTestLab {
  managedDevices {
    create("GalaxyS23Ultra") { ... }
    create("GalaxyZFlip3") { ... }
    create("GalaxyZFold3") { ... }
    create("GalaxyTabS2") { ... }
  }
}

Bu kullanıcıları samsungGalaxy adlı bir cihaz grubuna eklemek için groups {} blokunu kullanın:

firebaseTestLab {
  managedDevices {...}
}

android {
  ...
  testOptions {
    managedDevices {
      groups {
        create("samsungGalaxy") {
          targetDevices.add(devices["GalaxyS23Ultra"])
          targetDevices.add(devices["GalaxyZFlip3"])
          targetDevices.add(devices["GalaxyZFold3"])
          targetDevices.add(devices["GalaxyTabS3"])
        }
      }
    }
  }
}

Cihaz grubundaki tüm cihazlarda test çalıştırmak için aşağıdaki komutu kullanın:

Windows'da:

gradlew group-nameGroupBuildVariantAndroidTest

Linux veya macOS'te:

./gradlew group-nameGroupBuildVariantAndroidTest

Akıllı parçalama ile test çalıştırmalarını optimize edin

Gradle tarafından yönetilen Test Lab cihazlarında testler artık akıllı parçalamayı desteklemektedir. Akıllı parçalama, testlerinizi parçalara otomatik olarak dağıtır. Böylece her parça yaklaşık olarak aynı süre boyunca çalışır. Böylece, manuel ayırma çabalarını ve genel test çalıştırma süresini azaltır. Akıllı parçalama, testleri en uygun şekilde dağıtmak için test geçmişinizi veya testlerinizin daha önce ne kadar sürdüğü hakkındaki bilgileri kullanır. Akıllı parçalamayı kullanmak için Firebase Test Lab için Gradle eklentisinin 0.0.1-alpha03 sürümüne ihtiyacınız olduğunu unutmayın.

Akıllı parçalamayı etkinleştirmek için her bir parçadaki testlerin süresini belirtin. Testler tamamlanmadan parçaların iptal edilmesi gibi bir durumla karşılaşmamak için hedef parça süresini en az beş dakika timeoutMinutes olacak şekilde ayarlamanız gerekir.

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

Daha fazla bilgi edinmek için yeni DSL seçenekleri hakkında bilgi edinin.

Gradle tarafından yönetilen Firebase Test Lab cihazları için DSL güncellendi

Test çalıştırmalarınızı özelleştirmenize veya hâlihazırda kullanıyor olabileceğiniz diğer çözümlerden geçiş yapmanıza yardımcı olması için yapılandırabileceğiniz daha fazla DSL seçeneği vardır. Bu seçeneklerin bazılarını aşağıdaki kod snippet'inde açıklandığı gibi inceleyin.

firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       * 
       * Default to 0 for no sharding.
       */
      numUniformShards = 20
    }

    /**
     * For smart sharding, the target length of time each shard should takes in
     * minutes. Maxes out at 50 shards for physical devices and 100 shards for
     * virtual devices.
     *
     * Only one of numUniformShards or targetedShardDurationMinutes can be set.
     *
     * Defaults to 0 for no smart sharding.
     */
     targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
    }
  }
}

Gradle Sürüm Katalogları desteği

Android Studio Giraffe, bağımlılıkları tek bir merkezi konumdan yönetmenize ve bağımlılıkları modüller veya projeler arasında paylaşmanızı sağlayan TOML tabanlı Gradle Sürüm Katalogları özelliğini kullanıma sunuyor. Android Studio artık düzenleyici önerileri ve Proje Yapısı iletişim kutusuyla entegrasyon sayesinde sürüm kataloglarını yapılandırmayı kolaylaştırıyor. Gradle Sürüm Katalogları'na nasıl güncelleme yapılacağını öğrenmek için Derlemenizi sürüm kataloglarına taşıma bölümüne bakın.

Kod tamamlama ve gezinme

Bir sürüm kataloğunu TOML dosya biçiminde düzenlerken veya sürüm kataloğundan derleme dosyasına bir bağımlılık eklerken Android Studio, kod tamamlama özelliği sunar. Kod tamamlamayı kullanmak için Ctrl+Boşluk (macOS'te Command+Boşluk) tuşlarına basın. Buna ek olarak, Ctrl+b (macOS'te Command +b) tuşlarına basarak uygulamanızın build.gradle dosyasındaki bir bağımlılık referansından, sürüm kataloğunda bildirildiği yere hızlıca gidin.

Bağımlılık eklerken kod tamamlama

Proje Yapısı iletişim kutusuyla entegrasyon

Projeniz TOML dosya biçiminde tanımlanmış bir sürüm kataloğu kullanıyorsa burada tanımladığınız değişkenleri Android Studio'daki Proje Yapısı iletişim kutusu Değişkenler görünümünden (Dosya > Proje Yapısı > Değişkenler) düzenleyebilirsiniz. Her sürüm kataloğu için, ilgili katalogdaki değişkenleri listeleyen bir açılır liste bulunur. Bir değişkeni düzenlemek için ilgili değişkenin değerini tıklayın ve değişkenin üzerine yazın. Bu değişiklikleri kaydettiğinizde TOML dosyası uygun şekilde güncellenir.

Proje Yapısı iletişim kutusundaki bir sürüm kataloğundaki değişkenler

Bağımlılıkları Proje Yapısı iletişim kutusu Bağımlılıklar görünümünde de (Dosya > Proje Yapısı > Bağımlılıklar) güncelleyebilirsiniz. Proje Yapısı iletişim kutusunu kullanarak sürümleri güncellemek için düzenlemek istediğiniz modüle ve bağımlılığa gidin, ardından İstenen Sürüm alanını güncelleyin. Bu değişiklikleri kaydettiğinizde TOML dosyası uygun şekilde güncellenir. Bağımlılık sürümü bir değişken kullanılarak tanımlanmışsa, sürümü doğrudan bu şekilde güncellemek, değişkeni sabit kodlu bir değerle değiştirir. Ayrıca, Proje Yapısı iletişim kutusunu kullansanız da kullanmasanız da bir bağımlılığı derleme dosyasından kaldırmanın, bağımlılığı sürüm kataloğundan kaldırmadığını unutmayın.

Proje Yapısı iletişim kutusundaki bir sürüm kataloğundaki bağımlılıklar

Bilinen sorunlar ve sınırlamalar

Aşağıda, Android Studio'daki Gradle Sürüm Katalogları desteğiyle ilgili bilinen sorunlar veya sınırlamalar bulunmaktadır.

Kotlin komut dosyası dosyalarında eklenti takma adı bildirimleri vurgulanırken hata oluştu

alias(libs.plugins.example) biçiminde bir eklenti bildirimi eklediğinizde düzenleyici, libs bölümünün altına kırmızı bir alt çizgi ekler. Bu, Gradle'ın 8.0 ve önceki sürümlerinde bilinen bir sorundur ve Gradle'ın gelecekteki bir sürümünde çözülecektir.

Android Studio yalnızca TOML biçimindeki sürüm katalogları için desteklenir

Android Studio kod tamamlama, gezinme ve Proje Yapısı iletişim kutusu desteği şu anda yalnızca TOML dosya biçiminde tanımlanan sürüm katalogları için sunulmaktadır. Yine de sürüm kataloğunu doğrudan settings.gradle dosyasına ekleyebilir ve projenizde bu katalogun bağımlılıklarını kullanabilirsiniz.

Kotlin komut dosyası kullanılarak yazılan derleme dosyaları için Control+tıklama (macOS'te Command+tıklama) aracılığıyla bir bağımlılık tanımına gitme henüz desteklenmemektedir.

Firebase Asistan, bağımlılıkları doğrudan derleme komut dosyalarına ekler

Firebase Asistan, sürüm katalogları yerine doğrudan derleme komut dosyalarınıza bağımlılıklar ekler.

"Kullanımları bul" işlevi desteklenmiyor

Derleme dosyası ister KTS'te ister Groovy'de olsun, diğer derleme dosyalarında sürüm kataloğu değişkeninin kullanımlarını bulma henüz desteklenmemektedir. Diğer bir deyişle, sürüm kataloğundaki bir değişken tanımında Control+tıklama (macOS'te Command+tıklama) kullanıldığında, değişkenin kullanıldığı derleme dosyalarına yönlendirme yapılmaz.

Proje Yapısı iletişim kutusunda, birleşik derlemelere ait kataloglar gösterilmiyor

Android Studio'daki Proje Yapısı iletişim kutusu, kök gradle klasöründeyse birden fazla katalog dosyası gösterir ancak birleşik derleme kataloglarını göstermez. Örneğin, biri uygulamanız ve diğeri birleşik derleme için olmak üzere iki katalog dosyanız varsa Proje Yapısı iletişim kutusunda yalnızca uygulama kataloğu dosyası gösterilir. Kompozit bir derleme kullanabilirsiniz, ancak doğrudan TOML dosyasını düzenlemeniz gerekir.

Derleme optimizasyonunu yalnızca hedef API düzeyi için devre dışı bırak

Android Studio Giraffe Canary 6'dan başlayarak, hedef cihaz API düzeyi için IDE optimizasyonunu devre dışı bırakabilirsiniz. Varsayılan olarak Android Studio, dexing işlemini dağıtım yaptığınız hedef cihazın API düzeyine göre uyarlayarak genel derleme süresini kısaltır. Bu özelliği kapatmak için Dosya > Ayarlar > Deneysel'e gidin (macOS'te Android Studio > Ayarlar > Deneysel) ve Derlemeyi yalnızca hedef cihaz API düzeyi için optimize et seçeneğinin işaretini kaldırın. Bu derleme optimizasyonunu devre dışı bırakmanın derleme süresini artırabileceğini unutmayın.

[Yalnızca Windows] Virüsten koruma yazılımlarının derleme hızı üzerindeki etkisini en aza indirme

Derleme Analiz Aracı, virüsten koruma yazılımlarının derleme performansınızı etkileyip etkilemediğini size bildirir. Windows Defender gibi virüsten koruma yazılımları, Gradle tarafından kullanılan dizinleri gerçek zamanlı olarak tararsa bu durum yaşanabilir. Build Analiz Aracı, etkin taramadan hariç tutulacak dizinlerin bir listesini önerir ve mümkünse bunları Windows Defender klasör hariç tutma listesine eklemek için bir bağlantı sunar.

Eclipse Android Geliştirme Aracı projeleri artık desteklenmiyor

Android Studio Hedgehog ve sonraki sürümleri Eclipse ADT projelerini içe aktarmayı desteklemez. Bu projeleri hâlâ açabilirsiniz ancak bunlar artık Android projesi olmaz. Bu tür projeleri içe aktarmanız gerekiyorsa Android Studio'nun önceki bir sürümünü kullanabilirsiniz. Android Studio'nun belirli bir sürümü projenizi içe aktaramıyorsa daha eski bir sürümü deneyebilirsiniz. Proje, Android Studio'nun daha eski bir sürümü kullanılarak bir Android projesine dönüştürüldükten sonra, en yeni Android Studio sürümünü kullanarak bu projede çalışmak için AGP Yükseltme Asistanı'nı kullanabilirsiniz.

Android Studio İguana | 2.2.2023

Android Studio Iguana'daki yeni özellikler aşağıda belirtilmiştir.

Kullanıcı Arayüzü Kontrolü Oluşturun

Android Studio Iguana Canary 5, geliştiricilerin Jetpack Compose'da daha uyarlanabilir ve erişilebilir kullanıcı arayüzü geliştirmelerine yardımcı olmak için Oluşturma Önizlemesi'nde yeni bir Kullanıcı Arayüzü Kontrolü modunu kullanıma sundu. Bu özellik, görünümler için Görsel hata analizi ve Erişilebilirlik kontrolleri entegrasyonlarına benzer şekilde çalışır. Oluşturma kullanıcı arayüzünüzü otomatik olarak denetlemek ve büyük ekranlarda uzatılmış metin ya da düşük renk kontrastı gibi farklı ekran boyutlarında uyarlanabilir ve erişilebilirlik sorunlarını kontrol etmek için Android Studio için Oluştur kullanıcı arayüzü kontrol modunu etkinleştirin. Mod, farklı önizleme yapılandırmalarında bulunan sorunları vurgular ve bunları sorunlar panelinde listeler.

Oluşturma Önizlemesi'ndeki Kullanıcı Arayüzü Kontrolü simgesini tıklayarak bu özelliği hemen deneyin ve geri bildiriminizi gönderin:

Kullanıcı Arayüzü Kontrol Modu ile ilgili bilinen sorunlar:

  • Sorun panelindeki sorun seçimi odağını kaybedebilir
  • "Engelleme kuralı" çalışmıyor

Oluşturma Önizlemesi için Progresif Oluşturma

Android Studio Iguana Canary 3, Oluşturma Önizlemesi'nde progresif oluşturma özelliğini kullanıma sunuyor. Önizlemeleri daha performanslı hale getirmek için kesintisiz olarak sürdürdüğümüz çalışmalar kapsamında, artık görüntülenmeyen tüm önizlemelerde, kullanılan bellekten tasarruf etmek için oluşturma kalitesini kasıtlı olarak düşürüyoruz.

Bu özellik, bir dosya deneyi yaparak aynı anda daha fazla önizlemeyi işleyerek Önizlemelerin kullanılabilirliğini daha da artırmak ve geri bildiriminizi göndermek amacıyla geliştirilmiştir.

Studio Bot'u ile Tanışın

Studio Bot, Android geliştirme için kodlama yardımcınızdır. Bu, Android Studio'daki yapay zeka destekli bir konuşma deneyimidir ve Android geliştirme sorgularını yanıtlayarak daha üretken olmanıza yardımcı olur. Daha fazla bilgi için Meet Studio Bot'u sayfasını inceleyin.

Uygulama Kalitesi Analizleri'nde sürüm kontrol sistemi entegrasyonu

Uygulama Kalitesi Analizleri artık kilitlenmenin gerçekleştiği anda Crashlytics yığın izlemeden alakalı koda gitmenize olanak tanıyor. AGP, Android Studio'nun kodunuza gitmesine ve sorunun oluştuğu sürümde nasıl olduğunu göstermesine yardımcı olmak için kilitlenme raporlarına git kaydetme karma verilerini ekler. Uygulama Kalitesi Analizleri'nde bir kilitlenme raporu görüntülediğinizde mevcut git ödemenizdeki kod satırına gitmeyi seçebilir veya mevcut ödeme işlemi ile kilitlenmeyi oluşturan kod tabanınızın sürümü arasındaki farkı görüntüleyebilirsiniz.

Sürüm kontrol sisteminizi Uygulama Kalitesi Analizleri ile entegre etmek için aşağıdaki minimum gereksinimleri karşılamanız gerekir:

Sürüm kontrolü entegrasyonunu kullanmak için gradle.properties dosyasında android.enableVcsInfo işaretini etkinleştirin:

android.enableVcsInfo=true

Artık uygulamanızı derleyip Google Play'de yayınladığınızda, kilitlenme raporları IDE'nin yığın izlemeden uygulamanızın önceki sürümlerine bağlantı vermesi için gereken verileri içerir.

Espresso Device API'si ile yapılandırma değişikliklerine göre test etme

Cihaz döndürme ve ekranı açma gibi yaygın yapılandırma değişikliklerine tabi olduğunda uygulamanızı test etmek için Espresso Device API'yi kullanın. Espresso Device API, bu yapılandırma değişikliklerini sanal cihazda simüle etmenizi ve testlerinizi eşzamanlı olarak yürütmenizi sağlar. Böylece, tek seferde yalnızca bir kullanıcı arayüzü işlemi veya onayı gerçekleşir ve test sonuçlarınız daha güvenilir olur. Espresso ile kullanıcı arayüzü testleri yazma konusunda yeniyseniz dokümanlara bakın.

Espresso Device API'yi kullanmak için aşağıdakilere ihtiyacınız vardır:

  • Android Studio Iguana'nın en son Canary sürümü
  • Android Gradle Plugin 8.3'ün en son Alfa sürümü
  • Android Emulator 33.1.10 veya sonraki sürümler
  • API düzeyi 24 veya üstünü çalıştıran Android sanal cihaz

Espresso Device API'si için projenizi oluşturun

Projenizi Espresso Device API'yi destekleyecek şekilde ayarlamak için aşağıdakileri yapın:

  • Testin komutları test cihazına geçirmesine izin vermek için INTERNET ve ACCESS_NETWORK_STATE izinlerini androidTest kaynak grubundaki manifest dosyasına ekleyin:

      <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

  • gradle.properties dosyasında enableEmulatorControl deneysel işaretini etkinleştirin:

      android.experimental.androidTest.enableEmulatorControl=true

  • Modül düzeyindeki derleme komut dosyasında emulatorAccess seçeneğini etkinleştirin:

    Kotlin

      testOptions {
    emulatorAccess {
      isEnabled = true
    }
  }

    Modern

      testOptions {
    emulatorAccess {
      enabled true
    }
  }

  • Modül düzeyindeki derleme komut dosyasında, Espresso Cihazı kitaplığını projenize aktarın:

    Kotlin

      dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-device:1.0.0-alpha05")
  }

    Modern

      dependencies {
    androidTestImplementation 'androidx.test.espresso:espresso-device:1.0.0-alpha05'
  }

Sık kullanılan yapılandırma değişikliklerine göre test etme

Espresso Device API, cihaz yapılandırmasındaki değişiklikleri simüle etmek için kullanabileceğiniz birden fazla ekran yönü ve katlanabilir duruma sahiptir.

Ekran döndürmeye karşı test et

Cihaz ekranı döndüğünde uygulamanıza ne olduğunu nasıl test edeceğinize dair bir örneği aşağıda bulabilirsiniz:

  1. Öncelikle, tutarlı bir başlangıç durumu için cihazı dikey moda ayarlayın:

      import androidx.test.espresso.device.action.ScreenOrientation
  import androidx.test.espresso.device.rules.ScreenOrientationRule
  ...
  @get:Rule
  val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

  2. Test yürütülürken cihazı yatay yöne ayarlayan bir test oluşturun:

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    ...
  }

  3. Ekran döndükten sonra, kullanıcı arayüzünün beklendiği gibi yeni düzene uyum sağladığından emin olun.

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
  }
Ekran açılmaya karşı test et

Uygulamanız katlanabilir bir cihazdaysa ve ekranı açılıp açılmamışsa ne olduğunu nasıl test edeceğinize dair bir örneği aşağıda bulabilirsiniz:

  1. Öncelikle onDevice().setClosedMode() çağırarak cihazı katlanmış durumdayken test edin. Uygulama düzeninizin kompakt ekran genişliğine uyum sağladığından emin olun.

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
    composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
    ...
  }

  2. Tamamen katlanmamış bir duruma geçmek için onDevice().setFlatMode() numaralı telefonu arayın. Uygulama düzeninin, genişletilmiş boyut sınıfına uyum sağladığından emin olun.

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    ...
    onDevice().setFlatMode()
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
  }

Testlerinizin hangi cihazlara ihtiyacı olduğunu belirtin

Katlanabilir olmayan bir cihazda katlama işlemleri gerçekleştiren bir test çalıştırıyorsanız test büyük olasılıkla başarısız olur. Yalnızca çalışan cihazla ilgili testleri yürütmek için @RequiresDeviceMode ek açıklamasını kullanın. Test çalıştırıcı, test edilen yapılandırmayı desteklemeyen cihazlarda çalıştırılan testleri otomatik olarak atlar. Cihaz gereksinimi kuralını her teste veya bir test sınıfının tamamına ekleyebilirsiniz.

Örneğin, bir testin yalnızca düz yapılandırmaya genişletmeyi destekleyen cihazlarda çalıştırılması gerektiğini belirtmek için testinize aşağıdaki @RequiresDeviceMode kodunu ekleyin:

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}

Temel Profiller modülü sihirbazı

Android Studio Iguana'dan başlayarak, yeni modül sihirbazındaki (Dosya > Yeni > Yeni Modül) Temel Profil Oluşturma Aracı şablonunu kullanarak uygulamanız için Temel Profiller oluşturabilirsiniz.

Bu şablon projenizi Temel Profilleri destekleyecek şekilde ayarlar. Projenizi gerekli şekilde oluşturma sürecini tek bir Gradle göreviyle otomatikleştiren yeni Baseline Profiles Gradle eklentisini kullanır.

Şablon, Çalıştır/Hata Ayıklama Yapılandırması Seç açılır listesinden tek tıklamayla Temel Profil oluşturmanıza olanak tanıyan bir çalıştırma yapılandırması da oluşturur.