Android Studio iguana | 2.02.2023 r. (luty 2024 r.)

Oto nowe funkcje w Android Studio Iguana.

Wersje poprawek

Poniżej znajdziesz listę wersji poprawek w Android Studio Iguana i wtyczce Androida do obsługi Gradle 8.3.

Android Studio Iguana | 2023.2.1 Patch 2 i AGP 8.3.2 (kwiecień 2024 r.)

Ta niewielka aktualizacja zawiera te poprawki błędów.

Android Studio Iguana | 2023.2.1 Patch 1 i AGP 8.3.1 (marzec 2024 r.)

Ta niewielka aktualizacja zawiera te poprawki błędów.

Aktualizacja platformy IntelliJ IDEA 2023.2

Android Studio Iguana zawiera aktualizacje IntelliJ IDEA 2023.2, które poprawiają działanie środowiska IDE Studio. Szczegółowe informacje o zmianach znajdziesz w informacjach o wersji IntelliJ IDEA 2023.2.

Integracja systemu kontroli wersji w App Quality Insights

Statystyki jakości aplikacji umożliwiają teraz przechodzenie ze zrzutu stosu Crashlytics do odpowiedniego kodu w momencie wystąpienia awarii. AGP dołącza do raportów o awariach dane o hashu zatwierdzenia git, co pomaga Android Studio przejść do kodu i pokazać, jak wyglądał on w wersji, w której wystąpił problem. Gdy wyświetlasz raport o awariach w statystykach jakości aplikacji, możesz przejść do wiersza kodu w bieżącym wyewidencjonowaniu git lub wyświetlić różnice między bieżącym wyewidencjonowaniem a wersją bazy kodu, która spowodowała awarię.

Aby zintegrować system kontroli wersji z statystykami jakości aplikacji, musisz spełnić te minimalne wymagania:

Aby używać integracji kontroli wersji w przypadku rodzaju kompilacji z możliwością debugowania, włącz flagę vcsInfo w pliku kompilacji na poziomie modułu. W przypadku kompilacji wersji (bez możliwości debugowania) flaga jest domyślnie włączona.

Kotlin

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

Dynamiczny

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

Gdy teraz skompilujesz aplikację i opublikujesz ją w Google Play, raporty o awariach będą zawierać dane niezbędne do połączenia w środowisku IDE z poprzednimi wersjami aplikacji ze zrzutu stosu.

Wyświetlanie wariantów awarii Crashlytics w statystykach jakości aplikacji

Aby ułatwić analizowanie głównych przyczyn awarii, możesz teraz używać App Quality Insights do wyświetlania zdarzeń według wariantów problemu, czyli grup zdarzeń, które mają podobne ślady stosu. Aby wyświetlić zdarzenia w każdym wariancie raportu o awarii, wybierz wariant z menu. Aby zagregować informacje dotyczące wszystkich wariantów, wybierz Wszystkie.

Sprawdzanie interfejsu Compose

Aby pomóc programistom w tworzeniu bardziej adaptacyjnych i dostępnych interfejsów w Jetpack Compose, w Android Studio Iguana Canary 5 wprowadziliśmy nowy tryb sprawdzania interfejsu w podglądzie Compose. Ta funkcja działa podobnie jak integracja sprawdzania wizualnego i sprawdzania dostępności w przypadku widoków. Gdy aktywujesz tryb sprawdzania interfejsu Compose, Android Studio automatycznie sprawdza interfejs Compose i szuka problemów z dostosowaniem i ułatwieniami dostępu na różnych rozmiarach ekranu, takich jak rozciągnięty tekst na dużych ekranach lub niski kontrast kolorów. Tryb ten wyróżnia problemy znalezione w różnych konfiguracjach podglądu i wyświetla je w panelu problemów.

Wypróbuj tę funkcję już dziś, klikając przycisk sprawdzania interfejsu w podglądzie Compose, i prześlij opinię:

Aby aktywować sprawdzanie, kliknij przycisk trybu sprawdzania interfejsu Compose.

Znane problemy z trybem sprawdzania interfejsu:

  • Wybrany problem w panelu problemów może stracić fokus.
  • „Pomiń regułę” nie działa.
Tryb sprawdzania interfejsu Compose aktywowany ze szczegółami w panelu problemów.

Progresywne renderowanie w podglądzie Compose

Android Studio Iguana Canary 3 wprowadza progresywne renderowanie w podglądzie Compose. W ramach ciągłych prac nad zwiększeniem wydajności podglądów celowo zmniejszamy jakość renderowania podglądów, które są poza widokiem, aby oszczędzać pamięć.

Ta funkcja została opracowana z myślą o dalszym zwiększeniu użyteczności podglądów dzięki możliwości obsługi większej liczby podglądów w tym samym czasie w pliku. Wypróbuj ją już dziś i prześlij opinię.

Kreator modułu profili podstawowych

Od Android Studio Iguana możesz generować profile podstawowe dla swojej aplikacji za pomocą szablonu Generator profili podstawowych w kreatorze nowego modułu (Plik > Nowy > Nowy moduł).

Ten szablon konfiguruje projekt tak, aby obsługiwał profile podstawowe. Używa nowej wtyczki Gradle profili podstawowych, która automatyzuje proces konfigurowania projektu w wymagany sposób za pomocą jednego zadania Gradle.

Szablon tworzy też konfigurację uruchamiania i debugowania, która umożliwia wygenerowanie profilu podstawowego jednym kliknięciem z listy Wybierz konfigurację uruchamiania i debugowania.

Testowanie pod kątem zmian konfiguracji za pomocą interfejsu Espresso Device API

Użyj interfejsu Espresso Device API, aby testować aplikację, gdy urządzenie przechodzi typowe zmiany konfiguracji, takie jak obrót i rozłożenie ekranu. Interfejs Espresso Device API umożliwia symulowanie tych zmian konfiguracji na urządzeniu wirtualnym i synchroniczne wykonywanie testów, dzięki czemu w danym momencie wykonywane jest tylko jedno działanie lub jedno sprawdzenie interfejsu, a wyniki testów są bardziej wiarygodne. Dowiedz się więcej o pisaniu testów interfejsu za pomocą Espresso.

Aby używać interfejsu Espresso Device API, potrzebujesz:

  • Android Studio Iguana lub nowszej wersji
  • wtyczki Androida do obsługi Gradle w wersji 8.3 lub nowszej
  • emulatora Androida w wersji 33.1.10 lub nowszej
  • wirtualnego urządzenia z Androidem, na którym działa poziom interfejsu API 24 lub nowszy

Konfigurowanie projektu pod kątem interfejsu Espresso Device API

Aby skonfigurować projekt tak, aby obsługiwał interfejs Espresso Device API:

  1. Aby umożliwić testowi przekazywanie poleceń do urządzenia testowego, dodaj uprawnienia INTERNET i ACCESS_NETWORK_STATE do pliku manifestu w zestawie źródeł androidTest:

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

  2. Włącz eksperymentalną flagę enableEmulatorControl w pliku gradle.properties:

      android.experimental.androidTest.enableEmulatorControl=true

  3. Włącz opcję emulatorControl w skrypcie kompilacji na poziomie modułu:

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Dynamiczny

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. W skrypcie kompilacji na poziomie modułu zaimportuj do projektu bibliotekę Espresso Device:

    Kotlin

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

    Dynamiczny

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

Testowanie pod kątem typowych zmian konfiguracji

Interfejs Espresso Device API ma wiele stanów orientacji ekranu i składania, których możesz użyć do symulowania zmian konfiguracji urządzenia.

Testowanie pod kątem obrotu ekranu

Oto przykład testowania, co się stanie z aplikacją, gdy ekran urządzenia się obróci:

  1. Najpierw ustaw urządzenie w trybie pionowym, aby uzyskać spójny stan początkowy:

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

  2. Utwórz test, który podczas wykonywania testu ustawia urządzenie w orientacji poziomej:

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

  3. Po obróceniu ekranu sprawdź, czy interfejs dostosowuje się do nowego układu zgodnie z oczekiwaniami:

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

Testowanie pod kątem rozłożenia ekranu

Oto przykład testowania, co się stanie z aplikacją, jeśli jest ona na urządzeniu składanym, a ekran się rozłoży:

  1. Najpierw przetestuj urządzenie w stanie złożonym, wywołując onDevice().setClosedMode(). Sprawdź, czy układ aplikacji dostosowuje się do kompaktowej szerokości ekranu:

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

  2. Aby przejść do stanu całkowicie rozłożonego, wywołaj onDevice().setFlatMode(). Sprawdź, czy układ aplikacji dostosowuje się do rozszerzonej klasy rozmiaru:

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

Określanie, jakich urządzeń potrzebują testy

Jeśli uruchamiasz test, który wykonuje działania składania na urządzeniu, które nie jest składane, test zwykle kończy się niepowodzeniem. Aby wykonywać tylko testy, które są istotne dla uruchomionego urządzenia, użyj adnotacji @RequiresDeviceMode. Program do uruchamiania testów automatycznie pomija uruchamianie testów na urządzeniach, które nie obsługują testowanej konfiguracji. Regułę wymagania dotyczącego urządzenia możesz dodać do każdego testu lub do całej klasy testowej.

Aby na przykład określić, że test ma być uruchamiany tylko na urządzeniach, które obsługują rozkładanie do konfiguracji płaskiej, dodaj do testu ten kod @RequiresDeviceMode:

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