jBcrypt is a Java implementation. Android apps are written in almost-Java, for an almost-Java virtual machine called Dalvik.
For computing-intensive tasks, especially cryptographic algorithms, Java incurs a typical 3x slowdown compared to equivalent optimized C code: a good Java virtual machine runs a JIT compiler, and the performance of the code will be limited by the constraints which a JVM must operate in (translation from bytecode to native code must be fast and incremental, methods being translated on a per-call basis; and the result must still be appropriate for the garbage collector). Further slowdown can be observed in some specific cases where native code can benefit from extra opcodes provided by the CPU, the typical case being computations on big integers (say, for RSA), because the CPU may offer an "extended" multiplication (64x64->128) that Java code cannot use, due to the lack of a 128-bit integer type in Java.
For a rather thorough experiment in the context of hash functions (not "password hashing", just "hashing"), see sphlib: a library implementing a lot of hash functions, in C and in Java, with "similar efforts at optimizations" (same developer for the whole lot), and including measures on a variety of platform types.
Now, there can be additional slowdowns for Android apps:
The CPU of a smartphone is not as fast as that of a PC. Smartphone CPU can go to the gigahertz range, but still do less work per cycle than x86 CPU -- because one of the prime objectives of a smartphone CPU is to save battery. A smartphone must be alive for a full day, while engaging in radio activity, whereas a laptop can have a bulkier battery and only needs to be up for a few hours. Modern smartphones are efficient, but there still is a gap when compared to desktop PC. Let's say an additional 3x factor.
Dalvik is not necessarily the best JIT compiler around. The relative lack of raw muscle means that the JIT cannot apply the most complex optimization strategies, because it would make JIT translation of a method too expensive.
Up to Android 2.1 (included), Dalvik has no JIT. This is the worst slowdown, that other answers allude to. In Android 2.1 (and before), Java bytecode is interpreted, not translated to native code, and this incurs a heavy extra cost (say 10 to 20 times slower than JIT code). Android 2.2 onwards has JIT.
Switching to PBKDF2 won't change the picture much. If you use PBKDF2, be sure to use SHA-256 (or SHA-1), not SHA-512, because the smartphone CPU is ARM-based and will be quite uncomfortable with 64-bit arithmetic operations that SHA-512 heavily relies upon, thus slowing down your code -- whereas the attacker has a PC, which eats 64-bit operations for breakfast, and will not incur the same slowdown.
Summary: bcrypt will be very slow on Android 2.1 (and previous versions). It will be somewhat fast on Android 2.2, albeit not as fast as a PC (say, between 5 and 10 times slower). PBKDF2, scrypt... do not change this picture in a significant way.
All of this is said about the performance of bcrypt. I did not comment in any way on the proper use of bcrypt-derived secrets for both encryption and password verification. Indeed, when you store "something" to validate a password, you don't what that "something" to be too close to the password-derived key you use for encryption.
One "cryptographically reasonable method" is to compute the password hash with bcrypt or PBKDF2 (with salts and iterations and everything), and then take the output and expand it with a Key Derivation Function into enough key material for your needs. In your context, take the bcrypt output, then hash it with SHA-256. This yields 256 bits. Store the first 128 bits in your database as "password verification token". Use the other half as encryption key.
PBKDF2 makes this process slightly simpler since it is a KDF, so you can ask for 256 bits of password-derived output right away, not needing an additional hashing; whereas bcrypt's output size is fixed to 192 bits, which may not be sufficient for your needs.