Some Android devices can only record 8kHz audio and then upsample without telling you (where iOS hardware native is 44.1kHz). Some also apply filters you wouldn't expect at the input stage. There's also automatic gain control (AGC) which varies dramatically across manufacturers and phones. Similarly for output: filtering, sample rates, speaker quality, etc. Then taking into account the immense matrix of testing, the problem becomes non-trivial very quickly on Android in ways that are not an issue on iOS. Their choice of ASK complicates things further as amplitude modulation is more prone to transmission error afaik.
As someone who's spent way, way too long playing back and recording audio on mobile devices as a mechanism of communications, let me assure you, it's hugely harder on Android than it is on iOS. I would have made the same decision if I were them.
Surprised they didn't use BLE, honestly...
[edit] Very cool approach though!
Another solution is Electric Imp's BlinkUp, which encodes the WiFi information in flashing light from the screen. Patented.
"Eight weeks later, the first public demonstration was given to the class by using a simple ping packet. With a blinding 2bps speed, the class sat patiently as the packet was received in roughly 140 seconds. "
That's why. Sound is a pretty slow wavelength. Low end is 60hz, lets call it 600hz tones in this bongo (I don't actually know). However ultra sound is at 20 kHz and above. Eg 33 times faster. 33x the data. Eg 140 seconds now takes 4.25 seconds. Lets assume the bongo was 10 too long. Now we're down to 14 seconds in audible and .42 seconds in ultrasound.
you can see the benefit.
and that's without actually doing a real data rate calculation becuase I don't have a good number on how many waveforms you have to have on sound to pick up a real signal. Somthing somthing nyquest criterion somthing somthing.