Android Studio Iguana | 2023.2.1

O Android Studio é o ambiente de desenvolvimento integrado oficial para Android e tem tudo o que você precisa para criar apps desse sistema.

Esta página lista novos recursos e melhorias da versão mais recente no Canal estável, o Android Studio Iguana. Você pode fazer o download neste link ou atualizar no Android Studio clicando em Help > Check for updates. No macOS, clique em Android Studio > Check for updates.

Para conferir o que foi corrigido nessa versão do Android Studio, consulte os problemas fechados.

As notas de versões mais antigas do Android Studio estão disponíveis no artigo Versões anteriores.

Para ter acesso antecipado a recursos e melhorias futuras, consulte as versões de pré-lançamento do Android Studio.

Se você encontrar problemas no Android Studio, acesse a página Problemas conhecidos ou Resolver problemas.

Plug-in do Android para Gradle e compatibilidade com o Android Studio

O sistema de build do Android Studio é baseado no Gradle, e o Plug-in do Android para Gradle (AGP, na sigla em inglês) adiciona vários recursos específicos para a criação de apps Android. A tabela abaixo lista qual versão do AGP é necessária para cada versão do Android Studio.

Versão do Android Studio Versão necessária do AGP
Águas-vivas | 2023.3.1 3,2 a 8,4
Iguana | 2023.2.1 3.2-8.3
Hedgehog | 2023.1.1 3.2-8.2
Giraffe | 2022.3.1 3.2-8.1
Flamingo | 2022.2.1 3.2-8.0
Electric Eel | 2022.1.1 3.2-7.4

Versões anteriores

Versão do Android Studio Versão necessária do AGP
Dolphin | 2021.3.1 3.2-7.3
Chipmunk | 2021.2.1 3.2-7.2
Bumblebee | 2021.1.1 3.2-7.1
Arctic Fox | 2020.3.1 3.1-7.0

Para mais informações sobre as novidades do Plug-in do Android para Gradle, acesse as notas da versão.

Versões mínimas de ferramentas para um nível da API do Android

Há versões mínimas do Android Studio e do AGP que oferecem suporte a um nível específico da API. O uso de versões do Android Studio ou do AGP que são anteriores às exigidas pelo targetSdk ou compileSdk do projeto pode levar a problemas inesperados. Recomendamos usar as versões de pré-lançamento mais recentes do Android Studio e do AGP para trabalhar em projetos voltados para versões de pré-lançamento do SO Android. Além da versão estável, você também pode instalar versões de pré-lançamento do Android Studio.

As versões mínimas do Android Studio e do AGP são as seguintes:

Nível da API Versão mínima do Android Studio Versão mínima do AGP
Prévia do VanillaIceCream Águas-vivas | 2023.3.1 8.4
34 Hedgehog | 2023.1.1 8.1.1
33 Flamingo | 2022.2.1 7.2

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 1 e AGP 8.3.1 (março de 2024)

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

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.

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).

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