it uses AES-CBC
You should probably use EAX mode instead of CBC. It will prevent the encrypted data from being tampered with (with almost no effort), and it will protect you from certain edge cases that effect CBC mode. See this answer for a discussion of different modes.
The only changes you'll need to make to do this are to use EAX instead of CBC, and you need to use a key that's twice as large (a 256-bit key if using AES-128, or a 512-bit key if you're using AES-256). You can make PBKDF2 generate a key of any size, but make sure the output is the native output size of the hash function, so if you want a 512-bit key, use PBKDF2-HMAC-SHA512.
I dont want to use a static IV (due to security reasons) how do i go about it? do i have to append the IV to the file and then when decrypting extract it?
You can store the IV however you want. It seems common to prepend it to the data (prepending is slightly easier, because you can read the file from the beginning without jumping around). The OpenPGP format is nice because you can use other applications to read and write the files (and the format has had a lot of attention, so it probably handles cases you haven't thought of yet). I've written programs that output a JSON file, with the base64 encoded encrypted data, and the IV as attributes. You could use XML. You could distribute the data and the metadata as separate files. It's really up to you.
When the encryption is finished the unencrypted file is deleted. Should i have any concerns that an attacker could recover the unencrypted file (this is an android app so the underlying storage technology is flash, and i am using the standard API to delete the file) should i implement a secure delete function or how to deal with this?
When you delete a file, the filesystem usually just marks it as deleted so other files can be written over the top. To fix that, you would need to write over the file, but I'm not sure if there's any way to guarantee that on a journaling filesystem, especially if it's using flash (because flash controllers usually move blocks around for wear levelling). You could probably do this by deleting the file, then writing a giant file that takes up all of the free space on the device, then deleting that file.
The best way to guarantee that private data isn't left unencrypted on the disk is to never write it to the disk unencrypted, but it sounds like that may not be an option for your program.
The files are encrypted using a 256-Bit key derived by PBKDF2. PBKDF2 needs a salt for which i use a hash of the users password is this a bad idea?
A unique salt will protect your system from a large number of vulnerabilities, so you should definitely use it.
does the salt has to be random?
It doesn't necessarily have to be random, but it does need to be unique. Randomness is usually the easiest way to get unique values.
if so how do i deal with it do i have to append the salt to the file to perform decryption?
Store the salt the same way you store the IV.
Your probably also want to store the number of PBKDF2 iterations, so you can increase the default in the future, and still be able to decrypt older files. Make sure your iteration count is high enough. For comparison, iOS uses PBKDF2 with 10,000 iterations when storing passwords. Unless your program is running on a toaster, you have no excuse to set the value lower than that.
