Halaman ini diterjemahkan oleh Cloud Translation API.

Android Studio Iguana | 2023.2.1 (Feb 2024)

Berikut adalah fitur baru di Android Studio Iguana.

Rilis patch

Berikut adalah daftar rilis patch di Android Studio Iguana dan plugin Android Gradle 8.3.

Android Studio Iguana | 2023.2.1 Patch 2 dan AGP 8.3.2 (April 2024)

Update minor ini mencakup perbaikan bug ini.

Android Studio Iguana | 2023.2.1 Patch 1 dan AGP 8.3.1 (Maret 2024)

Update minor ini mencakup perbaikan bug ini.

Update platform IntelliJ IDEA 2023.2

Android Studio Iguana menyertakan update IntelliJ IDEA 2023.2, yang meningkatkan pengalaman IDE Studio. Untuk detail tentang perubahan ini, lihat catatan rilis IntelliJ IDEA 2023.2.

Integrasi sistem kontrol versi di App Quality Insights

App Quality Insights kini memungkinkan Anda membuka stack trace Crashlytics ke kode yang relevan—pada saat error terjadi. AGP melampirkan data hash commit git ke laporan error, yang membantu Android Studio membuka kode Anda dan menampilkannya dalam versi tempat masalah terjadi. Saat melihat laporan error di App Quality Insights, Anda dapat memilih untuk membuka baris kode di checkout git saat ini atau melihat perbedaan antara checkout saat ini dan versi codebase yang menghasilkan error.

Untuk mengintegrasikan sistem kontrol versi dengan App Quality Insights, Anda memerlukan persyaratan minimum berikut:

Android Studio Iguana versi Canary terbaru
Versi Alpha terbaru Plugin Android Gradle 8.3
Crashlytics SDK v18.3.7 (atau Firebase Android Bill of Materials v32.0.0)

Agar dapat menggunakan integrasi kontrol versi untuk jenis build yang dapat di-debug, aktifkan flag vcsInfo dalam file build level modul. Untuk build rilis (tidak dapat di-debug), flag diaktifkan secara default.

Kotlin

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

Groovy

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

Sekarang, saat Anda mem-build aplikasi dan memublikasikannya ke Google Play, laporan error akan menyertakan data yang diperlukan IDE untuk menautkan ke versi aplikasi sebelumnya dari stack trace.

Melihat varian error Crashlytics di App Quality Insights

Untuk membantu Anda menganalisis akar masalah error, kini Anda dapat menggunakan App Quality Insight untuk melihat peristiwa berdasarkan varian masalah, atau grup peristiwa yang memiliki stack trace serupa. Untuk melihat peristiwa di setiap varian laporan error, pilih varian dari menu drop-down. Untuk mengumpulkan informasi semua varian, pilih Semua.

Compose UI Check

Untuk membantu developer mem-build UI yang lebih adaptif dan mudah diakses di Jetpack Compose, Android Studio Iguana Canary 5 memperkenalkan mode Pemeriksaan UI baru di Pratinjau Compose. Fitur ini berfungsi mirip dengan Lint visual dan Integrasi pemeriksaan aksesibilitas untuk tampilan. Saat Anda mengaktifkan mode Pemeriksaan UI Compose, Android Studio akan otomatis mengaudit UI Compose Anda dan memeriksa masalah adaptif dan aksesibilitas di berbagai ukuran layar, seperti teks yang direntangkan di perangkat layar besar atau kontras warna rendah. Mode ini menyoroti masalah yang ditemukan di berbagai konfigurasi pratinjau dan mencantumkannya di panel masalah.

Coba fitur ini sekarang dengan mengklik tombol Pemeriksaan UI di Pratinjau Compose dan kirim masukan Anda:

Klik tombol Mode pemeriksaan UI Compose untuk mengaktifkan pemeriksaan.

Masalah umum Mode Pemeriksaan UI:

Masalah yang dipilih di panel masalah mungkin kehilangan fokus
"Sembunyikan aturan" tidak berfungsi

Mode Pemeriksaan UI Compose diaktifkan dengan detail di panel masalah.

Rendering Progresif untuk Pratinjau Compose

Android Studio Iguana Canary 3 memperkenalkan Progressive Rendering di Pratinjau Compose. Sebagai bagian dari upaya berkelanjutan untuk membuat pratinjau berperforma lebih baik, sekarang untuk pratinjau yang tidak terlihat, kami sengaja menurunkan kualitas rendernya untuk menghemat memori yang digunakan.

Fitur ini dikembangkan dengan tujuan untuk semakin meningkatkan kegunaan Pratinjau dengan mampu menangani lebih banyak pratinjau secara bersamaan dalam sebuah file. Coba sekarang dan kirim masukan Anda.

Wizard modul Profil Dasar Pengukuran

Mulai Android Studio Iguana, Anda dapat membuat Profil Dasar Pengukuran untuk aplikasi menggunakan template Generator Profil Dasar Pengukuran di wizard modul baru (File > New > New Module).

Template ini menyiapkan project Anda agar dapat mendukung Profil Dasar Pengukuran. Plugin ini menggunakan plugin Gradle Profil Dasar Pengukuran baru, yang mengotomatiskan proses menyiapkan project Anda dengan cara yang diperlukan dengan satu tugas Gradle.

Template ini juga membuat konfigurasi run yang memungkinkan Anda membuat Profil Dasar Pengukuran dengan sekali klik dari menu drop-down Select Run/Debug Configuration.

Menguji perubahan konfigurasi dengan Espresso Device API

Gunakan Espresso Device API untuk menguji aplikasi Anda saat perangkat mengalami perubahan konfigurasi umum, seperti rotasi dan pembukaan layar. Espresso Device API memungkinkan Anda menyimulasikan perubahan konfigurasi ini di perangkat virtual dan menjalankan pengujian secara sinkron, sehingga hanya satu tindakan atau pernyataan UI yang terjadi sekaligus dan hasil pengujian Anda lebih andal. Pelajari lebih lanjut cara menulis pengujian UI dengan Espresso.

Untuk menggunakan Espresso Device API, Anda memerlukan hal berikut:

Android Studio Iguana atau yang lebih baru
Plugin Android Gradle 8.3 atau yang lebih tinggi
Android Emulator 33.1.10 atau yang lebih tinggi
Perangkat virtual Android yang menjalankan API level 24 atau yang lebih tinggi

Menyiapkan project untuk Espresso Device API

Untuk menyiapkan project Anda agar mendukung Espresso Device API, lakukan hal berikut:

Agar pengujian dapat meneruskan perintah ke perangkat pengujian, tambahkan izin INTERNET dan ACCESS_NETWORK_STATE ke file manifes di set sumber androidTest:
```
  <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />
```
Aktifkan tanda eksperimental enableEmulatorControl dalam file gradle.properties:
```
  android.experimental.androidTest.enableEmulatorControl=true
```

Aktifkan opsi emulatorControl dalam skrip build level modul:

Kotlin

  testOptions {
    emulatorControl {
      enable = true
    }
  }

Groovy

  testOptions {
    emulatorControl {
      enable = true
    }
  }

Dalam skrip build level modul, impor library Perangkat Espresso ke project Anda:

Kotlin

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

Groovy

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

Menguji terhadap perubahan konfigurasi umum

Espresso Device API memiliki beberapa orientasi layar dan status perangkat foldable yang dapat Anda gunakan untuk menyimulasikan perubahan konfigurasi perangkat.

Menguji rotasi layar

Berikut ini contoh cara menguji apa yang terjadi pada aplikasi Anda saat layar perangkat diputar:

Pertama, untuk status awal yang konsisten, tetapkan perangkat ke mode potret:

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

Buat pengujian yang menetapkan perangkat ke orientasi lanskap selama eksekusi pengujian:

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

Setelah layar diputar, periksa apakah UI menyesuaikan dengan tata letak baru seperti yang diharapkan:

  @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
  }

Lakukan pengujian terhadap pembukaan layar

Berikut adalah contoh cara menguji apa yang terjadi pada aplikasi Anda jika berada di perangkat foldable dan layar dibentangkan:

Pertama, uji dengan perangkat dalam status terlipat dengan memanggil onDevice().setClosedMode(). Pastikan tata letak aplikasi Anda sesuai dengan lebar layar yang ringkas:

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

Untuk bertransisi ke status yang sepenuhnya dibentangkan, panggil onDevice().setFlatMode(). Pastikan tata letak aplikasi beradaptasi dengan class ukuran yang diperluas:

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

Menentukan perangkat yang diperlukan pengujian Anda

Jika Anda menjalankan pengujian yang melakukan tindakan lipat pada perangkat yang tidak dapat dilipat, pengujian biasanya akan gagal. Untuk hanya menjalankan pengujian yang relevan dengan perangkat yang sedang berjalan, gunakan anotasi @RequiresDeviceMode. Runner pengujian otomatis melewati pengujian yang berjalan di perangkat yang tidak mendukung konfigurasi yang sedang diuji. Anda dapat menambahkan aturan persyaratan perangkat ke setiap pengujian atau seluruh class pengujian.

Misalnya, untuk menentukan bahwa pengujian hanya boleh dijalankan di perangkat yang mendukung bentangan ke konfigurasi datar, tambahkan kode @RequiresDeviceMode berikut ke pengujian Anda:

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