IssueTracker

Not at the moment. But we have been asked this before, so I will treat this as a feature request.

OK thanks. At the moment I am just adding the name to the Data for the work request and retrieving it in startWork(), which works well enough.

No # of crashes is not a good metric in this particular case. This is because when a crash happens JobScheduler will retry the job, and this leads to a large number of crashes from a small number of devices affected. So a good metric to track is the total number of unique devices affected.

When the amount of disk space is low, there are very few things WorkManager can do as a client library. Apps should determine what they would like to do. You can use https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html for this. (This is internally what libraries like Crashlytics use). You might want so show a dialog to the user to reinstall the app after they clear disk space.

Since WorkManager is initialized very early in your app lifecycle, it's quite likely that it will be the one that catches disk full errors first and be the first to fail. So this is a real problem that will affect your app no matter what, even if WorkManager wasn't there.

We are working on the design for a new API to address this.

For now, the best you can do is to use a https://developer.android.com/reference/kotlin/java/lang/Thread.UncaughtExceptionHandler and check if the underlying Exception points to a StackTraceElement that was WorkManager or look at unrecoverable SQLiteExceptions.

Nothing yet. We plan to have something in version 2.6.x time frame.

Fatal Exception: android.database.sqlite.SQLiteDiskIOException: disk I/O error (code 4874 SQLITE_IOERR_SHMSIZE): , while compiling: PRAGMA journal_mode
       at android.database.sqlite.SQLiteConnection.nativePrepareStatement(SQLiteConnection.java)
       at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:903)
       at android.database.sqlite.SQLiteConnection.executeForString(SQLiteConnection.java:648)
       at android.database.sqlite.SQLiteConnection.setJournalMode(SQLiteConnection.java:333)
       at android.database.sqlite.SQLiteConnection.setWalModeFromConfiguration(SQLiteConnection.java:298)
       at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:217)
       at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:195)
       at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked(SQLiteConnectionPool.java:503)
       at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:204)
       at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:196)
       at android.database.sqlite.SQLiteDatabase.openInner(SQLiteDatabase.java:880)
       at android.database.sqlite.SQLiteDatabase.open(SQLiteDatabase.java:865)
       at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:739)
       at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:729)
       at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:355)
       at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:298)
       at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase(FrameworkSQLiteOpenHelper.java:145)
       at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase(FrameworkSQLiteOpenHelper.java:106)
       at androidx.room.RoomDatabase.beginTransaction(RoomDatabase.java:352)
       at androidx.work.impl.utils.ForceStopRunnable.cleanUp(ForceStopRunnable.java:156)
       at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:87)
       at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:764)

on

Brand: Xiaomi
Model: MiBox S
Orientation: Portrait
RAM free: 1.12 GB
Disk free: 808 KB

So it crashes during app start-up, when there is no free disk space

We are planning on introducing this API in SQLite, and Room so this is going to take a bit longer. In the meantime, you can consider using the @Restricted API (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:work/workmanager/src/main/java/androidx/work/Configuration.java;l=468).

You will need to @Suppress restricted APIs for now.

Thanks for the update!

We are currently using setInitializationExceptionHandler method, and while it helped reducing crashes happening in ForceStopRunnable that solution doesn't cover the crashes happening in other runnables like WorkerWrapper

for Example:

Fatal Exception: android.database.sqlite.SQLiteDatabaseCorruptException
file is not a database (code 26 SQLITE_NOTADB)
	android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow (SQLiteConnection.java)
	android.database.sqlite.SQLiteConnection.executeForCursorWindow (SQLiteConnection.java:942)
	android.database.sqlite.SQLiteSession.executeForCursorWindow (SQLiteSession.java:838)
	android.database.sqlite.SQLiteQuery.fillWindow (SQLiteQuery.java:62)
	android.database.sqlite.SQLiteCursor.fillWindow (SQLiteCursor.java:153)
	android.database.sqlite.SQLiteCursor.getCount (SQLiteCursor.java:140)
	androidx.work.impl.model.WorkTagDao_Impl.getTagsForWorkSpecId (WorkTagDao_Impl.java:96)

Also please make sure to consider the native crashes as well when creating that API, since that's the majority of the crashes.

For example:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
android::nativePrepareStatement(_JNIEnv*, _jclass*, long, _jstring*)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.example <<<

backtrace:
  #00  pc 0000000000131658  /system/lib64/libandroid_runtime.so (android::nativePrepareStatement(_JNIEnv*, _jclass*, long, _jstring*)+96)
  #00  pc 00000000002b5c44  /system/framework/arm64/boot-framework.oat (art_jni_trampoline+180)
  #00  pc 000000000056cce0  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteConnection.acquirePreparedStatement+192)
  #00  pc 0000000000572e10  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteConnection.prepare+176)
  #00  pc 000000000046cbd0  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteSession.prepare+288)
  #00  pc 000000000057902c  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteProgram.<init>+444)
  #00  pc 0000000000575a14  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteDatabase.compileStatement+116)
  #00  pc 0000000000137334  /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548)
  #00  pc 000000000014606c  /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244)
  #00  pc 00000000002e0784  /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+384)
  #00  pc 00000000002dba64  /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+912)
  #00  pc 000000000059a38c  /apex/com.android.runtime/lib64/libart.so (MterpInvokeVirtual+648)
  #00  pc 0000000000131814  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_virtual+20)
  #00  pc 00000000003b66f2  /system/framework/framework.jar (android.database.sqlite.SQLiteDatabase.isDatabaseIntegrityOk+222)
  #00  pc 000000000059a69c  /apex/com.android.runtime/lib64/libart.so (MterpInvokeVirtual+1432)
  #00  pc 0000000000131814  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_virtual+20)
  #00  pc 00000000003ab30c  /system/framework/framework.jar (android.database.DefaultDatabaseErrorHandler.diagnoseDatabase+128)
  #00  pc 000000000059ca2c  /apex/com.android.runtime/lib64/libart.so (MterpInvokeDirect+1168)
  #00  pc 0000000000131914  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_direct+20)
  #00  pc 00000000003abb90  /system/framework/framework.jar (android.database.DefaultDatabaseErrorHandler.onCorruption+304)
  #00  pc 000000000059be90  /apex/com.android.runtime/lib64/libart.so (MterpInvokeInterface+1740)
  #00  pc 0000000000131a14  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_interface+20)
  #00  pc 00000000003b8a10  /system/framework/framework.jar (android.database.sqlite.SQLiteDatabase.onCorruption+80)
  #00  pc 00000000002b13d0  /apex/com.android.runtime/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.7142318256121416140)+240)
  #00  pc 000000000058b994  /apex/com.android.runtime/lib64/libart.so (artQuickToInterpreterBridge+1012)
  #00  pc 0000000000140468  /apex/com.android.runtime/lib64/libart.so (art_quick_to_interpreter_bridge+88)
  #00  pc 000000000068f1fc  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteQuery.fillWindow+732)
  #00  pc 00000000006d8fc8  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteCursor.fillWindow+344)
  #00  pc 00000000006d98e8  /system/framework/arm64/boot-framework.oat (android.database.sqlite.SQLiteCursor.getCount+56)
  #00  pc 000000000059900c  /data/app/com.example-2NKb9y8uQYC083YPNqBiBQ==/oat/arm64/base.odex (androidx.work.impl.n.u.a+300)
  #00  pc 00000000003f6124  /data/app/com.example-2NKb9y8uQYC083YPNqBiBQ==/oat/arm64/base.odex (androidx.work.impl.k.run+84)
  #00  pc 00000000003fbeb8  /data/app/com.example-2NKb9y8uQYC083YPNqBiBQ==/oat/arm64/base.odex (androidx.work.impl.utils.g$a.run+72)
  #00  pc 00000000002fa878  /system/framework/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+984)
  #00  pc 00000000002f7ee0  /system/framework/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+64)
  #00  pc 00000000001a5568  /system/framework/arm64/boot.oat (java.lang.Thread.run+72)
  #00  pc 0000000000137334  /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548)
  #00  pc 000000000014606c  /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244)
  #00  pc 00000000004ab9d4  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
  #00  pc 00000000004aca68  /apex/com.android.runtime/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue const*)+416)
  #00  pc 00000000004ecdac  /apex/com.android.runtime/lib64/libart.so (art::Thread::CreateCallback(void*)+1176)
  #00  pc 00000000000e28c0  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  #00  pc 000000000008503c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

Does the app use multiple processes ?

No, single process (Also checked the merged manifest to double check third party libraries defining android:process for any component, and couldn't find any)

I got the same issue when I use room v2.1.0 . Android 11

We are using latest stable work manager (2.8.1) and for very few users we see following exception and all those users are on Android 13

java.lang.IllegalStateException: The database '/data/user/10/<package-name>/no_backup/androidx.work.workdb' is not open.
	at android.database.sqlite.SQLiteDatabase.throwIfNotOpenLocked(SQLiteDatabase.java:2483)
	at android.database.sqlite.SQLiteDatabase.createSession(SQLiteDatabase.java:431)
	at android.database.sqlite.SQLiteDatabase$$ExternalSyntheticLambda1.get(Unknown Source:2)
	at java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:284)
	at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
	at java.lang.ThreadLocal.get(ThreadLocal.java:170)
	at android.database.sqlite.SQLiteDatabase.getThreadSession(SQLiteDatabase.java:425)
	at android.database.sqlite.SQLiteProgram.getSession(SQLiteProgram.java:105)
	at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:67)
	at androidx.sqlite.db.framework.FrameworkSQLiteStatement.executeUpdateDelete(FrameworkSQLiteStatement.kt:38)
	at androidx.work.impl.model.WorkSpecDao_Impl.setState(WorkSpecDao_Impl.java:380)
	at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:458)
	at androidx.work.impl.WorkerWrapper.rescheduleAndResolve(WorkerWrapper.java:558)
	at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:360)
	at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:335)
	at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
	at java.lang.Thread.run(Thread.java:1012)

The database '/data/user/10/<package-name>/no_backup/androidx.work.workdb' is not open.

this one is 99% of direct boot. You can add UserManagerCompat.isUserUnlocked(mContext) to see if it is the case, when you try to initialise WorkManager.

In the future version we've added better error message.

Not 100% sure where one is supposed to insert that check. In our app we initialize work manager like this

    @Provides
    @Singleton
    fun provideWorkManager(@ForApplication context: Context): WorkManager {
        return WorkManager.getInstance(context)
    }

So is the suggestion to change the code to something like this?

    @Provides
    @Singleton
    fun provideWorkManager(@ForApplication context: Context): WorkManager? {
        return if (UserManagerCompat.isUserUnlocked(mContext)) {
             WorkManager.getInstance(context)
        } else
             null
        }
    }

Also if the app doesn't explicitly declare that it is directBootAware, why is it even running? I don't have this android:directBootAware="true" directive in AndroidManifest.xml, do I really need to change workManager getInstance?

directBootAware could come from another library, you should check merged manifest of your application.

Indeed FirebaseMessagingService & ComponentDiscoveryService request directBoot

        <service
            android:name="com.google.firebase.messaging.FirebaseMessagingService"
            android:directBootAware="true"
            android:exported="false" >
            <intent-filter android:priority="-500" >
                <action android:name="com.google.firebase.MESSAGING_EVENT" />
            </intent-filter>
        </service>
        <service
            android:name="com.google.firebase.components.ComponentDiscoveryService"
            android:directBootAware="true"
            android:exported="false" >
            <meta-data
                android:name="com.google.firebase.components:com.google.firebase.messaging.FirebaseMessagingRegistrar"
                android:value="com.google.firebase.components.ComponentRegistrar" />
            <meta-data
                android:name="com.google.firebase.components:com.google.firebase.datatransport.TransportRegistrar"
                android:value="com.google.firebase.components.ComponentRegistrar" />
            <meta-data
                android:name="com.google.firebase.components:com.google.firebase.installations.FirebaseInstallationsRegistrar"
                android:value="com.google.firebase.components.ComponentRegistrar" />
        </service>

FirebaseMessagingService is an issue and we'll try to think what kind of pattern we can provide on WM side for better handling of this. For now you have to handle it on app side.

PS ComponentDiscoveryService doesn't do anything actually, so its directBootAware = true is kinda red herring.

Perhaps orthogonal - our app also "upgrade" the database if we detect new installs, I take it one should also defer execution of performing any database upgrades if UserManagerCompat.isUserUnlocked(mContext) returns false?

Perhaps updating WorkManager documentation to specifically call out the scenario of direct-boot might be useful to other developers as well.

Thanks for the help!

WorkManager 2.8.1

SQLiteCantOpenDatabaseException: Cannot open database '/data/user/0/<package_name>/no_backup/androidx.work.workdb': Directory /data/user/0/<package_name>/no_backup doesn't exist

comment #32, this is running in direct boot, that isn't supported.

We're seeing this exception for Android 9 and 10 devices only. We're not even making use of WorkManager directly.

Exception java.lang.IllegalStateException: The file system on the device is in a bad state. WorkManager cannot access the app's internal data store.
  at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:113)
  at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java)
  at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
  at java.lang.Thread.run (Thread.java:919)
Caused by android.database.sqlite.SQLiteCantOpenDatabaseException: unknown error (code 14 SQLITE_CANTOPEN): Could not open database
  at android.database.sqlite.SQLiteConnection.nativeOpen
  at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:215)
  at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:197)
  at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked (SQLiteConnectionPool.java:505)
  at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:206)
  at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:198)
  at android.database.sqlite.SQLiteDatabase.openInner (SQLiteDatabase.java:915)
  at android.database.sqlite.SQLiteDatabase.open (SQLiteDatabase.java:895)
  at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:759)
  at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:748)
  at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:374)
  at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:317)
  at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase (FrameworkSQLiteOpenHelper.java)
  at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase (FrameworkSQLiteOpenHelper.java)
  at androidx.room.RoomDatabase.inTransaction (RoomDatabase.java)
  at androidx.room.RoomDatabase.assertNotSuspendingTransaction (RoomDatabase.java)
  at androidx.work.impl.model.SystemIdInfoDao_Impl.getWorkSpecIds (SystemIdInfoDao_Impl.java:50)
  at androidx.work.impl.background.systemjob.SystemJobScheduler.reconcileJobs (SystemJobScheduler.java:50)
  at androidx.work.impl.utils.ForceStopRunnable.cleanUp (ForceStopRunnable.java:50)
  at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable (ForceStopRunnable.java:50)
  at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:32)

Please, let us know if there is any work being done for this issue. We are seeing in several Android versions, 9, 10, 11, 12, 13. pretty even amount device types too.

android.database.sqlite.SQLiteCantOpenDatabaseException:unknown error (code 14 SQLITE_CANTOPEN): Could not open database
at androidx.work.impl.utils . ForceStopRunnable . run() (ForceStopRunnable.java:153)
at androidx.work.impl.utils . SerialExecutorImpl . run() (SerialExecutorImpl.java:96)
at java.util.concurrent . ThreadPoolExecutor . runWorker() (ThreadPoolExecutor.java:1167)
at java.util.concurrent . ThreadPoolExecutor . run() (ThreadPoolExecutor.java:641)
at java.lang . Thread . run() (Thread.java:919)
at Caused by android.database.sqlite.SQLiteCantOpenDatabaseException:unknown error (code 14 SQLITE_CANTOPEN): Could not open database()
at android.database.sqlite . SQLiteConnection . nativeOpen() (SQLiteConnection.java:-2)
at android.database.sqlite . SQLiteConnection . open() (SQLiteConnection.java:215)
at android.database.sqlite . SQLiteConnection . open() (SQLiteConnection.java:197)
at android.database.sqlite . SQLiteConnectionPool . openConnectionLocked() (SQLiteConnectionPool.java:505)
at android.database.sqlite . SQLiteConnectionPool . open() (SQLiteConnectionPool.java:206)
at android.database.sqlite . SQLiteConnectionPool . open() (SQLiteConnectionPool.java:198)
at android.database.sqlite . SQLiteDatabase . openInner() (SQLiteDatabase.java:915)
at android.database.sqlite . SQLiteDatabase . open() (SQLiteDatabase.java:895)
at android.database.sqlite . SQLiteDatabase . openDatabase() (SQLiteDatabase.java:759)
at android.database.sqlite . SQLiteDatabase . openDatabase() (SQLiteDatabase.java:748)
at android.database.sqlite . SQLiteOpenHelper . getDatabaseLocked() (SQLiteOpenHelper.java:374)
at android.database.sqlite . SQLiteOpenHelper . getWritableDatabase() (SQLiteOpenHelper.java:317)
at androidx.sqlite.db.framework . FrameworkSQLiteOpenHelper . getWritableOrReadableDatabase() (FrameworkSQLiteOpenHelper.kt:232)
at androidx.sqlite.db.framework . FrameworkSQLiteOpenHelper . innerGetDatabase() (FrameworkSQLiteOpenHelper.kt:223)
at androidx.sqlite.db.framework . FrameworkSQLiteOpenHelper . getSupportDatabase() (FrameworkSQLiteOpenHelper.kt:151)
at androidx.sqlite.db.framework . FrameworkSQLiteOpenHelper . getWritableDatabase() (FrameworkSQLiteOpenHelper.kt:104)
at androidx.room . RoomDatabase . inTransaction() (RoomDatabase.kt:638)
at androidx.room . RoomDatabase . assertNotSuspendingTransaction() (RoomDatabase.kt:457)
at androidx.work.impl.model . SystemIdInfoDao_Impl . getWorkSpecIds() (SystemIdInfoDao_Impl.java:163)
at androidx.work.impl.background.systemjob . SystemJobScheduler . reconcileJobs() (SystemJobScheduler.java:311)
at androidx.work.impl.utils . ForceStopRunnable . cleanUp() (ForceStopRunnable.java:278)
at androidx.work.impl.utils . ForceStopRunnable . forceStopRunnable() (ForceStopRunnable.java:242)
at androidx.work.impl.utils . ForceStopRunnable . run() (ForceStopRunnable.java:134)
at androidx.work.impl.utils . SerialExecutorImpl . run() (SerialExecutorImpl.java:96)
at java.util.concurrent . ThreadPoolExecutor . runWorker() (ThreadPoolExecutor.java:1167)
at java.util.concurrent . ThreadPoolExecutor . run() (ThreadPoolExecutor.java:641)
at java.lang . Thread . run() (Thread.java:919

For folks facing this issue:

There are many reasons why this could happen. This is a result of an underlying framework bug but one of the common cases is:

When an app is using multiple processes, and does not designate a "default" process using the https://developer.android.com/reference/androidx/work/Configuration.Builder#setDefaultProcessName(kotlin.String) API.

We recently added APIs that allow the app to recover.

https://developer.android.com/reference/androidx/work/Configuration.Builder#setInitializationExceptionHandler(androidx.core.util.Consumer)

This API can be used to clear your datastore, and start over from a clean slate.

The default process name is the same as the package name of the app.

Secondary processes are defined in your AndroidManifest.xml using the :suffix convention.

If your package name is com.example.app, and your manifest defines a :secondary process then you will run as 2 processes:

• com.example.app, and com.example.app:secondary.

You can use https://developer.android.com/reference/android/app/ActivityManager#clearApplicationUserData() API.

@46 That's not a good solution. This API doesn't even bring back the app when it's done. It force-stop of it...

Re #44 - is it possible that having a service with isolatedProcess=true in our manifest could trigger the multi-process issue?

Also, if the answer to #48 is yes and we are able to add a call to setDefaultProcessName to fix, would we need to also add the setInitializationExceptionHandler call and clear user data in order to get users out of a crash loop state? Or would just the former likely be enough and these crashes would stop once we set default process name? Would love to avoid clearing app data if possible.