The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
SQLite databases, by default, are stored on internal storage, accessible only to the app that creates them.
At least, that is the theory.
In practice, it is conceivable that others could get at an app’s SQLite database, and that those “others” may not have the user’s best interests at heart. Hence, if you are storing data in SQLite that should remain confidential despite extreme measures to steal the data, you may wish to consider encrypting the database.
Perhaps the simplest way to encrypt a SQLite database is to use SQLCipher. SQLCipher is a SQLite extension that encrypts and decrypts database pages as they are written and read. However, SQLite extensions need to be compiled into SQLite, and the stock Android SQLite does not have the SQLCipher extension.
SQLCipher for Android,
therefore, comes in the form of a replacement implementation of
SQLite that you add as an NDK library to your project. It also ships
with replacement editions of the
that use the SQLCipher library instead of the built-in SQLite. This
way, your app can be largely oblivious to the actual database
implementation, particularly if it is hidden behind a
ContentProvider or similar abstraction layer.
SQLCipher for Android is a joint initiative of Zetetic (the creators of SQLCipher) and the Guardian Project (home of many privacy-enhancing projects for Android). SQLCipher for Android is open source, under the Apache License 2.0.
Understanding this chapter requires that you have read the chapter on database access.
So, why might you want to encrypt a database?
Some developers probably are thinking that this is a way of protecting the app’s content against “those pesky rooted device users”. In practice, this is unlikely to help. As with most encryption mechanisms, SQLCipher uses an encryption key. If the app has the key, such as being hard-coded into the app itself, anyone can get the key by reverse-engineering the app.
Rather, encrypted databases are to help the user defend their data against other people seeing it when they should not. The classic example is somebody leaving their phone in the back of a taxi — if that device winds up in the hands of some group with the skills to root the device, they can get at any unencrypted content they want. While some users will handle this via the whole-disk encryption available since Android 3.0, others might not.
If the database is going anywhere other than internal storage, there is all the more reason to consider encrypting it, as then it may not even require a rooted device to access the database. Scenarios here include:
The preview of this section is sleeping in.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section was whisked away by a shark-infested tornado.
The preview of this section was abducted by space aliens.
The preview of this section is [REDACTED].
The preview of this section will not appear here for a while, due to a time machine mishap.
The preview of this section is in an invisible, microscopic font.