Fix background crash focus

[Thompson3142]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

This PR addresses the issue of NewPipe stealing focus to report an error even while it is in the background.
To check if the app has been in the background a monitoring class (that could also be used for different purposes) and a shared preference have been introduced to ensure that the state is correctly remembered and can then handle the reporting accordingly e.g. only show a notification if the crash happened while in foreground and show a not.
This was tested via delayed test crashes:

new Handler(Looper.getMainLooper()).postDelayed(() -> {
            // Deliberately throw a RuntimeException
            throw new RuntimeException("Simulated crash for testing purposes.");
        }, 20000);

Occasionally i have seen this misbehave seemingly when another crash occurred before with a different foreground/background state. Unfortunately i have not found a fix for this, if somebody wants to take a look or can reproduce it I would be grateful. I am also open to completely different approaches since this approach is of course not optimal.

Fixes the following issue(s)

• Fixes Do not steal focus to report a guru meditation #10135

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR. You can find more info and a video demonstration on this wiki page.

Due diligence

• I read the contribution guidelines.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Stypox]

Can't you override these functions directly in MainActivity?

[Thompson3142]

You can, i just missed that AppCompatActivity has these methods to overwrite. Unfortunately it does not seem like it fixes the occasionally wrong behavior i mentioned, probably something related to ACRA but I am unsure how to fix it.

[Profpatsch]

Can we add a button to the Settings -> Debug menu that does a delayed crash, so you can simulate the problem here? I don’t know how to reproduce it.

[Thompson3142]

I don't know how necessary it is to have a dedicated button for that, but if you want to reproduce it, you can do it very easily using something like:

new Handler(Looper.getMainLooper()).postDelayed(() -> {
            // Deliberately throw a RuntimeException
            throw new RuntimeException("Simulated crash for testing purposes.");
 }, 20000);

You could create a new button like the crashTheAppPreference in DebugSettingsFragment with this snippet, what i did was simply calling it when the player is opened but thats up to you.

[Profpatsch]

I couldn’t reproduce it by either inserting that into MainActivity nor Player; do you have a commit with the exact position where you added that?

[Thompson3142]

I never commited it because I don't wanted to mess with the git history, maybe I am missunderstanding though what you can not reproduce?

[Profpatsch]

what you can not reproduce?

I cannot reproduce the error screen popping up and taking focus when NewPipe is in the background.

If you want, you can commit the example on a fresh branch and just link the branch or the commit directly.

[Thompson3142]

Maybe it's something device specific? I can provide a commit that I used to test but it really just boils down to adding the code I mentioned into the first line after handleIntent in the Player class. Also can you not reproduce it in general or just with my attempt to fix it?

[Stypox]

In an app of mine I used a static field instead of the preferences, since there is only going to be one MainActivity alive at a time anyway: https://github.com/Stypox/dicio-android/blob/master/app/src/main/kotlin/org/stypox/dicio/MainActivity.kt#L178
Maybe it would be better if you switched to a static field now that I think of it, so you can make the code simpler and not rely on shared preferences (which do disk I/O every time).
Also, put the Log.d behind an if (DEBUG) { ... }

[Stypox]

Maybe it's something device specific?

Yes I think from Android 13 the background intents are blocked anyway

[Profpatsch]

Ah, so I need to test on an older Android version, I see.