Intégrer OSGi Felix dans Android causes dans UnsupportedOperationException: ne peut pas charger ce type de fichier de classe

Question

J'ai un projet Android développé avec AndroidStudio et Gradle qui embarque et démarre un petit projet OSGi basé sur felix. Pour déboguer j'utilise l'émulateur pour Nexus 5X avec Android 8.0, API 26. J'utilise le service déclaratif et donc mon projet repose sur felix.main, felix.scr et felix.configadmin. Tous les bundles sont dexifiés. L'installation des paquets fonctionne bien, mais si je démarre les paquets par bundle.start(), j'obtiens le message d'erreur suivant pour felix.scr et felix.configadmin (felix.main et mes propres paquets fonctionnent bien -> les états sont actifs):

08-03 13:58:00.880 19745-19745/android.cit.tu_berlin.de.helloandroid W/zygote: Skipping duplicate class check due to unrecognized classloader 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid E/OSGIService: catch exception while starting bundle: 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err: org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.configadmin [2]. 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.Felix.activateBundle(Felix.java:2276) 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) 
    08-03 13:58:00.881 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.cit.tu_berlin.de.helloandroid.OSGIService.startBundle(OSGIService.java:386) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.cit.tu_berlin.de.helloandroid.OSGIService.runSensorVisualisationPlugin(OSGIService.java:248) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.cit.tu_berlin.de.helloandroid.OSGIService.onStartCommand(OSGIService.java:158) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3539) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.app.ActivityThread.-wrap20(Unknown Source:0) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1698) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.os.Handler.dispatchMessage(Handler.java:105) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.os.Looper.loop(Looper.java:164) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at android.app.ActivityThread.main(ActivityThread.java:6540) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at java.lang.reflect.Method.invoke(Native Method) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err: Caused by: java.lang.UnsupportedOperationException: can't load this type of class file 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at java.lang.ClassLoader.defineClass(ClassLoader.java:591) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at java.lang.ClassLoader.loadClass(ClassLoader.java:312) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1415) 
    08-03 13:58:00.882 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4468) 
    08-03 13:58:00.883 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err:  at org.apache.felix.framework.Felix.activateBundle(Felix.java:2221) 
    08-03 13:58:00.883 19745-19745/android.cit.tu_berlin.de.helloandroid W/System.err: ... 15 more 

le script a gradle la déclaration suivante pour résoudre les dépendances aux pots felix:

provided fileTree(dir: 'src/main/assets/bundles/', include: ['*.jar']) 
// for finding Felix.class 
compile group: 'org.apache.felix', name: 'org.apache.felix.framework', version: '5.4.0' 

Et je devais définir la propriété suivante à felix pour résoudre à condition manquante osgi.ee (sur la base réponse de Christian Schneider dans celle post):

configMap.put(Constants.FRAMEWORK_SYSTEMCAPABILITIES, "osgi.ee; osgi.ee=\"JavaSE\";version:List=\"1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8\""); 

Je me demande si cette erreur est liée à celle post particulièrement à la partie « d'entrée Bibliothèque de référence au projet de construction Chemin » (basé sur la réponse de Alec B. Plumb dans ce post) parce que je ne savoir pourquoi la première ligne de "mon" rapport d'erreur indique

W/zygote: Skipping duplicate class check due to unrecognized classloader 

Pourquoi une classe dupliquée? Chaque lib est là une fois et il n'y a pas d'autres paramètres de projet ou de liens de dépendance sauf dans Gradle.

J'ai trouvé un post similaire et il est résolu en suivant les étapes du tutoriel d'Apache Felix. Sympa, mais j'ai fait pareil et l'erreur s'est produite de plus.

J'ai beaucoup essayé les derniers jours, j'ai beaucoup lu les derniers jours mais ce que j'ai trouvé ne correspond pas à mon problème, je suppose. S'il vous plaît aider! Et merci beaucoup d'avance!

Mise à jour 08/08/17:

j'ai essayé de trouver l'exception originale basée sur la réponse de Balazs Zsoldos et que le résultat: L'exception est levée dans BundleWiringImpl.class en getClassByDelegation (String name):

public Class getClassByDelegation(String name) throws ClassNotFoundException { 
     if(name != null && name.length() > 0 && name.charAt(0) == 91) { 
      return Class.forName(name, false, this.getClassLoader()); 
     } else if(this.isFiltered(name)) { 
      throw new ClassNotFoundException(name); 
     } else { 
      ClassLoader cl = this.getClassLoaderInternal(); 
      if(cl == null) { 
       throw new ClassNotFoundException("Unable to load class \'" + name + "\' because the bundle wiring for " + this.m_revision.getSymbolicName() + " is no longer valid."); 
      } else { 
       return cl.loadClass(name); 
      } 
     } 
    } 

La dernière ligne (cl.loadClass (name)) lève l'exception. Par souci d'exhaustivité ici les valeurs:

cl = org.apache.felix.configadmin 
name = org.apache.felix.cm.impl.ConfigurationManager 

Malheureusement je ne peux pas déboguer dans cette méthode, donc j'arrêté là et mis à attraper toutes Android Studio exceptions. L'arrêt suivant est provoqué par une exception lancée dans DexFile.class

cause = java.lang.ClassNotFoundException: java.lang.Object 
detailedMessage = Failed resolution of: Ljava/lang/Object 

Qu'est-ce que c'est que ça? Pourquoi dans DexFile.class et pourquoi il n'est pas possible de résoudre la classe d'objet? J'ai vérifié les fichiers dex et leur nom d'entrée (peut-être le problème de chemin absolu, Balazs Zsoldos mentionné) dans les bocaux de bundle. D'accord! Il n'y a pas d'addition cachée. Quelqu'un peut-il aider ou quelqu'un a-t-il eu un problème similaire et une idée de comment résoudre?

Mise à jour 10.08.17

Ce que je me demande c'est pourquoi seuls les paquets felix lancent des exceptions. Felix-Main Bundle et mon propre travail bien, ils sont en état actif. Et pourquoi est-il possible que mes propres paquets basés sur le service déclaratif soient actifs même si le paquet felix-scr ne démarre pas (l'état est résolu). Il semble que felix-scr ne soit pas en état actif pour résoudre la dépendance à felix-scr. Quoi qu'il en soit, pourquoi les librairies fixix dexified échouent-elles et mon propre travail? S'il vous plaît, aidez, je suis désespéré!

Mise à jour 11.08.2017

Aujourd'hui j'ai essayé mon projet pour exécuter et déboguer sur un appareil Android physique (Sony XPERIA Z2 avec Android 4.4.4, API 19) et cela fonctionne. Tous les bundles sont actifs dans l'état. Les derniers jours j'ai utilisé l'émulateur pour Nexus 5X avec Android 8.0, API 26, donc j'ai édité mon post pour ajouter cette information. Il semble dépendre fortement de l'appareil et/ou de la version Android et de l'API. Fou!

Answer 1

Votre plus gros problème est que vous ne pouvez pas savoir l'exception d'origine en raison d'un bug d'Apache Felix: https://issues.apache.org/jira/browse/FELIX-5643

S'il y a une exception lors du chargement de classe sous Android

• l'exception est avalée
• Felix retombe au mécanisme normal de chargement de classe JDK qui jette l'exception que vous voyez

Nous pourrions sol ve la question temporairement de deux façons:

Nous positionniez un point d'arrêt au début de BundleContextImpl.getDexFileClass (...) fonction dans Android Studio après avoir cessé, nous avons mis en studio dev Android pour attraper toutes les exceptions . En faisant cela, nous avons pu trouver la cause originale.

La première solution nous a fatigués car nous devions activer et désactiver la fonction d'arrêt d'urgence. Avec beaucoup de paquets où l'un échoue, il est difficile de trouver le bon pendant le débogage. Par conséquent, nous avons simplement copié le contenu de la classe BundleWiringImpl dans le studio de développement Android et l'avons modifié pour se déconnecter de l'exception avalée. En faisant cela, nous avons pu voir l'exception originale dans le journal. Btw .: Le problème le plus ennuyeux était le suivant. Nous avons dexifié les pots comme le disaient les tutoriels. Cependant, la commande aapt est si moche, que si vous spécifiez le fichier classes.dex avec une URL absolue, l'entrée du ZIP aura le même nom (y compris la lettre de lecteur si vous utilisez Windows). Exemple: Le nom d'entrée de classes.dex dans le zip est c: \ classes.dex et aucun éditeur ZIP ne montre la partie _c: _ de son nom. Par conséquent, nous avons listé les noms d'entrée du ZIP/JAR en Java et de trouver le vrai nom d'entrée.