4

I'm currently creating an Android application that uses a prepackaged database. The database is initially around 40MB in size and is stored in the assets/databases folder.

The Problem
When I look up how much space my application is using, the "App Info" page shows the following:

  • App Size: ~25mb
  • User Data: ~3mb
  • Cache: ~45mb


Here is a screenshot of what I'm seeing

I believe that ROOM is causing this because of the following reasons:

  1. I'm not caching anything in my application (Double checked using the Device File Explorer).
  2. This problem started happening when I migrated from SQLiteOpenHelper to Room
  3. The size of the database is much greater than the App Size, but it is around the same as the Cache size so whatever is stored as Cache must be related to the database.
  4. Whenever I add/remove indices from my Entities, the Cache size changes.
  5. When I clear the cache and open the app, the Cache size reverts back to ~45mb.

Is it normal for Android ROOM to be storing the prepackaged database as Cache? Any help would be much appreciated and let me know if you need more information.

Thank you

EDIT (Additional Information)
This is what I see in the Device File Explorer

Device File Explorer

And this is how I'm implementing the Room database

@Database(entities = {/* entities*/}, version = 1, exportSchema = false)
public abstract class MyDatabase extends RoomDatabase {
    public abstract MyDao myDao();
    private static volatile Database INSTANCE;

    public static Database getDatabase(final Context context) {
        if (INSTANCE == null) {
            synchronized (MyDatabase.class) {
                if (INSTANCE == null) {
                    INSTANCE = Room.databaseBuilder(context.getApplicationContext(),
                        MyDatabase.class, "database")
                        .createFromAsset("databases/database.db")
                        .build();
                }
            }
        }

        return INSTANCE;
    }
}
MikeT
  • 51,415
  • 16
  • 49
  • 68
lexler
  • 41
  • 5

1 Answers1

3

I believe that what you are experiencing may be due to either:

  1. you using an inMemoryDatabaseBuilder or
  2. that you there is confusion due to Room defaulting to using WAL (Write Ahead Logging) whereas previously you were using Journal Mode.

Most likely the latter.

The difference being that in journal mode a log is kept of the changes made to the database, so the database grows as an when changes are applied and new pages are required. Whereas in WAL mode changes are applied to the -wal file and at points (CHECKPOINTs) the changes are then applied to the database file. So until a CHECKPOINT takes places all of the changes are stored in the -wal file.

e.g. enter image description here enter image description here

Swapping to an inMemory database (with no other changes, so inserting exactly the same data) then :-

enter image description here

  • via Device File Explorer enter image description here
  • via App Inspection (aka Database Inspector)

So I suspect that the -wal file is being considered as cache.

MikeT
  • 51,415
  • 16
  • 49
  • 68
  • 1
    Hi Mike, thank you for your thoughtful response. I had a look into the Device File Explorer again and it doesn't seem like the wal file is taking up too much space. It's mostly taken up by the database file. I edited the post with additional info for clarification. It could be that the problem lies in the pre-populated database file itself but maybe not because everything worked fine when I used SQLiteOpenHelper. I'll do more testing. Thanks again! – lexler Nov 04 '21 at 13:57
  • 1
    @lexler uhhm `createFromAsset` uses temporary databases (not sure if inMemory though). Of course the size of the -wal file is dynamic *"quasi-persistent"*. If fully checkpointed (ooops said commit in the answer (will change)), the wal file is empty/doesn't exist. However checkpoints, by default (AUTO CHECKPOINTING) is about every 1000 pages (4Mb) but they are PASSIVE so there may be outstanding changes with those outstanding changes left in the wal file. – MikeT Nov 05 '21 at 03:11
  • Hi Mike, I tried changing the journal mode of the room database to TRUNCATE and the problem persisted so I don't think WAL mode specifically is causing this. When I make insertions/deletions to the room database, I noticed that the appropriate USER DATA size changes in the app info page. Are pre-packaged databases that's used through `createFromAsset` considered as Cache? Thank you taking your time on this. – lexler Nov 05 '21 at 07:03
  • @lexler the end result of createFromAsset is a normal/nothing special database. What is the actual problem? i.e. why does it matter where the data resides as long as it's accessible? – MikeT Nov 05 '21 at 09:52
  • Well I think of files stored in Cache as temporary; files that could be safely deleted if the user wishes to free up their storage space. The problem I'm experiencing doesn't affect my application because the data somehow gets regenerated when cache is cleared, but I thought it was unusual that my prepackaged database was being considered as cache. So I was wondering if this is expected behavior from ROOM – lexler Nov 05 '21 at 11:01
  • @lexler you would expect cache usage when accessing the database. e.g. a cursor would use temporary files (hence the problem that may arise when not closing cursors, the # file table can be exceeded), SQLite uses a page cache. You might find https://sqlite.org/tempfiles.html of interest/relevant. – MikeT Nov 05 '21 at 18:56