• Understanding Audio Focus (Part 1/3): Common Audio Focus use cases
  • Nazmul Idris (Naz)
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: oaosj

Understanding Audio focus (Part 1/3) : Common audio focus use cases

Android phones allow multiple applications to play audio simultaneously. Operating systems mix multiple audio streams, but multiple applications play audio at the same time, giving users a poor experience. To provide a more user-friendly experience, Android provides an API for apps to share audio focus, aiming to ensure that only one app can maintain audio focus at a time.

The purpose of this series of articles is to give you an in-depth understanding of what audio focus means, how to use it, and its importance to the user experience. This article is the first in a three-part series that includes:

  1. The most common Audio Focus use Cases and the Importance of being a Good Media career person (this article)
  2. Other use cases that illustrate the importance of audio focus to the app experience
  3. Three steps for implementing audio focus in your application

Good collaborative of audio focus, focus mainly depends on whether the application follow the audio guide, the operating system without enforcing norms governing the application of the audio focus, if applied to choose continue to play audio loudly after loss of audio focus, brings bad user experience and unload homes may directly result in application, but it is unable to prevent the behavior, It’s up to the developers to discipline themselves.

Here are some audio focus usage scenarios (assuming the user is playing audio with your application).

When your application needs to play a sound, it should request the audio focus first, and then play the sound after getting the audio focus.

Use case 1: While playing audio 1 in your application, the user opens another application and tries to play audio 2 related to that application

When your application does not handle audio focus:

Your audio 1 overlaps with another app’s audio 2, and the user can’t hear the audio from either app properly, which makes the user experience very unfriendly.

Your application handles the case of audio focus:

When another app needs to play audio, it asks for the audio focus to be permanent, which is the audio permanent focus. Once the system is authorized, it will start playing audio, at which point your application needs to respond to a loss of audio focus notification and stop playing. So the user only hears audio from another app.

In the same way, if your application needs to play audio after five minutes, you also need to apply for audio focus. Once authorized by the system, we can start playing audio, and other applications will respond to the notification of audio focus loss and stop playing.

Use case 2: When you are playing audio, your mobile phone comes in and you need to play a ring.

When your application does not handle audio focus:

When the mobile phone rings, the user will hear the ring tone and the audio of your mobile phone playing together. If the user chooses to hang up the call directly, your audio will remain playing. If a user selects to answer a call, the user hears the voice of the call played together with your application audio. After the call is hung up, the application audio is played continuously. In any case, your app’s audio will remain playing the entire time. This makes for a terrible phone experience.

Your application handles the case of audio focus:

When the phone rings (and you have not answered the call), your application should choose the appropriate avoidance (which is required by the application) in response to the temporary loss of audio focus. This can be done by lowering the volume of your app to 20%, or by simply pausing it (if your app is a podcast, voice app).

  • If the user refuses to answer the call, your application can immediately respond by getting the audio focus and then doing something to increase the volume or resume playback.
  • If the user answers the call, the operating system notifies him of the loss of audio focus. Your app should pause the call and resume it when the call ends.

conclusion

When your application needs to output audio, you should request audio focus. Only after the audio is in focus can it start playing. However, it may not be possible to keep the audio focus as its own during playback, because other applications can request the audio focus to preempt it. In this case, your application can choose to pause or lower the volume so that the user can hear the audio of other applications more clearly.

For more details on audio focus scenario use cases in applications, read the second article in this series.

Understand audio focus (Part 2/3) – Nazmul Idris (Naz) – Medium

To learn how to implement audio focus in your application, read the third and final article in this series.

Understand audio focus (Part 3/3) – Nazmul Idris (Naz) – Medium

Android multimedia development resources

  • Example code – MediaBrowserService
  • Sample code – MediaSession Controller Test (with audio focus Test)
  • Understand MediaSession
  • Multimedia API Guide – Overview of multimedia Applications
  • Multimedia API Guide – Using MediaSession
  • Build a simple audio application using MediaPlayer

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, React, front-end, back-end, product, design and other fields. If you want to see more high-quality translation, please continue to pay attention to the Project, official Weibo, Zhihu column.