Context.startForegroundService() did not then call Service.startForeground()

[Woffkaa]

Version

Media3 1.6.1

More version details

ANDROID_BUILD_SDK_VERSION = 35
ANDROID_BUILD_MIN_SDK_VERSION = 21
ANDROID_BUILD_TARGET_SDK_VERSION = ANDROID_BUILD_SDK_VERSION

JAVA_VERSION = JavaVersion.VERSION_17
KOTLIN_JDK = "org.jetbrains.kotlin:kotlin-stdlib-jdk8:2.0.20"

GRADLE_PLUGIN_VERSION = "8.6.0"
distributionUrl=https\://services.gradle.org/distributions/gradle-8.10-bin.zip

ANDROIDX_APPCOMPAT = "androidx.appcompat:appcompat:1.7.0"
ANDROIDX_MEDIA3_VERSION = "1.6.1"
ANDROIDX_MEDIA3_SESSION = "androidx.media3:media3-session:$ANDROIDX_MEDIA3_VERSION"
ANDROIDX_MEDIA3_EXOPLAYER = "androidx.media3:media3-exoplayer:$ANDROIDX_MEDIA3_VERSION

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <!-- MusicService -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" /> <!-- MusicService -->

<service
    android:name=".services.music.MusicService"
    android:exported="true"
    android:foregroundServiceType="mediaPlayback">
    <intent-filter>
        <action android:name="androidx.media3.session.MediaLibraryService" />
        <action android:name="android.media.browse.MediaBrowserService" />
    </intent-filter>
</service>

Devices that reproduce the issue

3100 crashes affecting 310 users on Android 11 (Only Samsungs, Only Galaxy A** series, not S**)

1200 crashes affecting 300 users on Android 11 (96%), Android 10 (2%), Android 9 (1%) and Android 8 (1%).
71% Samsung (All Galaxy series, A** and S**), 24% Xiaomi (Redmi, Mi, Xiaomi)

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

No

Reproduction steps

I have no idea
I spent hours trying to reproduce the crash when the app is in the background or removed from recents, and also using bluetooth headphones. Never worked.

I do NOT use the PlaybackResumption feature (#167)
and I do NOT see any ForegroundServiceDidNotStartInTimeException.

I do NOT override any of
onGetChildren
onGetItem
onGetLibraryRoot
onGetSearchResult
onAddMediaItems
onSearch
onSetMediaItems

But I see a lot of
Context.startForegroundService() did not then call Service.startForeground()
crashes (99% of all crashes)

The service only plays radio or a list of podcasts.

Here is a gists
How I manage the MediaBrowser lifecycle
https://gist.github.com/Woffkaa/15cc3565a82366a49d009a4b0ea6b42b
How I start the playback
https://gist.github.com/Woffkaa/11e2d11458f55122d963e9e508495feb
And the service itself
https://gist.github.com/Woffkaa/966c2ead021a3dced1f105e1f6c6480b

Expected result

No crash?

Actual result

A lot of crashes on Android 11

Is it my fault or are we still waiting for someone to reproduce and describe the steps in the demo?

Media

.

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[gabrielle88]

We have exactly the same issue as you. From our crashlytics report we know that this issue has 1,036 crash events affecting 89 users. 99%Samsung devices with 99%Android 11.

[marcbaechinger]

Thanks both. We know about this issue. It's unclear who or what is starting the service an these devices. We don't get support from Samsung for this I'm afraid. I suggest you contact Samsung for this issue. I can not help without further info from the vendor I'm afraid.

I will leave this issue open for a while in case someone find the actor that tries to restart the service on these devices.

See #167 also

[mattrob33]

Thanks for the update @marcbaechinger. Would the Media3 team be willing to incorporate a workaround if one can be found?

The OEM breakdown in our crash reports over the past couple of years shows 0 Pixel devices, which I agree does suggest it is OEM related. The issue is not restricted to Samsung though, so contacting the vendor unfortunately is not a viable option.

Samsung - 67%
Motorola - 8%
Transsion - 4%
Oppo - 4%
HMD Global- 4%
Xiaomi - 4%
Oppo - 2%
Huawei - 1%
Hisense - 1%
Foxconn - 1%

[marcbaechinger]

I think we should see that app developers are not blamed for things they can not change themselves. This includes fixing bugs in Media3, but IMO this also includes applying vendor specific workarounds even if it disables features on these devices. It's a case by case decision I think. We do this often with codec bugs of which we know they are probably not going away as it's in HW codecs. We did this for deviations in behavior of System UI as well.

We had such examples where we do this and we contacted the vendor internally, got a response which made us sure we understand the problem, generally and/or on that device. I never got a single word back from some vendors. We still don't know who or what may attempt to start the service on these devices. We did our part investigation (the community here did even more to help us, thanks for that!). We can't spend much more time on vendor specific investigations given we can't see this on AOSP and/or Pixel builds.

I think removing the 67% chunk would be nice already, so if that workaround works for some, I think we should look at such a workaround if available. What would you suggest as a workaround?

[johngray1965]

I'm quite certain that Media3 drops KEYCODE_HEADSETHOOK in some instances resulting in the request effectively being dropped and therefore Service.startForeground is never called. I believe the device that are crashing are just translating the Bluetooth commands to intents differently. If I get KEYCODE_MEDIA_PLAY_PAUSE, I'm always good. If I get KEYCODE_HEADSETHOOK, not so much. All my crashes are KEYCODE_HEADSETHOOK.

What's very concerning to me is that in those case, MediaSessionService.onStartCommand logs "Ignored unrecognized media button intent." We are dead in the water. We will crash. But there's no way for the caller of MediaSessionService.onStartCommand to know that happened. After the call to MediaSessionService.onStartCommand as far as we know all is good. But it's not.

I realize they aren't quite a one-to-one, but the MediaButtonReciever thought it was good, and MediaSessionService.onStartCommand didn't. I'd really hope MediaButtonReciever wouldn't start the service if MediaSessionService.onStartCommand couldn't act on. I believe the rub there is MediaButtonReciever is dealing with individual presses, and MediaSessionService.onStartCommand trying to detect double taps.

So MediaButtonReciever thought it was good, MediaSessionService.onStartCommand didn't, and nobody told me.

See #2768

[johngray1965]

@Woffkaa I started logging the intents via Google Analytics. They are always KEYCODE_HEADSETHOOK when we get crash. There's definitely bug in MediaSessionImpl with a missing case for KEYCODE_HEADSETHOOK. I put in PR for it today. #2779