Large vault items might crash the new Android (native) app.

[ryanjaeb]

The Bitwarden Android app has been crashing on me since I got the updated native version. I took some time to start digging into it tonight and I think my issue may have been caused by a large item in my vault.

There's a caveat to my explanation. I didn't notice the Android app updated to 2025.1.1 before I started debugging tonight, so it's also possible some of the other bug fixes in the release notes included something that resolved my issue.

The app would crash for me after entering my credentials and successfully completing MFA. Without biometric unlock it would crash immediately after entering my password. I watched the logs from my phone while it crashed and this is what looked relevant to me:

02-01 22:21:23.550 28648 28723 E AndroidRuntime: FATAL EXCEPTION: arch_disk_io_1
02-01 22:21:23.550 28648 28723 E AndroidRuntime: Process: com.x8bit.bitwarden, PID: 28648
02-01 22:21:23.550 28648 28723 E AndroidRuntime: android.database.sqlite.SQLiteBlobTooBigException: Row too big to fit into CursorWindow requiredPos=714, totalRows=715
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow(Native Method)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteConnection.executeForCursorWindow(SQLiteConnection.java:1050)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteSession.executeForCursorWindow(SQLiteSession.java:873)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:62)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:153)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.sqlite.SQLiteCursor.onMove(SQLiteCursor.java:123)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:269)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at android.database.AbstractCursor.moveToNext(AbstractCursor.java:301)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at C7.c.call(Unknown Source:1199)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at D2.b.invokeSuspend(Unknown Source:320)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at Jb.a.resumeWith(Unknown Source:7)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at ec.K.run(Unknown Source:109)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        at java.lang.Thread.run(Thread.java:1012)
02-01 22:21:23.550 28648 28723 E AndroidRuntime:        Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [t0{Cancelling}@773ae8, Dispatchers.Unconfined]
02-01 22:21:23.556 28648 28723 I Process : Sending signal. PID: 28648 SIG: 9

A bit earlier in the log I saw:

02-01 22:21:23.452 28648 28722 E SQLiteQuery: exception: Row too big to fit into CursorWindow requiredPos=714, totalRows=715; query: SELECT * FROM ciphers WHERE user_id = ?
02-01 22:21:23.453 28648 28723 E SQLiteQuery: exception: Row too big to fit into CursorWindow requiredPos=714, totalRows=715; query: SELECT * FROM ciphers WHERE user_id = ?

Taking a bit of a guess, I knew I had an old export from Enpass where I dumped 62k lines of JSON into the notes field of secure note, so I deleted that item from a working app. The Android app still crashed after that, but, after deleting all app data and caches, I was able to log in successfully. Maybe the app loads the existing DB and defers syncing from the server until after the existing DB is loaded (that's a guess). In that case, it would make sense that I deleted a problematic item from the DB and clearing data forced a new sync of a working DB when I re-did the setup.

Another possibility is that clearing the app data and caches helped to clean up from a bug in the previous version. If I would have realized the app was updated I would have done that before starting so I'd know for sure.

I tried to re-add my huge Enpass export using the Windows app, web app, and the Firefox addon. None of them would let me. All of them failed with an error message:

The field Notes exceeds the maximum encrypted value length of 10000 characters.

I think I used the web app to do the initial setup of my vault, but it was almost 4 years ago (Jul 2021), so I'm not positive. Maybe an older version of the web app allowed data to violate constraints that are assumed to be in place by newer implementations.

Looking at my DB also casts some doubt on whether or not the long note caused the issue. I have more than one note that exceeds 10,000 bytes. With .headers on and .mode column to make things look nice, I see this:

select uuid,user_uuid,length(notes) from ciphers where length(notes) > 9999;

uuid                                  user_uuid                             length(notes)
------------------------------------  ------------------------------------  -------------
b1657634-fcfd-493c-ad3f-3e0f13e2d52e  b2f...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  2909556
debc4db2-4c5f-40e5-a42a-80d0aeda2ade  cf1...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  89544
3f5bd962-48ff-4e43-b618-6daf58215e98  b2f...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  26760

The note field I deleted was 2,182,092 characters, so close to 2,909,556 and that's the row that's gone after I deleted the entry from my vault. I'm not sure what the other ~700k would be. I'm also not sure why the other two smaller, but >10k length items don't cause issues. I know my user is b2f....

Sorry I don't have something more definitive to offer, but I've seen several complaints the new Android app crashes, so if anyone else runs into a similar error maybe this will help give a possible cause that can be investigated.

[BlackDex]

My guess would be there was of cached data on which the client broke. Clearing all data should have been enough i think.
Vaultwarden had several fixes done to return this data in a valid way.

If you want to add it back again you need to configure a setting.

vaultwarden/.env.template

Line 439 in 1109293

# INCREASE_NOTE_SIZE_LIMIT=false

That should make it possible again.