I'm developing a library that will be able to be used across multiple apps. It serves the exact same function in each, and one of the goals of the library is to be as easy and painless to use as possible. In that way, I was hoping to use a SQLite db to store some important information relevant to the library, but NOT to the host app. I searched around and couldn't find anything confirming or denying the ability for libraries to have their own databases. Does anyone know if it is possible?
Thanks a lot.
Well, that depends upon what you mean by "the ability for libraries to have their own databases".
There is nothing stopping an Android library project -- or even a plain Android-compiled JAR -- from using SQLiteDatabase, SQLiteOpenHelper, and kin. So, from a code standpoint, the library can have its own database. You will need a Context object from the host app, at least for use with SQLiteOpenHelper, though.
That is because, from a file standpoint, the library does not exist outside of its hosting app. Hence, the database file will be stored in the app's portion of internal storage by default. You will need to take some steps to try to minimize the odds of collisions on database file name (e.g., mangle your library's package name into the filename), so the host app does not attempt to accidentally work with your library's data. The Context is supplied to SQLiteOpenHelper mostly so that it can call methods like getDatabasePath() to figure out where to put the database file.
Also, bear in mind that the host app can access your database, just as it can access its own. Please make sure that you document the rules regarding this database (e.g., do not use it directly, but use the library's API instead).
Related
I would like to write a backdoor into my app to access the DB directly so that I can, for example, delete unwanted rows created during development or modify values for testing.
It seems there should libraries out there for this but I cannot find any.
If these libraries don't exist, how do you get SQLiteOpenHelper (or whatever) to give the structure of a database (tables and rows)?
Thank you, good people.
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 am using SQLite database in my application. I want to make my SQLite database password protected.
HWACI (the commercial arm behind SQLite development) provides (for money) an encryption engine called SEE. It's quite painless to integrate this in if you are building your own SQLite source, and it's also very easy to use.
SQLCipher is an open source alternative to SEE. I've never used it but I would expect it's as easy to integrate and use as SEE.
As far as I know: no, you can't do it in a simply way.
Posible choices:
-You could simply encrypt the data you want to be secure when inserting it and decrypting the values when you want to play with them. In my opinion this is the best choice.
-You could encrypt the db file in your app's folder. And decrypt it every time you want to access it (not very recommended).
Also note that your DB file is stored in your app's private directory, so in most terminals (except for rooted ones) neither the user nor other apps will have r/w access.
EDIT: For the first choice, I recommend you to take a look to mah's answer if you don't want to implement your own encryption methods =)
I have a huge set of data that I want to insert into the sqlite database before the user is able to do anything inside my application. Right now I have all my data stored in CSV files, then I parse those files and use DatabaseUtils.InsertHelper to do a bulk insertion, but this is taking to long to complete.
I stumbled on this tutorial some time ago and I'm wondering: is it safe to distribute a pre-generated sqlite file? Can I run into problems due to different versions of SQLite on different devices?
I'm planning to support Android 2.1 and higher.
I suppose it depends on your definition of safe. It is certainly possible as long as the database conforms to the metadata table spec Android expects, which is what that tutorial you stumbled upon is showing you. You won't have to worry about version conflicts with SQLite as that is a package built into the core platform and isn't something OEMs add to or implement anything on top of.
However, if by safe you mean "protected" you would need to take special steps to ensure that your database is not externally readable if that is a concern. If you simply place the preconstructed DB into assets/ and copy it over, anyone who can properly deconstruct an APK file can view your database data. This may or may not be an issue for you.
The best approach is to populate this data in the database, keep the database in assets & then copy it to the device ... You can follow this complete sample code here.
I need to ship an app that uses read-only access to several preexisting SQLite3 DB's that each are a couple of 100MB's, total combines size > 1GB. The databases are created on a Mac, and are currently used in a shipping iOS app. I am pretty proficient in Java, but new to Android.
This leads to the following questions:
1) Will I need to modify the databases? I only plan to use them with SQLiteDatabase::rawQuery queries, so no nee for bindings and metadata I hope.
2) It it really correct that even if the DB's will only be used as read-only, I'll have to copy them out of the app bundle or download them to user directory on first start-up?
3) The queries can be slow. I want to run them in a thread and provide data via a callback. Is this done the way it's done in normal Java (Runnable/Thread), or will I have to use another method?
4) Is there anything else that's obvious to the Androidan that I have clearly missed?
1) No, it should work fine.
2) Yes, if you want to ship an APK that is over 50Mb you will need to use an expansion file.
3) For easy background tasks with a call back you could use an ASyncTask.
for a decent example of a sqlite helper class look here
you shouldnt need to edit the database. my sqlite databases work the same wether I access them via sqlite3 or with the android my sqlite helper class
once you copy them you can read and write
not really sure about this answer. i will say though that the database helper class above seems to work just fine (fast) but my db is smaller (500kb)
dont think so