Android Studio - Appel de méthode ambigu getClass ()

J'utilise Android Studio pour mon application Android.
Mon code fonctionne et se compile.
Récemment, l'EDI me montre une erreur (lignes rouges) sur getClass du code suivant:

fragment.getClass().getSimpleName()

Mais l'application se compile et s'exécute toujours.
L'erreur est:

Ambiguous method call. Both
getClass () in Object and
getClass () in Object match.

Quelqu'un peut-il m'expliquer de quoi il s'agit? et pourquoi le code est toujours en cours d'exécution?

Je pense que c'est un bogue dans Android Studio. Comme nous le savons, Android Studio est basé sur la plateforme IntelliJ et les fonctionnalités existantes d'IntelliJ IDEA Community Edition.

Google l'a développé en coopération avec JetBrains. Et le même bogue se produirait également dans IntelliJ. Jetez un œil au rapport d'erreur

La seule solution à ce problème est de lancer l'instance que vous appelez getClass()le, à la Objectmanière suivante:

((Object) this).getClass()

Plutôt que de modifier le code de votre application, vous pouvez éviter ce bogue en corrigeant le code source de votre SDK Android.

Lorsque vous rencontrez l'erreur getClass (), accédez à la déclaration de la méthode (⌘B sur Mac). Cela permettra d'accéder à un chemin tel que $ANDROID_HOME/sources/android-20/java/lang/Object.java. Maintenant, dans IntelliJ ou Android Studio:

• Rendre Object.javaaccessible en écriture en choisissant File -> Make File Writable. Vous pouvez être invité à le faire automatiquement si vous essayez de modifier le fichier.

• Supprimez le caractère générique illimité:

  // Suppression du caractère générique illimité (Classe) pour éviter http://youtrack.jetbrains.com/issue/IDEA-72835 public final native Class getClass ();

Les nouvelles versions d'Android Studio semblent souffrir d'un bogue qui vous empêche de modifier le fichier même après l'avoir déclaré inscriptible. Au lieu de cela, copiez le chemin, Edit -> Copy Pathou ⇧⌘C, et modifiez-le dans votre éditeur préféré.

Cette modification conservera la fonctionnalité de navigation source. Autres options:

• Vous pouvez commenter toute la getClass()déclaration.
• Vous pouvez ajouter une extension non Java au nom du Object.javafichier, par exemple Object.java.in.

Diffusez votre "getClass" sur un objet, utilisez

((Object) this).getClass()

Pour ceux qui ont ce problème avec les fragments, utilisez

((Object) fragment).getClass()

Tout d'abord, le problème associé à Android Studio est ici . Veuillez le mettre en étoile pour qu'il puisse attirer l'attention!

Le problème IntelliJ connexe est également ici .

Une bonne solution consiste à renommer <sdk>/android-<platform>/java/lang/Object.javaà Object.java.XXXpar exemple. Cela empêchera AS de le voir et le problème sera évité. Bien sûr, en faisant cela, vous ne pouvez plus facilement accéder à la source d'Object depuis AS.

Vous pouvez renommer le fichier à son nom d'origine lorsque ce bogue sera corrigé ...

Aujourd'hui, j'ai rencontré le même problème lorsque j'ai créé un nouveau projet. J'ai comparé à un autre projet qui n'avait pas ce problème et j'ai trouvé une différence. L'ancien projet était basé sur "Android 4.2.2" tandis que le nouveau était défini par défaut sur "Android API 19 Platform". J'ai changé cela en "Android 4.2.2" qui équivaut à l'API 17 et le marqueur d'erreur rouge a disparu. L'API 17 est suffisante pour mon projet donc je peux le laisser ainsi. Je n'ai aucune idée de pourquoi cela résout le problème, pour être honnête.

J'ai trouvé une solution à cela, du moins de mon côté. C'est certainement un bogue IntelliJ, mais il semble être causé par un conflit entre les classes dans le chemin source et dans le chemin de classe pour le SDK Android.

Si vous accédez à Structure du projet> SDK> {{Votre SDK Android}}, supprimez toutes les entrées Android de l'onglet Chemin source. Le problème avec cette solution de contournement est que vous n'avez plus d'accès direct aux sources à partir d'IntelliJ / Android Studio.

J'ai publié les mêmes informations sur le suivi des problèmes Jetbrains , donc j'espère que nous verrons bientôt un correctif.

Utilisez simplement fragment.class.getSimpleName ();