why running android 2.3.4 and android 1.6 emulator throw different exception?
<p>I test some code </p>

<pre><code>@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    Fragment f = new Fragment();

}
</code></pre>

<p>I usd sdk4.0 compile, and AndroidManifest.xml use-sdk minSdk=4 targetSdkVersion=14</p>

<p>When I run it on android 1.6 emulator it throw <strong>java.lang.VerifyError</strong>, but on phone running android 2.3.4 it throws <strong>java.lang.NoClassDefFoundError</strong>.</p>

<p>Why??</p>

<p>I do not need Fragment class, I just test a Class that include android 3.0 sdk. I just want to see what will print.</p>

<p>java.lang.VerifyError（Thrown when the VM notices that an attempt is made to load a class which does not pass the class verification phase.）</p>

<p>java.lang.NoClassDefFoundError
（Thrown when the VM is unable to locate a class which it has been asked to load.）</p>

<p>They both extend LinkageError，LinkageError is the superclass of all error classes that occur when loading and linking class files.</p>

<p>I found this in dalvik docs</p>

<blockquote>
  <p>Verification Failures</p>
  
  <p>The verifier may reject a class immediately, or it may defer throwing
  an exception until the code is actually used. For example, if a class
  attempts to perform an illegal access on a field, the VM should throw
  an IllegalAccessError the first time the instruction is encountered.
  On the other hand, if a class contains an invalid bytecode, it should
  be rejected immediately with a VerifyError.</p>
  
  <p>Immediate VerifyErrors are accompanied by detailed, if somewhat
  cryptic, information in the log file. From this it's possible to
  determine the exact instruction that failed, and the reason for the
  failure.</p>
  
  <p>It's a bit tricky to implement deferred verification errors in Dalvik.
  A few approaches were considered:</p>
  
  <p>We could replace the invalid field access instruction with a special
  instruction that generates an illegal access error, and allow class
  verification to complete successfully. This type of verification must
  be deferred to first class load, rather than be performed ahead of
  time during DEX optimization, because some failures will depend on the
  current execution environment (e.g. not all classes are available at
  dexopt time). At that point the bytecode instructions are mapped
  read-only during verification, so rewriting them isn't possible. We
  can perform the access checks when the field/method/class is resolved.
  In a typical VM implementation we would do the check when the entry is
  resolved in the context of the current classfile, but our DEX files
  combine multiple classfiles together, merging the field/method/class
  resolution results into a single large table. Once one class
  successfully resolves the field, every other class in the same DEX
  file would be able to access the field. This is incorrect. Perform the
  access checks on every field/method/class access. This adds
  significant overhead. This is mitigated somewhat by the DEX optimizer,
  which will convert many field/method/class accesses into a simpler
  form after performing the access check. However, not all accesses can
  be optimized (e.g. accesses to classes unknown at dexopt time), and we
  don't currently have an optimized form of certain instructions
  (notably static field operations). In early versions of Dalvik (as
  found in Android 1.6 and earlier), the verifier simply regarded all
  problems as immediately fatal. This generally worked, but in some
  cases the VM was rejecting classes because of bits of code that were
  never used. The VerifyError itself was sometimes difficult to
  decipher, because it was thrown during verification rather than at the
  point where the problem was first noticed during execution.</p>
  
  <p>The current version uses a variation of approach #1. The dexopt
  command works the way it did before, leaving the code untouched and
  flagging fully-correct classes as "pre-verified". When the VM loads a
  class that didn't pass pre-verification, the verifier is invoked. If a
  "deferrable" problem is detected, a modifiable copy of the
  instructions in the problematic method is made. In that copy, the
  troubled instruction is replaced with an "always throw" opcode, and
  verification continues.</p>
</blockquote>
