Iincorporating custom Error handler in the SQLiteOpenHelper class provided in sqlCipher

[edZilla]

I started using sqlCipher for Android (ver) 2.1.1 on Android 4.0.3 and it works like charm. Thanks for that. However I found that the SQLiteOpenHelper class does not have the constructor that takes the custom Error handler. This is very much there in the original SQLiteOpenHelper class provided in android.database and it is very useful to handle the errors in an app specific manner. Does anyone know how to incorporate a custom error handler when using sqlCipher?

Constructors available in android.database.sqlite

public SQLiteOpenHelper (Context context, String name, SQLiteDatabase.CursorFactory factory, int version);
public SQLiteOpenHelper (Context context, String name, SQLiteDatabase.CursorFactory factory, int version, DatabaseErrorHandler errorHandler);

Constructors available in net.sqlcipher.database

public SQLiteOpenHelper(Context context, String name, SQLiteDatabase.CursorFactory factory, int version);

 

In specific, when encountered with certain types of errors the default error handler (when using sqlcipher) is removing the database, albeit after providing a Log.e message. But I need to avoid it. Any help is appreciated.

[Stephen Lombardo]

Hello,

Custom database error handlers are more recent additions to the android.database package. The SQLCipher packages are based on an older API (level 7), and thus don't include this feature. We'll try to take a closer look at this and see if there is something we can do to address the issue without affecting backward compatibility.

Thanks!

Cheers,
Stephen

On 2012-12-25, edZilla wrote:
>
>
> I started using sqlCipher for Android (ver) 2.1.1 on Android 4.0.3 and it

> works like charm. Thanks for that. However I found that the SQLiteOpenHelperclass does not have the constructor that takes the custom Error handler.

> This is very much there in the original SQLiteOpenHelper class provided in
> android.database and it is very useful to handle the errors in an app
> specific manner. Does anyone know how to incorporate a custom error handler
> when using sqlCipher?
>

> Constructors available in *android.database.sqlite*

>
> public SQLiteOpenHelper (Context context, String name, SQLiteDatabase.CursorFactory factory, int version);public SQLiteOpenHelper (Context context, String name, SQLiteDatabase.CursorFactory factory, int version, DatabaseErrorHandler errorHandler);
>

> Constructors available in *net.sqlcipher.database*

[edZilla]

Thanks for the response. Hope for a quick solution for the same.

 

Regards

ed

[Stephen Lombardo]

Hello Ed,

We did a bit more research into this over the past week. Unfortunately it doesn't look like this would be a very simple change. We're still committed to supporting API Level 7 and the changes required to implement the new functionality while preserving backwards compatibility would be relatively complex. As a result, while we agree that the provider's behavior of deleting corrupt databases is undesirable, we may not have a short-term fix for this. We'll continue to look into it as time permits, but I at least wanted to let you know where things stand today.

Cheers,
Stephen

[Chris Brody]

I have just made
https://github.com/sqlcipher/android-database-sqlcipher/pull/84 that
should allow a custom error handler without breaking any API Level 7
functionality. @Ed can you try rebuilding the libraries with these
changes and see if they help you?

[edZilla]

Chris,

Sorry for coming in late for this. Tried it just now and it works. Thanks.

 

However there were two minor issue and two major issues.

1. Minor issue: DefaultDatabaseErrorHandler.java and DatabaseErrorHandler are located in net.sqlcipher but they have net.sqlcipher.database as package name inside them. Also wherever they are imported they are referred to as being from net.sqlcipher.database. This gives compilation errors. Although it appears that it was just their location that was incorrect and I could have moved them to net.sqlcipher.database, I changed the package name and the import references to net.sqlcipher. I liked them being located in net.sqlcipher instead of net.sqlcipher.database. Please correct either their location or the references (and package name inside them).

 

2. Minor issue: I compiled the demo project for Android 4.1 (and Android 4.0.,3).

SQLiteDirectCursorDriver.java implements SQLiteCursorDriver. hence the implemented functions come with @Override preceeding them. This is not allowed in Android 4.0.3 and 4.1. So I had to remove the @Override line for each of those 2-3 functions.

3.Major Issue (at least to me): The size of libstlport_shared.so has increased significantly (from 582KB in 2.1.1 to 1.15MB now. This threq my project out of memory and I retained the old SO files from 2.1.1 hoping there wouldn't be any serious changes that would affect the operation and Java code in the project. Things seem to work. Please advice if this is incorrect. A little bit of explanation is appreciated. you can assume a good knowledge of native (jni) and Java/Android in your explanation.

4. Major Issue: Demo project did not work. It failed at SQLiteOpenHelper.getWritableDatabase() saying null pointer exception. It looks like the db that is created is null, probably because the password is incorrect. Once it also gave classDefNotFound error for Maps.newHashmap(). Please look at it.

 

Overall I would say it is working. Thanks again for the quick fix. Can you please get back on #3 above?

[Chris Brody]

I reply to a question from over a year ago. The changes that I proposed only affect the Java part and have no affect on the native part. While the build process can and rebuild the JNI native part I see no reason you cannot use the existing native libs.

Chris