TeamNewPipe / NewPipe

A libre lightweight streaming front-end for Android.
https://newpipe.net
GNU General Public License v3.0
30.97k stars 3.01k forks source link

Do not steal focus to report a guru meditation #10135

Open rpdelaney opened 1 year ago

rpdelaney commented 1 year ago

Checklist

Affected version

0.25.1

Steps to reproduce the bug

I'm not sure unfortunately. I was watching videos last night and today I have the problem described below with the background process. I'm happy to experiment if anyone can make suggestions.

Expected behavior

When an unhandled exception occurs, NewPipe should print a guru meditation without stealing focus or switching me out of the app I'm working on.

Actual behavior

Today I'm driving my car navigating with a maps app. NewPipe repeatedly takes over the screen every few minutes to print a guru meditation. I had to pull off the road and force kill the app to get it to stop. This is dangerous and annoying.

To be clear, it's not important what the error was about. Errors happen. When they happen, NewPipe should not ever steal focus.

Screenshots/Screen recordings

No response

Logs

No response

Affected Android/Custom ROM version

grapheneOS.org

Affected device model

Pixel 6

Additional information

No response

1537hasnain commented 1 year ago

Brother please send Api

SameenAhnaf commented 1 year ago

Just in case, guru meditation error occurs you are supposed to scroll down a little, click on COPY FORMATTED REPORT button and paste it in the logs section of this GitHub issue. However, the steps how to reproduce the bug are required to be identified. Could you give us more information on how the error occurred while using the app?

rpdelaney commented 1 year ago

I was driving and not using NewPipe at all. Since I needed to get to my destination on time I did not bother to copy the error log. No matter what the content of the stack trace might be, NewPipe should not ever steal focus like this.

opusforlife2 commented 1 year ago

Basically, if the app is not in the foreground, it should simply generate an error notification, instead of a full-screen one. I think that's the most straightforward solution, @Stypox?

rpdelaney commented 1 year ago

A notification could be reasonable to cover the use case where someone needs to know that NewPipe is no longer running in the background. Ideally, DND mode would suppress that notification as well: in my case, I did not care at all what was going on with NewPipe at that time, which made the focus-stealing especially heavy-handed and frustrating.

mitchellcairns commented 1 year ago

It's not clear how this is replicated. The error will display when NewPipe is completely closed and hasn't been operating. First, fix the issue of the app stealing focus to display errors, second we can go through and determine what the issues actually are.

Stypox commented 1 year ago

I think that's the most straightforward solution, @Stypox?

Yes, although I am not sure there is a simple way to distinguish whether the app was in foreground or not AFTER it has crashed.

opusforlife2 commented 1 year ago

Is that place the point of intervention? I was thinking that the moment the app goes into the background (which I think you can query programmatically?), you could tell the app to send all potential full screen error reports as error notifications instead.

rpdelaney commented 1 year ago

Okay, I just had it happen again. I'm able to copy the stack trace.

I want to emphasize that it is not enough to fix any particular error. The point is that taking focus is a bad thing to do when an error occurred. There will be more errors and bugs: handling them gracefully is at least as important to the user experience as anything else. Therefore I'm putting this here in case the error itself has any clues about why NewPipe is taking focus.

Exception

android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{f892f11 u0 org.schabi.newpipe/.player.PlayerService}
    at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:2009)
    at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1983)
    at android.app.ActivityThread.-$$Nest$mthrowRemoteServiceException(Unknown Source:0)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2245)
    at android.os.Handler.dispatchMessage(Handler.java:106)
    at android.os.Looper.loopOnce(Looper.java:201)
    at android.os.Looper.loop(Looper.java:288)
    at android.app.ActivityThread.main(ActivityThread.java:7903)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
    at com.android.internal.os.ExecInit.main(ExecInit.java:49)
    at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
    at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:355)
Caused by: android.app.StackTrace: Last startServiceCommon() call for this service was made here
    at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1936)
    at android.app.ContextImpl.startForegroundService(ContextImpl.java:1891)
    at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:822)
    at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:822)
    at androidx.core.content.ContextCompat$Api26Impl$$ExternalSyntheticApiModelOutline0.m(R8$$SyntheticClass:0)
    at androidx.core.content.ContextCompat$Api26Impl.startForegroundService(ContextCompat.java:931)
    at androidx.core.content.ContextCompat.startForegroundService(ContextCompat.java:703)
    at androidx.media.session.MediaButtonReceiver.onReceive(MediaButtonReceiver.java:115)
    at android.app.ActivityThread.handleReceiver(ActivityThread.java:4311)
    at android.app.ActivityThread.-$$Nest$mhandleReceiver(Unknown Source:0)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2157)
    ... 9 more


GameOverFlowChart commented 1 year ago

I know a way to reproduce this problem.

Step 1: Have NewPipe in background without playing any video (not just paused)

Step 3: Press the play button on the Bluetooth headphones (by accident or not)

Step 4: Wait a while, it really takes some time

Step 5: NewPipe will crash and steal the focus from which ever app was open to show guru meditation

Wazhai commented 1 year ago

The core of the issue is NewPipe popping up with a full screen crash report while the app isn't in the foreground. For me this usually happens hours or even days after I last opened the app, and often repeatedly until I go and kill NewPipe manually. Most users won't care enough or have the skills to report it properly, making the unprompted focus-stealing pop-up solely a major nuisance.

atomizer commented 12 months ago

Step 3: Press the play button on the Bluetooth headphones (by accident or not)

Another annoying thing (though less annoying than the crash jumpscare) is that the button press gets stolen even if there was an eligible background media app that was used more recently. You have to open that app and resume playback manually.

opusforlife2 commented 12 months ago

That's new. Some versions ago this used to be a workaround for another bug where headphones or Bluetooth would cause the last media app to resume, and if that happened to be Newpipe it would show an empty notification. Making sure another media app was the last one opened was the way to bypass the bug.

amokfa commented 11 months ago

I have created a temporary fork that has guru code commented out. Branches off of dev branch. Download the apk from releases page. https://github.com/amokfa/NewPipe/releases/tag/v1.0.0

Coehill commented 8 months ago

I'm experiencing this same issue on Android 14 (happened on Android 13 too) and have been for many months now. I'll try to remember to attach a log to this ticket next time. I find it difficult since it's usually when I'm driving. I wonder if it has to do with Google Maps or Waze since it never happens with OSM or OrganicMaps for me...

rpdelaney commented 8 months ago

I use OSMAND and it happens frequently. This repro seems to be accurate.

opusforlife2 commented 8 months ago

I'll try to remember to attach a log to this ticket next time.

What log are you talking about? adb logcat? Otherwise it doesn't matter what specific crash report Newpipe generates. The idea is to redirect them all to an error notification.