TouchDB does not work on Android 4.1

Question

TouchDB does not work on Android 4.1

mschoch opened this issue 12 years ago · comments

java.lang.NoSuchFieldError: no field with name='mNativeHandle' signature='I' in class Landroid/database/sqlite/SQLiteDatabase;
at com.couchbase.touchdb.TDCollateJSON.nativeRegisterCustomCollators(Native Method)
at com.couchbase.touchdb.TDCollateJSON.registerCustomCollators(TDCollateJSON.java:10)
at com.couchbase.touchdb.TDDatabase.open(TDDatabase.java:222)
at com.couchbase.touchdb.TDDatabase.createEmptyDBAtPath(TDDatabase.java:161)
at com.couchbase.touchdb.testapp.tests.CRUDOperations.testCRUDOperations(CRUDOperations.java:46)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:190)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:175)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1584)

Marty Schoch · Answer 1 · Sun Jul 08 2012 05:29:02 GMT+0800 (China Standard Time)

TouchDB relies on some low-level implementation details to manually install our own collators using native code. On the surface it looks like those low-level details changed and broke our implementation. Unfortunately, source code for Android 4.1 is not available yet, making it hard to diagnose further.

‮rekcäH nitraM‮ · Answer 2 · Thu Jul 19 2012 21:32:47 GMT+0800 (China Standard Time)

Damn, running into this too.

I'ts kind of important for us to be able to deploy on 4.1 - can you maybe give an estimation when you'll be able to work on this one?

dehubbed · Answer 3 · Sun Jul 22 2012 17:51:58 GMT+0800 (China Standard Time)

Source code now available, this commit here is tagged "jb-release": http://omapzoom.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/database/sqlite/SQLiteDatabase.java;h=e2d44f2ab37b6f2f031b0da8c9ca94b7d1d8d13d;hb=c292a619c71a2ee56e42ca5ef45fbc62e5c09f1e

Not sure how what replaces the former mNativeHandle.

dehubbed · Answer 4 · Fri Jul 27 2012 17:32:27 GMT+0800 (China Standard Time)

maybe time to move the whole thing to H2 anyways, see here and here

Marty Schoch · Answer 5 · Sat Jul 28 2012 23:58:37 GMT+0800 (China Standard Time)

I've put in a fix that works in some cases (not convinced it works in all cases because of the way Android changed things)

ade012c

The unit tests pass and AndroidGrocerySync works as expected in the 4.1 emulator now, so its clearly an improvement worth sharing.

Nicholas Wilkie · Answer 6 · Mon Jul 30 2012 02:31:59 GMT+0800 (China Standard Time)

Could you elaborate on where you think we might run into trouble with this fix? Does it seem that the new hook may be device-dependent?

Marty Schoch · Answer 7 · Mon Jul 30 2012 22:29:04 GMT+0800 (China Standard Time)

The issue is that SQLiteDatabase no longer has a 1-1 mapping to the underlying sqlite handle (at the c library layer). Ideally, whenever a new sqlite handle is opened, we need to register our custom collation functions there. Now, SQLiteDatabase has a ThreadLocal reference to a SQLiteSession, which has reference to a SQLiteConnectionPool which has a pool of SQLiteConnections's. Each of these has their own sqlite handle (at the c library layer).

All of this means its a lot harder (maybe impossible) to reliably ensure our custom collation functions are always registered. I coded up what we needed to make sure it gets registered on the "primary" connection, which is the one that it uses when you first call openDatabase().

I actually didn't expect AndroidGrocerySync to work with this patch because I was pretty sure we have multiple threads accessing the SQLiteDatabase (in a coordinated manner). But, for some reason it does work. I have not had the time to go back and get a better understanding of why this is.

dehubbed · Answer 8 · Fri Aug 03 2012 23:59:40 GMT+0800 (China Standard Time)

I think you're taking the wrong approach here. Both native code and custom collators were KISS violations anyway and now this mess. So instead of registering a custom collator, compute an artificial collation key from the JSON that is e.g. a string and that has the quality that a comparison on that string with the built-in collator matches comparison on the corresponding JSON. Then store that key in the key column of your table. If you look at java.text.spi.CollatorProvider that comes with Open/Sun JDK (not Android) then you see it does the same thing (computing an artificial key) for performance reasons, only it is a binary blob.

Marty Schoch · Answer 9 · Sat Aug 04 2012 00:04:15 GMT+0800 (China Standard Time)

Thanks for the input, can you point me to any sample code doing this?

dehubbed · Answer 10 · Sat Aug 04 2012 00:15:22 GMT+0800 (China Standard Time)

Sorry no. I had the artificial collation key mostly figured out in my mind when I did the research into porting TouchDB to H2/JDBC but I'd yet have to type it in.

dongsheng · Answer 11 · Tue Jan 01 2013 03:32:48 GMT+0800 (China Standard Time)

Maybe it is better to include SQLite code in TouchDB? That way TouchDB is independent from the underneath changes?

Traun Leyden · Answer 12 · Sat Jul 27 2013 03:23:19 GMT+0800 (China Standard Time)

I've been testing extensively on Android 4.2 with no observed issues. Just now tried 4.1 and didn't see any problems.