When you are new to cryptography, don't use cryptography. Nothing personal here; that's because you cannot test for security. You cannot easily (or at all) know if some system/protocol/algorithm is secure or not. Such tests simply do not exist. This is very unlike functionality, which can be tested: it is easy enough to see if a server boots up and answers requests, but it is impossible to verify if all this happens securely. Theoretical reasons for that have deep fundamental roots like the halting problem.
The only known way to use cryptography correctly is to let it in the hands of people who have devoted their lives to the study of cryptography. If those guys cannot collectively come up with an attack on your system, despite years of silent toil and meditation, then your system is probably secure, or at least more secure than that of your competitors, which is often good enough.
A "remember me" feature is about keeping some state on the user side, so that when the user comes back to the server, the server will automatically recognise him, and won't ask for an irksome password entry. Whatever way you put it, this means that the user device (mobile phone, as I understand it) contains everything which is needed to "log on" the server without any special user interaction. In particular, if the mobile phone is stolen, then the thief can obtain the same data and then log on the server. This is unavoidable, and that's (again) fundamental: if the user needs not enter his password, then there is nothing specific about the human user, and his physical presence is not required. That's more-or-less the point of the "remember me" feature.
No amount of cryptography anywhere will change that. If the app can log on the server without user intervention, then it can.
A "remember me" feature is thus an inescapable risk which you must balance with the improved user experience (users basically prefer not entering their password over entering their password). There are some ways to make the trade-off a bit more favourable for you:
Whatever the app stores, don't make it password-dependent. Don't store user passwords or any hash computed from the user password. User passwords are sensitive data whose scope extends beyond your app; user passwords are highways into their brains. Instead, store a "session key" which was generated randomly server side. Make it 16 byte long (at least), and use on the server a cryptographically secure PRNG to produce it (e.g.
/dev/urandom or a wrapper around it).
If using a random session key, then you can cancel it on the server at any time, which is a good thing compared to the user password, because you cannot make the user "forget" his password, let alone any potential attacker.
Make it time-limited; for instance, make the "remember me" feature valid for one week. This will force the user to re-enter his password regularly, but you can choose the schedule; yet again, trade-offs. With a time-limited session key, you can contain the damage from any attacker within a strictly bounded time frame.
So now your problem is "simply" a matter of:
- obtaining a random session key from the server;
- storing it on the user device;
- sending it back to the server when needed.
In an HTTP/Web context, all of this already exists and is called HTTP cookies. Just make sure that you set the "Secure" and "HttpOnly" flag, and that you use SSL (HTTPS) (if you are not using SSL, then you already have a lot of bigger problems, so do that first). The system which is easiest to implement securely is the system which has already been implemented securely by someone else. So just use it.
It is highly preferable if you do not go there.