IssueTracker

There are some barriers. Assets files are part of the APK and the way they are stored are an implementation detail of the framework, the files might get compiled / compressed in some way to have smaller APKs for distribution which means they have to be decompiled to be read as intended. That is why more or less the AssetManager APIs are stream based, but the main drawback is that there is no File API for assets. Meanwhile SQLite needs a local file to be able to do random read access. SQLite does allow you to register a custom VFS callback so if you wanted to have a read-only, no-copy database in the assets then you need to provide the necessary reading mechanisms to and unbundled-sqlite.

Thank you, and I appreciate you opening this issue on my behalf.

That's interesting, I didn't know assets were stored in an implementation-detail way. Isn't there already something like this with jniLibs - where they are accessed directly from the installation thus saving storage space? I vaguely recall this introduced from a few OS releases back.

Regarding the VFS callback, is that something that might be standardised in a bundled sqlite in a future OS release?  Would be great if it supported encryption too, saving us having to use sqlcipher and the like.

For the NDK I think it is similar, still file path based, but the actual reading is stream based, see: https://developer.android.com/ndk/reference/group/asset

Hard to tell if bundled sqlite will expose registering VFS callbacks or support built-in encryption. A side from me asking around those might be worth issues filling to the framework team. Meanwhile we'll keep this issue open, maybe a Room + unbundled-sqlite combo can make this happen.

This is the native libs flag I mentioned earlier: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs

I actually opened a feature request 3 years ago, to the framework component: https://issuetracker.google.com/issues/37103265