IssueTracker

From all my tests it requires a visible activity or be in one of the few exclusions that count as user interaction allowing FGS start.

If you receive an intent from a widget or a media session callback from the notification then you can request focus even without having the service in foreground.

I really hope that it's a bug in Android 15 and they'll fix the bug and not that it's a documentation bug and they'll remove the notion of FGS and they'll break a tons of use cases like yours, or mine like auto playback start on headset plug while the app is in background or any published API. Users can remove battery restriction to allow apps to start FGS from background but we can't play audio, that does not sound right.

The issue reproduce on pixels:

Pixel 6 pro build: AP41-240823.009

Pixel 8 pro build: AP3A-241005.015

OP already have provided the rest that is needed, the corresponding team have everything needed to reproduce and confirm it's and Android 15 bug or a documentation bug.

• we tested on both a Pixel 9 phone and an Emulator running Android 15

• the Pixel 9 build was AP3A-241005.015, and the Emulator was AE3A.240806.005

• we've uploaded a bugreport and shared it at: https://drive.google.com/file/d/1kSyxTegya2BRuVk5wqOZXKkLKNgba4z0/view?usp=sharing

The bugreport logs of the event are about 10:31am, and highlights include:

10-24 10:31:24.219  1000   637  3357 W AS.AudioService: Audio focus request blocked by hardening

10-24 10:31:24.224 10208  9813  9813 E AlarmService: getAudioFocus() - isGranted: false (result: 0)

...emphasis on the new hardening in Android 15

If alarm apps are unable to gain audio focus in Android 15, then their ability to be heard over other media will have a severe impact on alarm reliability. I don't know if there's another workaround for this, but currently we cannot target Android 15 with our app (you can view our app from this developer account)

Behavior of YouTube/Spotify on Android 14 with our alarm app and Google Clock:

• media/music paused when alarm starts and resumed afterwards

Behavior with Android 15 and apps targeting Android 15:

• media/music and alarms both play at the same time due to failed audio focus

Note: our Android 15-targeting update is unreleased still

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Thanks

I have a very similar issue on my own project https://github.com/SimonMarquis/SleepTimer, which is now broken on Android 15.
Broken because stopping the media playback is the main (and only) feature provided by this app.
Even with a foreground service (mentionned in Android 15 behavior changes), requesting audio focus now always leads to AUDIOFOCUS_REQUEST_FAILED on Android 15.

Here is how the app works:

• A TileService detects user action, and starts a countdown by posting a Notification.
• The Notification is configured with a setTimeoutAfter(durationMs) and setDeleteIntent(PendingIntent) to a foreground service.
• When the timeout is reached, the notification is automatically deleted by the Android OS, which also triggers the PendingIntent.
• The service is started, startForeground(id, notification, type) is called, followed by requestAudioFocus(), but this always result in AUDIOFOCUS_REQUEST_FAILED with the following messages in logcat:

  AS.HardeningEnforcer  system_server  I  Focus request DENIED for uid:10521 clientId:android.media.AudioManager@5e957d9fr.smarquis.sleeptimer.SleepAudioService$$ExternalSyntheticLambda1@7f4b59e req:1 procState:4
  AS.AudioService       system_server  W  Audio focus request blocked by hardening
  

You can take a look at the PR trying to implement the new Android 15 requirements if you want to reproduce the issue.

Any update on this?

This is AOSP tracker they do not communicate with us unless you know someone on the assigned team. They have a copy of this and an external company triage and pass messages.

The good news is that the priority was changed so it was triaged on the other private side too. The bad news is that usually we'll only get the result at the very last moment and can't anticipate anything. So if it's broken and they can only fix for 16 this will be closed as fixed when 16 is officially out, and we'd loose a couple of month to prepare communication and workarounds for Android 15 when we are forced to target it.

I've reported several issues before and had feedback with the Google assignee, it just depends on who they are, and the issue... hoping to hear back as this is blocking us.

Issues on AOSP ?

I've reported hundreds of issues since nearly 14 years of doing Android apps, this is a special handling.

The vi... assigned here is not from Google but an external company passing data to the actual internal private issues when first data gathering is done.

On many other parts, you directly have access to Googlers like R8 and Compose, unfortunately not for this one.

Yes

And yet as you can see despite asking nicely no reactions.

When it's literally 5 seconds to write it's a doc issue we'll investigate the needs for Android 16/17/.... or it's a bug we'll investigate a solution.

We don't need the solution instantly we need to know if it's doc or AOSP bug to be able to take decisions for our millions users.

The issue has been fixed and watch out for future releases, Thanks.

And as always with AOSP a wonderful communication:(

Fixed docs? Fixed code for 15? for 16? For 16.1 ?

Let's find out one day.

It was P1 can a Googler take the necessary time to communicate on this as we need to make decisions.

Thanks in advance.

Thanks for the update, any clarification on "future release"? Will this make Pixel's December update so we can verify before releasing our update? Is it going to be included in Android 15, and not a future version such as 16?

Also, I'm not sure what was changed, but will the documentation be updated? https://developer.android.com/about/versions/15/behavior-changes-15#audio-focus

Currently it sounds like any foreground service can request audio focus successfully. Is this the case? Or does it need a specific foregroundServiceType?

Replying on #comment22:

Update target is Pixel Mar update, and should be in the beta for that release vehicle. The documentation is now consistent with the fixed behavior (any FGS type suffices). The buggy behavior requires a FGS which is launched with while-in-use permissions. That being said, we recommend choosing an appropriate FGS type, as further restrictions on various FGS types may be put in place in the future.

Thanks for the update, it sounds like the fix will be available in the next Quarterly Platform Release... early 2025.

Looks good with Pixel March update! Thx