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

Poniżej znajdziesz nowe funkcje w Android Studio Iguana.

Wersje poprawek

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

Android Studio iguana | Poprawki 2 i 8.3.2 z 2023 r. (kwiecień 2024 r.)

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

Android Studio iguana | Poprawki 1 i 8.3.1 z 2023 r. (marzec 2024 r.)

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

Integracja systemu kontroli wersji w statystykach jakości aplikacji

Statystyki jakości aplikacji umożliwiają teraz: przejdź ze zrzutu stosu Crashlytics do odpowiedniego kodu – w punkcie w momencie wystąpienia wypadku. AGP dołącza do awarii dane haszujące git zatwierdzenia które pomagają Android Studio przejść do kodu i pokazywać, w wersji, w której wystąpił problem. Gdy wyświetlisz raport o awariach w statystykami jakości aplikacji, możesz przejść do wiersza kodu w witrynie bieżący proces płatności git lub wyświetl różnice między bieżącym procesem płatności a wersją bazy kodu, która wygenerowała awarię.

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

Aby użyć integracji z kontrolą wersji dla kompilacji z możliwością debugowania, włącz funkcję vcsInfo w pliku kompilacji na poziomie modułu. Do wersji (bez możliwości debugowania) kompilacje, flaga jest domyślnie włączona.

Kotlin

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

Groovy

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

Teraz gdy tworzysz aplikację i publikujesz aplikację w Google Play, raporty o awariach zawierają dane niezbędne IDE do łączenia się z poprzednimi wersjami aplikacji z poziomu zrzut stosu.

Wyświetlanie wariantów awarii Crashlytics w statystykach 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 problemów lub grup zdarzeń, które mają podobne zrzuty stosu. Aby wyświetlić zdarzenia w poszczególnych wariantach raportu o awarii, wybierz wariant w menu. Aby zebrać 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 oraz integracje z testami ułatwień dostępu. . Gdy włączysz tryb sprawdzania w interfejsie tworzenia, Android Studio automatycznie sprawdza interfejs Compose oraz sprawdza, czy nie występują problemy z adaptacją i ułatwieniami dostępu o różnych rozmiarach ekranu, np. tekst rozciągnięty na dużych ekranach lub w niskiej kolorystyce; kontrast. 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 kontroli interfejsu w Podglądzie tworzenia wiadomości i wyślij opinię:

Kliknij przycisk Tryb sprawdzania w interfejsie tworzenia wiadomości, aby aktywować sprawdzanie.

Znane problemy w trybie kontroli interfejsu:

  • Wybrany problem w panelu problemów może przestać być zaznaczony
  • „Pomiń regułę” Nie działa
Tryb sprawdzania interfejsu aktywowany w komponowaniu z szczegółami w panelu problemów.

Renderowanie progresywne w podglądzie tworzenia wiadomości

Android Studio Iguana Canary 3 wprowadza renderowanie progresywne w narzędziu Compose Podgląd. 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 ma na celu dalsze zwiększenie użyteczności Podglądy dzięki możliwości jednoczesnej obsługi większej liczby podglądó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. it korzysta z nowej wtyczki Gradle profili Baseline, która automatyzuje proces skonfigurować projekt w wymagany sposób za pomocą jednego zadania Gradle.

Szablon tworzy również konfigurację uruchamiania, która pozwala wygenerować Profil podstawowy – jednym kliknięciem w sekcji Select Run/Debug Configuration (Wybierz konfigurację uruchamiania/debugowania). listę rozwijaną.

Testowanie zmian konfiguracji za pomocą interfejsu Espresso Device API

Za pomocą interfejsu API Espresso Device API możesz testować aplikację, gdy urządzenie przechodzi przez 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 tym, jak pisać Testy interfejsu 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 w wersji 33.1.10 lub nowszej
  • Urządzenie wirtualne z Androidem, na którym działa interfejs API na poziomie 24 lub wyższym

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ć działanie poleceń testowych na urządzeniu testowym, dodaj do Uprawnienia INTERNET i ACCESS_NETWORK_STATE do pliku manifestu w zbiorze źródłowym androidTest:

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

  2. Włącz flagę eksperymentu enableEmulatorControl w Plik gradle.properties:

      android.experimental.androidTest.enableEmulatorControl=true

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

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. Zaimportuj bibliotekę Espresso Device Policy w skrypcie kompilacji na poziomie modułu. do swojego projektu.

    Kotlin

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

    Odlotowe

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

Testowanie w przypadku typowych zmian konfiguracji

Espresso Device API może mieć wiele orientacji ekranu i możliwość złożenia co pozwala symulować zmiany w konfiguracji urządzenia.

Przeprowadź test względem obrotu ekranu

Oto przykład, jak sprawdzić, co dzieje się z aplikacją, gdy ekran urządzenia obraca się:

  1. Aby uzyskać spójny stan początkowy, ustaw urządzenie w orientacji pionowej tryb:

      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 testu ustawi na urządzeniu orientację poziomą wykonanie:

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

  3. Po obróceniu ekranu sprawdź, czy UI 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 otwierania ekranu

Oto przykład, jak sprawdzić, co dzieje się z aplikacją na urządzeniu składanym i wyświetla się ekran:

  1. Najpierw przetestuj urządzenie w stanie złożonym, dzwoniąc na numer onDevice().setClosedMode(). Dopilnuj, aby układ aplikacji dostosowuje się do szerokości niewielkiego 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 urządzenia, których potrzebują testy

Jeśli testujesz składanie elementów na urządzeniu, które nie jest składa się, test zwykle kończy się niepowodzeniem. Przeprowadzanie tylko istotnych testów do uruchomionego urządzenia, użyj adnotacji @RequiresDeviceMode. Zawodnik wykonujący test automatycznie pomija testy na urządzeniach, które nie obsługują testowanej konfiguracji. Do każdego testu możesz dodać regułę wymagań dotyczących urządzeń lub całej klasy testowej.

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

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