IssueTracker

Component used: Room.
Version used: 2.6.1.
Devices/Android versions reproduced on: Google Pixel 2 emulators with Android 10 and 11.

Steps to reproduce.

1. Create an @Entity with some property of ByteArray type. This property is going to be turned by Room into an SQL table's column.
2. Create a simple @Dao declaring only a couple of functions to write and read the entity [1] above.
3. Create an instance of the entity [1] with its ByteArray property filled by some random byte sequence of relatively big size - the issues start to appear when it is at least of about 1-2 MBs in its size.
4. Write this instance [3] into the database by the DAO [2]. Whatever size for the ByteArray [3] is used there are usually no problems on this step.
5. Try to read the record you've just written at the previous step [4]: if it's big enough and doesn't fit into a CursorWindow, this data reading attempt will crash with SQLiteBlobTooBigException.

While it seems to be discouraged to keep large BLOBs in SQLite databases, I think it's better to provide an option for Room users to either get the crash in this case or just performance decrease with a corresponding warning in logcat.

Possible ways to avoid the crash.

1. Just allow to adjust the size of CursorWindow when building RoomDatabase instances. Unsure if it can be easily done for all Android versions just by available public APIs.
2. Read such large BLOBs sequentially by chunks in cases when they don't fit into CursorWindow. It can be done by querying the length of BLOB first and then reading it by chunks of, let's say, 1 MB by using another SQLite's function - substr. There can be a config for androidx.room.Room#databaseBuilder to prefer such fallback reading for large BLOBs or just crash as it's done now.