>>Because of this, I shouldn't see the 802.11n devices at all, only other 802.11b or g devices.
This isn't true - you will see frames sent by that host at modulations that can be received by your capture interface. The bulk of data would likely be sent at the higher 802.11n/ac rates, but you would still likely see ACKs, CTS/RTS if in use, etc. So define 'shouldn't see at all'. If the airodump-ng tool requires data frames then your statement may be correct as the device would not show. But that is a specific tool requirement - change tools, and it may not hold. Also note that all radios have a Tx rate selection algorithm, so if you degrade signal strength enough, the device will communicate with the AP at lower rates so may be picked up by your sniffer. It's a moving target.
>>My card does support promiscuous mode. I can enable and disable promiscuous mode by running:
Good test to try, but unfortunately, this really has no effect on the wireless driver. Try it: with wireshark running, toggle the mode. Do you see a change?
>>I also ran wireshark with unicast capture filter ("not broadcast and not multicast") and was picking up traffic
OK - good - rules out promiscuous mode issues. This is the most common cause for me when I observe the symptoms that you have.
>> I could see the AP and my Android (communication is using 802.11g according to the header/radio information)
Good - the communication that you reference is for the frames that are visible - see all the ACKs? Each one of these is likely generated by a data frame, that you don't see. The data frame probably went at an 802.11n rate, but the ACKs go slower. I see Block Acks, and if you look at the beacons and association frames (not in the trace) you could work out if the device is using n rates by the presence and info in the HT information element.
>>(I don't see it as tcp, though, it shows ack's. I don't know if that's an issue, as wireshark and network sniffing is new to me
Maybe. If encrypted, you would not see TCP unless you decrypted the traffic. The TCP traffic would be in data or qos-data frames, which we don't see. Root cause is as MisterX says for this, mismatch in modulation because you can't pick up the high datarate frames with that capture device.
>> If I was running wireshark, should I have been picking up signals from all the routers/clients in the area, not just my phone and AP?
Yes, certainly. If they are on the channel and with range, they would be picked up. I don't know the internals of airodump-ng, but I would suspect it is just reading frames through libpcap or some other capture library and handling them. Wireshark does use libpcap and displays them in the tool.
So why does your device not show as connected? This is a question for looking in the code - or MisterX could just tell us - what does airodump-ng need to determine that a device is connected? Does it use data frames to pull out the bssid and populate the table? If so, we know why: modulation differences. If not, we still have to figure out what is going on.