Develop Reference

In android room, is the database's name app scoped?

(I'm new to android development)
Say android app-1 created a database hello, via roo.
Then could android app-2 created a database hello, on the same phone?
My guess is yes, since room use sqlite, each app may start a new sqlite instance, and may store its data in private space, otherwise it's too easy to get conflict. But I'm not sure.
The questions are:
Will 2 app share the same sqlite instance, or each app will start a new sqlite?
Is the database's name app scoped?
I guess the data of a database is also private to the application?
(I've searched about this, didn't get a confirm.)

By default, Room databases are stored in internal storage, and each app has its own internal storage. You can have two databases named hello, one per app, without a problem.

Really SQLite is a set is a set of file handling routines (more complex than just simple writes and reads though).
Android devices come with the routines built in (albeit different versions of SQLite which are typically backwards compatible).
Room is a wrapper around SQLite and thus the routines and caters for an object orientated approach to accessing the data (file(s)).
Unlike, for example, MySQL, SQLite it is not a server that manages transactions from extrenal sources, so SQLite is not a running instance background app/service. (The command line interface would be though)
A device can have many Apps that use the routines to access and update the underlying file (3 files if using the default WAL (Write-Ahead Logging, the core database file, the wal file and a third file the shm file a WAL file for the WAL), (2 files if using JOURNAL mode).
with WAL changes are applied to the WAL file which are then committed at times to the core/master file. Likewise for the shm file in regard to the WAL file. This allows a rollback to simply effectively delete/empty the WAL file.
JOURNAL mode the journal is a record/log of the changes made to the core database. A rollback is accomplished by reversing the changes according to the JOURNAL.
WAL is typically more efficient.
Typically this is all handled by the SQLite routines.
An App can itself access multiple databases if need be. SQLite even caters for accessing multiple database by ATTACHing databases to another.
By default the database is stored in the App's protected data storage area and thus is unique to the App. What you couldn't do, by default, is have the same database name twice within an App
you could say have two hello databases in different locations e.g. data/data/the_package/databases/hello and data/data/myotherdatabasesfolder/hello
note sure how you would go about this using Room though, certainly feasible using just the SQLite API.
So App1 and App2 could have the same hello database as the files will be in separate App specific locations (data/data/the_apps_package_name/databases by default).

Can I use an sqlite database created for android in IOS

I have an Android app I wrote that uses a sqllite database,(the app is used for the reservation) now I want to write the same app for iPhone and I want to use the same database I used in Android app. My question is can I use the same database in IOS.
If yes, then how can be used and where I place the sqllite database (I mean what folder)? and the users must be online to see the update in the database ?

Can I use an sqlite database created for android in IOS?
Yes, an SQLite database is a a file (or potentially 3 files if using Write-Ahead logging). It's simply a matter of copying the file(s).
Typically (i.e. if not specifying otherwise) an SQLite database is stored in data/data/your_package/database/the_database_name
where your_package is as per the App and the_database_name is the file name (may or may not have an extension).
Note if the database uses Write-ahead logging then 2 other files may exist, these being the_database_name-wal and the_database_name-shm. If they exist and are not empty, they need to also be copied.
However,
and the users must be online to see the update in the database ?
Is a completely different matter though. SQLite is not suited to a client/server situation, as you would have to write all the code to provide this functionality. See Appropriate Uses For SQLite.
Firebase may be an option if you don't mind Google's policies reqgarding information privacy. Otherwise you are likely then looking at something like MySQL/MariaDB.

Light weight mechanism for encrypting sqlite database on android without shipping customized sqlite distibution

I am building one android application where I want to maintain certain details in the sqlite database. I am using SQLiteOpenHelper interface in order to maintain single instance of the database for all the threads accessing the database.
For security reasons I want to encrypt my database because if the database file is not encrypted, it is possible to view the database file on rooted android devices.
To avoid this I want to encrypt the database file.
I have gone through SEE, wxSQLite, SQLiteCrypt and botansqlite3 but they all require cutomized distribution of SQLite to be shipped onto android device.
I want to secure my database file with the normal distribution of SQLite that is shipped with Android.
Also I tried to use SQLCipher but it increases my application's total size by 8-10MB. One more reason for not using SQLCipher is that it doesn't support mips architecure (but this could be built later on with some modifications in the source code).
Also my database will be accessed and updated by many threads and will be loaded all the time by a service so decrypting database at the time of loading/opening and encrypting at the time of unloading/closing will not work for me. It should be possible to fire queries on encrypted database only or there should be some alternative solution like creating temp database, decrypting it and performing operations on it.
Can anyone suggest me a light weight solution for encrypting SQLite database on android devices?
Thanks in advance.

Using External DB in Android

What is the difference between using external db file(from assets) and creating a new db using SQLiteOpenHelper? Performance wise which one will be fast? will accessing db from assets slow down my application.

What is the difference between using external db file(from assets) and creating a new db using SQLiteOpenHelper?
You cannot directly use a database that is pre-packaged in your app as an asset. SQLite needs a file; an asset is not a file, but rather is an entry in the ZIP file that makes up an APK.
Using something like SQLiteAssetHelper, you can a pre-packaged database as the starting point for your user, by copying the database from assets into internal storage for your app.
will accessing db from assets slow down my application.
That depends on what you compare it to, and even then the difference will only be the first time you try to work with the database.
With the database-packaged-as-a-asset approach, the database needs to be copied from assets before it can be used. This takes time. It should not be dramatically slower than creating an empty database and executing SQL statements to populate it. In fact, I would expect it to be faster in many cases. However, it will be slower than starting from an empty database.
Once the database is created and set up -- whether via your own CREATE TABLE statements or by copying a starter database from assets -- performance will be identical, because the databases themselves are identical.

The assets folder is read-only, so if you need to edit your database then it won't work for yourapp. If you have a pre-populated database, one option is to make a copy from the assets folder into somewhere that is writeable when your app is first accessed, and then continue with using the writeable version.

There isn't a performance difference assuming your database is properly configured. See this:
http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
I'm using this procedure for a ~500mb database upon which I have to do fairly complex and substantial queries routinely, and which I zip for distribution and unzip on the first run due to size and this works flawlessly.

What are the .db-shm and .db-wal extensions in Sqlite databases?

I am seeing some strange behavior with my application and the state of its database file after running some tests that close the database, delete it, and replace it with a test fixture. When I examine the database file with a tool on my debugging PC, it doesn't match what the application itself seems to be reporting. It's possible that this strange behavior is related to this bug.
I noticed that there are two files with the same base name as the database (with the normal .db extension.) The file extensions are .db-shm and .db-wal, and each is newer than the .db file's timestamp.
I assume that these are some type of temporary files. However, I am wondering if the application is terminated, shouldn't they be deleted? More importantly, I assume whatever data is stored in them is updated inside the .db file before the application is terminated by the operating system. Is this correct?

You are correct, these are temporary files created by SQLite. If you are manually deleting the main db you should probably delete these too. From what I can gather the WAL is a replacement for the rollback journal that enables SQLite to rollback changes when a transaction fails. How SQLite uses them and why they are kept around for so long is up to the authors of SQLite but in general SQLite seems pretty rock solid so I wouldn't worry too much about them. For more info take a look here:
http://www.sqlite.org/fileformat2.html#walindexformat
These files are a new feature of SQLite 3.7. I'm not sure if their existence relates to the bug you point out but the bug report suggests a work-around anyway.
UPDATE:
Better documentation about the WAL is here:
https://www.sqlite.org/wal.html
The contents of the WAL are periodically moved to the DB file but this is not guaranteed to occur each time the process exits. Thus when WAL is enabled each SQLite DB consists of two files on disk that must be preserved, both the .db file and the .db-wal file.
The .db-shm file is a shared memory file that contains only temporary data.

I do not yet have enough reputation to just add a comment to satur9nine's answer, so I'll pile on here.
As per the SQLite docs, the DB-SHM file is a Shared Memory file, only present when SQLite it running in WAL (Write-Ahead Log) mode. This is because in WAL mode, db connections sharing the same db file must all update the same memory location used as index for the WAL file, to prevent conflicts.
As for WAL file, as hinted above, it is a write log/journal, useful for commits/rollback purposes.

Make sure that you have closed cursor properly into SELECT operation. Sometimes SQLiteOpenHelper creates .db-shm and .db-wal extensions database due to unclosed Cursor.