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:
- Apri la finestra Impostazioni facendo clic su File > Impostazioni
- Vai a Aspetto e comportamento > Aspetto.
- Seleziona Utilizza carattere personalizzato.
- Aumentare la dimensione dei caratteri.
- Nella finestra Impostazioni, vai a Editor > Carattere.
- Aumentare la dimensione dei caratteri.
- 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, eseguendoibus-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:
- Innanzitutto, prova a installare la versione più recente di HAXM da SDK Manager.
- In MacOS, vai a Preferenze di Sistema > Sicurezza e Privacy.
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 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 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.
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:
- Apri SDK Manager da Android Studio facendo clic su Strumenti > SDK Manager oppure su SDK Manager nella barra degli strumenti.
- 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 .
- 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.