Android Studio iguana | 1.2023.2023

Android Studio to oficjalne środowisko IDE do programowania na Androida. Zawiera wszystko, czego potrzebujesz do tworzenia aplikacji na Androida.

Ta strona zawiera listę nowych funkcji i udoskonaleń w najnowszej wersji stabilnej wersji Android Studio Iguana. Możesz ją pobrać tutaj lub zaktualizować w Android Studio, klikając Pomoc > Sprawdź dostępność aktualizacji (Android Studio > Sprawdź dostępność aktualizacji w systemie macOS)

Aby zobaczyć, jakie poprawki zostały naprawione w tej wersji Android Studio, zajrzyj do sekcji Zamknięte problemy.

Informacje o starszych wersjach Android Studio znajdziesz w sekcji Wcześniejsze wersje.

Aby uzyskać wcześniejszy dostęp do nadchodzących funkcji i ulepszeń, przeczytaj artykuł Wersje przedpremierowe Android Studio.

Jeśli napotkasz problemy w Android Studio, zajrzyj na stronę Znane problemy lub Rozwiązywanie problemów.

Wtyczka Android do obsługi Gradle i zgodność ze Android Studio

System kompilacji Android Studio jest oparty na Gradle, a wtyczka Android do obsługi Gradle (AGP) dodaje kilka funkcji charakterystycznych dla tworzenia aplikacji na Androida. W tabeli poniżej znajdziesz listę wersji AGP, która jest wymagana w przypadku każdej wersji Androida Studio.

Nowości we wtyczce Androida do obsługi Gradle znajdziesz w informacjach o wersji wtyczki Androida do obsługi Gradle.

Minimalne wersje narzędzi na poziomie interfejsu Android API

Istnieją minimalne wersje Android Studio i AGP, które obsługują określony poziom interfejsu API. Używanie starszych wersji Androida Studio lub AGP niż te wymagane przez targetSdk lub compileSdk projektu może spowodować nieoczekiwane problemy. Zalecamy korzystanie z najnowszej wersji testowej Android Studio i AGP przy projektach kierowanych na wersje przedpremierowe systemu operacyjnego Android. Możesz zainstalować podglądy Androida Studio obok wersji stabilnej.

Minimalne wersje Android Studio i AGP to:

Oto nowe funkcje w Android Studio Iguana.

Wersje poprawek

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

Android Studio Iguana | Poprawka 2 i 3.02.2023.2.1 (kwiecień 2024 r.)

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

Android Studio Iguana | Poprawka 1 w wersji 1 i 8.3.1 w wersji 2023.2.1 (marzec 2024 r.)

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

Integracja systemu kontroli wersji w statystykach jakości aplikacji

Statystyki jakości aplikacji umożliwiają teraz przechodzenie ze zrzutu stosu Crashlytics do odpowiedniego kodu w momencie wystąpienia awarii. Do raportów o awariach AGP dołącza dane skrótu git Commit. To pomaga Android Studio przejść do kodu i pokazać, jak był w wersji, w której wystąpił problem. Po wyświetleniu raportu o awariach w statystykach jakości aplikacji możesz przejść do wiersza kodu w bieżącej płatności Git lub wyświetlić różnicę między bieżącą płatnością a wersją bazy kodu, która wygenerowała awarię.

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

• Najnowsza wersja Android Studio Iguana w wersji Canary
• Najnowsza wersja alfa wtyczki Androida do obsługi Gradle 8.3
• Pakiet SDK Crashlytics w wersji 18.3.7 (lub zestawienie materiałów Firebase na Androida w wersji 32.0.0)

Aby użyć integracji kontroli wersji w przypadku typu kompilacji z możliwością debugowania, włącz flagę vcsInfo w pliku kompilacji na poziomie modułu. W przypadku kompilacji (które nie są możliwe do debugowania) flaga jest domyślnie włączona.

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

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

Teraz, gdy utworzysz aplikację i opublikujesz ją w Google Play, raporty o awariach będą zawierać dane niezbędne IDE do połączenia się z poprzednimi wersjami aplikacji ze zrzutu stosu.

Wyświetlaj warianty awarii Crashlytics w statystykach dotyczących jakości aplikacji

Aby łatwiej przeanalizować główne przyczyny awarii, możesz teraz korzystać ze Statystyk jakości aplikacji, które pozwalają 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 awariach, wybierz z menu wariant. Aby zebrać informacje o wszystkich wariantach, wybierz Wszystkie.

Test interfejsu tworzenia wiadomości

Aby pomóc deweloperom tworzyć bardziej elastyczne i łatwo dostępne interfejsy użytkownika w Jetpack Compose, w Android Studio Iguana Canary 5 wprowadzono nowy tryb sprawdzania interfejsu w podglądzie tworzenia wiadomości. Ta funkcja działa podobnie do lintowania wizualnego i integracji ułatwień dostępu pod kątem widoków danych. Gdy włączysz tryb sprawdzania interfejsu tworzenia, Android Studio automatycznie sprawdzi interfejs i poszuka problemów z adaptacją i ułatwieniami dostępu na ekranach o różnych rozmiarach, np. rozciągniętym tekstem na dużych ekranach lub niskim kontrastem. Tryb ten wyróżnia problemy znalezione w różnych konfiguracjach podglądu i wyświetla je w panelu problemów.

Już dziś wypróbuj tę funkcję, klikając przycisk Sprawdzanie interfejsu w podglądzie tworzenia wiadomości, a następnie prześlij swoją opinię:

Znane problemy z trybem sprawdzania interfejsu:

• Wybrany problem w panelu problemu może przestać być aktywny
• „Pomiń regułę” nie działa

Renderowanie progresywne na potrzeby podglądu tworzenia wiadomości

Android Studio Iguana Canary 3 wprowadza renderowanie progresywne w podglądzie tworzenia wiadomości. Nieustannie pracujemy nad zwiększaniem wydajności podglądów, dlatego teraz w przypadku niewidocznych podglądów celowo obniżamy jakość ich renderowania, aby oszczędzać pamięć używaną.

Opracowaliśmy tę funkcję, aby jeszcze bardziej ułatwić korzystanie z podglądów przez umożliwienie obsługi większej liczby podglądów w tym samym czasie. Wypróbuj go już dziś i prześlij opinię.

Aktualizacja platformy IntelliJ IDEA 2023.2

Android Studio Iguana zawiera aktualizacje IntelliJ IDEA 2023.2, które poprawiają działanie IDE Studio. Szczegóły zmian znajdziesz w informacjach o wersji IntelliJ IDEA 2023.2.

Kreator modułu profili bazowych

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

Ten szablon konfiguruje projekt tak, aby mógł obsługiwać profile podstawowe. Wykorzystuje nową wtyczkę Gradle profili bazowych, która automatyzuje proces konfigurowania projektu w wymagany sposób za pomocą jednego zadania Gradle.

Szablon tworzy też konfigurację uruchomienia, która pozwala wygenerować profil podstawowy jednym kliknięciem na liście Wybierz konfigurację uruchamiania/debugowania.

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

Przetestuj swoją aplikację za pomocą interfejsu Espresso Device API, jeśli w urządzeniu występują typowe zmiany konfiguracji, takie jak obrót ekranu czy rozwijanie ekranu. Interfejs Espresso Device API pozwala symulować te zmiany konfiguracji na urządzeniu wirtualnym i synchronicznie wykonywać testy. Dzięki temu w danym momencie wykonywane jest tylko jedno działanie interfejsu lub jedno asercja, a wyniki testu są bardziej wiarygodne. Dowiedz się więcej o tym, jak pisać testy interfejsu użytkownika w Espresso.

Aby korzystać z interfejsu Espresso Device API, potrzebujesz:

• Android Studio Iguana lub nowsza
• Wtyczka Androida do obsługi Gradle w wersji 8.3 lub nowszej
• Emulator Androida w wersji 33.1.10 lub nowszej
• Wirtualne urządzenie z Androidem z interfejsem API na poziomie 24 lub wyższym

Konfigurowanie projektu do obsługi interfejsu Espresso Device API

Aby skonfigurować projekt pod kątem obsługi interfejsu Espresso Device API, wykonaj te czynności:

1. Aby zezwolić na używanie poleceń testowych na urządzeniu testowym, dodaj 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 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
       }
     }

   Odlotowy

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. W skrypcie kompilacji na poziomie modułu zaimportuj bibliotekę urządzenia do espresso do swojego projektu:

   Kotlin

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

   Odlotowy

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

Testowanie pod kątem typowych zmian konfiguracji

Espresso Device API ma wiele orientacji ekranu i umożliwia składanie, co pozwala symulować zmiany w konfiguracji urządzenia.

Przetestuj na podstawie obrót ekranu

Ten przykład pokazuje, jak sprawdzić, co dzieje się z aplikacją po obróceniu ekranu urządzenia:

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

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

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

3. Po obróceniu ekranu sprawdź, czy interfejs zgodnie z oczekiwaniami 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()
     }

Przeprowadź testy względem rozwijania ekranu

Oto przykład, jak sprawdzić, co dzieje się z aplikacją, która zostanie umieszczona na urządzeniu składanym i po otwarciu ekranu:

1. Najpierw przetestuj złożone urządzenie, 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 pełnego rozłożenia, wywołaj onDevice().setFlatMode(). Sprawdź, czy układ aplikacji dostosowuje się do klasy rozwiniętego rozmiaru:

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

Określ, jakich urządzeń potrzebują Twoje testy

Jeśli przeprowadzasz test, który wykonuje działania zwijania na urządzeniu, które nie jest składane, test zwykle kończy się niepowodzeniem. Aby wykonać tylko te testy, które dotyczą działającego urządzenia, użyj adnotacji @RequiresDeviceMode. Uruchamiający testy 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 do całej klasy testowej;

Aby np. wskazać, że test powinien być przeprowadzany tylko na urządzeniach, które obsługują rozwijanie do płaskiej konfiguracji, dodaj do testu ten kod @RequiresDeviceMode:

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