felix-on-android | felix-on-android osgi android | Android library

Your biggest issue is that you cannot know the original exception due to a bug of Apache Felix: https://issues.apache.org/jira/browse/FELIX-5643

If there is an exception during Android based class loading

• the exception is swallowed
• Felix falls back to normal JDK class loading mechanism that throws the exception you see

We could solve the issue temporarily in two ways:

We did set a breakpoint to the beginning of BundleContextImpl.getDexFileClass(...) function in Android Studio and after it stopped, we did set Android dev studio to catch all exceptions. By doing that, we were able to find the original cause.

The first solution made us tired as we had to switch on and off the stop-at-exception feature. With many bundles where one is failing, it is hard to find the right one during debugging. Therefore, we simply copied out the content of BundleWiringImpl class into Android developer studio and changed it to log out the swallowed exception. By doing that, we were able to see the original exception in the log.

Btw.: The most annoying problem was the following. We dexified the jars as the tutorials said. However, the aapt command is that ugly, that if you specify the classes.dex file with an absolute URL, the entry of the ZIP will have the same name (including drive letter if you use windows). E.g.: The entry name of classes.dex in the zip is c:\classes.dex and no ZIP editor show the _c:_ part of its name. Therefore we listed the entry names of the ZIP/JAR in Java and to find out the real entry name.