La balise languageLevel d'Android .idea / misc.xml ne cesse de changer les JDK

181

La clé languageLevel passe de JDK_1_8 à JDK_1_7 pour des raisons que je ne connais pas.

Que pourrait-il se passer?

Est-ce que cela a quelque chose à voir avec l'EDI d'autres développeurs travaillant sur le projet? Peut-être ont-ils un autre paramètre Android Studio?

Voici ce qui apparaît après avoir remarqué que les fichiers sous contrôle de code source ont changé:

$ 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">

Ceci est mon gitignore au cas où cela importerait.

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

Comment procéder pour que ça reste dans un sens ou dans l'autre?

kraftydevil
la source
1
J'ai fait. Réponse ajoutée.
kraftydevil
4
Je veux juste souligner que intellij-support.jetbrains.com/hc/en-us/articles/... est la réponse officielle à ce qui devrait être dedans.gitignore , et cette solution de contournement va à l'encontre de cela. Vous perdez la possibilité de partager les propriétés du projet avec tous les développeurs, comme les inspections / paramètres de charpie que nous utilisons pour éviter certaines mauvaises pratiques standard avant même de passer à la révision du code. Vous pouvez simplement ajouter /.idea/misc.xmlau .gitignorefichier pour résoudre ce problème.
Matt Quigley
4
J'ai moi-même remarqué ce problème et ce n'était même pas après qu'un autre membre de l'équipe se soit engagé à travailler. J'ai fait mon propre travail, poussé un commit, fait un peu plus de travail et j'ai remarqué que cela m'avait remis en marche. C'est ce qui me préoccupe le plus. Si c'est un membre différent de l'équipe, je sais pourquoi cela change, mais changer au hasard pendant le développement personnel local est inquiétant et déroutant. Un aperçu de cela?
John Shelley
3
J'ai le même problème, le niveau de langue ne cesse de changer entre 1.7 et 1.8.
Han He
1
sujet lié à stackoverflow.com/questions/17637179/…
CrandellWS

Réponses:

43

Cela m'a rendu fou pendant un moment. J'ai pu résoudre ce problème en définissant explicitement la version java dans mon build.gradle:

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

Notez que si vous utilisez VERSION_1_7, lorsque vous lancez à froid Android Studio ou passez à un autre projet qui utilise VERSION_1_8, il sera modifié .idea/misc.xmlpour utiliser JDK_1_8. Faire une synchronisation gradle le réinitialisera JDK_1_7. Si vous utilisez VERSION_1_8, vous n'aurez pas ce problème.

Ce n'est pas parfait mais j'ai trouvé que c'était assez bon pour le moment.

Noel
la source
2
Actuellement, n'utilisez pas et ne souhaitez pas utiliser le JDK incorporé comme suggéré dans stackoverflow.com/a/40083824/1815624 en utilisant l'option gradle pour éviter le problème de changement. Vous voudrez peut-être noter cela via code.google.com/p/android/issues/detail?id=172115
CrandellWS
Dois-je le mettre dans le projet ou dans le fichier du module?
rraallvv
@rraallvv le module
Noel
Ce genre de "corrige" ça pour moi. J'ai ces options dans mon fichier gradle. Si j'ouvre studio (il effectue une synchronisation graduelle et), il définit misc.xml sur 1_8. Si je construis alors, il sera remis à 1_7. Si je synchronise ensuite le gradle, il sera remis à 1_8 et la construction ne le remettra plus à 1_7. Faire la synchronisation gradle ne le définit jamais sur 1_7 pour moi, il est toujours 1_8 après une synchronisation gradle. Chaque fois que j'ouvre un studio, il est réglé sur 1_8.
David
Si vous voulez utiliser JDK 1.8: android {compileOptions {sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8}}
Beatrice Lin
25

Je suis venu ici de Google après la mise à jour vers Android Studio 2.2. Cela pourrait être utile aux autres.

Depuis Android Studio 2.2, le JDK est fourni avec lui, au lieu de devoir le télécharger et l'installer sur votre système. Mon projet JDK a commencé à basculer lorsque j'ai mis à jour vers 2.2, peut-être à cause de la confusion entre les deux versions actuellement disponibles - système et embarquée.

Si vous allez dans Fichier> Structure du projet (Mac OS), dans l'onglet Emplacement du SDK, il y a l'emplacement du JDK. Il existe maintenant un nouveau paramètre pour utiliser le JDK intégré. Une fois que je suis passé à lui, cela a résolu mon problème.

entrez la description de l'image ici

ROUGE_
la source
7
Je l'ai fait (bien que dans Win10) mais dès que j'ai redémarré AS, j'ai remarqué que le problème persiste :(
CesarPim
2
Cela fonctionne pour résoudre le problème. Comme le mentionne @CesarPim, je vois qu'il refait surface lorsque la construction n'est pas synchronisée. L'exécution de la synchronisation gradle annule alors la modification. Dans l'ensemble, une bonne solution propre, bien meilleure qu'avant - merci!
Gene Bo
5
Que voulez-vous dire @gnB? Avec moi, ça va et vient entre 1.7 et 1.8 ... je n'ai pas pu trouver une solution stable. Étiez-vous?
CesarPim
3
@gnB oui, la même chose avec moi, mais cela me dérange toujours que cela se produise à chaque fois que je lance AS ... cela ne devrait pas arriver
CesarPim
15
Cela se passe toujours dans Android Studio 3.0, et cette suggestion ne l'a pas résolu. J'ai déjà sélectionné "JDK intégré", et pourtant il continue de changer de 1_7 à 1_8 et inversement sans raison apparente.
Greg Ennis
9

Il semble que le fichier devrait être stocké sous contrôle de version . Je proposerais de le garder dans git, mais d'ignorer tous les changements locaux:

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

Lors du changement de branche, il peut y avoir un conflit dans ces fichiers. Ensuite, vous pouvez utiliser le script imlreset suivant pour réinitialiser les fichiers:

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

Créez un script similaire pour ignorer ces fichiers si vous le faites souvent.

Paweł Nadolski
la source
Cela n'évite pas les problèmes lors du changement de branche, si l'EDI modifie le fichier, les modifications doivent être supprimées avant de pouvoir extraire une autre branche.
ergosys du
@ergosys, merci pour vos commentaires. Script ajouté que j'utilise dans de tels cas.
Paweł Nadolski
1
Ignorer le fichier est une solution anti, et même pas une solution de contournement bénéfique. Il ne remédie pas à la cause, il cache les symptômes et, ce faisant, crée et masque des problèmes simples de sorte qu'ils deviennent difficiles à trouver et à résoudre.
Barry Staes
@BarryStaes, merci pour vos commentaires. Je n'ai pas trouvé de solution parfaite pour ce problème (les autres solutions ne fonctionnaient pas) et celle-ci fonctionne pour moi et peu d'autres personnes. Notez que cela n'ignore pas complètement les fichiers ne cachant que le fait qu'ils ont changé. Étant donné que ces fichiers peuvent changer souvent et de manière aléatoire, cela permet de les filtrer lors de l'exécution de commandes git. Vous pouvez toujours les valider quand vous le souhaitez.
Paweł Nadolski
1

J'ai résolu ce problème lorsque j'ai supprimé et arrêté de valider le dossier .idea au contrôle de code source.

Le problème est que certains de ces fichiers sont des configurations spécifiques à la machine, leur partage peut donc poser problème.

Le supprimer et d'autres fichiers incriminés était un processus git en deux étapes:

1) Ajoutez ce .gitignore (à partir de 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) Pour chaque ligne du .gitignore, exécutez à git rm linepartir de la ligne de commande.

Exemple:

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

Ajouter et valider les modifications

Désormais, ces fichiers seront générés lorsque vous ouvrirez le projet Android Studio et ils ne seront pas ajoutés à git.

kraftydevil
la source
20
Selon intellij-support.jetbrains.com/hc/en-us/articles/ ... vous êtes censé valider la majeure partie du .ideadossier car ils ne sont pas spécifiques à la machine, à l'exception de workspace.xmlet tasks.xml. Cela étant dit, ce n'est pas très bien pensé en termes de contrôle de version, à cause de problèmes comme ceux-ci. Je suppose qu'ils finiront par régler le problème.
Matt Quigley
Je comprends qu'il y a des divergences. En même temps, je ne suis au courant d'aucun problème dans mon équipe de développement lié à l'utilisation de ce fichier .gitignore. Si j'en savais plus, je pourrais vous conseiller davantage, mais c'est ce qui fonctionne pour nous en ce moment. Si un problème se présente, je changerai ma réponse.
kraftydevil
31
Oui, nous savons tous comment forcer git à ignorer ce fichier. Mais la vraie question est de savoir pourquoi il ne cesse de passer de JDK_1_8 à JDK_1_7 (et parfois de nouveau)?
SMBiggs
J'ai commencé à m'arriver avec Android Studio 2.2. Je pense qu'ils ont regroupé le JDK en commençant par AS 2.2, il est donc possible qu'il continue à se confondre entre celui du système et celui de AS.
RED_
3
Cela ne répond pas du tout à la question. Ce qui est étrange parce que vous l'avez demandé. Voici comment ignorer le problème, ce qui pourrait vous convenir, je suppose, j'aimerais savoir pourquoi il ne cesse de changer et comment l'empêcher de le faire.
David