You didn't give much information, but this smells like a serial port configuration problem. Are you really sure the baud rate, number of data bits, parity, and number of stop bits is the same in both cases. Probably not. Since it's working with Hyperterm, see what it's set to, then make sure the Android is set to the same thing.
Also look at how flow control is handled. If the unit is expecting to use RTS/CTS and the Android doesn't have those lines hooked up or doesn't have that turned on it could make it not work.
If you treat the PDA as simply a display, then you can change your way of thinking about what data actually needs to be sent. It only needs a single trace of data, the width of the display, up to 30 times per second. If we assume 8 bit samples, and a retina display width of 960 columns, then you only need to send 960 bytes 30 times a second, or 28.8kbytes per second. If you are fine with 10Hz update rates, then the link only needs to handle 9,600 bytes per second. When the user zooms in, or changes any of the parameters of the measurement, send the new parameters to the microcontroller, and have the microcontroller prepare the data so you only need a low data rate stream to display the data.
If you want to do analysis on the PDA, then you'll have to send a whole chunk of data, and that's simply going to be slow.
But the more analysis you do on the microcontroller side, the less data you have to send, and the more frequently you can update the display.
Keep in mind that fast bluetooth data links will not connect to iOS devices (iPod touch, iPhone, iPad) without fulfilling the requirements of the Apple Made For iPod program, or jailbreaking the iOS device. This is why many similar devices are using wifi.
If you cannot reduce your data rate, and need the PDA to have full access to all the data with no breaks, you should skip bluetooth entirely and use wifi. Inexpensive wifi adaptors might only handle low data rates, but there are wifi modules that will provide more bandwidth.
Best Answer
Not with the HC-06. The HC-06 is a specialized firmware for the CSR bluetooth module it runs on. It lacks any options for GPIO, either from a master or to it.
There are other versions. The HC-05 is even more limited. A newer version known as the BC-04C or some variation on that now has a limited GPIO option, and can be run without a microcontroller host hooked up. (Electrodragon, not affiliated), but it has poor documentation.
See https://www.youtube.com/watch?v=ExtMyV3fDLM or https://www.youtube.com/watch?v=KMUMnF0F4jE
Even so, you would need to setup the module at least once, with a microcontroller or a usb-to-ttl serial cable, and put it in Monitor/Collection work mode (input reading mode).
As for directly hooking up the PIR output to the TX pin, that can create garbage characters that might lock up the module. I don't recommend it.
The easiest solution would be to use an Arduino clone, or ATTINY and make a quick sketch that involves reading an input pin, and sending a string via the TX and RX pins (software serial). It wouldn't take much.
Edit: A simple hack would be to use a device like a Bluetooth Selfie Stick button. These buttons are a fully contained bluetooth with multiple digital inputs, and even a battery. Add a transistor and a resistor and your all done. There are apps that can configure what the button "press" does on the android side. I may do this myself now!