I have an Android app that writes data to a db. Initially, when we started, we stored the db in an app-specific folder (something like /storage/org.domain.app/db/db.sync and so on). Things worked with no issues. However, the issue was that this DB would get wiped out everytime we reinstall the app.
We therefore moved the DB to a different folder outside the app. (Now the path is something like /storage/data/db/db.sync). Now, if we reinstall the app, we still have the old DB entries. However, now reading and writing to the DB is a lot lot slower.
I am not sure if this slowness is because the amount of data has shot up. Since the data is now persistent across multiple reinstalls.
I suspect this could also be because the DB is now in a folder external to the app. To rule this out, I setup the DB in an app specific folder and intend to copy the entire DB from some previous tests (that contains lot more data - the amount of data which caused the DB access to slow down). However, I am unable to do so.
Some questions:
1. I am not able to actually access the folder where the DB is setup. The folder is created in Context.MODE_PRIVATE mode. Therefore, only the app itself can access it. I tried changing it to MODE.WORLD_READABLE. However, this is deprecated and throws an exception while using it. Is there a way to make this folder easily editable?
I also tried accessing the DB from Device file explorer in Android studio. I opened the existing DB (db.sync file) and just copy-pasted the large DB I already have. However, it looks like this method does not allow us to copy or even display more than 400 KB of information. The DB I have is around 60-70 MB. Hence this approach did not work either.
Is there a way I can edit the db.sync file?
Does DB being in a folder external to the app make it slower? Esp when there are too many entries. In my case, certain search operations happen via a local cache and happens in a giffy. However, we also need to log some stuff to the DB and that takes forever. I figured this out by adding timer logs in the code.
Anything else, I could do to identify if the DB path is causing the issue?
Thanks,
Anand
Related
I want to keep a 22mb large encrypted sqlite DB in the assets folder of my Android app. When the app runs, I want to copy this DB to the actual DB in /data/data/... which is also supposed to be encrypted. Then I want to sync this DB time to time with the db on my server. No doubts in implementation part, but can anyone please suggest whether it is a good practice and worth it?
Thanks.
When the app runs, I want to copy this DB to the actual DB
This is one time initialization? It's OK, even better if you delete the seed file after initing.
actual DB in /data/data/... which is also supposed to be encrypted.
AFAIK doing this means you are using at least extra 22 MB of RAM everytime you do a database operation. And at least 22 MB worth of disk write everytime you commit. Please do this sensibly, e.g. use batching techniques, do the disk write in a background thread, etc.
Then I want to sync this DB time to time with the db on my server.
Depends on how you do the sync, and also the frequency. If you upload the full 22 MB everytime, it's not ok. If you only update what has been changed, it's ok. Give users the option to only sync when on wifi.
In my android projects I need database to store data for offline usage.
For that I am looking at two options 1)Creating the empty db and copying it to asset 2)Creating the db via code
which option will be good as my app is handling secure data.
weather it will cause any security vulnerability if we store the db structure in asset folder as it will be easily available if we extract .apk file.
Thanks for your support
If your database has something you don't want your legitimate user to see, look for a new project because you cannot attain that. Using a static database in the APK is as you know, easily viewable, but creating it from your app also leaves something that is viewable. You could encrypt the contents, but then you have the problem of how you store the key in a way the user cannot access -- so you really haven't solved anything.
Back to your original question though -- is the data static, or is your application ever going to make changes to it? If the data is static, providing a pre-populated database is fine. If the application is intended to be able to make changes though, you are much better served by letting the application create and manage updates on the database, its schema, and its contents. Following Google's examples will get you there.
I have 7mb app that consumes 25mb once the sqlite db is copied to the data/data/packagename/database folder. This is too big on my frugal emulator and potentially offensive to users.
Is there a way to put the sqlite db straight onto the sdcard? Or the whole app et al? Asking users to force it across after installation seems too little too late and i can't host the dayabase myself.
Is there a way to put the sqlite db straight onto the sdcard?
You could probably make a mod to SQLiteAssetHelper to handle this. By default, it will place the database in the normal spot on internal storage. Unfortunately, right now, it would require some non-trivial surgery to make this change, though I have just filed a feature request to make that a bit easier.
Or the whole app et al?
You can use android:installLocation="preferExternal", though it may not be honored. And, that will not affect your database -- getFilesDir(), getDatabaseDir(), and kin are always on internal storage.
Also note that this is all really only an issue for Android 1.x/2.x devices. Everything newer than that should consider internal and external storage to be on one partition, so they share space.
I'm developing a content provider which stores its data in an SQLite database. During development, I need to change the schema, or delete the database entirely and have it rebuilt (I'm not upgrading the database at this stage of development).
I found the database file, stored at /data/data//databases/app_db . When I pull it to my desktop machine, I can use SqliteSpy to see its content and all is well. However, when I delete it, it doesn't always get really deleted. Although I can't see the file in DDMS or ADB, my application still sees it.
I tried to make sure my application and service aren't up when I delete the file, but it doesn't seem to help. In about half the times I delete the file, I need to restart the emulator for it to have effect.
What could be preventing the file from being really deleted?
Itay.
I've seen this issue too when was writing unit tests for my ContentProviders. You need to make sure you've killed the process that hosts ContentProvider that uses that specific database file. And only than delete it.
First I want to say thanks to everyone that reads this. Stackoverflow is an amazing site and you guys help me out with answers everyday in the form of questions already submitted. You all rock!
My problem:
I'm working on a database app that I'd like to back up the database at certian points so I can save the data I've collected in database over time, during development. So to save the database to accessible memory I've followed this page:
How can I pull databases off my android onto my desktop?
..and the above code is working great in the emulator (I can use DDMS to pull the copy of the database to my PC and view it using SQLite Database Browser). However when I run it on an actual device, SQLite Database Browser can't read it. To extrapolate, the copy is being created just fine on the SD card, but when I copy to my PC from my device and view it, I get nothing, SDB can't understand it or something. However when I use an emulator, I can copy it off using DDMS and view all the tables just fine with SDB.
Using WinMerge to compare the two raw database files (one generated by the device, one generated by the emulator both running the same code) I can see there are formatting differences, but nothing that looks corrupted, but I'm not 100% sure. The android metadata and SQL sequence tables appear to be in there (albeit in different orders), as well as my custom table.
Do you guys have any suggestions on how to debug this? I'm not sure where to start since it seems to work perfectly on the emulator. Also, I've run the emulator at the same android release (2.3.3) as the device, so I'm am pretty sure they are using the same SQLite engine.
Thanks,
Matt
I'd try opening this database with different SQLite clients.
If that doesn't work, the next step may be to try finding an SQLite database file validator and/or to run the standard SQLite client in debug mode (but to be honest, I don't even know if those two last options are even possible).