SQLCipher for Android Refresh (Beta)

We are happy to announce the beta availability of a new SQLCipher for Android client library. This new library provides major benefits including optimized support for concurrent database access, drastic performance improvements, API simplification, and codebase modernization. Please read more about this here:

More information is needed on how to build this new library using OpenSSL 3.0 and the FIPS provider module. (ie build flags, config files, loading of the FIPS provider, calling validation tests, etc.).

Hi, any timelines for publishing SQLCypher for Android Refresh Community editions as stated in the linked announcement? Thanks.

Hi @Alain_El_Hakim

We don’t have a time frame yet, however, it will likely align with a public SQLCipher core release in the future. Please keep an eye on the Discuss site, we’ll create a post as soon as it is available.

Hi @developernotes , appreciate your prompt response. If I am correct, the Android Refresh library is already available in the commercial version (in Beta), where could I read more about the commercial licensing? Thanks.

Hi @Alain_El_Hakim

That is correct, Commercial licenses of SQLCipher for Android may be purchased here.

Hi,
That’s great, we are dealing with the following exception causing our app to crash (we are actually on the community release version), and it is giving us hard time to reproduce. Can you suggest a way how we can verify that new library resolves that issue. Or maybe if you could help to pinpoint the root cause.

Fatal Exception: java.util.concurrent.TimeoutException: net.sqlcipher.database.SQLiteCompiledSql.finalize() timed out after 10 seconds
at net.sqlcipher.database.SQLiteCompiledSql.native_finalize(SQLiteCompiledSql.java)
at net.sqlcipher.database.SQLiteCompiledSql.releaseSqlStatement(SQLiteCompiledSql.java:103)
at net.sqlcipher.database.SQLiteCompiledSql.finalize(SQLiteCompiledSql.java:141)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:209)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:192)
at java.lang.Thread.run(Thread.java:818)

We really appreciate your help.

Thanks,
A.

Hi @Alain_El_Hakim

What version of SQLCipher for Android are you using? We removed the locking around the finalizer last year. If you aren’t running the latest (currently 4.5.1), you might consider upgrading. Also, you can try calling setLockingEnabled(false) on your connection once opened.

We getting the same exception

java.util.concurrent.TimeoutException: net.sqlcipher.database.SQLiteCompiledSql.finalize() timed out after 10 seconds
at net.sqlcipher.database.SQLiteCompiledSql.native_finalize(Native Method)
at net.sqlcipher.database.SQLiteCompiledSql.releaseSqlStatement(SQLiteCompiledSql.java:103)
at net.sqlcipher.database.SQLiteCompiledSql.finalize(SQLiteCompiledSql.java:141)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:202)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:185)
at java.lang.Thread.run(Thread.java:818)

Note this looks like it has the fix you mentioned about removing the locking around finalizer, but it’s happening in the native_finalize method. Using version 4.5.2

In this case we should call setLockingEnabled(false) ?

Thanks,

Pradeep

Hi @pradeep07,

Can you try setting setLockingEnabled(false) and report back the behavior observed?

sure will try but in this case it’s not calling the lock() and unlock() methods correct? unlike in previous versions there was locking around finalizer so would call setLockingEnabled(false) have any affect?

Will give this try anyways and see

Thanks,

Pradeep

Hi @pradeep07,

Correct, the Java locking on the database was removed surrounding the call to native_finalize() for the purposes of finalizing the internal sqlite3_stmt, however, since the lock still exists within the SQLiteDatabase instance, it would be good to verify it isn’t causing a conflict for your use case.

Thanks for the clarification. I haven’t been able to reproduce yet in my environment yet. Waiting to try in another environment where it was reproducible a lot and will confirm

Thanks,

Pradeep

Sorry for the delay, but we were able to reproduce with setLockingEnabled(false) as well on the android device.

java.util.concurrent.TimeoutException: net.sqlcipher.database.SQLiteCompiledSql.finalize() timed out after 10 seconds
at net.sqlcipher.database.SQLiteCompiledSql.native_finalize(Native Method) ~[na:0.0]
at net.sqlcipher.database.SQLiteCompiledSql.releaseSqlStatement(SQLiteCompiledSql.java:103) ~[na:0.0]
at net.sqlcipher.database.SQLiteCompiledSql.finalize(SQLiteCompiledSql.java:141) ~[na:0.0]
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:202) ~[na:0.0]
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:185) ~[na:0.0]
at java.lang.Thread.run(Thread.java:818) ~[na:0.0]

We do have parallel threads reading and writing to the db just FYI

Hello @pradeep07,

Since it sounds as if you are using the SQLCipher for Android legacy library, if you would please submit a pull request with a new test case which reproduces the behavior in the test suite, we would be happy to look into this further. Thanks!

Thanks I’ll take at seeing if i can add a testcase. One question I don’t have WAL enabled is that necessary? Or should i also try to increase the timeout? I have seen in previous posts that increasing the timeout did not take an effect?

Thanks,

Pradeep

Hi @pradeep07,

You do not necessarily need to use WAL, however, in concurrent usage of SQLCipher, WAL provides more concurrency as readers do not block writers and writers do not block readers. WAL can be faster in most scenarios. It will be helpful to review the public test case to better understand the situation.