My app works fine when I launch an Android app from Eclipse. In the past, I have also successfully exported a signed version of the application.
Now the exported version of the application crashes suddenly. Key message seems to be
Called: aaaab: The selected LogFactory implementation does not extend LogFactory. Check the configuration. (A java.lang.ClassCastException is thrown: the application indicated that a custom LogFactory implementation should be used, but the class 'org.apache.commons.logging.impl.LogFactoryImpl' could not be converted to 'aaaac'. Please check the custom implementation. Help can find @ http://commons.apache.org/logging/troubleshooting.html .).
Here are the Proguard settings. Am I missing something?
-dontwarn org.apache.** -dontwarn org.apache.commons.logging.** -ignorewarnings -dontusemixedcaseclassnames -dontskipnonpubliclibraryclasses -dontskipnonpubliclibraryclassmembers
apache.org doc says:
A custom LogFactory implementation can only be used if the implementation class loaded dynamically at runtime can be ported to the LogFactory class that loaded it. There are several ways in which this cast can fail. The most obvious is that the source code cannot actually extend LogFactory. The source may be compatible, but if the LogFactory class with which the source code is compiled is not binary compatible, then the tide will also fail.
There is another unusual way in which this cast may fail: even if the binary is compatible, the implementation class loaded at runtime may be associated with another instance of the LogFactory class. See the Technical Guide for more information.
This situation may occur in containers that use a custom implementation of LogFactory. An implementation will typically be provided in a shared high-level class loader along with the JCL. When the application class loader contains LogFactory, the implementation will be loaded from this higher level class loader. The implementation class will be associated with the LogFactory class loaded by the higher level class loader. Even if the LogFactory implementations are binary compatible because they are loaded by different class loaders, the two instances of the LogFactory class are not equal, and so the cast should fail.
They say potential fixes include:
There are various solutions to this problem. The right decision depends on the circumstances.
If you like to use a different class loading policy for the application, select a class loading policy that ensures that LogFactory will be loaded from a common classloader containing a custom implementation.
If you want to bypass the container adaptation mechanism, set the corresponding system property to the default value when the container starts:
-Dorg.apache.commons.logging.LogFactory = org.apache.commons.logging.impl.LogFactoryImpl
If you want to continue using the default container mechanism, then: • Find and replace the standard logging system implemented in the container with the most modern version • Replace the public bank in the application using ATM adapters. This ensures that the application class loader will delegate the parent component to it when loading LogFactory.
I thought the command "-Dorg.apache.commons ......" would go into the proguard-project.txt file, but this caused the application to not even be able to build. So, on the bottom line, I don’t understand what apache is trying to say, and I hope some of you experienced people can provide some clarity / guidance.
Here's the stack trace:
07-22 02:49:32.109: E/AndroidRuntime(13589): FATAL EXCEPTION: AsyncTask