AudioExoPlayer a simple player with great potential

The OtherPlayerStarted notification works based on the player's focus. When the player loses focus for various reasons, such as a call, changes its behavior, mutes, pauses, etc., the player built into the app inventor implements focus support. It also has a listener that detects the loss of focus and triggers the OtherPlayerStarted event. My extension is based on the exo player library, which manages focus itself. To trigger the OtherPlayerStarted event, I would have to disable the built-in focus support and implement it myself. However, I think this is better implemented in the library than I could do myself. But it is possible... OK, explain to me: when your player loses focus because someone is calling, for example, what do you do in the OtherPlayerStarted event?

I have not successfully implemented this yet...Looks like you understand this MUCH better than I do. I was trying to use the phone call component to detect the beginning of a call but I encountered a problem that I reported in post number 1113 in this thread:

The idea is to mute the player (Vol=0) and immediately re/start it when a phone call was started...and then unmute it when the call ended... But the phone call notification is not now working in Itoo

So how do you recommend that I detect the loss of focus since the Phone Call component does not presently work from within Itoo? Is there another way to detect the beginning of a call? Or should simply wait until this is made available in Itoo?

Thank you for your help.

-Randal

I can make the player mute the sound on incoming calls.

Well, if that will be a set-able/read-able boolean property, it would be quite nice!! :slight_smile:

If set=true,
On incomming calls: AudioExoPlayer does not pause but sound is muted (or Vol=0)

On call end (no answer or hangup or refuse, etc.) : AudioExoPlayer is unmuted (or Vol is set to previous vol)

Is that what you propose? That would be just what I need!!

-Randal

I tested this on my POCO phone with Android 15, and it doesn't work for me. Starting the second player doesn't trigger the OtherPlayerStarted event.

Hmmm... I assume you ran the OtherPlayer_Test.aia app that I posted above...

Let me try on other API/OS versions...

But as far as I am converned if you can implement the OnPhoneCallStart and OnPhoneCallEnd events/actions as discussed above, I would preferr that to the OtherPlayerStarted ... since the Phone call interruption on my phone did NOT fire the IA2 Comp[onent Player.OtherPlayerStarted event anyway. So your suggestion is better for me ... maybe not for other users??

Let me test a bit and get back.

-Randal

Tested on API 26 (OS ver 8) and 35 (OS ver 15) and seems to work for me.

Start Player 1 (Note that Player1 volume is set VERY low...), then start Player 2 which stops player 1 and starts player 2 playing the same audio clip but louder...I also get the momentary display/Alert notification stating one player detects the start of the other.

You can check which player is playing (or not) with the Display Player Status button...

Can you tell me what happens? Do both players play after starting the second one? If you start player2 first (louder one) does player1 start (use button to see which are playing) and player2 keeps playing...

You might remove/delete Notifier1 just to see of that's possibly making the difference. When I deleted it, it took no other code changes and it worked as expected. Again, you can use button to verify which is or is not playing...

-Randal

Yes, both players are playing simultaneously for me. I swapped Player for my AudioExoPlayer and got the same result. I think it might be some internal implementation changes depending on the phone manufacturer. But I still receive a notification whenever a call comes in.

So if you need such an event, I can do something like AudioFocusChanged, which returns a boolean value indicating focus lost. If it returns true, it means focus has been lost and someone is calling, and if it returns false, it means the call has been disconnected.

Yes, an Event. But to clarify, by "returns" do you mean that the event passes a single boolean parameter? That would be good...I just want to be sure you don't mean a function that returns a boolean value when called?

However, FULL DISCLOSURE:

I have to tell you that the AudioExoPlayer will be running in an Itoo service/process (;which I have implemented).

BUT, earlier I reported what appears to be a bug (Open Source β€’ Background Tasks: Itoo πŸš€ - #1165 by Randal_Andress ) that prevents the PhoneCall component's events IncomingCallAnswered and PhoneCallEnded from working...

If you are using these PhoneCall events in your extension to provide this new event, I'm concerned that it may not work from within Itoo either. If you build it, I am happy to try it, but I would not want you to go to a lot of trouble building it when it may not work from Itoo :frowning: ... and if it is fixed, then I can simply use the PhoneCall component for these events :slight_smile: ... I'd like to give your new event a try, but it may not solve my problem.

-Randal

The previous event had a "focusLost" parameter, which will only be true if losing focus would result in your player being paused (e.g., while someone is calling on the phone or using an instant messenger). Sometimes, losing focus will cause the player to mute, but this won't trigger the event.

If this event is called with an argument of true, it will mean that my player has lost focus and has been paused, correct?

So, if I set the volume to zero and issue a Play command, that should minimize any delay added to the stream that is playing.

Will the event be called when the call or message has ended with a parameter of false? If so, I could then unmute my player.

-Randal

No, it is not possible to play when the player is not have focus. I tried.

You can try a new event.

Thanks, @Patryk_F, for version 2.0! Just downloaded it and the test app... looking forward to trying it tonight!

Tnx,
Randal

@Patryk_F, just letting you know it will be tomorrow before I can get you any meaningful feedback :frowning:

Kind regards,
Randal

@Patryk_F, I have not been able to get the new event (AudioFocusChanged) to occur.

Perhaps my test app is ill-designed, but I had expected that, if the player was playing, an incoming call would cause the even to be called. But the player pauses and then unpauses on the end of the call without any indication that the event was called.

BTW, the default url is a music data file included with the app....(so long as you do not press the toggle url button).

UIExoPlayer_FocusChange.aia (6.7 MB)

Perhaps I have misunderstood or have made an error in my implementation.

Can you see what is wrong?

==================

I have added a smaller/simpler test:

ExoPlayer_Focus_Test.aia (6.7 MB)

Screen1.Initialize starts the player. The start of a phone call pauses the player - when the call ends, the player resumes with no indication of an error or a focus change.

-Randal

There was a minor error which I have already fixed.

Thanks! I have downloaded version 2.1 and now I am able to get the event. However, I cannot seem to stop the player from pausing for the duration of the call.

I have tried to execute the play command and reset the volume, but it still seems to pause/

Here is the focus cnanged blockl:

The test case blocks:

The ai2 cocde:

ExoPlayer_Focus_Test_v2_1.aia (6.7 MB)

Any ideas on how to keep the phone call from pausing the player?

-Randal

Yes, I think this is forced by the system, and we can't continue playing when the phone rings. Have you done similar tests with the regular Player?

I asked Gemini for you and below is the answer
Taifun


Generally, it is not possible for a music player app to continue playing audio audibly during an active phone call on a standard Android phone.

Android's audio focus system is designed to give exclusive, high-priority access to the phone call app, which by default causes other media apps (like music players) to automatically pause or mute. This is the intended behavior for a good user experience, ensuring the user can hear the call clearly.

Key Technical and User Considerations

  1. Audio Focus
    The primary mechanism that prevents simultaneous audio is Audio Focus.
  • When a phone call starts, the Phone app requests and is granted the highest level of audio focus.
  • Media apps (like your music player) are notified of this loss of focus with a AUDIOFOCUS_LOSS_TRANSIENT event, which signals them to pause their playback.
  • Even if a music app was programmed to ignore this focus loss, the Android system on newer versions (Android 12+) is designed to mute media playback when an incoming call is received to prevent conflicts.
  1. Hardware and Bluetooth Limitations
    The ability to play two different audio streams (a phone call and music) to the same Bluetooth device is often a limitation of the Bluetooth standard (HFP vs. A2DP profiles) or the specific Bluetooth hardware, which typically prioritizes the call audio.

Exceptions and Workarounds
While standard media playback is blocked, there are a few scenarios where multiple audio streams might be possible:

  • System/OEM-Specific Features (e.g., Samsung): Some device manufacturers, like Samsung, offer features that can override the default audio focus behavior.
    • Good Lock/Sound Assistant: Users can sometimes enable a "Multi Sound" or "Separate app sound" feature that allows selected apps to play audio simultaneously with a call, or play one app's audio to a different output device.
  • Developer/Root-Level Tweaks: Advanced users can sometimes use third-party apps like AppOps (often requiring root or ADB access) to revoke the "Take Audio Focus" permission from the phone call app.
    • Caveat: This is highly technical, not recommended for average users, and may result in the music playing at full volume over the call, making it difficult to hear the conversation.
  • App Configuration: Some individual music player apps might have a setting like "Pause During Call" which, if unchecked, attempts to let the music play, but this is usually still overridden by the phone's system-level call prioritization.
1 Like