Android Studio Iguana | 1.2.2023 (febbraio 2024)

Di seguito sono riportate le nuove funzionalità di Android Studio Iguana.

Release delle patch

Di seguito è riportato un elenco delle release delle patch in Android Studio Iguana e nel plug-in Android Gradle 8.3.

Android Studio Iguana | Patch 2 di 2023.2.1 e AGP 8.3.2 (aprile 2024)

Questo aggiornamento minore include queste correzioni di bug.

Android Studio Iguana | Patch 1 di 2023.2.1 e AGP 8.3.1 (marzo 2024)

Questo aggiornamento minore include queste correzioni di bug.

Aggiornamento della piattaforma IntelliJ IDEA 2023.2

Android Studio Iguana include gli aggiornamenti di IntelliJ IDEA 2023.2, che migliorano l'esperienza IDE di Studio. Per informazioni dettagliate sulle modifiche, consulta le note di rilascio di IntelliJ IDEA 2023.2.

Integrazione del sistema di controllo della versione in App Quality Insights

App Quality Insights ora ti consente di passare da una traccia dello stack di Crashlytics al codice pertinente nel momento in cui si è verificato l'arresto anomalo. AGP allega i dati dell'hash del commit di Git ai report sugli arresti anomali, il che aiuta Android Studio a passare al codice e a mostrare come era nella versione in cui si è verificato il problema. Quando visualizzi un report sugli arresti anomali in App Quality Insights, puoi scegliere di passare alla riga di codice nel check-out git corrente o visualizzare una differenza tra il check-out corrente e la versione del codice base che ha generato l'arresto anomalo.

Per integrare il sistema di controllo della versione con App Quality Insights, devi soddisfare i seguenti requisiti minimi:

Per utilizzare l'integrazione del controllo delle versioni per un tipo di build di debug, attiva il flag vcsInfo nel file di build a livello di modulo. Per le build di release (non debbugabili), il flag è abilitato per impostazione predefinita.

Kotlin

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

Groovy

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

Ora, quando crei l'app e la pubblichi su Google Play, i report sugli arresti anomali includono i dati necessari per consentire all'IDE di collegarsi alle versioni precedenti dell'app dalla tracce di stack.

Visualizzare le varianti di arresto anomalo di Crashlytics in App Quality Insights

Per aiutarti ad analizzare le cause principali di un arresto anomalo, ora puoi utilizzare App Quality Insights per visualizzare gli eventi in base alle varianti dei problemi o ai gruppi di eventi che condividono analisi dello stack simili. Per visualizzare gli eventi in ogni variante di un report sugli arresti anomali, seleziona una variante dal menu a discesa. Per aggregare le informazioni per tutte le varianti, seleziona Tutte.

Controllo dell'interfaccia utente di Componi

Per aiutare gli sviluppatori a creare UI più adattive e accessibili in Jetpack Compose, Android Studio Iguana Canary 5 ha introdotto una nuova modalità di controllo dell'interfaccia utente in Compose Preview. Questa funzionalità funziona in modo simile al linting visivo e alle integrazioni dei controlli di accessibilità per le visualizzazioni. Quando attivi la modalità di controllo dell'interfaccia utente di Compose, Android Studio esamina automaticamente l'interfaccia utente di Compose e controlla la presenza di problemi di adattabilità e accessibilità su diversi dimensioni dello schermo, ad esempio testo allungato su schermi di grandi dimensioni o basso colore contrasto. La modalità mette in evidenza i problemi rilevati in diverse configurazioni di anteprima e li elenca nel riquadro dei problemi.

Prova questa funzionalità oggi stesso facendo clic sul pulsante di controllo dell'interfaccia utente in Anteprima di composizione e invia il tuo feedback:

Fai clic sul pulsante Modalità di controllo dell'interfaccia utente di Componi per attivare il controllo.

Problemi noti della modalità di controllo dell'interfaccia utente:

  • Il problema selezionato nel riquadro dei problemi potrebbe perdere lo stato attivo
  • La "Regola di soppressione" non funziona
Modalità di controllo dell'interfaccia utente di composizione attivata con i dettagli nel riquadro dei problemi.

Rendering progressivo per l'anteprima di Compose

Android Studio Iguana Canary 3 introduce il rendering progressivo nell'anteprima di Compose. Nell'ambito del nostro impegno continuo per migliorare le prestazioni delle anteprime, ora per qualsiasi anteprima non visibile riduciamo intenzionalmente la qualità del rendering per risparmiare memoria.

Questa funzionalità è stata sviluppata con l'obiettivo di migliorare ulteriormente l'usabilità delle anteprime, consentendo di gestire più anteprime contemporaneamente in un file. Provalo oggi stesso e inviaci il tuo feedback.

Assistente del modulo Profili di riferimento

A partire da Android Studio Iguana, puoi generare profili di riferimento per la tua app utilizzando il modello Generatore di profili di riferimento nella procedura guidata per la creazione di nuovi moduli (File > Nuovo > Nuovo modulo).

Questo modello configura il progetto in modo che possa supportare i profili di riferimento. Utilizza il nuovo plug-in Gradle Baseline Profiles, che automatizza il processo di configurazione del progetto nel modo richiesto con un'attività Gradle.

Il modello crea anche una configurazione di esecuzione che ti consente di generare un profilo di riferimento con un solo clic dall'elenco a discesa Seleziona configurazione di esecuzione/debug.

Eseguire test in base alle modifiche alla configurazione con l'API Espresso Device

Utilizza l'API Espresso Device per testare la tua app quando il dispositivo subisce modifiche di configurazione comuni, come la rotazione e l'apertura dello schermo. L'API EspressoDevice consente di simulare queste modifiche di configurazione su un dispositivo virtuale ed esegue i test in modo sincrono, quindi viene eseguita una sola azione o asserzione dell'interfaccia utente alla volta e i risultati dei test sono più affidabili. Scopri di più su come scrivere test UI con Espresso.

Per utilizzare l'API Espresso Device, devi disporre di quanto segue:

  • Android Studio Iguana o versioni successive
  • Plug-in Android per Gradle 8.3 o versioni successive
  • Android Emulator 33.1.10 o versioni successive
  • Dispositivo virtuale Android con livello API 24 o versioni successive

Configurare il progetto per l'API Espresso Device

Per configurare il progetto in modo che supporti l'API Espresso Device, svolgi i seguenti passaggi:

  1. Per consentire al test di trasmettere comandi al dispositivo di test, aggiungi le autorizzazioni INTERNET e ACCESS_NETWORK_STATE al file manifest nell'insieme di origini androidTest:

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

  2. Attiva il flag sperimentale enableEmulatorControl nel gradle.properties file:

      android.experimental.androidTest.enableEmulatorControl=true

  3. Attiva l'opzione emulatorControl nello script di compilazione a livello di modulo:

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. Nello script di compilazione a livello di modulo, importa la libreria Espresso Device nel progetto:

    Kotlin

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

    Groovy

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

Eseguire test in base a modifiche alla configurazione comuni

L'API Espresso Device dispone di più stati di orientamento dello schermo e di dispositivi pieghevoli che puoi utilizzare per simulare le modifiche alla configurazione del dispositivo.

Testare la rotazione dello schermo

Ecco un esempio di come testare cosa succede all'app quando lo schermo del dispositivo gira:

  1. Innanzitutto, per uno stato iniziale coerente, imposta il dispositivo in modalità Ritratto:

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

  2. Crea un test che imposti il dispositivo in orizzontale durante l'esecuzione del test:

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

  3. Dopo la rotazione dello schermo, verifica che l'interfaccia utente si adatti al nuovo layout come previsto:

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

Testare l'apertura dello schermo

Ecco un esempio di come testare cosa succede alla tua app se si trova su un dispositivo pieghevole e lo schermo si apre:

  1. Innanzitutto, esegui il test con il dispositivo chiuso chiamando onDevice().setClosedMode(). Assicurati che il layout dell'app si adatti alla larghezza dello schermo compatto:

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

  2. Per passare a uno stato completamente aperto, chiama onDevice().setFlatMode(). Verifica che il layout dell'app si adatti alla classe di dimensioni espansa:

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

Specifica i dispositivi necessari per i test

Se esegui un test che esegue azioni di chiusura su un dispositivo che non è pieghevole, in genere il test non va a buon fine. Per eseguire solo i test pertinenti al dispositivo in esecuzione, utilizza l'annotazione @RequiresDeviceMode. Il programma di esecuzione dei test salta automaticamente l'esecuzione dei test sui dispositivi che non supportano la configurazione in fase di test. Puoi aggiungere la regola del requisito del dispositivo a ogni test o a un'intera classe di test.

Ad esempio, per specificare che un test deve essere eseguito solo sui dispositivi che supportano la visualizzazione espansa in una configurazione piatta, aggiungi il seguente codice @RequiresDeviceMode al test:

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