Fixed
Status Update
No update yet.
Comments
yb...@google.com
ya...@google.com
since these are in public API (:/) we need to do this in 1.2
mm...@commonsware.com
since it is already marked as deprecated, we can probably do it by now.
ya...@google.com
Opening diff shortly
mm...@commonsware.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/61 .
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/1396827
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request from
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
ya...@google.com
I think I am starting to understand the issue.
In InvalidationTracker, we catch exceptions from table monitoring query when database is closing.
We catch android.database.sqlite.SQLiteException, but other implementation such as sqlcipher might throw other exception types, such as net.sqlcipher.database.SQLiteException. That's why we can't see this in Room with framework sqlite.
We have to come up with a better way to handle db closing in InvalidationTracker.
In InvalidationTracker, we catch exceptions from table monitoring query when database is closing.
We catch android.database.sqlite.SQLiteException, but other implementation such as sqlcipher might throw other exception types, such as net.sqlcipher.database.SQLiteException. That's why we can't see this in Room with framework sqlite.
We have to come up with a better way to handle db closing in InvalidationTracker.
Description
Version used: 1.0.0-alpha3
Devices/Android versions reproduced on: Nexus 5X (ODP3)
The implementation of FrameworkSQLiteOpenHelper does not close the actual SQLite database. The static OpenHelper class' close() method is:
@Override
public synchronized void close() {
super.close();
mWrappedDb = null;
}
(based on the code distributed along with the 1.0.0-alpha3 artifact)
AFAICT, there should be an mWrappedDb.close() in there, as I do not see anything else that will ever close that FrameworkSQLiteDatabase.
I am back to working on SafeRoom, my SQLCipher for Android implementation of the Support* classes. If I add close() to my SupportSQLiteHelper.Factory as shown above, I then run into a related crash:
E/AndroidRuntime: FATAL EXCEPTION: pool-1-thread-1
Process: com.commonsware.cwac.saferoom.test, PID: 9294
net.sqlcipher.database.SQLiteMisuseException: library routine called out of sequence: , while compiling: SELECT * FROM room_table_modification_log WHERE version > ? ORDER BY version ASC;
at net.sqlcipher.database.SQLiteCompiledSql.native_compile(Native Method)
at net.sqlcipher.database.SQLiteCompiledSql.compile(SQLiteCompiledSql.java:91)
at net.sqlcipher.database.SQLiteCompiledSql.<init>(SQLiteCompiledSql.java:64)
at net.sqlcipher.database.SQLiteProgram.<init>(SQLiteProgram.java:84)
at net.sqlcipher.database.SQLiteQuery.<init>(SQLiteQuery.java:49)
at net.sqlcipher.database.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:42)
at net.sqlcipher.database.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1820)
at com.commonsware.cwac.saferoom.Database.query(Database.java:176)
at com.commonsware.cwac.saferoom.Database.query(Database.java:145)
at android.arch.persistence.room.RoomDatabase.query(RoomDatabase.java:156)
at android.arch.persistence.room.InvalidationTracker$2.run(InvalidationTracker.java:354)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
This is stemming from InvalidationTracker, and it is occurring sometime after I call close() on the RoomDatabase. If I either do not close() the RoomDatabase or I do not close() the actual database, this crash does not appear. My best guess is that close() on RoomDatabase is not shutting down related InvalidationTrackers, so those objects continue tracking, then get cranky when their database is closed.
Attached is a sample project. Running the instrumentation tests should reproduce the problem.