androidx.datastore crashes with java.io.FileNotFoundException: /data/user/0/com.app.id/files/datastore/a_datastore.preferences_p [337870543]

Fixed

Bug

Status Update

No update yet.

Description

mk...@opera.com

created issue #1

Apr 30, 2024 06:11AM

DataStore Component used: androidx.datastore for Android DataStore Version used: 1.1.0 Devices/Android versions reproduced on: Seems not connected to any specific device/Android version as we see it on many different ones on all Android versions.

After updating androidx.datastore from 1.0.0 to 1.1.0 we started to see a lot of the following crashes.

Fatal Exception: java.io.FileNotFoundException: /data/user/0/com.app.id/files/datastore/a_datastore.preferences_pb: open failed: ENOENT (No such file or directory)
       at libcore.io.IoBridge.open(IoBridge.java:574)
       at java.io.FileInputStream.<init>(FileInputStream.java:160)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.kt:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:111)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:99)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:585)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:693)

The crashes happen on app startup when we try read from the datastore early in the app startup process. We see a lot of them in the wild. Happened to us locally few times as well, but it's very rare and unpredictable which makes it hard to debug.
Among other calls we use runBlocking to read from the datastore in one place
Our app is single process and we only create the datastore once
We use single process datastore (the code didn't change after updating the lib)

Comments

mk...@opera.com <mk...@opera.com> #2Apr 30, 2024 07:37AM

Hi all, I've implemented custom navigator to provide with Navigation Shared Elements transition ability

https://github.com/lion4ik/aac-navigation-shared-elements-transition

se...@opera.com <se...@opera.com> #3May 8, 2024 09:17AM

Is there any info if it's planned to be implemented?

to...@gmail.com <to...@gmail.com> #4May 27, 2024 12:41PM

Support for shared elements for both activities and fragments has been added in

https://android-review.googlesource.com/c/platform/frameworks/support/+/752138 through the introduction of a general purpose Navigator.Extras interface, providing a way to send a specific Navigator extra information at runtime (such as the Views you want included in shared element transitions).

This means for activity destinations, you can now provide any ActivityOptionsCompat instance you want alongside your navigate() call. For fragment destinations, you provide a map of shared elements. Documentation will be provided for both of these use cases.

This will be available in 1.0.0-alpha06.

mk...@opera.com <mk...@opera.com> #5Jun 13, 2024 11:35AM

Yes, it's worked in 1.0.0-alpha06, but only in forward direction...

Component used: Navigation
Version used: 1.0.0-alpha06
Devices/Android versions reproduced on: All

Fragment one: RecyclerView (GridLayoutManager). Transition name to ImageView is assigned in Adapter from model's name (unique)
Fragment two: Detail Fragment with ImageView and some text data. Transition name retrieved from argument's bundle.

Forward shared transition works excellent, but when I press "back" button there is no transition at all.
In NavHostActivity: override fun onSupportNavigateUp() = findNavController(R.id.nav_host_fragment).navigateUp()

In old paradigm

fragmentManager
.beginTransaction()
.addSharedElement(sharedImageView, transitionName)
all worked fine.

di...@gmail.com <di...@gmail.com> #6Jul 1, 2024 09:02AM

https://issuetracker.google.com/issues/116250233 has an example of Shared Element transitions that works in both directions, so this is likely due to the edge cases of shared element transitions and not something caused by navigation. Please open a new issue with a sample project if you're still running into issues.

da...@asana.com <da...@asana.com> #7Jul 12, 2024 12:20AM

exact same issue, we went from 1.0.0 to 1.1.1 and are encountering this!

mi...@outlook.com <mi...@outlook.com> #8Jul 17, 2024 07:35PM

Did some testing: for 200 fresh app installs there is 10-15 crashes on startup on Android 14.

ju...@ratpsmartsystems.com <ju...@ratpsmartsystems.com> #9Jul 18, 2024 01:06PM

Same problem here. Happens on app startup as well. But we do have a higher numer of crashes compared to users impacted. So maybe some users tried to launch the app again and it happened.
We had the problem with 1.0.0, updating the lib to 1.1.0 didn't change anything.

br...@linear.app <br...@linear.app> #10Aug 19, 2024 06:18PM

Downgrading from 1.1.1 to 1.0.0 has seemingly resolved the issue for us.

mk...@opera.com <mk...@opera.com> #11Aug 19, 2024 06:54PM

Downgrading is not an option for us as we need multiplatform support.

dc...@openai.com <dc...@openai.com> #12Sep 23, 2024 10:58PM

We are seeing a pretty high volume of this - would be great if DataStore had more graceful handling out of the box, or had a pluggable way to customize it (like with the ReplaceFileCorruptionHandler).

Right now, there doesn't seem to be a straightforward way to change the error handling here, without adding an abstraction above the DataStore itself.

ja...@gmail.com <ja...@gmail.com> #13Oct 21, 2024 10:30AM

I'm not sure why the above error is happening. It seems to be expecting the file to be created first and then queried.

Is there a timing issue?

Message last modified on Oct 21, 2024 10:31AM

dc...@openai.com <dc...@openai.com> #14Oct 30, 2024 08:07PM

Downgrading to 1.0.0 appears to have fixed this for us

du...@gmail.com <du...@gmail.com> #15Nov 14, 2024 05:46AM

I got the same issue with version 1.1.1. We have to use 1.1.1 to support Kotlin Multiplatform. Is there any update for this critical issue?

zh...@google.com <zh...@google.com> #16Dec 11, 2024 08:43PM

Reassigned to zh...@google.com.

Sorry for the delay of responding to this issue, as we've seen similar issues in the other bugs and followed up there. This is hard for us to debug as it seems to be a race condition and we cannot easily reproduce it and understand the root cause. Please help us by providing more details (device populations, API levels, or anything you discover as relevant to the bug distribution) from your observation of its occurrence! Also a sample app to reproduce would be great if possible.

In the meantime, I'll try to do some more investigation with the given information. Thanks for your patience.

ps...@google.com <ps...@google.com> #17Dec 12, 2024 09:48AM

It does not seem to be limited to a specific API, I see logs on API 10 to 15.

These are the errors I see on Crashlytics on a Pixel 8 Pro (unfortunately I have not been able to reproduce locally):

Fatal Exception: java.io.FileNotFoundException: /data/user/0/com.myapp/files/datastore/tracked apps.preferences_pb: open failed: ENOENT (No such file or directory)
       at libcore.io.IoBridge.open(IoBridge.java:574)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

Caused by android.system.ErrnoException: open failed: ENOENT (No such file or directory)
       at libcore.io.Linux.open(Linux.java)
       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:8591)
       at libcore.io.IoBridge.open(IoBridge.java:560)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

ma...@marcardar.com <ma...@marcardar.com> #18Jan 13, 2025 12:42PM

I've also been seeing this since updating from 1.0.0 (problem exists in both 1.1.0 and 1.1.1) and so I had to downgrade to 1.0.0 to avoid these crashes.

Has anyone tried: https://developer.android.com/topic/libraries/architecture/datastore?hl=en#handle-file-corruption ? Does it help?

UPDATE: no it doesn't help

Message last modified on Jan 15, 2025 10:46AM

ma...@marcardar.com <ma...@marcardar.com> #19Jan 15, 2025 10:48AM

Comment has been deleted.

Message last modified on Jan 16, 2025 03:50PM

ni...@usecopper.com <ni...@usecopper.com> #20Jan 21, 2025 02:47PM

having the same issue. Seeing that there is no solution yet, as a temporary test fix, we're considering making a dummy DataStore call immediately at the app startup and catching the exception

in...@gmail.com <in...@gmail.com> #21Feb 7, 2025 01:53PM

Also, had the same issue using it in the compose multiplatform project with datastore library of version "1.1.1"

el...@google.com <el...@google.com> Feb 14, 2025 07:28AM

Reassigned to el...@google.com.

el...@google.com <el...@google.com> #22Feb 15, 2025 02:59AM

Hi there - we were able to reproduce the issue on our end, a fix is in the works. I'll update here once we have it merged & ready for release.

el...@google.com <el...@google.com> #23Feb 19, 2025 12:00AM

Marked as fixed.

This issue should be fixed for the upcoming 1.1.3 release. Please let us know if the issue persists after the release.

ap...@google.com <ap...@google.com> #24Feb 19, 2025 12:02AM

Project: platform/frameworks/support
Branch: androidx-main
Author: elifbilgin <elifbilgin@google.com>
Link: https://android-review.googlesource.com/3496412

Resolve FileNotFoundException issue in OkioStorage at startup.

Expand for full commit details

Resolve FileNotFoundException issue in OkioStorage at startup. 
 
This change introduces a second attempt at reading a file in OkioStorage `readData()`, in case the initial read attempt failed due to a race condition caused by in the file being created by a different process. 
 
Bug: 337870543 
Test: Tested locally via aosp/3496411. 
Change-Id: I43b3fb565cc76344bc14c7dc3964ff76b2319358

Files:

M datastore/datastore-core-okio/src/commonMain/kotlin/androidx/datastore/core/okio/OkioStorage.kt
A datastore/datastore-core-okio/src/commonTest/kotlin/androidx/datastore/core/okio/OkioFakeFileSystem.kt
M datastore/datastore-core-okio/src/commonTest/kotlin/androidx/datastore/core/okio/OkioStorageTest.kt
M datastore/datastore-core/src/jvmAndroidMain/kotlin/androidx/datastore/core/FileStorage.kt

Hash: 3e2cc72ab89a0c011f99627a61eba045d7378cb5
Date: Thu Feb 13 23:25:56 2025

ki...@protonmail.com <ki...@protonmail.com> #25Feb 24, 2025 07:14PM

still present in 1.1.2

only present on Android/JVM no problem on iOS

Message last modified on Feb 24, 2025 07:16PM

el...@google.com <el...@google.com> #26Feb 24, 2025 07:29PM

Thanks for the update regarding the platform specific behavior, we are still working on pinpointing the issue

el...@google.com <el...@google.com> #27Feb 24, 2025 07:32PM

kikoski@protonmail.com Could you share some info on how you are initializing/setting up your datastore?

el...@google.com <el...@google.com> #28Feb 25, 2025 12:22AM

Apologies, this issue is resolved and the fix will be available in 1.1.3