On Mar 1, 10:27 pm, dhananjay <dhananjayingr...@gmail.com> wrote: > V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/ClassLoader; > V/dalvikvm( 368): THROW 'Ljava/lang/VerifyError;' > msg='java.lang.Class' cause=(none) > V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/VerifyError;' 0x0 > (isnew=1) --> 0x2aab0dd0 > V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/LinkageError; > V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/Error; > V/dalvikvm( 368): THROW 'Ljava/lang/VerifyError;' > msg='Ljava.lang.Error;' cause=(none) > E/dalvikvm( 368): Too many exceptions during init (failed on 'Ljava/ > lang/VerifyError;' 'Ljava.lang.Error;')
Looks like it's encountering some sort of verification error in java.lang.Class. This is a pretty fundamental piece, so when the errors start to cascade the VM realizes that it's hosed and just aborts. Generally when the verifier encounters a problem it logs a bunch of stuff before it throws a VerifyError, but those are largely suppressed while dexopt runs. In dalvik/vm/analysis/VerifySubs.c there's a function called dvmLogVerifyFailure that does this: if (gDvm.optimizing) { return; //logLevel = ANDROID_LOG_DEBUG; } else { logLevel = ANDROID_LOG_WARN; } Replace the "return" with the commented-out line and try again. That should let you see what it's complaining about. Making it happy is the next step. :-) -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting