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

Questa pagina monitora i problemi noti relativi ad Android Studio Iguana e al plug-in Android Gradle 8.3.0. Se riscontri un problema che non è già stato incluso qui, segnala un bug.

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

Problemi noti di Android Studio

Questa sezione descrive i problemi noti che si verificano nell'ultima versione stabile di Android Studio.

La finestra dell'Assistente Firebase mostra un messaggio di errore

Se nella finestra dell'Assistente Firebase (Strumenti > Firebase dal menu principale) viene visualizzato un messaggio di errore, annulla la validità delle cache e riavvia Android Studio per correggere l'errore.

I nodi di scrittura non sono tutti ispezionabili mediante Controllo layout

Se noti che non tutti i nodi di Compose possono essere ispezionati quando utilizzi Layout Inspector, probabilmente ciò è dovuto a un bug che è stato corretto in Compose versione 1.5.0-alpha04. Se riscontri questo problema, assicurati di eseguire l'upgrade a Compose versione 1.5.0-alpha04 o successiva.

Errore durante il rendering dell'anteprima di Compose

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

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

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

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

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

Quando vai a Crea > Genera bundle / APK firmato e tenti di 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 causare 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 sia per l'archivio chiavi.

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

Studio cerca di importare l'estensione .vmoptions precedente e di gestirla in modo che funzioni con il garbage collector utilizzato da JDK 11. Se questo processo non riesce, l'IDE potrebbe non avviarsi per alcuni utenti che hanno impostato 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 è disponibile 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.

App che usano l'arresto anomalo di Database Inspector nell'emulatore di Android 11

Le app che utilizzano Database Inspector potrebbero avere un arresto anomalo durante l'esecuzione sull'emulatore di 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 a Strumenti > SDK Manager. Nella scheda Piattaforme SDK, seleziona la casella Mostra dettagli pacchetto e scegli la revisione 9 o successiva dell'emulatore Android 11.

Studio non si avvia dopo l'upgrade

Se Studio non viene avviato 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. Una soluzione alternativa consiste nel provare a eliminare (o a rinominare la directory, a scopo di backup) di seguito, a seconda della versione e del sistema operativo di Android Studio, e poi avviare nuovamente Android Studio. Android Studio verrà reimpostato sullo stato predefinito e verranno rimossi tutti i plug-in di terze parti.

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 release canary e beta di Android Studio è PreviewX.Y anziché X.Y per <version>. Ad esempio, le build canary di Android Studio 4.1 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

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

Conflitti di mappatura delle chiavi 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 popolari, come KDE e GNOME. Queste scorciatoie da tastiera in conflitto potrebbero non funzionare come previsto in Android Studio.

Ulteriori informazioni su questo problema (incluse potenziali soluzioni alternative) sono disponibili nello strumento di monitoraggio dei bug di IntelliJ.

Testo piccolo dell'interfaccia utente su ChromeOS

Su ChromeOS, il testo potrebbe apparire molto più piccolo rispetto alle release precedenti. Per risolvere questo problema, procedi nel seguente modo:

  1. Apri la finestra Impostazioni facendo clic su File > Impostazioni
  2. Vai a Aspetto e comportamento > Aspetto.
  3. Seleziona Utilizza 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

In questa sezione vengono descritti i problemi noti relativi all'editor di codice.

Blocco dell'immissione da tastiera: 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 è attivato dalla mancanza di sincronizzazione tra iBus e XLib + AWT ed è già stato segnalato a monte di JetBrains e iBus. Attualmente esistono tre soluzioni alternative per questo problema:

  • Soluzione alternativa 1: forza la modalità sincrona di iBus. Prima di avviare Android Studio, esegui il comando seguente nella riga di comando:
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Soluzione 2:disattiva l'input iBus in Android Studio. Per disattivare l'input iBus solo per Android Studio, esegui il comando seguente nella riga di comando:
    $ XMODIFIERS= ./bin/studio.sh
    Questa soluzione alternativa disabilita solo i metodi di immissione per Android Studio e non altre applicazioni in esecuzione. Tieni presente che se riavvii il daemon mentre Android Studio è in esecuzione (ad esempio, eseguendo ibus-daemon -rd), disabiliti di fatto i metodi di inserimento per tutte le altre applicazioni e potrebbe anche causare l'arresto anomalo della JVM di Android Studio con un errore di segmentazione.
  • Soluzione 3: ricontrolla le associazioni di scorciatoie per assicurarti che la Scorciatoia per l'immissione successiva non sia impostata su Ctrl + Barra spaziatrice, poiché è anche la scorciatoia per il completamento del codice in Android Studio. Ubuntu 14.04 (Trusty) rende Super+Space la scorciatoia predefinita, ma le impostazioni delle versioni precedenti potrebbero essere ancora invariate. Per controllare le associazioni delle scorciatoie, esegui ibus-setup sulla riga di comando per aprire la finestra Preferenze IBus. In Scorciatoie da tastiera, seleziona il Metodo di immissione successivo. Se è impostata su Ctrl + Barra spaziatrice, cambiala 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 Gradle.

Sincronizzazione Gradle non riuscita: tubo rotto

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

  • Soluzione 1: su Linux, inserisci quanto segue in ~/.profile o ~/.bash_profile:
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Soluzione 2: nel file VMware di Android Studio, cambia la riga -Djava.net.preferIPv4Addresses=true in -Djava.net.preferIPv6Addresses=true. Per ulteriori informazioni, consulta la Guida per gli utenti IPv6 sul networking.

Errori "peer non autenticato" da Gradle Sync o SDK Manager

La causa principale di questi errori è un certificato mancante 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 potresti dover utilizzare keytool per aggiungere il certificato del server proxy al file cacerts.
  • Reinstalla un JDK supportato e non modificato. Si è verificato un problema noto che interessa gli utenti di Ubuntu e di conseguenza viene visualizzato 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 Mac OS] Gli aggiornamenti incrementali non vengono applicati a causa di un problema di visualizzazione del file Gradle sui progetti salvati in /System/Volumes/Data

Il problema di Gradle 18149 riguarda le versioni 7.0 e successive del plug-in Android per Gradle, perché richiede Gradle versione 7.0 e successive. A partire da Gradle 7.0, la visualizzazione dei file è abilitata per impostazione predefinita. Se lavori su Mac OS e il tuo progetto viene salvato in /System/Volumes/Data, la visualizzazione dei file Gradle non terrà traccia correttamente delle modifiche ai file. Di conseguenza, il sistema di compilazione non rileverà le modifiche ai file e non aggiornerà gli APK. Il codice di deployment incrementale non avrà quindi nienza perché lo stato dell'APK locale è lo stesso del dispositivo.

Per risolvere il problema, devi spostare la directory del progetto nella directory utente, ovvero in /Users/username. Quindi, il sistema di compilazione riceverà una notifica corretta delle modifiche ai file da parte della visualizzazione del file Gradle e le modifiche incrementali verranno applicate correttamente.

Emulatore Android HAXM su macOS High Sierra

L'emulatore Android su macOS High Sierra (10.13) richiede HAXM 6.2.1 o versioni successive per una compatibilità e una stabilità ottimali con macOS. Tuttavia, macOS 10.13 ha un processo più integrato per installare le estensioni del kernel, come HAXM. Devi consentire manualmente l'installazione dell'estensione del kernel, come segue:

  1. Innanzitutto, prova a installare la versione più recente di HAXM da SDK Manager.
  2. In MacOS, vai a Preferenze di Sistema > Sicurezza e Privacy.
  3. Se viene visualizzato un avviso che ti informa che il caricamento del software di sistema dello sviluppatore "Intel Corporation Apps" è stato bloccato, 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 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 Esegui per eseguire nuovamente il deployment dell'app e visualizzare le modifiche.

Un problema in Android Runtime genera un errore

Se usi un dispositivo con Android 8.0 o 8.1, potresti visualizzare messaggi "Verifica_ERROR" quando cerchi di applicare determinati tipi di modifiche (soprattutto se usi Kotlin). Questo messaggio è causato da un problema con Android Runtime risolto in Android 9.0 e versioni successive. Anche se il problema causa l'esito negativo dell'applicazione delle modifiche, puoi comunque eseguire Icona Esegui l'app di nuovo per vedere 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.

Quando viene eseguito da Android Studio, JUnit testa la mancanza di risorse in classpath

Se nei tuoi moduli Java sono presenti cartelle di risorse specifiche, queste risorse non saranno disponibili durante l'esecuzione dei test dall'IDE. L'esecuzione di test utilizzando Gradle dalla riga di comando funzionerà. Anche l'esecuzione dell'attività Gradle check dall'IDE funzionerà. Vedi il problema 64887 per ulteriori dettagli.

Questo problema si verifica a partire da IntelliJ 13, che richiede di avere una sola cartella come classpath. Il builder di IntelliJ copia tutte le risorse in quella cartella, ma Gradle non le copia.

  • 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. Vedi il commento 13 per ulteriori informazioni.

L'esecuzione di test JUnit può compilare il codice due volte

Durante la creazione di un nuovo progetto, è possibile creare la configurazione JUnit del modello con due passaggi "Prima del lancio": Make (Crea) e Gradle-aware Make. Questa configurazione viene quindi propagata a tutte le configurazioni di esecuzione JUnit create.

  • Per risolvere il problema relativo al progetto corrente, fai clic su Esegui > Modifica configurazioni e cambia la configurazione predefinita di JUnit in modo da includere solo il passaggio Make Gradle-aware.
  • Per risolvere il problema per tutti i progetti futuri, fai clic su File > Chiudi progetto. Dovresti visualizzare la schermata di benvenuto. Quindi fai clic su Configura > Impostazioni predefinite progetto > Esegui configurazioni e modifica la configurazione di JUnit in modo da includere solo il passaggio Make Gradle-aware.

Alcune configurazioni dell'esecuzione di test non funzionano

Non tutte le configurazioni di esecuzione disponibili facendo 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 (con un logo Gradle come icona) non funzionano.
  • Le configurazioni di esecuzione di JUnit (che presentano un'icona senza l'Android verde) non si applicano ai test di strumentazione, che non possono essere eseguiti sulla JVM locale.
Android Studio memorizza inoltre 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 propone di eseguirla in 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 un punto di interruzione nel codice nativo, i debugger Auto e Dual potrebbero non riconoscere immediatamente i nuovi punti di interruzione Java impostati. Per evitare questo problema, aggiungi punti di interruzione Java prima di avviare una sessione di debug o mentre l'app è in pausa in un punto di interruzione Java. Per ulteriori informazioni, vedi il problema 229949.

Uscire dal debugger nativo

Quando utilizzi il debugger Auto o Doppio per eseguire il debug di Java e del codice nativo, se 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, fai clic su Esegui l'accesso ) e vuoi tornare al tuo codice Java, fai clic su Riprendi programma (invece che su Esegui l'esecuzione o Riprendi il processo dell'app ).your-module Per ulteriori informazioni, vedi il problema 224385.

Il debugger nativo si blocca durante il caricamento delle librerie

Quando si utilizza il debugger nativo per la prima volta dopo l'upgrade ad Android Studio 4.2 e versioni successive, il debugger nativo potrebbe smettere di rispondere durante il caricamento delle librerie dal dispositivo Android. Si tratta di un problema fisso che continua a verificarsi anche se arresti e riavvii il debugger. Per risolvere il problema, svuota la cache dell'LLDB all'indirizzo $USER/.lldb/module-cache/.

Il debugger nativo si arresta in modo anomalo con "Processo di debug completato con il codice di uscita 127"

Questo errore si verifica sulle piattaforme basate su Linux all'avvio del debugger nativo. Indica che una delle librerie richieste dal debug 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 sapere quali librerie mancano. In genere, la libreria mancante è ncurses5 perché di recente è già stato eseguito l'upgrade di alcune distribuzioni Linux a ncurses6.

Profiler

In questa sezione vengono descritti i problemi noti relativi ai Profiler.

Profiler della memoria nativa: profilazione non disponibile durante l'avvio dell'app

Il Profiler della memoria nativa al momento non è disponibile durante l'avvio dell'app. Questa opzione sarà disponibile in una release futura.

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

Errori di timeout nel Profiler della CPU

Quando selezioni le configurazioni Metodi Java di esempio o Metodi Java di traccia potresti riscontrare errori di interruzione registrazione non riuscita nel profiler CPU di Android Studio. Spesso si tratta di errori di timeout, soprattutto se vedi il seguente messaggio di errore nel file idea.log:

Wait for ART trace file timed out

Gli errori di timeout tendono a influire maggiormente sui metodi tracciati rispetto ai metodi campionati e sulle registrazioni più lunghe rispetto alle registrazioni più brevi. Come soluzione alternativa temporanea, potrebbe essere utile provare registrazioni più brevi per vedere se l'errore scompare.

Se riscontri problemi di timeout con Profiler, segnala un bug che includa la marca o 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 "AdbCommandDirectedException" o "Impossibile connettere la porta" nel file idea.log quando selezioni Guida > Mostra log. L'upgrade degli strumenti della piattaforma alla versione 29.0.4 o successiva risolve entrambi i problemi.

Per eseguire l'upgrade degli Strumenti della piattaforma:

  1. Apri SDK Manager da Android Studio facendo clic su Strumenti > SDK Manager oppure su SDK Manager nella barra degli strumenti.
  2. Fai clic sulla casella di controllo accanto a SDK Platform-Strumenti SDK Android in modo che mostri un segno di spunta. Nella colonna a sinistra dovrebbe essere visualizzata un'icona di download .
  3. Fai clic su Applica o OK.

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

L'utilizzo del plug-in CMake Simple highlighter impedisce che i contenuti vengano visualizzati nella finestra Build Output (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 questa versione. Ad esempio, se prima installi la versione canary di Android Studio e poi provi a installare e avviare la versione stabile, la versione stabile potrebbe non essere avviata. 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.

Il Registratore di prova Espresso non funziona con Compose

Il registratore di test Espresso non funziona con i progetti che includono Compose. Per creare test dell'interfaccia utente per i progetti che includono Compose, consulta Test del layout di Compose.

Conflitti delle scorciatoie di Logcat con layout di tastiera non in inglese

Se utilizzi un layout di tastiera non inglese, una scorciatoia da tastiera predefinita 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 mappa nuovamente la mappa dei tasti Logcat in conflitto. Per modificare le mappe dei tasti Logcat in Android Studio, vai su Android Studio > Impostazioni > Mappa dei tasti e cerca Logcat nell'elenco delle mappe dei tasti. Per ulteriori informazioni, consulta il problema n. 263475910.

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

Problemi noti relativi al plug-in Android per Gradle

Questa sezione descrive i problemi noti che si verificano nell'ultima versione stabile del plug-in Android Gradle.

Non tutte le dipendenze delle librerie di funzionalità dinamiche vengono controllate tramite 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). Come soluzione alternativa, l'attività lint può essere eseguita su queste librerie.

File di firma denominato con caratteri di ritorno a capo

La firma JAR (schema v1) non supporta i nomi di 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 in fase di compilazione, 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ù complesse che prevedono l'accesso agli oggetti outputFile non funzionano più. in quanto le attività specifiche per le varianti non vengono più create durante la fase di configurazione. In questo modo il plug-in non conosce tutti gli output in anticipo e comporta anche dei tempi di configurazione più rapidi.

manifestOutputFile non è più disponibile

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

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 logica. L'esempio riportato di seguito 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 AGP 7.3.0 AIDL e Kotlin 1.7.x

L'utilizzo di AGP 7.3.0 con KAPT in Kotlin 1.7.x causa la rimozione dei set di origini AIDL per varianti di build specifiche. Puoi comunque utilizzare gli altri set di origini AIDL, inclusi quelli di main/, tipi di build, gusti e combinazioni di gusti del prodotto. Se devi utilizzare i set di origini AIDL specifici delle varianti, continua a usare Kotlin 1.6.21.

Risolti problemi noti

In questa sezione vengono descritti i problemi noti risolti in una release recente. Se riscontri uno di questi problemi, ti consigliamo di aggiornare Android Studio all'ultima versione stabile o in anteprima.

Corretto in Android Studio 2021.1.1

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

Corretto in Android Studio 2020.3.1

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

Corretto in Android Studio 4.2

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

Corretto in Android Studio 4.1

  • Riavvia per applicare le impostazioni di memoria della versione precedente dell'IDE: dopo aver aggiornato Android Studio, devi riavviare Android Studio per applicare le impostazioni di memoria migrate da una versione precedente dell'IDE.
  • La classe del file manifest con stringhe di autorizzazioni personalizzate non viene più generata per impostazione predefinita: se vuoi generare la classe, imposta android.generateManifestClass = true.

Corretto in Android Studio 3.6

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

    Su 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 codice XML interrotto: durante la modifica del codice XML, l'IDE ha applicato uno stile di codice errato quando hai selezionato Codice > Riformattazione codice dalla barra dei menu.

Corretto in Android Studio 3.3.1

  • Errori di memoria insufficienti durante la scansione di progetti basati su C++: quando Gradle analizza un progetto che contiene codice C++ in più posizioni sulla stessa unità, l'analisi include tutte le directory al di sotto della prima directory comune. L'analisi di un numero elevato di directory e file può causare errori di esaurimento della memoria.

    Per ulteriori informazioni, leggi il bug associato al problema.