If the user can read his document, but you cannot, then the user must "know" (i.e. remember or store) some value that you do not. A secret "value" which is used to unlock access to some documents: cryptographers call such values "keys".
A password is a key that the user can remember, i.e. he can store it in his brain. This has shortcomings, foremost of which being that realistic passwords are weak against brute force. Appropriate password hashing is used to try to cope with this weakness. In any case, users can forget passwords.
From a cryptographic point of view, a "reasonable" way of doing things is the following:
- Each user has two "passwords": his normal one (P) and a "recovery password" (R) which is not really a password, in that it is a big sequence of random letters, and the user will not try to remember it.
- The user writes down the recovery password on some piece of paper that he stores in a safe place (e.g. in a bank). The recovery password is there to recover the data when the user forgets his password.
- Each file is encrypted with a symmetric key K, called the "master key" (each user has his own "master key").
- The storage system, where the documents are, also contains the encryption of K by P, and the encryption of K by R. When encrypting "by the password P", I mean that there is a user-specific random salt used in a good password hashing function to convert P into a symmetric key KP, and that symmetric key is used to encrypt K. Similarly with R.
When the user wants to read his documents, he enters P, from which KP is derived (using the stored salt); this allows recovering K, and thus decrypting the documents.
When the user changes his password into P', it suffices to recover K (as above), generate a new salt, then compute KP', encrypt K with that, and store the result (along with the new salt) on the server.
When the user forgets his password, he goes to his bank, retrieves his recovery password R, and uses it to recover K and then choose a new password.
With the above, the storage server sysadmin may obtain enough information to "try passwords" (that's called an "offline dictionary attack"). This is unavoidable, and that's why we use a good password hashing function with salts and many iterations.
As @scuzzy-delta indicates, a critical point is that the customer is not a developer, so he will necessarily have to trust some software, at some point, not to play nasty tricks on him. This covers your app, but also the operating system; and, more generally, it will be up to the customer to ensure that his PC is not malware-ridden. Under these conditions, you cannot guarantee that the customer's documents will not be pillaged; but you can ensure that you will not be blamed for it, if you get your code audited (remember that your customers are lawyers: they may be fierce). Audit is very expensive, and increasingly more so if the code is bigger, so you want to keep you app as small as possible.
Cryptography is known to be tricky to implement, so you are widely encouraged to stick to existing standard formats and, if possible, standard libraries. The OpenPGP format would be a good place to start. Ideally, you would find a good format already implemented by both Android and iOS (code which is already in the phone needs not be audited, at least not for the audit which covers your own skin).