Il tag languageLevel di Android .idea / misc.xml continua a cambiare i JDK


178

La chiave languageLevel viene modificata da JDK_1_8 a JDK_1_7 per motivi che non sono a conoscenza.

Cosa potrebbe succedere?

Questo ha qualcosa a che fare con l'IDE di altri sviluppatori che lavorano al progetto? Forse hanno un'altra impostazione di Android Studio?

Ecco cosa appare dopo che ho notato che i file sotto il controllo del codice sorgente sono cambiati:

$ git diff
diff --git a/.idea/misc.xml b/.idea/misc.xml
index fbb6828..5d19981 100644
--- a/.idea/misc.xml
+++ b/.idea/misc.xml
@@ -37,7 +37,7 @@
     <ConfirmationsSetting value="0" id="Add" />
     <ConfirmationsSetting value="0" id="Remove" />
   </component>
-  <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" default="true" assert-keyword="true" jdk-15="true" project-jdk-name="1.8" project-jdk-type="JavaSDK">
+  <component name="ProjectRootManager" version="2" languageLevel="JDK_1_7" default="true" assert-keyword="true" jdk-15="true" project-jdk-name="1.8" project-jdk-type="JavaSDK">
     <output url="file://$PROJECT_DIR$/build/classes" />
   </component>
   <component name="ProjectType">

Questo è il mio gitignore nel caso in cui sia importante.

.gradle
/local.properties
/.idea/workspace.xml
/.idea/libraries
.DS_Store
/build
/captures

Come posso procedere in modo che rimanga solo in un modo o nell'altro?


1
L'ho fatto. Risposta aggiunta.
kraftydevil,

4
Voglio solo sottolineare che intellij-support.jetbrains.com/hc/en-us/articles/… è la risposta ufficiale a ciò che dovrebbe esserci .gitignore, e questa soluzione alternativa va contro questo. Si perde la capacità di condividere le proprietà del progetto con tutti gli sviluppatori, come le impostazioni di ispezione / lanugine che utilizziamo per prevenire alcune cattive pratiche standard prima ancora di arrivare alla revisione del codice. Puoi semplicemente aggiungere /.idea/misc.xmlal .gitignorefile per risolvere questo problema.
Matt Quigley,

4
Ho notato questo problema da solo e non è stato nemmeno dopo che un altro membro del team ha lavorato. Ho fatto il mio lavoro, mi sono impegnato, ho fatto ancora un po 'di lavoro e ho notato che mi aveva riacceso. Questo è ciò che mi preoccupa di più. Se è un membro del team diverso, allora so perché sta cambiando, ma cambiare casualmente durante lo sviluppo locale personale è preoccupante e confuso. Qualche idea su questo?
John Shelley,

3
Ho lo stesso problema, il livello della lingua continua a cambiare tra 1.7 e 1.8.
Han He

Risposte:


42

Questo mi ha fatto impazzire per un po '. Sono stato in grado di risolverlo impostando esplicitamente la versione java nel mio build.gradle:

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }
}

Si noti che se si utilizza VERSION_1_7, quando si avvia a freddo Android Studio o si passa a un altro progetto che utilizza VERSION_1_8, verrà modificato .idea/misc.xmlper l'uso JDK_1_8. Effettuare una sincronizzazione graduale ripristinerà l'utilizzo JDK_1_7. Se stai usando VERSION_1_8, non avrai questo problema.

Non è perfetto ma ho trovato questo abbastanza buono per ora.


2
Attualmente, non utilizzare né vuole utilizzare il JDK incorporare come suggerito nella stackoverflow.com/a/40083824/1815624 utilizzando l'opzione Gradle non impedire il rilascio cambiando. Potrebbe volerlo notare però code.google.com/p/android/issues/detail?id=172115
CrandellWS

Devo inserirlo nel progetto o nel file del modulo?
rraallvv,

@rraallvv il modulo
Noel

Questo tipo di "risolve" per me. Ho queste opzioni nel mio file Gradle. Se apro studio (esegue una sincronizzazione graduale e), imposta misc.xml su 1_8. Se costruisco, verrà riportato a 1_7. Se poi sincronizzo Gradle, verrà ripristinato su 1_8 e building non lo ripristinerà più su 1_7. Fare la sincronizzazione dei gradi non lo imposta mai su 1_7 per me, è sempre 1_8 dopo una sincronizzazione dei gradi. Ogni volta che apro studio, viene impostato su 1_8.
David,

Se si desidera utilizzare JDK 1.8: android {compileOptions {sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8}}
Beatrice Lin

24

Sono venuto qui da Google dopo l'aggiornamento ad Android Studio 2.2. Questo potrebbe essere utile per gli altri.

Da Android Studio 2.2, JDK è stato integrato con esso, invece di doverlo scaricare e installare sul tuo sistema. Il mio progetto JDK ha iniziato a cambiare quando ho aggiornato a 2.2, probabilmente a causa della confusione tra le due versioni disponibili ora: sistema e incorporato.

Se vai in File> Struttura del progetto (Mac OS), nella scheda Posizione SDK, c'è la posizione JDK. Ora c'è una nuova impostazione per usare il JDK incorporato. Una volta passato a questo, ha risolto il mio problema.

inserisci qui la descrizione dell'immagine


7
L'ho fatto (anche se in Win10) ma non appena ho riavviato AS ho notato che il problema persiste :(
CesarPim

2
Questo funziona per risolvere il problema. Come cita @CesarPim, vedo che riappare quando la build non è sincronizzata. L'esecuzione della sincronizzazione graduale quindi cancella la modifica. Nel complesso una bella soluzione pulita, molto meglio di prima - grazie!
Gene Bo,

5
Cosa intendi con @gnB? Con me continua ad andare avanti e indietro tra 1.7 e 1.8 ... non sono riuscito a trovare una soluzione stabile. Eri tu?
Cesar Pin

3
@gnB sì, lo stesso con me, ma mi dà ancora fastidio che succeda ogni volta che lancio AS ... non dovrebbe accadere
CesarPim

15
Succede ancora in Android Studio 3.0 e questo suggerimento non è stato risolto. Ho già selezionato "JDK incorporato", eppure continua a cambiare da 1_7 a 1_8 e viceversa senza motivo apparente.
Greg Ennis,

9

Sembra che il file debba essere archiviato sotto il controllo della versione . Proporrei di tenerlo in git, ma ignoro tutte le modifiche locali:

git update-index --assume-unchanged .idea/misc.xml

Quando si cambiano rami potrebbero esserci dei conflitti in questi file. Quindi è possibile utilizzare il seguente script imlreset per ripristinare i file:

#!/bin/bash                                                                     
while read f                                                                    
do                                                                              
  [ -f $f ] && git checkout $f                                                    
done <<!                                                                        
app/app.iml                                                           
wear/wear.iml                                                                   
!

Crea uno script simile per ignorare questi file se lo fai spesso.


Questo non evita problemi quando si cambiano i rami, se l'IDE cambia il file, le modifiche devono essere rimosse in qualche modo prima di poter effettuare il checkout di un ramo diverso.
ergosys,

@ergosys, grazie per il commento. Aggiunto script che utilizzo in questi casi.
Paweł Nadolski,

1
Ignorare il file è una soluzione anti e nemmeno una soluzione utile. Non pone rimedio alla causa, nasconde i sintomi e, in tal modo, crea e oscura problemi semplici in modo che diventino difficili da trovare e risolvere.
Barry Staes

@BarryStaes, grazie per il feedback. Non ho trovato la soluzione perfetta per questo problema (altre soluzioni non hanno funzionato) e questo funziona per me e poche altre persone. Si noti che ciò non ignora completamente i file, nascondendo solo il fatto che sono stati modificati. Dato che questi file possono cambiare spesso e in modo casuale, consente di filtrarli durante l'esecuzione di comandi git. Puoi ancora impegnarli quando vuoi.
Paweł Nadolski,

1

Ho risolto questo problema quando ho rimosso e smesso di eseguire il commit della cartella .idea per il controllo del codice sorgente.

Il problema è che alcuni di questi file sono configurazioni specifiche della macchina, quindi condividerli potrebbe essere un problema.

Rimuoverlo e altri file offensivi è stato un processo git in due passaggi:

1) Aggiungi questo .gitignore (da https://stackoverflow.com/a/32942758/869936 ):

#built application files
*.apk
*.ap_

# files for the dex VM
*.dex

# Java class files
*.class

# generated files
bin/
gen/

# Local configuration file (sdk path, etc)
local.properties

# Windows thumbnail db
Thumbs.db

# OSX files
.DS_Store

# Eclipse project files
.classpath
.project

# Android Studio
*.iws
*.iml
.idea
.gradle
build/
*/build/

2) Per ogni riga di .gitignore, eseguire git rm linedalla riga di comando.

Esempio:

$ git rm *.iws
$ git rm *.iml
$ git rm .idea
$ git rm .gradle
$ git rm build/
$ git rm */build/

Aggiungi e impegna le modifiche

Ora questi file verranno generati quando apri il progetto Android Studio e non verranno aggiunti a git.


20
Secondo intellij-support.jetbrains.com/hc/en-us/articles/… dovresti impegnare la maggior parte della .ideacartella perché non sono specifici della macchina, ad eccezione di workspace.xmle tasks.xml. Detto questo, non è molto ben pensato in termini di controllo della versione, a causa di problemi come questi. Immagino che alla fine risolveranno il casino.
Matt Quigley,

Capisco che ci sono discrepanze. Allo stesso tempo, non sono a conoscenza di problemi nel mio team di sviluppo nell'uso di questo .gitignore. Se ne sapessi di più, potrei consigliarti ulteriormente, ma questo è ciò che funziona per noi in questo momento. Se si presenta un problema, cambierò la mia risposta.
kraftydevil,

31
Sì, sappiamo tutti come forzare git a ignorare questo file. Ma la vera domanda è perché continua a cambiare da JDK_1_8 a JDK_1_7 (e talvolta di nuovo indietro)?
Scott Biggs,

Ho iniziato a succedermi con Android Studio 2.2. Penso che abbiano unito il JDK a partire da AS 2.2, quindi è possibile che rimanga confuso tra il sistema uno e quello all'interno di AS.
RED_

3
Questo non risponde affatto alla domanda. Il che è strano perché l'hai chiesto. Questo è il modo per ignorare il problema, che potrebbe andare bene per te, immagino, vorrei sapere perché continua a cambiare e come fermarlo.
David,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.