【转载自sqlite官网】SQLite Android Bindings

链接：http://www.sqlite.org/android/doc/trunk/www/index.wiki

The SQLite library is a core part of the Android environment. Java applications and content providers access SQLite using the interface in theandroid.database.sqlite namespace.

One disadvantage of using Android's built-in SQLite support is that the application is forced to use the version of SQLite that the current version of Android happened to ship with. If your application happens to require a newer version of SQLite,or a build with a custom extension or VFS installed,you're out of luck.

The code in this project allows an application to use the Android NDKto build a custom version of SQLite to be shipped with the application while still continuing to use the standard Java interface.

Normal Usage

Installation

Copy the following files from this project into the equivalent locations in the application project.

    jni/Android.mk
    jni/Application.mk
    jni/sqlite/*                       (copy contents of directory recursively)
    src/org/sqlite/database/*          (copy contents of directory recursively)

Following this,the directory structures should contain these files.

Directory "jni/sqlite/" contains copies of the sqlite3.h and sqlite3.c source files. Between them,they contain thesource code for the SQLite library. If necessary,replace these with the source for the specific version of SQLite required. If SQLite is to be compiled with any special pre-processor macros defined,add them to the "jni/sqlite/Android.mk" file (not jni/Android.mk).

Once the files have been added to the project,run the command "ndk-build" in the root directory of the project. This compiles the native code in 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.

Application Programming

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 "org.sqlite.database.sqlite". For example,the following:

  import android.database.sqlite.SQLiteDatabase;

should be replaced with:

  import org.sqlite.database.sqlite.SQLiteDatabase;

As well as replacing all uses of the classes in the android.database.sqlite.* namespace,the application must also be sure to use the following two:

  org.sqlite.database.SQLException
  org.sqlite.database.DatabaseErrorHandler

instead of:

  android.database.SQLException
  android.database.DatabaseErrorHandler

Aside from namespace changes,there are other differences from the stock Android interface that applications need to be aware of:

1. The SQLiteStatement.simpleQueryForBlobFileDescriptor() API is not available.

2. The collation sequence "UNICODE" is not available.

3. The collation sequence "LOCALIZED",which normally changes with the system's current locale,is always equivalent to SQLite's built in collation BINARY.

Using The SQLite Encryption Extension

To use the SQLite Encryption Extension (SEE) on Android,replace the sqlite3.c file at "jni/sqlite/sqlite3.c" with a SEE-enabled version (i.e. the concatenation of sqlite3.c and see.c - refer to the link above for details). Next,open the file jni/sqlite/Android.mk and locate the following two lines:

  # If using SEE,uncomment the following:
  # LOCAL_CFLAGS += -DSQLITE_HAS_CODEC

Uncomment the second of them,then run "ndk-build" as described above to generate the shared libraries.

After opening or creating an encrypted database,the application must immediately execute a PRAGMA to configure the encryption key. This must be done before any other database methods are called. For example:

  import org.sqlite.database.sqlite.SQLiteDatabase;

    ...

  SQLiteDatabase db = SQLiteDatabase.openOrCreateDatabase("my.db",null);
  db.execSQL("PRAGMA key = 'secretkey'");

Or,if you are using the SQLiteOpenHelper helper class,the PRAGMA must be the first thing executed within the onConfigure() callback. For example:

  import org.sqlite.database.sqlite.SQLiteDatabase;
  import org.sqlite.database.sqlite.SQLiteHelper;

    ...

  class MyHelper extends SQLiteOpenHelper {
    ...
    void onConfigure(SQLiteDatabase db){
      db.execSQL("PRAGMA key = 'secretkey'");
    }
    ...
  }

Refer to the SEE documentation for further details regarding encryption keys.

Aside from supporting encrypted databases,SEE-enabled builds behave differently in two more respects:

1. The SQLiteDatabase.enableWriteAheadLogging() method does not enable connection pooling. It is not possible for connection pooling to be used with a SEE-enabled build (even if the database is unencrypted).

2. In Android,if database corruption is encountered,or if an attempt is made to open a file that is not an SQLite database,the default behaviour is to delete the file and create an empty database file in its place. In a SEE-enabled build,the default behaviour is to throw an exception.
   
   The reason for this is that supplying an incorrect encryption key is indistinguishable from opening a file that is not a database file. And it seems too dangerous to simply delete the file in this case.
   
   The default behaviour can be overriden using the DatabaseErrorHandler interface.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!