Encrypt a single file, chunk-by-chunk, each chunk using different key (AES)
Step 1: good job, this is the right way. You can also use bcrypt or scrypt for extra resistance. Make sure you have chosen sufficiently strong parameters, that is, 64-bit salt and 10000 rounds absolute minimum.

Step 2: no! once you have a strong derived master key, you don't need to apply PBKDF2 on any keys derived from this master key. You are just wasting time and effort and it doesn't scale at all. Use HMAC with a random nonce and keyed with the master key.

Step 3: Why not just encrypt the whole file with a single (derived) key? Why would you want to split the file into chunks? If you do have a good reason, ignore this.

Step 4: I.. suppose.

Step 5: Yeah.



Is my design flawed? Well I won't lie to you, it is a bit weird. You don't need to split the file into chunks if you just want to encrypt it. You are making it needlessly complex. Unless you have good reason. Now the real problem is you have no mechanism in place for integrity checking and authentication. That is BAD.

Or is my design totally pointless and extra? Frankly, yes, it is.

Any else comments are welcomed. Do not design your own real world cryptosystem. Either you do it the simple way and have someone competent (or better yet, multiple) look over it  before deploying it, or don't do it at all. Mindlessly throwing cryptography at a problem isn't the right approach.

The problem I have with this question is that you have no clear goal in mind. What are you protecting against? What is your threat model?  Where is the database stored? Who or what  will access it? etc..

Without knowing this, "extra security" doesn't mean anything. More secure than what, against what?



TL;DR: design is flawed and over-engineered, designer should not be designing cryptosystems for real world use (though it's fine to experiment, of course). Best use an existing file encryption scheme (there ought to be millions for Android, but OpenSSL will do fine) and store metadata in a secure database.