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

Questa pagina monitora i problemi noti relativi a Android Studio Ladybug e al plug-in Android per Gradle 8.7.0. 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 per Gradle ha lo scopo di migliorare la stabilità e le prestazioni e di aggiungere nuove funzionalità. Per usufruire subito dei vantaggi delle prossime release, scarica e installa Anteprima di Android Studio.

Problemi noti di Android Studio

Questa sezione descrive i problemi noti presenti nell'ultima versione stabile di Android Studio.

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

Quando esegui il deployment delle modifiche al codice su un dispositivo API 35 con "Applica modifiche e riavvia attività", l'app non verrà riavviata e non vedrai l'effetto delle modifiche. Se esegui di nuovo l'applicazione, vedrai l'effetto delle modifiche al codice. Il nostro team lo sta esaminando attivamente.

La finestra dell'assistente Firebase mostra un messaggio di errore

Se nella finestra dell'assistente Firebase (Strumenti > Firebase nel menu principale) viene visualizzato un messaggio di errore, invalida le cache e riavvia Android Studio per correggere l'errore.

Impossibile isolare una visualizzazione utilizzando l'ispettore layout

La possibilità di isolare una visualizzazione utilizzando lo strumento Controllo layout incorporato non è temporaneamente disponibile. Stiamo lavorando per risolvere il problema in una release futura.

Non tutti i nodi di composizione sono ispezionabili utilizzando Layout Inspector

Se noti che non tutti i nodi Compose sono ispezionabili quando utilizzi Layout Inspector, è probabile che si tratti di un bug corretto nella versione 1.5.0-alpha04 di Compose. Se riscontri questo problema, assicurati di eseguire l'upgrade alla versione 1.5.0-alpha04 o successiva di Compose.

Errore durante il rendering dell'anteprima di Componi

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

Se nel pannello dei problemi viene visualizzato java.lang.NoSuchFieldError: view_tree_lifecycle_owner, assicurati di includere nel modulo una dipendenza da debugImplementation a androidx.lifecycle:lifecycle-runtime.

Se nel riquadro dei problemi viene visualizzato 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 da androidx.customview:customview-poolingcontainer nel modulo.

Errore durante l'utilizzo di password diverse per la chiave e il keystore

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

Quando vai a Compila > Genera bundle / APK firmato e provi a configurare la firma dell'app per un app bundle o per un APK, se inserisci password diverse per la chiave e il keystore potresti visualizzare 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 il keystore.

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

Studio tenta di importare i file .vmoptions precedenti e di sottoporli a sanificazione per utilizzarli con il garbage collector utilizzato da JDK 11. Se il processo non va a buon fine, 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.

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

Le app che utilizzano lo strumento di controllo del database potrebbero arrestarsi in modo anomalo durante l'esecuzione nell'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 a Strumenti > Gestore SDK. Nella scheda Piattaforme SDK, seleziona la casella Mostra dettagli del pacchetto 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, a scopo di backup) la directory riportata di seguito, a seconda della versione di Android Studio e del sistema operativo, e avvia di nuovo Android Studio. In questo modo, Android Studio verrà reimpostato 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 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 le release candidate e le release stabili.

Problema di compilazione nei progetti multipiattaforma Kotlin

Nel codice MPP di 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 dei tasti su Linux

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

Puoi trovare ulteriori informazioni su questo problema (incluse potenziali soluzioni alternative) nel tracker dei bug di IntelliJ.

Testo dell'interfaccia utente di piccole dimensioni su ChromeOS

Su ChromeOS, il testo potrebbe essere molto più piccolo rispetto alle release precedenti. Per risolvere il problema:

  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

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

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

Esistono alcune interazioni tra il demone iBus su Linux e Android Studio. In alcuni scenari, l'IDE smette di rispondere all'input della tastiera o inizia a inserire caratteri casuali. Questo bug viene attivato da una sincronizzazione mancante 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 quanto segue sulla 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 quanto segue nella riga di comando: 
    $ XMODIFIERS= ./bin/studio.sh
    Questa soluzione alternativa disattiva i metodi di inserimento solo per Android Studio, non per altre applicazioni in esecuzione. Tieni presente che se riavvii il daemon mentre Android Studio è in esecuzione (ad esempio, eseguendo ibus-daemon -rd), disattivi effettivamente i metodi di inserimento per tutte le altre applicazioni e potresti anche arrestare in modo anomalo la JVM di Android Studio con un errore di segmentazione.
  • Soluzione alternativa 3: verifica le associazioni delle scorciatoie per assicurarti che la scorciatoia per l'inserimento successivo non sia impostata su Control+Barra spaziatrice, poiché si tratta anche della scorciatoia per il completamento del codice in Android Studio. Ubuntu 14.04 (Trusty) ha impostato Super+Spazio come scorciatoia predefinita, ma le impostazioni delle versioni precedenti potrebbero essere ancora presenti. Per controllare le associazioni delle scorciatoie, eseguiibus-setup sulla riga di comando per aprire la finestra delle preferenze di IBus. In Scorciatoie da tastiera, seleziona Metodo di immissione successivo. Se è impostato su Ctrl+Spazio, impostalo su Super+Spazio o su un'altra scorciatoia di tua scelta.

Configurazione progetto

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

Gradle Sync Failed: Broken Pipe

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

  • Soluzione alternativa 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, cambia la riga -Djava.net.preferIPv4Addresses=true in -Djava.net.preferIPv6Addresses=true. Per ulteriori informazioni, consulta la Guida dell'utente per la rete IPv6.

Errori "peer not authenticated" (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 sei dietro 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 di Ubuntu, che si traduce in un /etc/ssl/certs/java/cacerts vuoto. Per risolvere il problema, esegui quanto segue 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 collegato.

[Solo Mac OS] 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 Gradle 18149 interessa le versioni 7.0 e successive del plug-in Android per Gradle perché richiedono la versione 7.0 e successive di Gradle. A partire da Gradle 7.0, il monitoraggio dei file è abilitato per impostazione predefinita. Se utilizzi macOS e il progetto è salvato in /System/Volumes/Data, il monitoraggio dei file di Gradle non monitora correttamente le modifiche ai file. Di conseguenza, il sistema di compilazione non vedrà alcuna modifica ai file e non aggiornerà gli APK. Il codice di deployment incrementale non farà nulla perché lo stato dell'APK locale è lo stesso del dispositivo.

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

HAXM dell'emulatore Android 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 una procedura più complessa per installare 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 indica che è stato bloccato il caricamento del software di sistema dello 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 a 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 Esegui per eseguire nuovamente il deployment dell'app e visualizzare le modifiche.

Problema nel runtime Android che genera un errore

Se utilizzi un dispositivo con Android 8.0 o 8.1, potresti visualizzare messaggi "VERIFICATION_ERROR" quando provi ad applicare determinati tipi di modifiche (in particolare se utilizzi Kotlin). Questo messaggio è causato da un problema con il runtime Android risolto in Android 9.0 e versioni successive. Anche se il problema fa sì che l'applicazione delle modifiche non vada a buon fine, puoi comunque eseguire nuovamenteIcona Esegui la tua 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.

I test JUnit non trovano le risorse mancanti nel classpath quando vengono eseguiti da Android Studio

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

Questo problema si verifica perché, a partire da IntelliJ 13, è richiesta solo una singola cartella come percorso di classe. Il builder di IntelliJ copia tutte le risorse nella cartella di compilazione, ma Gradle non le copia.

  • Soluzione alternativa 1: esegui l'attività Gradle check dall'IDE anziché eseguire un test unitario.
  • Soluzione alternativa 2: aggiorna lo script di compilazione per copiare manualmente le risorse nella cartella di compilazione. Per ulteriori informazioni, consulta commento 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 Make consapevole di Gradle. 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 di compilazione 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 Configura > Immagini predefinite del progetto > Configurazioni di esecuzione e modifica la configurazione JUnit in modo da includere solo il passaggio di compilazione consapevole di Gradle.

Alcune configurazioni di esecuzione del 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. Nello specifico, 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 di JUnit (che hanno un'icona senza l'Android verde) non si applicano ai test di strumentazione, che non possono essere eseguiti sulla JVM locale.
Android Studio ricorda 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à di eseguire l'esecuzione 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

Quando 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 i breakpoint Java prima di avviare una sessione di debug o mentre l'app è in pausa su un breakpoint Java. Per ulteriori informazioni, consulta il problema 229949.

Uscire dal debugger nativo

Quando utilizzi il debugger Auto o Dual per eseguire il debug del codice Java e nativo, se esegui il passaggio a una funzione nativa da il 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 Passa ) e vuoi tornare al codice Java, fai clic su Ripristina programma (anziché su Esegui il passaggio indietro o Esegui il passaggio avanti ). Il processo dell'app sarà ancora in pausa, quindi fai clic su Ripristina programma nella scheda your-module-java per riprenderlo. Per ulteriori informazioni, 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 smettere di rispondere durante il caricamento delle librerie dal dispositivo Android. Questo problema è un problema ostinato che si verifica 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 "Il processo di debugger è terminato con il codice di uscita 127"

Questo errore si verifica sulle piattaforme basate su Linux durante l'avvio del 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: la profilazione non è disponibile durante l'avvio dell'app

Al momento, lo strumento di profilazione della memoria nativa non è disponibile durante l'avvio dell'app. Questa opzione sarà disponibile in una release futura.

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

Errori di timeout in Profiler della CPU

Potresti riscontrare errori "Impossibile interrompere la registrazione" nel profiler della CPU di Android Studio quando selezioni le configurazioni Sample Java Methods o Trace Java Methods. Spesso si tratta di errori di timeout, in particolare 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ù che i metodi campionati e le registrazioni più lunghe rispetto a quelle più brevi. Come soluzione temporanea, può essere utile provare registrazioni più brevi per vedere se l'errore scompare.

Se riscontri problemi di timeout con il Profiler, invia un bug che includa 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 "Failed to connect port" 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 Strumenti > SDK Manager o su SDK Manager nella barra degli strumenti.

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

  3. Fai clic su Applica o OK.

Il plug-in impedisce il funzionamento della finestra Output compilazione

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

L'ordine di installazione impedisce l'avvio

L'installazione di una versione più recente di Android Studio prima di una precedente potrebbe impedire il lancio della versione precedente. 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 questi casi, devi cancellare 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 Scrivi

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

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

Se utilizzi un layout di tastiera diverso dall'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 tasti Logcat in conflitto. Per modificare le mappature dei tasti di Logcat in Android Studio, vai a Android Studio > Impostazioni > Mappatura dei tasti e cerca Logcat nell'elenco delle mappature dei tasti. Per ulteriori informazioni, consulta il problema 263475910.

Questo problema verrà risolto con la rimozione della scorciatoia Logcat nella patch 1 di Electric Eel di Android Studio.

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 delle librerie di funzionalità dinamiche sono sottoposte a controllo lint

Quando esegui lint con checkDependencies = true da un modulo dell'app, le dipendenze delle librerie di funzionalità dinamiche non vengono controllate, a meno che non siano anche dipendenze dell'app (issue #191977888). Come soluzione alternativa, l'attività di lint può essere eseguita su queste librerie.

Firma del file denominato con caratteri di a capo

La firma JAR (schema v1) non supporta i nomi di file contenenti caratteri di a capo (issue #63885809).

La modifica delle uscite delle varianti in fase di compilazione potrebbe non funzionare

L'utilizzo dell'API Variant per manipolare le uscite delle varianti non è supportato dal nuovo plug-in. Funziona ancora per attività semplici, come la modifica del nome dell'APK durante il tempo 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 richiedono 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 contenente tutti i manifest generati. Puoi quindi trovare un manifest e applicare la tua logica. L'esempio riportato di seguito modifica dinamicamente il codice di versione nel file 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 di AIDL per 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 origine AIDL per varianti di build specifiche. Puoi comunque utilizzare gli altri set di sorgenti AIDL, inclusi quelli di main/, i tipi di build, i flavor di prodotto e le combinazioni di flavor di prodotto. Se devi utilizzare i set di origine AIDL specifici per la variante, 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 riscontrato uno di questi problemi, devi aggiornare Android Studio all'ultima versione stabile o di anteprima.

Risolto in Android Studio 2021.1.1

  • Output lint mancante: non viene stampato alcun output di testo del lint in stdout quando l'attività di lint è UP-TO-DATE (issue #191897708). Corretto in AGP 7.1.0-alpha05.
  • Problemi con i test di unità di un progetto di app che utilizza il plug-in Hilt: Il percorso di classe del test di unità contiene le classi di app non instrumentate, il che significa che Hilt non esegue l'instrumentazione delle classi di app per gestire l'iniezione di dipendenza quando vengono eseguiti i test di unità (issue #213534628). Risolto in AGP 7.1.1.

Risolto in Android Studio 2020.3.1

  • Eccezione di lint nei progetti Kotlin: i progetti Kotlin che impostano checkDependencies = true potrebbero riscontrare eccezioni o errori relativi a puntatori null (issue #158777858).

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

Risolto in Android Studio 4.1

  • Riavvia per applicare le impostazioni di memoria dalla 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 manifest con stringhe di autorizzazione personalizzate non viene più generata per impostazione predefinita: se vuoi generare la classe, imposta android.generateManifestClass = true.

Risolto in Android Studio 3.6

  • Errore di installazione dell'APK su LineageOS: il deployment dell'app sui 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.

Risolto in Android Studio 3.5.2

  • Stile di codice XML non valido: durante la modifica del codice XML, l'IDE ha applicato uno stile di codice errato quando hai selezionato Codice > Riformatta il codice dalla barra del menu.

Risolto in Android Studio 3.3.1

  • Errori di esaurimento della memoria durante la scansione di progetti basati su C++: quando Gradle esegue la scansione di un progetto con codice C++ in più posizioni sulla stessa unità, la scansione include tutte le directory sotto la prima directory comune. La scansione di un numero elevato di directory e file può causare errori di esaurimento della memoria.

    Per ulteriori informazioni su questo problema, consulta il bug associato.