AeroPlayne is a native app for Android that reimplements the audio component of Apple’s AirTunes protocol (popularly known as version 1 of AirPlay®). This enables an Android device to appear on your local Wi-Fi network as a “virtual speaker” (the receiver) which is capable of receiving audio sent from an iOS device using AirPlay® (the sender).

Additionally, it can:


Every AirPlay® receiver requires a name. It doesn’t need to be unique, but it’s a good idea nonetheless. By default, this is the model name of the device. You can choose something more memorable from the Settings page .

The app can be in 2 possible states:

  1. Standby: The receiver is “asleep” , and not present on your network. This is indicated by the main switch being in the off position, and the glowing light in the lower-right corner of the speaker.

  2. On: The receiver is “awake” , and ready to receive audio. It has registered itself on your network and will appear as a receiver in the AirPlay® menu of devices also on the network. A persistent notification will also appear to indicate this state.

By default, the app will go back to sleep in 3 minutes if no audio is received. This is because while it is ready to receive, the device’s radio must remain active to listen for incoming connections, which increases battery usage. You can change or disable this duration from the Settings page.

When a connection is successfully formed, the app will enter its receiver mode.

The presence of these items depends on their being supplied by the sending device, and also its reported capabilities. This information is also shown in a persistent notification.

Note: Without an in-app Premium purchase the app operates in trial mode. In general, all functionality is present but time or quality limited.

In this case, audio is limited to three minutes, after which noise is overlaid on the audio. You can reset the trial timer by disconnecting or restarting the audio.


Audio streaming relies on buffers to account for fluctuating network conditions which could cause audio to skip or pause. Buffers help smooth over short interruptions by building up a backlog of audio.

By default, AirPlay® uses approximately 1.75 seconds of buffering, meaning it takes this long from the audio being sent, to it being played by the receiving device. This is why there is (sometimes) a delay between an event on the sending device, and its effects being heard on the receiving device, known as its latency.

Unlike many AirPlay® receivers, you can change the size of this buffer, which trades decreased latency for an increase in susceptibility to bad network connectivity. In practice, if you only require audio streaming, the buffer can be very small. For audio played alongside video, the buffer size will also influence its synchronization.

A buffer size that is too small will cause audio to skip, drop out, glitch, and be generally unreliable.

To change the buffer size, choose Adjust Latency from the menu, or long-press on the status bar at the bottom-center of the screen. The dialog allows you to change the buffer size, by dragging the slider or tapping the plus/minus buttons.

Audio Effects

At the bottom left corner of the screen, there is an equalizer icon, representing audio effects. When an effect is enabled, the icon is badged with the number of enabled effects. Tapping the icon causes a sheet to appear, containing a tab for all available effects. By default Android supplies 5 effects:

Each effect can be enabled by toggling the switch in the toolbar. Enabled effects are indicated with a check mark alongside the name.

The current settings for all effects can be collected and saved as a preset. Preset management is controlled by items in the toolbar menu.


At the bottom right corner of the screen is the metadata icon. Information supplied by the current sender is shown in this sheet. The data includes most of the standard details defined in the iTunes/Music app for Mac, such as Title, Artist & Album Name, Year of Release, etc. It may, depending on the source, show file-based information such as the source file location, the file size, and the bitrate.


Next to the metadata icon is the relay icon. At the highest level, this is a component that forwards received audio to other networked devices. For example, when using Google Cast, it automatically relays the received audio to that device.

You can also use the relay manually. Switch the relay on, and one or more servers will be made available on your local network. Their addresses are listed at the bottom of the sheet. Each is now ready to receive connections from devices on your local network. You can enter these addresses into a ShoutCAST or IceCast compatible player, such as a web browser or VLC, and the audio will be relayed to it. Active connections to the server (its clients) will be listed in the sheet.

You can also proactively connect to an internet server, and the device will act as a source for that server to send audio to listeners on the wider internet. To do this, select Connect to Server from the menu. Details of what to enter in this dialog should be available from your service provider.

Note: in trial mode only the lowest quality MP4 bitrate is available, and noise will overlay the audio after 3 minutes.


The app can record (or more accurately transcode) the audio it receives, meaning it can save an audio file consisting of the audio encoded as an MP4 file (for lossy-compressed AAC audio data), High-Efficiency AAC audio data (for lower bitrate, space-constrained or voice-only situations), or a FLAC audio file (for perfect, losslessly-compressed audio). Choose the format from the Settings page.

Note: In trial mode only the lowest quality MP4 bitrate is available, and recording is limited to 3 minutes.

A recording first requires a file to write to. Select Record from the menu, and choose a destination file location and name. The receiver is now primed to record. If it was already receiving audio it will begin immediately. If not, it is now Ready to Record, meaning it will start recording when the audio starts. To stop recording, tap the Finish button.

It is possible to pause a recording without finishing it, by pausing the sending device. As long as this doesn’t cause the device to disconnect itself or send silence (see Frequently Asked Questions), the recording will automatically resume when the received audio resumes.

Other Settings

These settings are available from the app’s Settings page



Volume Level


Note: in trial mode this option is not available. Only the lowest quality AAC bitrate is available.




Known Issues

Frequently Asked Questions

Why does the app pause for a long time before the recording finishes?

For some reason, a certain stage of the recording process that only happens at the end can sometimes take a long time. If it takes more than a few seconds, a notice will appear. However the file will still eventually be written.

If this is the first time the delay occurs, the Direct File Writer setting will be automatically disabled. This makes it use a different method to ‘finish’ the file, which is likely to be faster, and the expense of being less compatible with exotic file destinations.

Note: this bug is probably already fixed, but I will leave this here just in case

Why does the artwork not always appear when sending from the Music app on the Mac?

When sending from the macOS Music app, the artwork for each item may not be displayed. This seems to be a bug in the Music app, as the image is explicitly specified as empty even when it is present.

Why can’t I record in the MP3 file format?

I have no idea. Android doesn’t seem to natively support it. Probably due to licensing costs.

My problem isn’t listed here!

If the issue causes a crash, enable Crash Reporting and eventually I’ll get the report. If it works but doesn’t seem correct, get in touch.

Why can't I AirPlay® directly from Safari on the Mac?

As of macOS Ventura (and perhaps before), using AirPlay® from within Safari’s video element (as used by YouTube, etc) is NOT supported. I suspect this now requires AirPlay® version 2. This issue also affects Apple’s own AirPort Express® device. For some reason, the iOS browser version does still work.

A workaround is to use the app as an AirPlay® output device in the Sound Control Panel.

The play, pause, or volume controls are shown, but they are disabled!

The availability of these controls is determined by the advertised capabilities of the device that is currently sending audio, in particular its adoption of the DACP protocol. This is how sending devices allow themselves to be controlled remotely.

The protocol allows a sender device to advertise what it is capable of doing (eg: change volume, play, pause, skip tracks). When the app (the receiver) notices these capabilities it enables the corresponding buttons. However, this is a functional protocol. It defines what to do, not how to do it, which in practice can confuse the user.

For example, the functional definition of pausing audio is when a command to pause the audio is received, the audio should pause. Here are three different ways to achieve this:

  1. Tell the receiver to stop playing audio (typical of the Mac’s Music app, and the most desirable outcome).

  2. Don’t tell the receiver to stop playing audio, but instead send silent audio (typical of the audio component of a video).

  3. Immediately disconnect from the receiver, and ignore any further commands (typical of iOS devices, presumably to save battery).

In the first case, the audio will pause immediately (which is probably the expected outcome). In the second, the receiver will have to work its way through its buffer before it gets to the silence, meaning the response appears delayed by a few seconds. In the third case, it appears that the sending device suddenly disappeared, putting the receiver back into standby mode. These responses are all technically very different, but they do all functionally work.

The Apple Music app (formerly known as iTunes) on the Mac has the most comprehensive implementation of this protocol. iOS devices tend to have less complete conformance to this protocol (and in some cases no conformance at all).

In other words, treat the remote controls offered by the receiver as an idiosyncratic bonus that may or may not work.

What is Trial Mode?

This is a paid app. In its free mode (aka Trial), audio receiving is limited to three minutes, after which noise is overlaid on the sound. Additionally, the recording quality is limited to its lowest setting.