the jni/ directory (including the custom SQLite version) to shared libraries
  that will be deployed to the device along with the application. Assuming
  it is successful, unless you modify the sources or makefiles within the
  jni/ directory structure, you should not need to run "ndk-build" again.

<h3>Application Programming</h3>















<p>
  The classes that make up the built-in Android SQLite interface reside in
  the "android.database.sqlite" namespace. This interface provides all of
  the same classes, except within the "org.sqlite.database.sqlite" namespace.
  This means that to modify an application to use the custom version of 
  SQLite, all that is usually required is to replace all occurrences
  "android.database.sqlite" within the source code with

  the jni/ directory (including the custom SQLite version) to shared libraries
  that will be deployed to the device along with the application. Assuming
  it is successful, unless you modify the sources or makefiles within the
  jni/ directory structure, you should not need to run "ndk-build" again.

<h3>Application Programming</h3>

<p>
  Before using any SQLite related methods or objects, the shared library
  compiled using the ndk must be loaded into the application using the
  following code:

<verbatim>
  System.loadLibrary("sqliteX");
</verbatim>

<p>
  One way to ensure that the shared library is loaded early enough is
  to add it to a "static" block within the declaration of the application's
  main Activity class.

<p>
  The classes that make up the built-in Android SQLite interface reside in
  the "android.database.sqlite" namespace. This interface provides all of
  the same classes, except within the "org.sqlite.database.sqlite" namespace.
  This means that to modify an application to use the custom version of 
  SQLite, all that is usually required is to replace all occurrences
  "android.database.sqlite" within the source code with