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

In questa pagina vengono monitorati i problemi noti relativi a Android Studio Rilascio di funzionalità Koala e plug-in Android Gradle 8.6.0. Se si verifica un problema che non è già stato 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 versioni, scarica e installa Anteprima di Android Studio.

Problemi noti con Android Studio

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

Nella finestra dell'assistente di Firebase viene visualizzato un messaggio di errore

Se nella finestra di Firebase Assistant (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 vista con Layout Inspector

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

Non è possibile ispezionare tutti i nodi di scrittura utilizzando Layout Inspector

Se noti che non tutti i nodi Compose sono ispezionabili quando utilizzi Controllo layout, probabilmente a causa di 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 in alto.

Errore durante il rendering dell'anteprima di Componi

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

Se nel riquadro dei problemi visualizzi java.lang.NoSuchFieldError: view_tree_lifecycle_owner, assicurati di includere una dipendenza debugImplementation da androidx.lifecycle:lifecycle-runtime nel tuo 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 androidx.customview:customview-poolingcontainer nel modulo.

Errore durante l'utilizzo di password diverse per chiavi e archivi chiavi

A partire dalla versione 4.2, Android Studio ora funziona su JDK 11. Questo aggiornamento causa un cambiamento del comportamento di base relativo alle chiavi di firma.

Quando vai a Crea > Genera Bundle / APK firmato e tentare 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 comportare 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 viene avviato dopo l'installazione della versione 4.2

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

Per aggirare il problema, ti consigliamo di aggiungere commenti alle opzioni personalizzate in .vmoptions (utilizzando il carattere "#"). Il file .vmoptions può essere che si trovano 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 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 Database Inspector potrebbero arrestarsi in modo anomalo quando vengono eseguite su Android 11 emulatore, con un errore come il seguente che compare 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 entro il giorno vai a Strumenti > SDK Manager. 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 un errore La configurazione di Android Studio importata da una versione precedente di Android Studio o un plug-in incompatibile. Come soluzione alternativa, prova a eliminare (o rinominare, ai fini del backup), la directory di seguito, a seconda della versione di Android Studio e il sistema operativo e riavvia Android Studio. Android verrà reimpostato Ripristina lo stato predefinito di Studio, rimuovendo 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 versioni canary e beta di Android Il valore di Studio è PreviewX.Y anziché X.Y per la <version>. Ad esempio, Android Le build canary di Studio 4.1 utilizzano AndroidStudioPreview4.1 anziché Directory AndroidStudio4.1 utilizzata per i candidati alle release e il livello stabile release.

Problema di compilazione nei progetti multipiattaforma Kotlin

Nel codice MPP Kotlin potrebbero verificarsi errori di compilazione a causa della mancanza di simboli. Il problema dovrebbe risolversi aggiornando il plug-in Kotlin alla versione 1.4.

Conflitti di mappatura dei tasti su Linux

Su Linux, alcune scorciatoie da tastiera sono in conflitto con la tastiera Linux predefinita scorciatoie da tastiera e quelle di gestori di finestre molto 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. Verso il lavoro per risolvere questo problema:

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

Modifica del codice

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

Inserimento da tastiera bloccato: "iBus" problemi su Linux

Esistono alcuni tipi di dati interazioni 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 da una sincronizzazione mancante tra iBus e XLib + AWT ed è già stata segnalata a monte a JetBrains e iBus. Esistono tre soluzioni alternative attuali per questo problema:

  • Soluzione 1: forza iBus in modalità sincrona. Prima di avviare Android Studio, esegui il comando riportato di seguito nella riga di comando:
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Soluzione alternativa 2: disattiva iBus Input 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 solo i metodi di inserimento per Android Studio, non per altre applicazioni in esecuzione. Tieni presente che se riavvii daemon mentre è in esecuzione Android Studio (ad esempio, eseguendo ibus-daemon -rd), disabiliti in modo efficace i metodi di immissione per tutti altre applicazioni e potrebbe causare l'arresto anomalo della JVM di Android Studio con errore di segmentazione.
  • Soluzione 3: ricontrolla le associazioni di scorciatoie per assicurarti che La scorciatoia di immissione successiva non è impostata su Ctrl + Barra spaziatrice, poiché è a sua volta la scorciatoia per il completamento del codice in Android Studio. Ubuntu 14.04 (Trusty) rende Super+Barra spaziatrice la scorciatoia predefinita, ma le impostazioni della barra versioni potrebbero essere ancora disponibili. 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 + Barra spaziatrice, cambialo in Super + Barra spaziatrice o un'altra scorciatoia di la tua scelta.

Configurazione progetto

Questa sezione descrive i problemi noti relativi alla configurazione del progetto e a Gradle sincronizzare.

Sincronizzazione Gradle non riuscita: tubo rotto

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

  • Soluzione 1: su Linux, inserisci il seguente codice nel file ~/.profile oppure ~/.bash_profile:
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Soluzione 2: in vmoptions di Android Studio file, cambia la riga -Djava.net.preferIPv4Addresses=true in -Djava.net.preferIPv6Addresses=true Per ulteriori informazioni, consulta Utente IPv6 di rete Guida.

"peer non autenticato" errori di sincronizzazione Gradle 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 richiesta funziona, quindi per connetterti tramite il proxy potresti dover utilizza 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 il 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 della tua app in un dispositivo.

[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 interessa Plug-in Android per Gradle versione 7.0 e successive perché richiede Gradle 7.0 e versioni successive. A partire da Gradle 7.0, la visualizzazione dei file è abilitata per impostazione predefinita. Se stai lavorando su Mac OS e il progetto è salvato in /System/Volumes/Data, la visione dei file Gradle non monitorerà correttamente le modifiche ai file. In questo modo, il sistema di compilazione non rileverà le modifiche ai file pertanto non aggiornare gli APK. Il codice di deployment incrementale niente perché lo stato dell'APK locale è lo stesso di quello sul dispositivo.

Per aggirare il problema, devi spostare la directory del progetto nell'interfaccia utente ossia sotto /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.

Emulatore Android HAXM su macOS High Sierra

Android Emulator on macOS High Sierra (10.13) richiede HAXM 6.2.1+ per la migliore compatibilità e stabilità con macOS. Tuttavia, macOS 10.13 ha una maggiore un processo coinvolto per l'installazione di estensioni kernel come HAXM. Devi consentire manualmente l'installazione dell'estensione del kernel come segue:

  1. Innanzitutto, prova a installare l'ultima versione di HAXM dal Gestore SDK.
  2. In MacOS, vai a Preferenze di Sistema > Sicurezza e privacy.
  3. Se viene visualizzato un avviso che ti informa che software di sistema dello sviluppatore "Intel Corporation App" È stato bloccato il caricamento, 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.

Nome della nuova app non applicato

Se rinomini l'app e poi provi ad applicare la modifica, il nome aggiornato potrebbe non saranno visibili. Per aggirare il problema, fai clic su Esegui. Icona Esegui eseguire nuovamente il deployment dell'app e vedere le modifiche apportate.

Un problema in Android Runtime genera un errore

Se utilizzi un dispositivo con Android 8.0 o 8.1, potresti riscontrare "ERRORE_VERIFICA" quando provi ad applicare determinati tipi di modifiche. (soprattutto se usi Kotlin). Questo messaggio è causato da un problema relativo Android Runtime corretto in Android 9.0 e versioni successive. Sebbene il problema se l'applicazione delle modifiche non riesce, puoi comunque fare clic su Esegui Icona Esegui l'app per vedere le modifiche. Tuttavia, ti consigliamo di eseguire l'upgrade del dispositivo ad Android 9.0 o versioni successive.

Debug e test

In questa sezione vengono descritti i problemi noti relativi al debug e ai test della tua app.

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

Se nei moduli Java sono presenti cartelle di risorse specifiche, non sarà possibile trovare risorse durante l'esecuzione di test dall'IDE. Esecuzione dei test usare Gradle dalla riga di comando. Esecuzione di Gradle check dell'ambiente IDE funzionerà anch'essa. Visualizza il problema 64887 per ulteriori informazioni i dettagli.

Questo problema si verifica perché a partire da IntelliJ 13, che richiede di avere solo in una singola cartella. Il builder di IntelliJ copia tutte le risorse nella cartella di compilazione, ma Gradle non le copia.

  • Soluzione 1: esegui l'attività Gradle check dall'IDE anziché eseguendo un test delle unità.
  • Soluzione 2: aggiorna lo script di build per copiare manualmente le risorse in nella cartella di build. Per ulteriori informazioni, consulta commento 13.

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

Quando crei un nuovo progetto, potrebbe essere creata la configurazione modello JUnit con due "Prima del lancio" passaggi: Make e Gradle-aware Make. Questa configurazione viene poi propagato 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. Quindi fai clic su Configura > Impostazioni predefinite del progetto > Esegui configurazioni e modifica la JUnit per includere solo il passaggio di creazione sensibile a Gradle.

Alcune configurazioni di esecuzione di test non funzionano

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

  • Le configurazioni di esecuzione Gradle (che hanno un logo Gradle come icona) al lavoro.
  • Configurazioni di esecuzione JUnit (con un'icona senza il simbolo Android verde) non si applicano ai test di strumentazione, che non possono essere eseguiti sulla JVM locale.
di Gemini Advanced. Android Studio ricorda anche la configurazione di esecuzione creata contesto (ad esempio, fare clic con il tasto destro del mouse su una classe o un metodo specifico) e non che in futuro vengano eseguite con una configurazione diversa. Per risolvere il problema, fai clic su Esegui > Modifica configurazioni e rimuovi quelle create in modo errato configurazioni.

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

Mentre l'app è in pausa in un punto di interruzione nel browser nativo i debugger Auto e Doppio potrebbero non riconoscere immediatamente nuovi punti di interruzione Java che hai impostato. Per evitare questo problema, aggiungi punti di interruzione Java prima di avviare una sessione di debug o mentre l'app è in pausa su un computer Java punto di interruzione. 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 passi a una funzione nativa da il codice Java (ad esempio, il debugger mette in pausa l'esecuzione in una riga Codice Java che chiama una funzione nativa e fai clic su Accedi ) e vuoi tornare al tuo codice Java, fai clic su Riprendi il programma (anziché Esci o Passa ). La tua app sarà ancora in pausa, quindi fai clic su Riprendi Programma nel file your-module-java Tab per ripristinarla. 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 non rispondere più durante il caricamento dal dispositivo Android. Si tratta di un problema fisso che continua anche se arresti e riavvii il debugger. Per risolvere il problema, svuota la cache LLDB in $USER/.lldb/module-cache/.

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

Questo errore si verifica sulle piattaforme basate su Linux quando viene avviato il debugger nativo. Indica che una delle librerie richieste dall'ambiente nativo il debugger non è installato nel 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. Questo sarà disponibile in una versione futura.

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

Errori di timeout in CPU Profiler

Potresti visualizzare il messaggio "Interruzione registrazione non riuscita" nella CPU di Android Studio Profiler quando selezioni Metodi Java di esempio o Metodi Java di Trace configurazioni. 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 ad influenzare i metodi tracciati più che quelli campionati. registrazioni più lunghe di quelle più brevi. Come soluzione alternativa 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 gli Strumenti della piattaforma 29.0.3, il debug nativo e Android Studio I profiler potrebbero non funzionare correttamente e potresti vedere "AdbCommandRifiutaeccezione" o "Impossibile connettere la porta" in idea.log file quando selezioni Guida > Mostra log. Upgrade degli strumenti della piattaforma a La versione 29.0.4 o successiva risolve entrambi i problemi.

Per eseguire l'upgrade degli strumenti di piattaforma, segui questi passaggi:

  1. Apri SDK Manager da Android Studio facendo clic su 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-Strumenti, quindi mostra un segno di spunta. Un'icona di download dovrebbe essere visualizzato nella colonna a sinistra.
  3. Fai clic su Applica o OK.

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

Il 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 c'è nessun output stampato (problema n. 204791544).

L'ordine di installazione impedisce l'avvio

Se installi una versione più recente di Android Studio prima che una versione precedente potrebbe impedire l'avvio della versione precedente. Ad esempio, se installi prima versione canary di Android Studio, quindi prova a installare e avviare la versione la versione stabile potrebbe non avviarsi. In questi casi, devi cancellare la cache per avviare la versione stabile (precedente). Su macOS, per cancellare svuotare la cache Library/ApplicationSupport/Google/AndroidStudioversion_number . Su Windows, per svuotare la cache utilizza Pulizia del disco.

Espresso Test Registratore non funziona con Compose

Espresso Test Recorder non funziona con i progetti che includono Compose. Creazione di test dell'interfaccia utente per i progetti che includono Compose, vedi Testare il layout di Compose.

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

Se utilizzi un layout di tastiera non inglese, una tastiera Logcat predefinita potrebbe essere in conflitto con il layout e impedirti di digitare determinati durante la modifica del testo in Android Studio. Per aggirare questo problema, elimina o rimappa la mappa dei tasti Logcat in conflitto. Per modificare le mappe dei tasti Logcat in Android Studio, vai ad Android Studio > Impostazioni > mappa dei tasti e cerca Logcat nell'elenco delle mappe 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 del plug-in Android per Gradle

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

Non tutte le dipendenze della libreria di funzionalità dinamiche sono controllate da 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 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 nomi di file contenenti carriage restituisce caratteri (problema n. 63885809).

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

L'utilizzo dell'API Variant per manipolare gli output delle varianti non funziona con il nuovo . Funziona comunque per attività semplici, come la modifica del nome dell'APK durante 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 delle varianti non vengono più create durante la fase di configurazione. Di conseguenza, il plug-in non conosce tutti i suoi output in anticipo, ma comporta anche tempi di configurazione 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.

Invece di chiamare manifestOutputFile() per ottenere il file manifest per ogni variante, puoi chiamare processManifest.manifestOutputDirectory() per restituire percorso della directory che contiene 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 AGP 7.3.0 AIDL e Kotlin 1.7.x

Usare AGP 7.3.0 con KAPT in Kotlin 1.7.x fa sì che i set di sorgenti AIDL per specifiche varianti di build da rimuovere. Puoi comunque usare l'altra origine AIDL set, inclusi quelli di main/, tipi di build, versioni dei prodotti e combinazioni di sapori dei prodotti. Se devi usare set di origini AIDL specifici della variante, continuare a usare Kotlin 1.6.21.

Problemi noti risolti

Questa sezione descrive i problemi noti che sono stati risolti in una release recente. Se se riscontri 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. Il testo lint non viene stampato in stdout quando l'attività lint è UP-TO-DATE (problema n. 191897708). Risolto 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).

Corretta in Android Studio 4.2

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

Corretta in Android Studio 4.1

  • Riavvia per applicare le impostazioni di memoria della versione precedente dell'IDE: dopo devi riavviare Android Studio per applicare delle impostazioni della memoria da una versione precedente dell'IDE.
  • La classe manifest con stringhe di autorizzazioni personalizzate non viene più generata default: se vuoi generare il corso, imposta android.generateManifestClass = true.

Risolto in Android Studio 3.6

  • Errore di installazione dell'APK su LineageOS: deployment dell'app sui dispositivi alcune versioni di LineageOS o CyanogenMod potrebbero 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 Eseguire un'installazione completa dell'app quando esegui il deployment dell'app ai dispositivi LineageOS o CyanogenMod, il che potrebbe comportare un deployment più lungo volte.

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

Corretta in Android Studio 3.3.1

  • Errori di memoria insufficiente durante l'analisi dei progetti basati su C++: durante l'analisi da Gradle un progetto che contiene codice C++ in più di una posizione sulla stessa unità, La scansione include tutte le directory sotto la prima directory comune. Ricerca in corso... un numero elevato di directory e file può causare errori di memoria insufficiente.

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