Fix music stop on unlock and buffering issues

[adrielGGmotion]

This change fixes an issue where music playback would stop suddenly when unlocking the phone or during specific buffering scenarios on Pixel 9 (Android 16).

The root cause was a race condition in handleAudioFocusChange. When multiple transient focus loss events occurred in quick succession, the wasPlayingBeforeAudioFocusLoss flag was unconditionally updated to the current player.isPlaying state. If the player was already paused by the first event, the second event would overwrite the flag to false, preventing the app from resuming playback when focus was regained.

The fix ensures wasPlayingBeforeAudioFocusLoss is only updated to true if the player is currently playing, preserving the resume intent during overlapping focus loss events.

---

PR created automatically by Jules for task 15857672458169717871 started by @adrielGGmotion

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Summary of Changes

Hello @adrielGGmotion, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue where music playback would unexpectedly cease, particularly when unlocking a phone or during certain buffering scenarios. The problem stemmed from a race condition in how audio focus changes were handled, specifically with a flag intended to track playback state before focus loss. The changes ensure this flag accurately reflects the player's state, thereby preserving the intent to resume playback after transient audio interruptions.

Highlights

• Race Condition Fix: Addressed a race condition in the handleAudioFocusChange method that caused music playback to stop unexpectedly, particularly when unlocking the phone or during buffering, on Android 16 devices like Pixel 9.
• Conditional wasPlayingBeforeAudioFocusLoss Update: The wasPlayingBeforeAudioFocusLoss flag is now only set to true if the player is actively playing when an audio focus loss event occurs. This prevents the flag from being incorrectly overwritten to false during successive transient focus loss events, ensuring proper playback resumption.

Changelog

• app/src/main/kotlin/com/metrolist/music/playback/MusicService.kt
  • Modified the handleAudioFocusChange method to ensure wasPlayingBeforeAudioFocusLoss is only set to true when the player is actively playing during AUDIOFOCUS_LOSS, AUDIOFOCUS_LOSS_TRANSIENT, and AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK events.
  • Removed the unconditional assignment of wasPlayingBeforeAudioFocusLoss = player.isPlaying before the if (player.isPlaying) check in audio focus loss handlers.

Activity

• No human activity (comments, reviews) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively addresses a race condition in handleAudioFocusChange that caused music to stop unexpectedly. The fix correctly ensures wasPlayingBeforeAudioFocusLoss is only set when playback is paused due to focus loss, preventing its state from being corrupted by multiple focus events. However, this same logic was applied to the AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK case, where playback is not paused. This introduces a bug where the player might incorrectly resume later. I've provided a comment with a suggested fix for this specific case.

[gemini-code-assist]

Setting wasPlayingBeforeAudioFocusLoss to true here introduces a potential bug. Since AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK only lowers the volume ('ducks') and doesn't pause playback, this flag should not be modified. If it's set to true here, it won't be reset upon regaining focus (since the player is still playing), which can cause the player to incorrectly resume playback later if the user manually pauses it.

The wasPlayingBeforeAudioFocusLoss flag should only be set when playback is actually paused due to audio focus loss. For ducking, this line should be removed.

                if (player.isPlaying) {
                    player.volume = (playerVolume.value * 0.2f)
                }