Status Update
Comments
ga...@gmail.com <ga...@gmail.com> #2
jb...@google.com <jb...@google.com>
ga...@freeletics.com <ga...@freeletics.com> #3
ap...@google.com <ap...@google.com> #5
In our case, we have b2b app running on dedicated devices.
After 1.1.0 DataStore update we had 6 terminals reported 30k androidx.datastore.core.CorruptionException
fatal crashes on app start.
We use DataStore in WorkManager jobs and on regular Activity starts. Seems that after the application gets this state it will never will succeed to start successfully again. I am afraid that data is being corrupted.
Can't reproduce. But same as OP, we have very vanilla usage of DataStore Preferences. No multiple processes, just simple read/write key-values in a single process single Activity.
cl...@google.com <cl...@google.com> #6
Hi, thanks for the feedback, noticed the number of +1s, I'll prioritize an investigation.
To facilitate the process, could you please share how you create the DataStore instance?
na...@google.com <na...@google.com> #7
Here is how we are creating our DataStore<Preferences>
instances:
PreferenceDataStoreFactory.create(
produceFile = { context.preferencesDataStoreFile(filename) }, // filename is [a-zA-Z]
scope = scope, // CoroutineScope(Dispatchers.IO + SupervisorJob())
migrations = listOf(
SharedPreferencesMigration(
context = context,
sharedPreferencesName = sharedPrefFile, // we are using our package name here
keysToMigrate = keysToMigrate, // a Set<String>, sometimes empty if nothing to be migrated
),
),
corruptionHandler = ReplaceFileCorruptionHandler {
// logging step omitted
emptyPreferences()
},
)
And these methods are called in Hilt @Provides
methods in a @InstallIn(SingletonComponent::class) @Module
for each preferences we use in our app.
na...@google.com <na...@google.com> #8
@Module
@InstallIn(SingletonComponent::class)
class PreferencesDataStoreModule {
@Provides
@Singleton
fun provideDataStore(@ApplicationContext context: Context): DataStore<Preferences> =
PreferenceDataStoreFactory.create(
produceFile = {
context.preferencesDataStoreFile(PREFERENCES_FILE_NAME)
},
)
}
Description
Version used: 2.6.0
Devices/Android versions reproduced on: Emulator Android 13
Very simple scenario for demo purposes:
1. MainFragment navigates to Dialog1Fragment
2. Dialog1Fragment navigates to Dialog2Fragment
3. Dialog2Fragment navigates back
This will result in the lifecycle of Dialog1Fragment's NavBackStackEntry to go back into `ON_START` but it will never go back to `ON_RESUME` even though it is now the top destination on the stack.
I've attached a small sample project with these 3 fragments