Android Studio Iguana | 2023.2.1 (fevereiro de 2024)

Confira a seguir os novos recursos do Android Studio Iguana.

Versões de patch

Esta é uma lista das versões de patch no Android Studio Iguana e no Plug-in do Android para Gradle 8.3.

Android Studio Iguana | 2023.2.1 Patch 2 e AGP 8.3.2 (abril de 2024)

Esta atualização secundária inclui estas correções de bugs.

Android Studio Iguana | 2023.2.1 Patch 1 e AGP 8.3.1 (março de 2024)

Esta atualização secundária inclui estas correções de bugs.

Atualização da plataforma IntelliJ IDEA 2023.2

O Android Studio Iguana inclui as atualizações do IntelliJ IDEA 2023.2, que melhoram a experiência do ambiente de desenvolvimento integrado do Studio. Para mais detalhes sobre as mudanças, consulte as notas da versão do IntelliJ IDEA 2023.2 (link em inglês).

Integração do sistema de controle de versões nos insights de qualidade do app

O App Quality Insights agora permite navegar de um stack trace do Crashlytics até o código relevante no momento em que a falha ocorreu. O AGP anexa dados de hash de confirmação git aos relatórios de erros, o que ajuda o Android Studio a navegar até o código e mostrar como ele estava na versão em que o problema ocorreu. Ao visualizar um relatório de erros no App Quality Insights, você pode navegar até a linha de código na finalização do git atual ou conferir as diferenças entre o processo atual e a versão da base de código que gerou a falha.

Para integrar seu sistema de controle de versões ao App Quality Insights, você precisa dos seguintes requisitos mínimos:

Para usar a integração de controle de versões para um tipo de build depurável, ative a flag vcsInfo no arquivo de build do módulo. Para builds de lançamento (não depuráveis), a flag é ativada por padrão.

Kotlin

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

Groovy

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

Agora, quando você criar o app e publicar no Google Play, os relatórios de erros vão incluir os dados necessários para o ambiente de desenvolvimento integrado se vincular a versões anteriores do app pelo stack trace.

Conferir variantes de falhas do Crashlytics no App Quality Insights

Para ajudar a analisar as causas raiz de uma falha, agora é possível usar os insights de qualidade do app para visualizar eventos por variantes de problema ou grupos de eventos que compartilham stack traces semelhantes. Para conferir os eventos em cada variante de um relatório de erros, selecione uma variante na lista suspensa. Se quiser agregar informações para todas as variantes, selecione Todas.

Verificação da interface do Compose

Para ajudar os desenvolvedores a criar IUs mais adaptáveis e acessíveis no Jetpack Compose, o Android Studio Iguana Canary 5 introduziu um novo modo de verificação de interface na visualização do Compose. Esse recurso funciona de maneira semelhante à inspeção visual e às integrações de verificações de acessibilidade para visualizações. Quando você ativa o modo de verificação de interface do Compose, o Android Studio audita automaticamente a interface do Compose e verifica se há problemas de adaptação e acessibilidade em diferentes tamanhos de tela, como texto esticado em telas grandes ou com baixo contraste de cores. O modo destaca os problemas encontrados em diferentes configurações de visualização e os lista no painel de problemas.

Teste esse recurso hoje mesmo clicando no botão de verificação de interface na visualização do Compose e envie seu feedback:

Clique no botão de modo de verificação da interface do Compose para ativar a verificação.

Problemas conhecidos do modo de verificação da interface:

  • O problema selecionado no painel de problemas pode perder o foco
  • A opção "Suprimir regra" não funciona
Modo de verificação da interface do Compose ativado com detalhes no painel de problemas.

Renderização progressiva para a prévia do Compose

O Android Studio Iguana Canary 3 introduz a renderização progressiva na visualização do Compose. Como parte de um esforço contínuo para melhorar o desempenho das visualizações, agora para qualquer visualização que está fora da visualização, diminuímos intencionalmente a qualidade de renderização dela para economizar memória usada.

Esse recurso foi desenvolvido com o objetivo de melhorar ainda mais a usabilidade das prévias, permitindo processar mais visualizações ao mesmo tempo em um arquivo. Teste hoje mesmo e envie seu feedback.

Assistente do módulo de perfis de referência

No Android Studio Iguana e versões mais recentes, é possível gerar perfis de referência para o app usando o modelo Gerador de perfil de referência no assistente de novo módulo (File > New > New Module).

Esse modelo configura o projeto para oferecer suporte a perfis de referência. Ele usa o novo plug-in do Gradle para perfis de referência, que automatiza o processo de configuração do projeto da maneira necessária com uma tarefa do Gradle.

O modelo também cria uma configuração de execução que permite gerar um perfil de referência com um clique na lista suspensa Select Run/Debug Configuration.

Testar mudanças de configuração com a API Espresso Device

Use a API Espresso Device para testar seu app quando o dispositivo passar por mudanças de configuração comuns, como rotação e desdobramento da tela. A API Espresso Device permite simular essas mudanças de configuração em um dispositivo virtual e executar testes de forma síncrona. Assim, apenas uma ação ou declaração de interface acontece por vez e os resultados do teste são mais confiáveis. Saiba mais sobre como programar testes de interface com o Espresso.

Para usar a API Espresso Device, você precisará do seguinte:

  • Android Studio Iguana ou versão mais recente
  • Plug-in do Android para Gradle 8.3 ou mais recente
  • Android Emulator 33.1.10 ou mais recente
  • Dispositivo virtual Android com o nível 24 da API ou mais recente.

Configurar o projeto para a API Espresso Device

Para configurar o projeto para que ele ofereça suporte à API Espresso Device, faça o seguinte:

  1. Para permitir que o teste passe comandos para o dispositivo de teste, adicione as permissões INTERNET e ACCESS_NETWORK_STATE ao arquivo de manifesto no conjunto de origem androidTest:

      <uses-permission android:name="android.permission.INTERNET" />
      <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />
  2. Ative a flag experimental enableEmulatorControl no arquivo gradle.properties:

      android.experimental.androidTest.enableEmulatorControl=true
  3. Ative a opção emulatorControl no script de build do módulo:

    Kotlin

      testOptions {
        emulatorControl {
          enable = true
        }
      }

    Groovy

      testOptions {
        emulatorControl {
          enable = true
        }
      }
  4. No script de build do módulo, importe a biblioteca Espresso Device para o projeto:

    Kotlin

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

    Groovy

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

teste em relação a alterações comuns de configuração

A API Espresso Device tem várias orientações de tela e estados dobráveis que podem ser usados para simular mudanças de configuração do dispositivo.

Testar a rotação da tela

Confira um exemplo de como testar o que acontece com o app quando a tela do dispositivo é girada:

  1. Primeiro, para um estado inicial consistente, defina o dispositivo para o modo retrato:

      import androidx.test.espresso.device.action.ScreenOrientation
      import androidx.test.espresso.device.rules.ScreenOrientationRule
      ...
      @get:Rule
      val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)
  2. Crie um teste que defina o dispositivo para a orientação paisagem durante a execução do teste:

      @Test
      fun myRotationTest() {
        ...
        // Sets the device to landscape orientation during test execution.
        onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
        ...
      }
  3. Depois que a tela girar, verifique se a interface se adapta ao novo layout conforme o esperado:

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

Testar o desdobramento da tela

Confira um exemplo de como testar o que acontece com o app se ele estiver em um dispositivo dobrável e a tela se abrir:

  1. Primeiro, teste com o dispositivo no estado dobrado chamando onDevice().setClosedMode(). Verifique se o layout do app se adapta à largura compacta da tela:

      @Test
      fun myUnfoldedTest() {
        onDevice().setClosedMode()
        composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
        composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
        ...
      }
  2. Para fazer a transição para um estado totalmente desdobrado, chame onDevice().setFlatMode(). Verifique se o layout do app se adapta à classe de tamanho expandida:

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

Especificar os dispositivos necessários para os testes

Se você estiver executando um teste que realiza ações de dobra em um dispositivo não dobrável, o teste geralmente falha. Para executar apenas os testes relevantes para o dispositivo em execução, use a anotação @RequiresDeviceMode. O executor de testes ignora automaticamente a execução de testes em dispositivos que não oferecem suporte à configuração que está sendo testada. Você pode adicionar a regra de requisito de dispositivo a cada teste ou a uma classe de teste inteira.

Por exemplo, para especificar que um teste só pode ser executado em dispositivos compatíveis com uma configuração simples, adicione o seguinte código @RequiresDeviceMode ao teste:

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