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

Oto nowe funkcje w Android Studio Iguana.

Wersje poprawek

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

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

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

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

Ta niewielka aktualizacja zawiera 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. Szczegółowe informacje o zmianach znajdziesz w informacjach o wersji IntelliJ IDEA 2023.2.

Integracja systemu kontroli wersji ze Statystykami jakości aplikacji

Raporty o jakości aplikacji umożliwiają teraz przechodzenie z wyświetlenia ścieżki wywołania w Crashlytics do odpowiedniego kodu w miejscu, w którym nastąpiła awaria. AGP dołącza do raportów o wstrzymaniu dane haszowania commitów git, co pomaga Android Studio przejść do kodu i pokazać, jak wyglądał w wersji, w której wystąpił problem. Podczas wyświetlania raportu o wypadkach w Raportach o jakości aplikacji możesz przejść do linii kodu w bieżącym repozytorium Git lub wyświetlić różnice między bieżącym repozytorium a wersją kodu, która spowodowała wystąpienie błędu.

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

Aby korzystać z integracji kontroli wersji w przypadku typu kompilacji umożliwiającej debugowanie, włącz flagę vcsInfo w pliku kompilacji na poziomie modułu. W przypadku wersji (niedebugowalnych) flaga jest domyślnie włączona.

Kotlin

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

Groovy

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

Gdy teraz kompilujesz aplikację i publikujesz ją w Google Play, raporty o awariach zawierają dane potrzebne IDE do połączenia z poprzednimi wersjami aplikacji na podstawie ścieżki stosu.

Wyświetlanie wariantów awarii Crashlytics w Raporcie o jakości aplikacji

Aby ułatwić analizowanie głównych przyczyn awarii, możesz teraz korzystać z Raportów o jakości aplikacji, aby wyświetlać zdarzenia według wariantów problemu lub grup zdarzeń, które mają podobne zrzuty stosu. Aby wyświetlić zdarzenia w poszczególnych wariantach raportu o wypadkach, wybierz wariant w menu. Aby zsumować informacje o wszystkich wariantach, wybierz Wszystkie.

Sprawdzanie interfejsu tworzenia

Aby pomóc deweloperom tworzyć w Jetpack Compose bardziej elastyczne i dostępne interfejsy użytkownika, w Android Studio Iguana Canary 5 wprowadziliśmy nowy tryb sprawdzania interfejsu w Compose Preview. Ta funkcja działa podobnie do wizualnego sprawdzania kodu i integracji z funkcją sprawdzania dostępności w przypadku widoków. Gdy aktywujesz tryb sprawdzania interfejsu Compose, Android Studio automatycznie zweryfikuje interfejs Compose i sprawdza problemy związane z adaptacją i ułatwieniami dostępu na różnych rozmiarach ekranu, takie jak rozciągnięty tekst na dużych ekranach czy niski kontrast kolorów. Tryb ten wyróżnia problemy znalezione w różnych konfiguracjach podglądu i wypisuje je w panelu problemów.

Wypróbuj tę funkcję już dziś, klikając przycisk sprawdzania interfejsu użytkownika w sekcji Podgląd kompozycji i prześlij opinię:

Aby aktywować sprawdzanie, kliknij przycisk Tryb sprawdzania w interfejsie tworzenia wiadomości.

Znane problemy w trybie sprawdzania interfejsu:

  • Wybrany problem w panelu problemów może stracić fokus
  • „Reguła pomijania” nie działa
Tryb sprawdzania interfejsu aktywowany w komponowaniu z szczegółami w panelu problemów.

Renderowanie progresywne w ramach podglądu w widoku tworzenia

Android Studio Iguana Canary 3 wprowadza progresywne renderowanie w Compose. W ramach ciągłych starań o zwiększenie wydajności podglądów obniżamy teraz celowo jakość renderowania w przypadku wszystkich podglądów, które nie są widoczne, aby zaoszczędzić pamięć.

Ta funkcja została opracowana w celu dalszego zwiększenia użyteczności funkcji Podgląd, umożliwiając jednoczesne wyświetlanie większej liczby podglądów w pliku. Wypróbuj je już dziś i prześlij opinię.

Kreator modułu Profil podstawowy

Począwszy od wersji Android Studio Iguana możesz generować profile referencyjne dla aplikacji za pomocą szablonu Generatora profili referencyjnych w nowym kreatorze modułów (Plik > Nowy > Nowy moduł).

Ten szablon konfiguruje projekt tak, aby obsługiwał profile podstawowe. Używa nowego wtyczka Gradle do profili referencyjnych, który automatyzuje proces konfigurowania projektu w wymagany sposób za pomocą jednego zadania Gradle.

Szablon tworzy też konfigurację wykonania, która umożliwia wygenerowanie profilu podstawowego jednym kliknięciem na liście Wybierz konfigurację wykonania lub debugowania.

Testowanie zmian konfiguracji za pomocą interfejsu Espresso Device API

Za pomocą interfejsu API Espresso Device API możesz testować aplikację, gdy urządzenie przechodzi typowe zmiany konfiguracji, takie jak obrót i rozkładanie ekranu. Interfejs Device API w usłudze Espresso umożliwia symulowanie tych zmian konfiguracji na urządzeniu wirtualnym i wykonywanie testów synchronicznie, dzięki czemu w danym momencie występuje tylko jedno działanie lub twierdzenie UI, a wyniki testów są bardziej wiarygodne. Dowiedz się więcej o pisaniu testów UI za pomocą Espresso.

Aby korzystać z interfejsu Espresso Device API, musisz mieć:

  • Android Studio Iguana lub nowszy
  • Wtyczka Androida do obsługi Gradle w wersji 8.3 lub nowszej
  • emulator Androida 33.1.10 lub nowszy.
  • wirtualne urządzenie z Androidem na poziomie interfejsu API 24 lub nowszym,

Konfigurowanie projektu pod kątem interfejsu Espresso Device API

Aby skonfigurować projekt tak, aby obsługiwał interfejs Espresso Device API, wykonaj te czynności:

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

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

  2. Włącz flagę eksperymentalną 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
    }
  }

    Groovy

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

    Groovy

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

Testowanie w przypadku typowych zmian konfiguracji

Interfejs Espresso Device API obsługuje różne orientacje ekranu i stany składania, które możesz wykorzystać do symulowania zmian konfiguracji urządzenia.

Testowanie na obrót ekranu

Oto przykład testowania tego, co dzieje się z aplikacją po obróbieniu ekranu urządzenia:

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

      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:

      @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 otwierania ekranu

Oto przykład testowania tego, co dzieje się z aplikacją, gdy jest ona na urządzeniu składanym i rozkłada się ekran:

  1. Najpierw przetestuj urządzenie w stanie złożonym, dzwoniąc na numer onDevice().setClosedMode(). Upewnij się, że układ aplikacji dostosowuje się do wąskiej szerokości ekranu:

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

  2. Aby przejść do stanu pełnego rozłożenia, wywołaj funkcję onDevice().setFlatMode(). Sprawdź, czy układ aplikacji dostosowuje się do rozszerzonej klasy rozmiarów:

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

Określ, jakie urządzenia są potrzebne do testów

Jeśli test wykonuje czynności składania na urządzeniu, które nie jest składane, test zwykle się nie powiedzie. Aby wykonać tylko testy, które są odpowiednie dla danego urządzenia, użyj adnotacji @RequiresDeviceMode. Narzędzie do uruchamiania testów automatycznie pomija testy na urządzeniach, które nie obsługują testowanej konfiguracji. Regułę wymagań dotyczących urządzenia możesz dodać do każdego testu lub całej klasy testów.

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

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