Problemi noti relativi ad Android Studio e al plug-in Android per Gradle

Questa pagina tiene traccia dei problemi noti di Android Studio e del plug-in Android Gradle. Se riscontri un problema non ancora incluso qui, segnala un bug.

Esegui l'upgrade alla versione di anteprima: ogni release di Android Studio e del plug-in Android Gradle mira a migliorare la stabilità e le prestazioni e ad aggiungere nuove funzionalità. Per provare subito i vantaggi delle prossime release, scarica e installa Android Studio Preview.

Problemi noti di Android Studio

Questa sezione descrive i problemi noti di Android Studio.

Android Studio Panda 3 non compatibile con il plug-in IntelliJ Develocity 1.2.0

Quando utilizzi il plug-in Develocity IDE v1.2.0, a partire da Android Studio Panda 3 Canary 1, l'azione di esecuzione non va a buon fine con il seguente errore (problema n. 492439205):

Found interface com.android.tools.idea.gradle.project.build.invoker.GradleBuildInvoker$Request, but class was expected

Gli sviluppatori di Develocity stanno lavorando a una correzione per la nuova versione.

Soluzione alternativa: la disattivazione del plug-in IDE Develocity v1.2.0 risolve il problema finché questa incompatibilità non viene corretta in una nuova versione del plug-in.

Kotlin 2.0: impossibile risolvere le espressioni lambda in Layout Inspector

Quando utilizzi Kotlin 2.0, le espressioni lambda non possono essere risolte e Layout Inspector non può accedere al codice sorgente dell'espressione lambda come di consueto.

Soluzione: aggiungi l'opzione del compilatore di seguito come soluzione alternativa fino alla risoluzione del problema:

kotlin {
  compilerOptions {
    freeCompilerArgs.add("-Xlambdas=class")
  }
}

L'esecuzione della configurazione senza l'opzione "Prima del lancio" di Make compatibile con Gradle genera un errore di deployment

Si è verificato un problema in Android Studio Ladybug Feature Drop Canary 9 che ha rimosso le informazioni di configurazione di esecuzione dai progetti aperti con quella versione. Se hai aperto il progetto con questa versione a un certo punto e l'esecuzione dell'app genera l'errore "caricamento degli artefatti di build", verifica che la configurazione di esecuzione attiva abbia il passaggio "Make compatibile con Gradle" nella sezione "Prima del lancio". Per verificarlo, fai clic su Configurazioni di esecuzione/debug > Modifica configurazioni, fai clic sulla configurazione di esecuzione attiva e verifica che sia presente un passaggio "Gradle-aware Make" nella sezione "Prima del lancio". Purtroppo Android Studio non può risolvere automaticamente questo problema perché alcune configurazioni di esecuzione potrebbero essere state configurate intenzionalmente senza un passaggio "Gradle-aware Make".

"Applica modifiche e riavvia l'attività" non riavvia l'attività su emulatori o dispositivi con livello API 35

Quando esegui il deployment delle modifiche al codice su un dispositivo con API 35 con "Applica modifiche e riavvia l'attività", l'app non verrà riavviata e non vedrai l'effetto delle modifiche. Se esegui nuovamente l'applicazione, vedrai l'effetto delle modifiche al codice. Il nostro team sta svolgendo un'indagine in merito.

La finestra di Firebase Assistant mostra un messaggio di errore

Se la finestra di Firebase Assistant (Strumenti > Firebase dal menu principale) mostra un messaggio di errore, invalida le cache e riavvia Android Studio per correggere l'errore.

Impossibile isolare una visualizzazione utilizzando Layout Inspector

La possibilità di isolare una visualizzazione utilizzando lo strumento Layout Inspector incorporato non è al momento disponibile. Ci stiamo adoperando per risolvere questo problema in una versione futura.

Non tutti i nodi di composizione sono ispezionabili utilizzando Layout Inspector

Se noti che non tutti i nodi di Compose sono ispezionabili quando utilizzi Layout Inspector, è probabile che ciò sia dovuto a un bug che è stato corretto nella versione 1.5.0-alpha04 di Compose. Se riscontri questo problema, assicurati di eseguire l'upgrade a Compose versione 1.5.0-alpha04 o successive.

Errore durante il rendering dell'anteprima di Compose

A partire da Android Studio Chipmunk, se nel riquadro dei problemi vengono visualizzati java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner o java.lang.ClassNotFoundException: androidx.savedstate.R$id, assicurati di includere una dipendenza debugImplementation a androidx.lifecycle:lifecycle-viewmodel-savedstate nel modulo.

Se vedi java.lang.NoSuchFieldError: view_tree_lifecycle_owner nel riquadro dei problemi, assicurati di includere una dipendenza debugImplementation a androidx.lifecycle:lifecycle-runtime nel modulo.

Se nel riquadro dei problemi visualizzi java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer o java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener, assicurati di includere una dipendenza debugImplementation a androidx.customview:customview-poolingcontainer nel modulo.

Errore durante l'utilizzo di password diverse per la chiave e l'archivio chiavi

A partire dalla versione 4.2, Android Studio viene eseguito su JDK 11. Questo aggiornamento causa una modifica del comportamento sottostante relativa alle chiavi di firma.

Quando vai a Build > Generate Signed Bundle / APK e provi a configurare la firma dell'app per un app bundle o un APK, l'inserimento di password diverse per la chiave e l'archivio chiavi potrebbe generare il seguente errore:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

Per risolvere il problema, inserisci la stessa password sia per la chiave che per il keystore.

Android Studio non si avvia dopo l'installazione della versione 4.2

Studio tenta di importare i file .vmoptions precedenti e di correggerli in modo che funzionino con il garbage collector utilizzato da JDK 11. Se questo processo non va a buon fine, l'IDE potrebbe non avviarsi per alcuni utenti che impostano opzioni VM personalizzate nel file .vmoptions.

Per risolvere il problema, ti consigliamo di commentare le opzioni personalizzate in .vmoptions (utilizzando il carattere "#"). Il file .vmoptions si trova nelle seguenti posizioni:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

Se Studio continua a non avviarsi dopo aver provato questa soluzione alternativa, consulta la sezione Studio non si avvia dopo l'upgrade di seguito.

Le app che utilizzano Database Inspector si arrestano in modo anomalo sull'emulatore Android 11

Le app che utilizzano Database Inspector potrebbero arrestarsi in modo anomalo quando vengono eseguite sull'emulatore Android 11, con un errore simile al seguente visualizzato in logcat:

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

Per risolvere il problema, esegui l'upgrade dell'emulatore Android 11 alla versione 9 o successive andando su Strumenti > SDK Manager. Nella scheda SDK Platforms, seleziona la casella Show Package Details e seleziona la revisione 9 o successiva dell'emulatore Android 11.

Studio non si avvia dopo l'upgrade

Se Studio non si avvia dopo un upgrade, il problema potrebbe essere dovuto a una configurazione di Android Studio non valida importata da una versione precedente di Android Studio o a un plug-in incompatibile. Come soluzione alternativa, prova a eliminare (o rinominare, per scopi di backup) la directory di seguito, a seconda della versione di Android Studio e del sistema operativo, e riavvia Android Studio. In questo modo, Android Studio verrà ripristinato allo stato predefinito e tutti i plug-in di terze parti verranno rimossi.

Per Android Studio 4.1 e versioni successive:

  • Windows: %APPDATA%\Google\AndroidStudio<version>
    Esempio: C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

  • macOS: ~/Library/Application Support/Google/AndroidStudio<version>
    Esempio: ~/Library/Application Support/Google/AndroidStudio4.1

  • Linux: ~/.config/Google/AndroidStudio<version> e ~/.local/share/Google/AndroidStudio<version>
    Esempio: ~/.config/Google/AndroidStudio4.1 e ~/.local/share/Google/AndroidStudio4.1

Per Android Studio 4.0 e versioni precedenti:

  • Windows: %HOMEPATH%\.AndroidStudio<version>\config
    Esempio: C:\Users\your_user_name\.AndroidStudio3.6\config

  • macOS: ~/Library/Preferences/AndroidStudio<version>
    Esempio: ~/Library/Preferences/AndroidStudio3.6

  • Linux: ~/.AndroidStudio<version>/config
    Esempio: ~/.AndroidStudio3.6/config

Tieni presente che la directory di configurazione per le versioni Canary e Beta di Android Studio è PreviewX.Y anziché X.Y per <version>. Ad esempio, le build Android Studio 4.1 Canary utilizzano AndroidStudioPreview4.1, anziché la directory AndroidStudio4.1 utilizzata per i candidati per la release e le release stabili.

Problema di compilazione nei progetti multipiattaforma Kotlin

Potrebbero verificarsi errori di compilazione nel codice Kotlin MPP a causa di simboli mancanti. L'upgrade del plug-in Kotlin alla versione 1.4 dovrebbe risolvere il problema.

Conflitti di mappatura dei tasti su Linux

Su Linux, alcune scorciatoie da tastiera sono in conflitto con le scorciatoie da tastiera predefinite di Linux e con quelle dei gestori di finestre più diffusi, come KDE e GNOME. Queste scorciatoie da tastiera in conflitto potrebbero non funzionare come previsto in Android Studio.

Per saperne di più su questo problema (incluse potenziali soluzioni alternative), consulta il tracker dei bug di IntelliJ.

Testo dell'interfaccia utente di piccole dimensioni su ChromeOS

Su ChromeOS, il testo potrebbe apparire molto più piccolo rispetto alle versioni precedenti. Per risolvere il problema, segui questi passaggi:

  1. Apri la finestra Impostazioni facendo clic su File > Impostazioni.
  2. Vai ad Appearance & Behavior > Appearance (Aspetto e comportamento > Aspetto).
  3. Seleziona Usa carattere personalizzato.
  4. Aumentare la dimensione dei caratteri.
  5. Nella finestra Impostazioni, vai a Editor > Carattere.
  6. Aumentare la dimensione dei caratteri.
  7. Fai clic su OK.

Modifica del codice

Questa sezione descrive i problemi noti relativi all'editor di codice.

Input da tastiera bloccato: problemi con "iBus" su Linux

Esistono alcune interazioni note tra il daemon iBus su Linux e Android Studio. In alcuni scenari, l'IDE smette di rispondere all'input da tastiera o inizia a inserire caratteri casuali. Questo bug è causato da una mancata sincronizzazione tra iBus e XLib + AWT ed è già stato segnalato a JetBrains e iBus. Al momento esistono tre soluzioni alternative per questo problema:

  • Soluzione 1: forza iBus in modalità sincrona. Prima di avviare Android Studio, esegui questo comando nella riga di comando: 
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Soluzione alternativa 2: disattiva l'input iBus in Android Studio. Per disattivare l'input iBus solo per Android Studio, esegui il seguente comando nella riga di comando: 
    $ XMODIFIERS= ./bin/studio
     Questa soluzione alternativa disattiva i metodi di immissione solo per Android Studio, non per altre applicazioni che potresti eseguire. Tieni presente che se riavvii il daemon mentre Android Studio è in esecuzione (ad esempio eseguendo ibus-daemon -rd), disattivi di fatto i metodi di immissione per tutte le altre applicazioni e potresti anche causare l'arresto anomalo della JVM di Android Studio con un errore di segmentazione.
  • Soluzione alternativa 3: controlla le associazioni delle scorciatoie per assicurarti che la scorciatoia per l'input successivo non sia impostata su Ctrl+Spazio, poiché questa è anche la scorciatoia per il completamento del codice in Android Studio. Ubuntu 14.04 (Trusty) imposta Super+Spazio come scorciatoia predefinita, ma le impostazioni delle versioni precedenti potrebbero essere ancora presenti. Per controllare le associazioni delle scorciatoie, esegui ibus-setup sulla riga di comando per aprire la finestra Preferenze di IBus. Nella sezione Scorciatoie da tastiera, seleziona Metodo di immissione successivo. Se è impostata su Ctrl+Spazio, modificala in Super+Spazio o in un'altra scorciatoia a tua scelta.

Configurazione progetto

Questa sezione descrive i problemi noti relativi alla configurazione del progetto e alla sincronizzazione di Gradle.

Sincronizzazione Gradle non riuscita: pipe interrotta

Il problema è che il daemon Gradle sta tentando di utilizzare IPv4 anziché IPv6.

  • Soluzione 1: su Linux, inserisci quanto segue in ~/.profile o ~/.bash_profile: 
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Soluzione alternativa 2: nel file vmoptions di Android Studio, modifica la riga -Djava.net.preferIPv4Addresses=true in -Djava.net.preferIPv6Addresses=true Per saperne di più, consulta la guida dell'utente per il networking IPv6.

Errori "peer non autenticato" dalla sincronizzazione di Gradle o da SDK Manager

La causa principale di questi errori è la mancanza di un certificato in $JAVA_HOME/jre/lib/certificates/cacerts. Per risolvere questi errori, procedi come segue:

  • Se utilizzi un proxy, prova a connetterti direttamente. Se la connessione diretta funziona, per connetterti tramite il proxy potrebbe essere necessario utilizzare keytool per aggiungere il certificato del server proxy al file cacerts.
  • Reinstalla un JDK supportato e non modificato. Esiste un problema noto che interessa gli utenti Ubuntu e che genera un /etc/ssl/certs/java/cacerts vuoto. Per risolvere il problema, esegui questo comando nella riga di comando: 
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Deployment in corso…

Questa sezione descrive i problemi noti relativi al deployment dell'app su un dispositivo connesso.

[Solo macOS] Gli aggiornamenti incrementali non vengono applicati a causa di un problema con il monitoraggio dei file Gradle nei progetti salvati in /System/Volumes/Data

Il problema di Gradle 18149 interessa il plug-in Android per Gradle versione 7.0 e successive perché richiedono Gradle versione 7.0 e successive. A partire da Gradle 7.0, il monitoraggio dei file è abilitato per impostazione predefinita. Se lavori su Mac OS e il tuo progetto è salvato in /System/Volumes/Data, il monitoraggio dei file di Gradle non monitorerà correttamente le modifiche ai file. In questo modo, il sistema di build non rileverà alcuna modifica ai file e, di conseguenza, non aggiornerà gli APK. Il codice di deployment incrementale non farà nulla perché lo stato dell'APK locale è lo stesso di quello sul dispositivo.

Per risolvere questo problema, devi spostare la directory del progetto nella directory utente, ovvero in /Users/username. Il sistema di build verrà quindi informato correttamente delle modifiche ai file tramite il monitoraggio dei file di Gradle e le modifiche incrementali verranno applicate correttamente.

HAXM per l'emulatore Android su macOS High Sierra

L'emulatore Android su macOS High Sierra (10.13) richiede HAXM 6.2.1 o versioni successive per la migliore compatibilità e stabilità con macOS. Tuttavia, macOS 10.13 prevede una procedura più complessa per l'installazione di estensioni del kernel come HAXM. Devi consentire manualmente l'installazione dell'estensione del kernel nel seguente modo:

  1. Innanzitutto, prova a installare l'ultima versione di HAXM da SDK Manager.
  2. In macOS, vai a Preferenze di Sistema > Sicurezza e Privacy.

  3. Se viene visualizzato un avviso che indica che è stato bloccato il caricamento del software di sistema dallo sviluppatore "Intel Corporation Apps", fai clic su Consenti:

Per ulteriori informazioni e soluzioni alternative, consulta questa pagina web di Apple e il problema 62395878.

Applica modifiche

Questa sezione descrive i problemi noti relativi ad Applica modifiche.

Nuovo nome dell'app non applicato

Se rinomini l'app e poi provi ad applicare la modifica, il nome aggiornato potrebbe non essere visualizzato. Per risolvere il problema, fai clic su Esegui Icona Run per eseguire nuovamente il deployment dell'app e visualizzare le modifiche.

Un problema in Android Runtime genera un errore

Se utilizzi un dispositivo con Android 8.0 o 8.1, potresti riscontrare messaggi "VERIFICATION_ERROR" quando provi ad applicare determinati tipi di modifiche (soprattutto se utilizzi Kotlin). Questo messaggio è causato da un problema con Android Runtime che è stato risolto in Android 9.0 e versioni successive. Anche se il problema causa l'errore di Applica modifiche, puoi comunque eseguire Icona Run di nuovo l'app per visualizzare le modifiche. Tuttavia, ti consigliamo di eseguire l'upgrade del dispositivo ad Android 9.0 o versioni successive.

Debug e test

Questa sezione descrive i problemi noti relativi al debug e al test dell'app.

Risorse mancanti nei test JUnit nel classpath se eseguiti da Android Studio

Se hai cartelle di risorse specifiche nei moduli Java, queste risorse non verranno trovate durante l'esecuzione dei test dall'IDE. L'esecuzione dei test utilizzando Gradle dalla riga di comando funzionerà. Anche l'esecuzione dell'attività Gradle check dall'IDE funzionerà. Per maggiori dettagli, consulta il problema 64887.

Questo problema si verifica perché, a partire da IntelliJ 13, è necessario avere una sola cartella come percorso di classe. Il builder di IntelliJ copia tutte le risorse in quella cartella di build, ma Gradle non copia le risorse.

  • Soluzione 1: esegui l'attività Gradle check dall'IDE anziché eseguire un test delle unità.
  • Soluzione 2: aggiorna lo script di build per copiare manualmente le risorse nella cartella di build. Per saperne di più, consulta il commento n. 13.

L'esecuzione dei test JUnit potrebbe compilare il codice due volte

Quando crei un nuovo progetto, la configurazione JUnit del modello potrebbe essere creata con due passaggi "Prima del lancio": Make e Gradle-aware Make. Questa configurazione viene poi propagata a tutte le configurazioni di esecuzione JUnit create.

  • Per risolvere il problema per il progetto corrente, fai clic su Esegui > Modifica configurazioni e modifica la configurazione JUnit predefinita in modo da includere solo il passaggio Crea compatibile con Gradle.
  • Per risolvere il problema per tutti i progetti futuri, fai clic su File > Chiudi progetto. Dovresti vedere la schermata di benvenuto. Poi fai clic su Configure > Project Defaults > Run Configurations (Configura > Impostazioni predefinite del progetto > Esegui configurazioni) e modifica la configurazione JUnit in modo da includere solo il passaggio Make compatibile con Gradle.

Alcune configurazioni di esecuzione dei test non funzionano

Non tutte le configurazioni di esecuzione disponibili quando fai clic con il tasto destro del mouse su un metodo di test sono valide. In particolare, le seguenti configurazioni non sono valide:

  • Le configurazioni di esecuzione di Gradle (che hanno un logo Gradle come icona) non funzionano.
  • Le configurazioni di esecuzione JUnit (che hanno un'icona senza il simbolo Android verde) non si applicano ai test di instrumentazione, che non possono essere eseguiti sulla JVM locale.
Android Studio memorizza anche la configurazione di esecuzione creata in un determinato contesto (ad esempio, facendo clic con il tasto destro del mouse su una classe o un metodo specifico) e non offrirà la possibilità di eseguire una configurazione diversa in futuro. Per risolvere il problema, fai clic su Esegui > Modifica configurazioni e rimuovi le configurazioni create in modo errato.

Aggiunta di punti di interruzione Java durante il debug del codice nativo

Mentre l'app è in pausa in corrispondenza di un punto di interruzione nel codice nativo, i debugger Automatico e Doppio potrebbero non riconoscere immediatamente i nuovi punti di interruzione Java impostati. Per evitare questo problema, aggiungi i punti di interruzione Java prima di avviare una sessione di debug o mentre l'app è in pausa su un punto di interruzione Java. Per saperne di più, consulta il problema 229949.

Uscita dal debugger nativo

Se utilizzi il debugger Automatico o Doppio per eseguire il debug del codice Java e nativo, quando entri in una funzione nativa dal codice Java (ad esempio, il debugger mette in pausa l'esecuzione in una riga del codice Java che chiama una funzione nativa e fai clic su Entra ) e vuoi tornare al codice Java, fai clic su Riprendi programma (anziché su Esci o Salta ). Il processo dell'app verrà comunque messo in pausa, quindi fai clic su Riprendi programma nella scheda your-module-java per riprenderlo. Per saperne di più, consulta il problema 224385.

Il debugger nativo si blocca durante il caricamento delle librerie

Quando utilizzi il debugger nativo per la prima volta dopo l'upgrade ad Android Studio 4.2 e versioni successive, il debugger nativo potrebbe non rispondere durante il caricamento delle librerie dal dispositivo Android. Questo problema è persistente e continua a verificarsi anche se interrompi e riavvii il debugger. Per risolvere il problema, elimina la cache LLDB in $USER/.lldb/module-cache/.

Il debugger nativo si arresta in modo anomalo con il messaggio "Processo del debugger terminato con codice di uscita 127"

Questo errore si verifica sulle piattaforme basate su Linux quando si avvia il debugger nativo. Indica che una delle librerie richieste dal debugger nativo non è installata sul sistema locale. Il nome della libreria mancante potrebbe essere già stampato nel file idea.log. In caso contrario, puoi utilizzare un terminale per accedere alla directory di installazione di Android Studio ed eseguire la riga di comando bin/lldb/bin/LLDBFrontend --version per scoprire quali librerie mancano. In genere, la libreria mancante è ncurses5, poiché alcune distribuzioni Linux recenti hanno già eseguito l'upgrade a ncurses6.

Profiler

Questa sezione descrive i problemi noti relativi ai profiler.

Native Memory Profiler: profilazione non disponibile durante l'avvio dell'app

Al momento, Native Memory Profiler non è disponibile durante l'avvio dell'app. Questa opzione sarà disponibile in una versione futura.

Come soluzione alternativa, puoi utilizzare il profiler a riga di comando autonomo Perfetto per acquisire i profili di avvio.

Errori di timeout in CPU Profiler

Potresti riscontrare errori "Impossibile interrompere la registrazione" in CPU Profiler di Android Studio quando selezioni le configurazioni Metodi Java di esempio o Traccia metodi Java. Spesso si tratta di errori di timeout, soprattutto se nel file idea.log viene visualizzato il seguente messaggio di errore:

Wait for ART trace file timed out

Gli errori di timeout tendono a interessare i metodi tracciati più di quelli campionati e le registrazioni più lunghe più di quelle più brevi. Come soluzione temporanea, potrebbe essere utile provare registrazioni più brevi per vedere se l'errore scompare.

Se riscontri problemi di timeout con Profiler, segnala un bug includendo la marca/il modello dei tuoi dispositivi ed eventuali voci pertinenti di idea.log e logcat.

Eccezione ADB durante il debug o la profilazione

Quando utilizzi Platform Tools 29.0.3, il debug nativo e i profiler di Android Studio potrebbero non funzionare correttamente e potresti visualizzare "AdbCommandRejectedException" o "Impossibile connettere la porta" nel file idea.log quando selezioni Guida > Mostra log. L'upgrade di Platform Tools alla versione 29.0.4 o successive risolve entrambi i problemi.

Per eseguire l'upgrade di Platform Tools:

  1. Apri SDK Manager da Android Studio facendo clic su Tools (Strumenti) > SDK Manager o fai clic su SDK Manager nella barra degli strumenti.

  2. Fai clic sulla casella di controllo accanto a SDK Android Platform-Tools in modo che venga visualizzato un segno di spunta. Nella colonna di sinistra dovrebbe essere visualizzata un'icona di download .

  3. Fai clic su Applica o su Ok.

Il plug-in impedisce il funzionamento della finestra Output di build

L'utilizzo del plug-in CMake simple highlighter impedisce la visualizzazione dei contenuti nella finestra Output di build. La build viene eseguita e viene visualizzata la scheda Output build, ma non viene stampato alcun output (problema n. 204791544).

L'ordine di installazione impedisce l'avvio

L'installazione di una versione più recente di Android Studio prima di una versione precedente potrebbe impedire l'avvio di quest'ultima. Ad esempio, se installi prima la versione Canary di Android Studio e poi provi a installare e avviare la versione stabile, quest'ultima potrebbe non avviarsi. In casi come questo, devi svuotare la cache per avviare la versione stabile (precedente). Su macOS, per svuotare la cache, elimina la directory Library/ApplicationSupport/Google/AndroidStudioversion_number. Su Windows, per svuotare la cache utilizza Pulizia disco.

Espresso Test Recorder non funziona con Compose

Espresso Test Recorder non funziona con i progetti che includono Compose. Per creare test della UI per i progetti che includono Compose, consulta Testare il layout di Compose.

La scorciatoia di Logcat è in conflitto con i layout di tastiera non inglesi

Se utilizzi un layout di tastiera non in inglese, una scorciatoia da tastiera predefinita di Logcat potrebbe entrare in conflitto con il layout e impedirti di digitare determinati caratteri durante la modifica del testo in Android Studio. Per risolvere il problema, elimina o rimappa la mappa dei tasti di Logcat in conflitto. Per modificare le mappe dei tasti di Logcat in Android Studio, vai ad Android Studio > Impostazioni > Mappa dei tasti e cerca Logcat nell'elenco delle mappe dei tasti. Per saperne di più, consulta il problema n. 263475910.

Questo problema verrà risolto con la rimozione della scorciatoia Logcat in Android Studio Electric Eel Patch 1.

Problemi noti con il plug-in Android per Gradle

Questa sezione descrive i problemi noti presenti nell'ultima versione stabile del plug-in Android per Gradle.

Non tutte le dipendenze della libreria di funzionalità dinamiche vengono sottoposte a controlli lint

Quando esegui lint con checkDependencies = true da un modulo dell'app, le dipendenze della libreria di funzionalità dinamiche non vengono controllate, a meno che non siano anche dipendenze dell'app (problema n. 191977888). Per risolvere il problema, l'attività lint può essere eseguita su queste librerie.

File di firma con nome contenente caratteri di ritorno a capo

La firma JAR (schema v1) non supporta i nomi file contenenti caratteri di ritorno a capo (problema n. 63885809).

La modifica degli output delle varianti in fase di build potrebbe non funzionare

L'utilizzo dell'API Variant per manipolare gli output delle varianti non funziona con il nuovo plug-in. Funziona ancora per attività semplici, come la modifica del nome dell'APK durante la fase di build, come mostrato di seguito: 

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

Tuttavia, le attività più complicate che prevedono l'accesso agli oggetti outputFile non funzionano più. Questo perché le attività specifiche per le varianti non vengono più create durante la fase di configurazione. Di conseguenza, il plug-in non conosce tutti i suoi output in anticipo, ma i tempi di configurazione sono più rapidi.

manifestOutputFile non è più disponibile

Il metodo processManifest.manifestOutputFile() non è più disponibile e quando lo chiami viene visualizzato il seguente errore: 

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task
   ':myapp:processDebugManifest' of type
   com.android.build.gradle.tasks.ProcessManifest.

Anziché chiamare manifestOutputFile() per ottenere il file manifest per ogni variante, puoi chiamare processManifest.manifestOutputDirectory() per restituire il percorso della directory che contiene tutti i manifest generati. Puoi quindi individuare un manifest e applicarvi la tua logica. L'esempio seguente modifica dinamicamente il codice di versione nel manifest:

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}

Problemi con il supporto AIDL di AGP 7.3.0 e Kotlin 1.7.x

L'utilizzo di AGP 7.3.0 con KAPT in Kotlin 1.7.x comporta la rimozione dei set di risorse AIDL per varianti di compilazione specifiche. Puoi comunque utilizzare gli altri set di risorse AIDL, inclusi quelli di main/, i tipi di build, le versioni prodotto e le combinazioni di versioni prodotto. Se devi utilizzare i set di risorse AIDL specifici per le varianti, continua a utilizzare Kotlin 1.6.21.

Problemi noti risolti

Questa sezione descrive i problemi noti che sono stati risolti in una release recente. Se riscontri uno di questi problemi, devi aggiornare Android Studio all'ultima versione stabile o alla versione di anteprima.

Risolto in Android Studio Rabbit 1 Canary 5

  • Esecuzione della sincronizzazione Gradle in parallelo: in Android Studio Quail 1, la proprietà org.gradle.parallel=true in gradle.properties non attivava più il recupero del modello in parallelo durante la sincronizzazione Gradle quando si utilizzava Gradle versione 9.4 o successiva. Ciò ha comportato una regressione del tempo di sincronizzazione per i progetti di grandi dimensioni. La nuova proprietà org.gradle.tooling.parallel attiva il recupero parallelo dei modelli, ma non per i generatori di modelli di IDEA. Questa limitazione è stata rimossa.

Problemi risolti in Android Studio 2021.1.1

  • Output lint mancante: non viene stampato alcun output di testo lint in stdout quando l'attività lint è UP-TO-DATE (problema n. 191897708). Correzione in AGP 7.1.0-alpha05.
  • Problemi con i test delle unità di un progetto di app che utilizza il plug-in Hilt: il classpath del test delle unità contiene le classi dell'app non instrumentate, il che significa che Hilt non instrumenta le classi dell'app per gestire l'inserimento delle dipendenze durante l'esecuzione dei test delle unità (problema n. 213534628). Risolto in AGP 7.1.1.

Problema risolto in Android Studio 2020.3.1

  • Eccezioni di Lint nei progetti Kotlin: i progetti Kotlin che impostano checkDependencies = true potrebbero riscontrare eccezioni di puntatore nullo o errori (problema n. 158777858).

Problemi risolti in Android Studio 4.2

  • L'IDE si blocca su macOS Big Sur: Android Studio 4.1 potrebbe bloccarsi quando apri una finestra di dialogo.

Problema risolto in Android Studio 4.1

  • Riavvia per applicare le impostazioni della memoria della versione precedente dell'IDE: dopo aver aggiornato Android Studio, devi riavviarlo per applicare le impostazioni della memoria di cui è stata eseguita la migrazione da una versione precedente dell'IDE.
  • La classe manifest con stringhe di autorizzazione personalizzate non viene più generata per impostazione predefinita: se vuoi generare la classe, imposta android.generateManifestClass = true.

Problemi risolti in Android Studio 3.6

  • Errore di installazione dell'APK su LineageOS: il deployment della tua app su dispositivi con determinate versioni di LineageOS o CyanogenMod potrebbe non riuscire e generare un'eccezione INSTALL_PARSE_FAILED_NOT_APK.

    In Android Studio 3.6 Beta 1 e versioni successive, l'IDE gestisce questa eccezione eseguendo un'installazione completa dell'app quando esegui il deployment dell'app su dispositivi LineageOS o CyanogenMod, il che potrebbe comportare tempi di deployment più lunghi.

Corretto in Android Studio 3.5.2

  • Stile del codice XML non funzionante: durante la modifica del codice XML, l'IDE applicava uno stile del codice errato quando selezionavi Codice > Riformatta codice dalla barra dei menu.

Corretto in Android Studio 3.3.1

  • Errori di memoria esaurita durante l'analisi di progetti basati su C++: quando Gradle analizza un progetto con codice C++ in più posizioni sulla stessa unità, l'analisi include tutte le directory sotto la prima directory comune. La scansione di un numero elevato di directory e file potrebbe causare errori di out of memory.

    Per saperne di più su questo problema, leggi il bug associato.