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 drobna 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 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 w statystykach 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 powiązań 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 wypadek.

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

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 produkcyjnych (niedebuggowanych) ta 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 statystykach jakości aplikacji

Aby łatwiej analizować główne przyczyny awarii, możesz teraz korzystać ze statystyk dotyczących jakości aplikacji, aby wyświetlać zdarzenia według wariantów problemu lub grup zdarzeń o podobnych zrzutach 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 linowania wizualnego i integracji z kontrolą ułatwień dostępu w widokach danych. Gdy włączysz tryb sprawdzania interfejsu tworzenia wiadomości, Android Studio automatycznie sprawdzi interfejs tworzenia wiadomości i sprawdzi, czy nie występują problemy z adaptacją i ułatwieniami dostępu na ekranach o różnych rozmiarach, np. tekst rozciągnięty 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 użytkownika w oknie podglądu 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. Ciągle pracujemy nad zwiększeniem wydajności podglądów. Teraz celowo zmniejszamy jakość renderowania w przypadku każdego niewidocznego podglądu, aby oszczędzać pamięć.

Ta funkcja została opracowana w celu dalszego zwiększenia użyteczności funkcji Podgląd, ponieważ umożliwia obsługę większej liczby podglądów w tym samym 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 on 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

Użyj interfejsu Espresso Device API, aby przetestować aplikację, gdy na urządzeniu zmienią się typowe zmiany w konfiguracji, takie jak obrót lub rozłożenie 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 interfejsu w Espresso.

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

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

Konfigurowanie projektu pod kątem interfejsu Espresso Device API

Aby skonfigurować projekt do obsługi interfejsu 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

Espresso Device API ma orientację ekranu i różne stany złożone, dzięki czemu możesz symulować zmiany w 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. Aby uzyskać spójny stan początkowy, ustaw urządzenie w trybie pionowym:

      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 ustawi orientację poziomą na urządzeniu podczas jego wykonywania:

      @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()
  }

Przetestuj rozłożenie 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 złożone urządzenie, wywołując funkcję 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ądzeń możesz dodać do każdego testu lub całej klasy testowej.

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() {
  ...
}