Confusing error with database filename when moving to AndroidSQLiteDriver [377830104]

Fixed

Bug

Status Update

No update yet.

Description

an...@mobile-power.co.uk

created issue #1

Nov 7, 2024 02:33PM

Component used: room

Version used: 2.7.0-alpha11

Devices/Android versions reproduced on: Android 11

I was porting our code over to the new AndroidSQLiteDriver. We previously pass in a database name of "data.db", like so:

Room.databaseBuilder(context, AppDatabase::class.java, "data.db")

With the new AndroidSQLiteDriver, it appears it requires an absolute path for the file. It doesn't give a clear error message about this however - it just says something about a read-only filesystem, (presumably it's resolving the filename against a read-only folder, instead of my app's database folder). Can you handle this case to give a clearer error message?

FATAL EXCEPTION: arch_disk_io_1 @coroutine#33
 java.lang.IllegalStateException: Unable to lock file: 'data.db.lck'.
	at androidx.room.concurrent.FileLock.lock(FileLock.jvmAndroid.kt:49)
	at androidx.room.concurrent.ExclusiveLock.withLock(ExclusiveLock.kt:46)
	at androidx.room.BaseRoomConnectionManager$DriverWrapper.open(RoomConnectionManager.kt:59)
	at androidx.room.coroutines.AndroidSQLiteDriverConnectionPool$androidConnection$2.invoke(AndroidSQLiteDriverConnectionPool.android.kt:38)
	at androidx.room.coroutines.AndroidSQLiteDriverConnectionPool$androidConnection$2.invoke(AndroidSQLiteDriverConnectionPool.android.kt:37)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
	at androidx.room.coroutines.AndroidSQLiteDriverConnectionPool.getAndroidConnection(AndroidSQLiteDriverConnectionPool.android.kt:37)
	at androidx.room.coroutines.AndroidSQLiteDriverConnectionPool.useConnection(AndroidSQLiteDriverConnectionPool.android.kt:45)
	at androidx.room.RoomConnectionManager.useConnection(RoomConnectionManager.android.kt:126)
	at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:583)
	at androidx.room.TriggerBasedInvalidationTracker.syncTriggers$room_runtime_release(InvalidationTracker.kt:290)
	at androidx.room.InvalidationTracker$addObserver$1.invokeSuspend(InvalidationTracker.android.kt:261)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:277)
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:95)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:69)
	at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source:1)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
	at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source:1)
	at androidx.room.InvalidationTracker.addObserver(InvalidationTracker.android.kt:261)
	at androidx.room.InvalidationTracker.addWeakObserver(InvalidationTracker.android.kt:303)
	at androidx.room.RoomTrackingLiveData.refresh(RoomTrackingLiveData.android.kt:69)
	at androidx.room.RoomTrackingLiveData.access$refresh(RoomTrackingLiveData.android.kt:40)
	at androidx.room.RoomTrackingLiveData$onActive$1.invokeSuspend(RoomTrackingLiveData.android.kt:123)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at java.lang.Thread.run(Thread.java:1012)
	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [CoroutineId(33), "coroutine#33":StandaloneCoroutine{Cancelling}@9f42369, androidx.arch.core.executor.ArchTaskExecutor$$ExternalSyntheticLambda1@bf341ee]
 Caused by: java.io.FileNotFoundException: data.db.lck: open failed: EROFS (Read-only file system)
	at libcore.io.IoBridge.open(IoBridge.java:574)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:259)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:208)
	at androidx.room.concurrent.FileLock.lock(FileLock.jvmAndroid.kt:44)
	... 29 more
 Caused by: android.system.ErrnoException: open failed: EROFS (Read-only file system)
	at libcore.io.Linux.open(Native Method)
	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
	at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274)
	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
	at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:8070)
	at libcore.io.IoBridge.open(IoBridge.java:560)
	... 32 more

I was able to fix by using an absolute path like below, but it wasn't very easy to work out the problem.

Room.databaseBuilder(context, AppDatabase::class.java, context.getDatabasePath("data.db").absolutePath)

Comments

da...@google.com <da...@google.com> Jan 17, 2025 07:09PM

Reassigned to da...@google.com.

da...@google.com <da...@google.com> Jan 21, 2025 05:20PM

Accepted by da...@google.com.

ap...@google.com <ap...@google.com> #2Jan 24, 2025 03:55AM

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

da...@google.com <da...@google.com> Jan 24, 2025 01:34PM

Marked as fixed.

na...@google.com <na...@google.com> #3Jan 29, 2025 06:11PM

If the investigation takes time, would it be possible to revert the surrounding implementation to 1.6.x equivalent?

Or is that option not available?

Even if the root cause is POBox, from the perspective of the app's customers, it looks like an app bug, so this issue is a blocker against updating Jetpack Compose.

Issue 377830104