Questa pagina monitora i problemi noti relativi ad Android Studio Narwhal e al plug-in Android per Gradle 8.11.0. Se riscontri un problema non ancora incluso qui, segnala un bug.
Esegui l'upgrade all'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 usufruire subito dei vantaggi delle prossime release, scarica e installa Android Studio Preview.
Problemi noti di Android Studio
Questa sezione descrive i problemi noti presenti nell'ultima versione stabile di Android Studio.
L'esecuzione della configurazione senza "Prima del lancio" di Gradle-aware Make genera un errore di deployment
Si è verificato un problema in Android Studio Ladybug Feature Drop Canary 9 che ha rimosso le informazioni di configurazione di esecuzione dai progetti aperti con questa versione. Se hai aperto il progetto con questa versione a un certo punto e l'esecuzione dell'app genera l'errore "loading build artifacts", verifica che la configurazione di esecuzione attiva abbia il passaggio "Gradle-aware Make" nella sezione "Prima del lancio". Per verificarlo, fai clic su Run/Debug Configurations > Edit Configurations (Esegui/Esegui debug delle configurazioni > Modifica configurazioni), fai clic sulla configurazione di esecuzione attiva e verifica che nella sezione "Before launch" (Prima del lancio) sia presente un passaggio "Gradle-aware Make" (Compilazione compatibile con Gradle). Purtroppo Android Studio non può risolvere automaticamente questo problema perché alcune configurazioni di esecuzione potrebbero essere state configurate intenzionalmente senza un passaggio "Gradle-aware Make".
"Applica modifiche e riavvia attività " non riavvia l'attività sui dispositivi o sugli 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 sta effettuando accertamenti in merito.
Nella finestra dell'assistente Firebase viene visualizzato un messaggio di errore
Se nella finestra dell'assistente Firebase (Strumenti > Firebase dal menu principale) viene visualizzato un messaggio di errore, invalida le cache e riavvia Android Studio per risolvere l'errore.
Impossibile isolare una visualizzazione utilizzando Layout Inspector
La possibilità di isolare una visualizzazione utilizzando lo strumento di ispezione del layout incorporato non è temporaneamente disponibile. Stiamo lavorando per risolvere il problema in una versione futura.
Non tutti i nodi Compose sono ispezionabili utilizzando Layout Inspector
Se noti che non tutti i nodi Compose sono ispezionabili quando utilizzi Layout Inspector, è probabile che ciò sia dovuto a un bug che è stato corretto nella versione 1.5.0-alpha04 di Compose. Se riscontri questo problema, assicurati di eseguire l'upgrade a Compose versione 1.5.0-alpha04 o successive.
Errore durante il rendering dell'anteprima di Composizione
A partire da Android Studio Chipmunk, se visualizzi
java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner
o
java.lang.ClassNotFoundException: androidx.savedstate.R$id
nel riquadro dei problemi,
assicurati di includere una dipendenza debugImplementation
da
androidx.lifecycle:lifecycle-viewmodel-savedstate
nel tuo modulo.
Se visualizzi java.lang.NoSuchFieldError: view_tree_lifecycle_owner
nel
pannello dei problemi, assicurati di includere una dipendenza debugImplementation
da
androidx.lifecycle:lifecycle-runtime
nel tuo modulo.
Se nel riquadro dei problemi visualizzi java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer
o
java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener
, assicurati di includere una dipendenza debugImplementation
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 viene eseguito su JDK 11. Questo aggiornamento comporta una modifica del comportamento sottostante relativa alle chiavi di firma.
Quando vai a Build > Generate Signed Bundle / APK e tenti di configurare la firma dell'app per un app bundle o un APK, l'inserimento di password diverse per la chiave e il keystore potrebbe generare il seguente errore:
Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores
Per risolvere questo 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 precedenti .vmoptions e di sanificarli per funzionare 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 può essere trovato 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, vedi Studio non si avvia dopo l'upgrade di seguito.
Le app che utilizzano Database Inspector si arrestano in modo anomalo sull'emulatore Android 11
Le app che utilizzano Database Inspector potrebbero arrestarsi in modo anomalo durante l'esecuzione sull'emulatore Android 11, con un errore simile al seguente visualizzato in logcat:
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
Per risolvere il problema, esegui l'upgrade dell'emulatore Android 11 alla versione 9 o successive andando su Strumenti > SDK Manager. Nella scheda Piattaforme SDK, seleziona la casella Mostra dettagli pacchetto e scegli la revisione 9 o successive 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 riavvia Android Studio. Android Studio verrà ripristinato allo stato predefinito e tutti i plug-in di terze parti verranno rimossi.
Per Android Studio 4.1 e versioni successive:
Windows:
%APPDATA%\Google\AndroidStudio<version>
Esempio:C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1
macOS:
~/Library/Application Support/Google/AndroidStudio<version>
Esempio:~/Library/Application Support/Google/AndroidStudio4.1
Linux:
~/.config/Google/AndroidStudio<version>
e~/.local/share/Google/AndroidStudio<version>
Esempio:~/.config/Google/AndroidStudio4.1
e~/.local/share/Google/AndroidStudio4.1
Per Android Studio 4.0 e versioni precedenti:
Windows:
%HOMEPATH%\.AndroidStudio<version>\config
Esempio:C:\Users\your_user_name\.AndroidStudio3.6\config
macOS:
~/Library/Preferences/AndroidStudio<version>
Esempio:~/Library/Preferences/AndroidStudio3.6
Linux:
~/.AndroidStudio<version>/config
Esempio:~/.AndroidStudio3.6/config
Tieni presente che la directory di configurazione per le versioni Canary e beta di Android
Studio è PreviewX.Y
anziché X.Y
per
<version>
. Ad esempio, le build Canary di Android Studio 4.1 utilizzano AndroidStudioPreview4.1
anziché la directory AndroidStudio4.1
utilizzata per le versioni candidate e 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 mapping dei tasti su Linux
Su Linux, alcune scorciatoie da tastiera sono in conflitto con quelle predefinite di Linux e con quelle dei gestori di finestre più diffusi, come KDE e GNOME. Queste scorciatoie da tastiera in conflitto potrebbero non funzionare come previsto in Android Studio.
Per ulteriori informazioni su questo problema (incluse le potenziali soluzioni alternative), consulta Bug Tracker di IntelliJ.
Testo dell'interfaccia utente piccolo su ChromeOS
Su ChromeOS, il testo potrebbe apparire molto più piccolo rispetto alle versioni precedenti. Per risolvere il problema:
- Apri la finestra Impostazioni facendo clic su File > Impostazioni.
- Vai a Aspetto e comportamento > Aspetto.
- Seleziona Usa carattere personalizzato.
- Aumentare le dimensioni del carattere.
- Nella finestra Impostazioni, vai a Editor > Carattere.
- Aumentare le dimensioni del carattere.
- Fai clic su OK.
Modifica del codice
Questa sezione descrive i problemi noti relativi all'editor di codice.
Input da tastiera bloccato: problemi di "iBus" su Linux
Sono note alcune 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 è causato da una sincronizzazione mancante tra iBus e XLib + AWT ed è già stato segnalato 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 questo comando nella riga di comando:
$ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
- Soluzione alternativa 2: disattiva l'input iBus in Android Studio. Per disattivare l'input iBus
solo per Android Studio, esegui il seguente comando nella riga di comando:
Questa soluzione alternativa disattiva solo i metodi di input per Android Studio, non altre applicazioni che potresti eseguire. Tieni presente che se riavvii il daemon mentre è in esecuzione Android Studio (ad esempio eseguendo$ XMODIFIERS= ./bin/studio.sh
ibus-daemon -rd
), disattivi i metodi di input per tutte le altre applicazioni e potresti anche causare l'arresto anomalo della JVM di Android Studio con un errore di segmentazione. - Soluzione alternativa 3: controlla attentamente le associazioni di scorciatoie per assicurarti che la
scorciatoia per l'input successivo non sia impostata su Control+Spazio, poiché questa è anche
la scorciatoia per il completamento del codice in Android Studio. Ubuntu 14.04 (Trusty)
imposta Super+Spazio come scorciatoia predefinita, ma le impostazioni delle versioni precedenti
potrebbero essere ancora presenti. Per controllare le associazioni di scorciatoie, esegui
ibus-setup
sulla riga di comando per aprire la finestra delle preferenze di IBus. Nella sezione Scorciatoie da tastiera, seleziona Metodo di immissione successivo. Se è impostato su Control+Spazio, modificalo in Super+Spazio o in un'altra scorciatoia di tua scelta.
Configurazione progetto
Questa sezione descrive i problemi noti relativi alla configurazione del progetto e alla sincronizzazione di Gradle.
Sincronizzazione Gradle non riuscita: pipe interrotta
Il problema è che il daemon Gradle sta tentando di utilizzare IPv4 anziché IPv6.
- Soluzione 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,
modifica la riga
-Djava.net.preferIPv4Addresses=true
in-Djava.net.preferIPv6Addresses=true
Per ulteriori informazioni, consulta la guida per l'utente Networking IPv6.
Errori "peer not authenticated" (peer non autenticato) durante la sincronizzazione di 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
nel seguente modo:
- 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. Esiste un
problema noto
che interessa gli utenti Ubuntu e che genera un
/etc/ssl/certs/java/cacerts
vuoto. Per risolvere il problema, esegui il seguente 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 con il monitoraggio dei file Gradle nei progetti salvati in /System/Volumes/Data
Il problema 18149 di Gradle interessa
le versioni del plug-in Android per Gradle 7.0 e successive perché richiedono Gradle versione 7.0 e successive. A partire da Gradle 7.0, il monitoraggio dei file è attivo per impostazione predefinita.
Se lavori su Mac OS e il tuo progetto è salvato in
/System/Volumes/Data
, il monitoraggio dei file Gradle non terrà traccia correttamente delle modifiche ai file.
In questo modo, il sistema di compilazione non rileverà modifiche 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 questo problema, sposta la directory del progetto nella directory utente, ovvero in /Users/username
. Il sistema di compilazione verrà
avvisato correttamente delle modifiche ai file tramite il monitoraggio dei file Gradle e le modifiche
incrementali verranno applicate correttamente.
Android Emulator HAXM su macOS High Sierra
L'emulatore Android su macOS High Sierra (10.13) richiede HAXM 6.2.1+ per una migliore compatibilità e stabilità con macOS. Tuttavia, macOS 10.13 prevede una procedura più complessa per installare le estensioni del kernel come HAXM. Devi consentire manualmente l'installazione dell'estensione del kernel nel seguente modo:
- Innanzitutto, prova a installare l'ultima versione di HAXM da SDK Manager.
- In macOS, vai a Preferenze di Sistema > Sicurezza e Privacy.
Se vedi 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 ad Applica modifiche.
Il nuovo nome dell'app non è stato 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.
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
(soprattutto se utilizzi Kotlin). Questo messaggio è causato da un problema con
Android Runtime, risolto in Android 9.0 e versioni successive. Sebbene il problema
impedisca l'applicazione delle modifiche, puoi comunque eseguire
di nuovo 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 della tua app.
I test JUnit non trovano le risorse nel classpath quando vengono eseguiti da Android Studio
Se hai cartelle di risorse specifiche nei moduli Java, queste
non verranno trovate durante l'esecuzione dei test dall'IDE. L'esecuzione dei test
utilizzando Gradle dalla riga di comando funzionerà. Anche l'esecuzione dell'attività Gradle check
dall'IDE funziona. Per maggiori dettagli, consulta il problema
64887.
Questo problema si verifica perché a partire da IntelliJ 13, che richiede di avere una sola cartella come classpath. Il builder di IntelliJ copia tutte le risorse nella cartella di build, ma Gradle non le copia.
- Soluzione alternativa 1: esegui l'attività Gradle
check
dall'IDE anziché eseguire un test delle unità. - Soluzione 2: aggiorna lo script di build per copiare manualmente le risorse nella cartella di build. Per saperne di più, consulta il commento n. 13.
L'esecuzione dei test JUnit potrebbe compilare il codice due volte
Quando crei un nuovo progetto, la configurazione del modello JUnit potrebbe essere creata con due passaggi "Prima del lancio": Make e Make compatibile con Gradle. Questa configurazione viene quindi 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 che includa solo il passaggio di compilazione compatibile con Gradle.
- Per risolvere il problema per tutti i progetti futuri, fai clic su File > Chiudi progetto. Dovresti visualizzare la schermata di benvenuto. Poi fai clic su Configura > Impostazioni predefinite progetto > Configurazioni di esecuzione e modifica la configurazione JUnit in modo da includere solo il passaggio di compilazione compatibile con 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 JUnit (che hanno un'icona senza il verde di Android) 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 Automatico e Doppio potrebbero non riconoscere immediatamente i nuovi punti di interruzione Java che hai impostato. Per evitare questo problema, aggiungi i punti di interruzione Java prima di avviare una sessione di debug o mentre l'app è in pausa su un punto di interruzione Java. Per ulteriori informazioni, vedi il problema 229949.
Uscire dal debugger nativo
Quando utilizzi il debugger Automatico o Doppio per
eseguire il debug del codice Java e nativo, se entri in una funzione nativa dal
tuo codice Java (ad esempio, il debugger mette in pausa l'esecuzione in una riga del tuo
codice Java che chiama una funzione nativa e fai clic su Entra
) e vuoi tornare al tuo codice Java, fai clic su
Riprendi programma
(anziché su Esci
o Salta
). Il processo dell'app verrà comunque messo in pausa, quindi fai clic su Riprendi
programma
nella scheda your-module-java
per riprenderlo. Per ulteriori informazioni, vedi 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 persistente che continua
a verificarsi anche se interrompi e riavvii il debugger. Per risolvere il problema,
elimina la cache LLDB in $USER/.lldb/module-cache/
.
Arresto anomalo del debugger nativo con il messaggio "Debugger process finished with exit code 127"
Questo errore si verifica sulle piattaforme basate su Linux all'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 passare 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 sono già state aggiornate a ncurses6
.
Profiler
Questa sezione descrive i problemi noti relativi ai Profiler.
Profilatore della memoria nativa: profilazione non disponibile durante l'avvio dell'app
Al momento, il Profiler di memoria nativa non è disponibile durante l'avvio dell'app. Questa opzione sarà disponibile in una versione futura.
Come soluzione alternativa, puoi utilizzare lo strumento di profilazione a riga di comando autonomo Perfetto per acquisire i profili di avvio.
Errori di timeout in CPU Profiler
Potresti riscontrare errori "Impossibile interrompere la registrazione" nel Profiler CPU di Android Studio quando selezioni le configurazioni Campiona metodi Java o Traccia metodi Java. Spesso si tratta di errori di timeout, soprattutto se nel file idea.log
viene visualizzato il seguente messaggio di errore:
Wait for ART trace file timed out
Gli errori di timeout tendono a interessare maggiormente i metodi tracciati rispetto a quelli campionati e le registrazioni più lunghe rispetto a quelle più brevi. Come soluzione alternativa temporanea, può essere utile provare registrazioni più brevi per verificare se l'errore scompare.
Se riscontri problemi di timeout con Profiler, segnala 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'aggiornamento di Platform Tools alla versione
29.0.4 o successive risolve entrambi i problemi.
Per eseguire l'upgrade degli strumenti della piattaforma:
- Apri SDK Manager da Android Studio facendo clic su Strumenti >
SDK Manager o su SDK Manager
nella barra degli strumenti.
- Fai clic sulla casella di controllo accanto a Android SDK
Platform-Tools in modo che venga visualizzato un segno di spunta. Nella colonna di sinistra dovrebbe essere visualizzata un'icona di download
.
- Fai clic su Applica o Ok.
Il plug-in impedisce il funzionamento della finestra Output di compilazione
L'utilizzo del plug-in CMake simple highlighter impedisce la visualizzazione dei contenuti nella finestra Output di compilazione. 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 della versione precedente. Ad esempio, se prima installi la versione canary di Android Studio e poi provi a installare e avviare la versione stabile, quest'ultima potrebbe non avviarsi. In casi come questo, devi
svuotare la cache per avviare la versione stabile (precedente). Su macOS, per svuotare
la cache, elimina la
directory Library/ApplicationSupport/Google/AndroidStudioversion_number
. Su Windows, per svuotare la cache utilizza
Pulizia disco.
Espresso Test Recorder non funziona con Compose
Espresso Test Recorder non funziona con i progetti che includono Compose. Per creare test UI per progetti che includono Compose, consulta Testare il layout di Compose.
Il conflitto di scorciatoie Logcat con i layout di tastiera non inglesi
Se utilizzi un layout di tastiera non inglese, una scorciatoia da tastiera Logcat predefinita potrebbe entrare in conflitto con il layout e impedirti di digitare determinati caratteri durante la modifica del testo in Android Studio. Per aggirare il problema,
elimina o rimappa la mappatura tasti Logcat in conflitto. Per modificare le mappature dei tasti di Logcat in
Android Studio, vai a Android Studio > Impostazioni > Mappatura tasti e cerca
Logcat
nell'elenco delle mappature dei tasti. Per ulteriori informazioni, vedi
il problema n. 263475910.
Questo problema verrà risolto con la rimozione della scorciatoia Logcat in Android Studio Electric Eel Patch 1.
Problemi noti del plug-in Android per Gradle
Questa sezione descrive i problemi noti presenti nell'ultima versione stabile del plug-in Android per Gradle.
Non tutte le dipendenze della libreria delle funzionalità dinamiche vengono controllate con Lint
Quando esegui lint con checkDependencies = true
da un modulo dell'app,
le dipendenze della libreria di funzionalità dinamiche non vengono controllate a meno che non siano anche dipendenze dell'app (problema n. 191977888).
Per risolvere il problema, è possibile eseguire l'attività di lint su queste librerie.
Firma del file denominato con caratteri di ritorno a capo
La firma JAR (schema v1) non supporta i nomi file contenenti caratteri di ritorno a capo (problema n. 63885809).
La modifica degli output delle varianti in fase di compilazione potrebbe non funzionare
L'utilizzo dell'API Variant per manipolare gli output delle varianti non funziona con il nuovo plug-in. Funziona ancora per attività semplici, come la modifica del nome dell'APK durante la 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ù complicate che prevedono l'accesso agli oggetti outputFile
non funzionano più. Questo perché le attività specifiche per le varianti non vengono più create
durante la fase di configurazione. Di conseguenza, il plug-in non conosce
in anticipo tutti i suoi output, ma i tempi di configurazione sono più rapidi.
manifestOutputFile non è più disponibile
Il metodo processManifest.manifestOutputFile()
non è più disponibile e quando lo chiami viene visualizzato il seguente errore:
A problem occurred configuring project ':myapp'. Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest' of type com.android.build.gradle.tasks.ProcessManifest.
Anziché chiamare manifestOutputFile()
per ottenere il file manifest per ogni
variante, puoi chiamare processManifest.manifestOutputDirectory()
per restituire il
percorso della directory che contiene tutti i manifest generati. Puoi quindi
individuare un manifest e applicarvi la tua logica. L'esempio seguente modifica
dinamicamente il codice 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 di AIDL di AGP 7.3.0 e Kotlin 1.7.x
L'utilizzo di AGP 7.3.0 con KAPT in Kotlin 1.7.x comporta la rimozione dei set di origini AIDL per varianti di build specifiche. Puoi comunque utilizzare gli altri set di origini AIDL, inclusi quelli di main/
, i tipi di build, le varianti di prodotto e le combinazioni di varianti di prodotto. Se devi utilizzare i set di origini AIDL specifici della 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 riscontri uno di questi problemi, devi aggiornare Android Studio all'ultima versione stabile o di anteprima.
Corretto in Android Studio 2021.1.1
- Output lint mancante: non viene stampato alcun output di testo lint in
stdout
quando l'attività lint èUP-TO-DATE
(problema n. 191897708). Corretto 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 del test delle unità contiene le classi dell'app non strumentate, il che significa che Hilt non strumenta le classi dell'app per gestire l'inserimento delle dipendenze durante l'esecuzione dei test delle unità (problema n. 213534628). Corretto 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 errori o eccezioni di puntatore nullo (problema n. 158777858).
Corretto in Android Studio 4.2
- Blocco dell'IDE su macOS Big Sur: Android Studio 4.1 potrebbe bloccarsi quando apri una finestra di dialogo.
Corretto in Android Studio 4.1
- Riavvia per applicare le impostazioni di memoria della versione precedente dell'IDE: dopo l'aggiornamento di Android Studio, devi riavviarlo per applicare le impostazioni di memoria di cui è stata eseguita la migrazione da una versione precedente dell'IDE.
- La classe manifest con stringhe di autorizzazione personalizzate non viene più generata per impostazione predefinita: se vuoi generare la classe, imposta
android.generateManifestClass = true
.
Corretto in Android Studio 3.6
Errore di installazione dell'APK su LineageOS: il deployment dell'app sui 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 la implementi su dispositivi LineageOS o CyanogenMod, il che potrebbe comportare tempi di implementazione più lunghi.
Corretto in Android Studio 3.5.2
- Stile del codice XML danneggiato: durante la modifica del codice XML, l'IDE ha applicato uno stile di codice errato quando hai selezionato Codice > Riformatta codice dalla barra dei menu.
Corretto in Android Studio 3.3.1
Errori di memoria insufficiente 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 memoria insufficiente.
Per ulteriori informazioni su questo problema, leggi il bug associato al problema.