Hallo,
Ohne Codeausschnitt ist wahrscheinlich nicht viel zu machen.
Kann ich gerne noch einstellen - bringt aber denke ich nicht viel, da das dann recht viel Code wäre, der an sich an auch völlig korrekt ist (betreibe ich ihn in einem OSGi Framework unter "normalem" Java, z. B. auf einem PC, dann funktioniert dieser Code absolut problemlos). Erst, wenn er nach Dalvik überführt und auf Android bzw. in einem Framework unter Android ausgeführt wird gibt es Probleme. Diese treten exakt in dem Moment auf, wenn der Service (sprich: die Java-Klasse) instanziiert wird, in dessen Methodensignaturen javax.security.auth.Subjects mit übergeben werden können (und zwar wirklich beim Instanziieren dieser Klasse, nicht etwa erst beim Aufruf einer dieser Methoden...
Außerdem wäre ein Link zum Framework nett.
Ansonsten sagt der Logcat nur, dass dort ein Fehler ist:
unable to find class referenced in signature (Ljavax/security/auth/Subject
Getestet habe ich das mit a) Felix ( http://felix.apache.org/site/a…k-and-google-android.html ) und b) dem ProSyst mBS Mobile ( http://www.prosyst.com/index.p…9/mBS-Mobile-for-Android/ ). Der Fehler tritt mit beiden Frameworks auf, allerdings in leicht unterschiedlichen Ausprägungen: bei Felix kommt er erst, wenn auch wirklich die Instanz der o.g. Klasse (des Services) erzeugt wird, d.h. starte ich da einfach nur das Bundle, und kommentiere das Instanziieren des Services aus, passiert nichts; das mBS Mobile Framework stürzt direkt beim Installieren / Starten des Bundles ab. Das liegt m. E. nach aber eher daran, dass dieses Framework evtl. direkt beim Starten überprüft, wie es denn so mit den benötigten Klassen aussieht, und dann eben das javax.security.auth.Subject nicht geladen bekommt. Felix scheint das nicht zu prüfen, sondern erst "im Falle des Falles" zu laden (denke ich, andern kann ich mir das Verhalten nicht erklären.
Ich verstehe halt nicht wirklich, warum diese Klasse (das Subject) nicht gefunden wird - in der Dalvik VM ist diese verfügbar (versch. javax.*-Klassen sind dort AFAIK ausgelassen, gerade diese aber nicht). Schaut man sich bspws. das Log des mBS Mobile an, dann sieht man auch, dass das Laden dieser Klasse an die Dalvik VM delegiert wird, diese die Klasse anscheinend auch lädt, aber dann *irgendwie* die Rückgabe schiefzugehen scheint:
03-24 08:31:04.976: INFO/System.out(243): fw>$[COMPONENTMANAGER_ACTIVATOR] Registering ComponentManager-Services...
03-24 08:31:05.056: INFO/mBS(243): Cannot load class: javax/security/auth/Subject from /data/data/com.prosyst.mbs.mobile.android/app_mbs/lib/serverandroid.jar
03-24 08:31:05.056: DEBUG/mBS(243): [DalvikClassLoader] Loaded class from boot class loader: class javax.security.auth.Subject
03-24 08:31:05.066: INFO/mBS(243): Cannot load class: javax/security/auth/Subject from /data/data/com.prosyst.mbs.mobile.android/app_mbs/bin/vms/dalvikvm/storage/bundles/8^1^OSAmI-Binding-API_1.0.0.jar
03-24 08:31:05.226: INFO/DEBUG(31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-24 08:31:05.226: INFO/DEBUG(31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
03-24 08:31:05.226: INFO/DEBUG(31): pid: 243, tid: 377 >>> com.prosyst.mbs.mobile.android:mbsservice <<<
03-24 08:31:05.226: INFO/DEBUG(31): signal 11 (SIGSEGV), fault addr 00000024
(die folgenden Zeilen mit der Fehlermeldung spare ich mir mal, da kommen Registernummern oder sowas...)
Inzw. hab ich testweise mal eine Version des Services / der Klasse gebaut, bei denen alle Subjects in den Methodensignaturen stumpf zu Objects refactored wurden - diese Version lässt sich dann ganz normal instanziieren, starten, und auch nutzen; dabei stürzt nichts ab. Ist natürlich leider keine Lösung, da hier dann auch Funktionsumfang verlorengegangen ist - und vor allem ist es ja gerade unser Ziel, auf allen Plattformen identische Bundles (mal abgesehen von z. B. der Umwandlung nach Dalvik) einsetzen zu können. Das ist dann ja nicht mehr gegeben...
