You want to use bcrypt for storage on the server side: that's good. You have to remember why you do that: it is because you fear that the server's storage area may be plundered in some way, and you want an extra layer of protection. The point of bcrypt (or any other similar password hashing function) is to make dictionary attacks more expensive: there is a salt (to prevent parallel attacks on many hashed passwords, and precomputations), and there are many iterations (to make each guess expensive).
You thus want to maximize the number of iterations. This implies that the hashing has to be done on a fast computer. A smartphone running Java code is not fast (a recent enough Android version includes a Java VM with a JIT compiler which will offer not-too-pathetic speed, but the result will still be uncompetitive with the server's abilities). Therefore, you really want the bcrypt to happen on the server side. Even if obtaining the salt from the server was acceptable (from a network latency point of view), the lack of CPU performance on the client side would be debilitating.
Therefore, your problem really is about how to transfer a very sensitive information (the password) from the smartphone to the server, making sure that it does not get intercepted while in transit. Since an app cannot contain secrets (because reverse engineering works, and that's not exclusive to Java), you will have to use asymmetric cryptography, with a public/private key pair, such that the server owns the private key, and the client can make sure that it uses the right public key (and not a fake attacker-controlled key). At that point, you are pretty close to SSL.
Using HTTPS would be the simplest method to achieve what you seek; in particular because the phone already includes all the needed code.
It might be argued that HTTPS implies too many network round-trips. It is conceptually feasible to do better when what you want is a one-way transmission of some secret data to the server; in that case, you can mimic the email model, which then points at OpenPGP. You could asymmetrically encrypt the password to send, using the known server's PGP public key (hardcoded in the app -- that's not a problem, it is a public key), and sending the result as a single HTTP request. This minimizes network traffic, while still relying on an encryption format which has survived some amount of external review. A Google search on "android openpgp library" yields a few useful pointers for the actual implementation.