Smartphones have become a critical component for many of the things we do in our lives. There are still plenty of bugs and weird little things that don't quite work right on our phones, but it's when they have to connect to other devices that many of the strangest behaviors start to crop up. For years, one particular issue has been plaguing users as they connect a phone to their car stereos, headphones, or other audio output devices. Moments after a connection is made, the phone will suddenly and unexpectedly begin playing music – and anecdotally, they're always quite loud. Google Play Music is often blamed for this behavior because it's the app most likely to respond, but there's now a toggle to prevent that from happening.
Open up the Settings page in Play Music v7.12 and you're likely to find a new option called "Allow external devices to start playback" with a summary that explains it's intended for things like the Bluetooth stereo in your car or wired headsets. Turn that off and you should be safe from surprises in the future.
To be specific, this won't actually prevent devices from starting playback entirely, it should only prevent them from starting music when a connection is made. That means you should still be able to use the regular controls to start and stop playback normally.
This auto-start option wasn't originally available when v7.12.5217 or .5218 came out, but Google is now enabling it remotely. If you're running v7.12 and don't have it yet, wait a little while longer and it should show up.
What is this about?
Note: I was already preparing to post this as a teardown, but it wasn't quite finished before Google started enabling this feature. Nevertheless, the explanation might be interesting to some people, or it might explain why the feature was added for the people that have never experienced the bug. If you've read a bit about the auto-play problem, you may already know most of this.
The quick and simple explanation is that some car stereos, headphones, and other audio output devices are designed to send a command to start playback when a player is attached. This can happen with both wired and Bluetooth connections, though it seems to be more common with wireless pairings. Not all audio output devices send this command, and it seems to be getting less common with newer hardware. Some car stereos also have a setting that allows this behavior to be customized, but it's often buried in menus where it might not be easily discovered.
When your phone receives this start command, it does exactly what it's supposed to do and tells an audio service to begin playing. It's pretty likely that the last audio player to be open on the device will be the one to respond, but if it has been a while since one was running or if the last one was booted out of memory, the app selection can seem pretty random. Due to a couple of implementation details (basically the services it has running), Play Music will usually end up responding, which has led many people to believe it is the cause of the problem and even resulted in some pretty wild accusations.
This is a fairly widespread issue and it has popped up in dozens of support threads and forum discussions for almost every audio player from podcast apps to music streamers. Complaints were already fairly common back in 2010 and still crop up today. This isn't just a problem for Android apps, it's also prevalent on iOS, as well. A quick search turned up a report on Apple's community forum at least as far back as 2011, and by some lucky coincidence, iMore happened to post some advice and workarounds for iPhone users that will minimize (but not really solve) this issue.
Assuming your stereo or headphones are prone to starting playback automatically but don't offer a way to turn off that behavior, there are ways to reduce the likelihood of surprises, but most of the solutions are either less than 100% effective or they require some undesirable compromises like turning off features you might actually want to use. Some call for making sure the play queue is empty in Play Music and other apps so they won't have anything to play when the command comes in. Others suggest installing apps that will aggressively stay in memory to intercept the start command. There are even some people that disable audio output to certain devices in Settings and re-enable them after a connection is made.
Plenty of rationales have been suggested to explain why manufacturers have their systems autoplay music, and it surely varies from one to the next, but the prevailing theory is that this is a leftover from the early days of audio players like the SanDisk Sansas, Apple iPods, Microsoft Zune (lol), and Sony A, S, and E Series Walkmans. At the time, it was still common to power down most electronics instead of leaving them to idle with the screen off like we do with phones today. Since the startup time was fairly lengthy and it took even longer if a Bluetooth connection had to be made, you could be waiting up to a minute before everything was ready to go. Nobody wanted to wait that long, so manufacturers took the logical step of starting playback on behalf of users. After all, the assumption was that the connections would only ever be made by dedicated audio players, and only when they were just turned on to start music.
Google's implementation appears to ignore start commands for just a moment after a connection, but begins responding again almost immediately. Let us know if it's working for you. Hopefully, this will spell the end of surprise musical attacks when a car starts or after walking into a house with a paired bluetooth speaker.
The APK is signed by Google and upgrades your existing app. The cryptographic signature guarantees that the file is safe to install and was not tampered with in any way. Rather than wait for Google to push this download to your devices, which can take days, download and install it just like any other APK.