Fix ghost notifications and fix "did not then call startForeground()"#12606
Merged
Stypox merged 2 commits intoTeamNewPipe:devfrom Sep 30, 2025
Merged
Fix ghost notifications and fix "did not then call startForeground()"#12606Stypox merged 2 commits intoTeamNewPipe:devfrom
Stypox merged 2 commits intoTeamNewPipe:devfrom
Conversation
6 tasks
Stypox
force-pushed
the
do-not-startService-randomly
branch
from
1362612 to
a0fcf18
Compare
AudricV
added
bug
TobiGr
approved these changes
Sep 16, 2025
Contributor
TobiGr
left a comment
TobiGr
left a comment
There was a problem hiding this comment.
the changes look reasonable to me. And as per #12489 (comment) they seem to fix the problem.
github-actions
bot
added
size/medium
This commit fixes one way ghost notifications could be produced (although I don't know if there are other ways). This is the call chain that would lead to ghost notifications being created: 1. the system starts `PlayerService` to query information from it, without providing `SHOULD_START_FOREGROUND_EXTRA=true`, so NewPipe does not start the player nor show any notification, as expected 2. the `PlayerHolder::serviceConnection.onServiceConnected()` gets called by the system to inform `PlayerHolder` that the player started 3. `PlayerHolder` notifies `MainActivity` that the player has started (although in fact only the service has started), by sending a `ACTION_PLAYER_STARTED` broadcast 4. `MainActivity` receives the `ACTION_PLAYER_STARTED` broadcast and brings up the mini-player, but then also tries to make `PlayerHolder` bind to `PlayerService` just in case it was not bound yet, but does so using `PlayerHolder::startService()` instead of the more passive `PlayerHolder::tryBindIfNeeded()` 5. `PlayerHolder::startService()` sends an intent to the `PlayerService` again, this time with `startForegroundService` and with `SHOULD_START_FOREGROUND_EXTRA=true` 6. the `PlayerService` receives the intent and due to `SHOULD_START_FOREGROUND_EXTRA=true` decides to start up the player and show a dummy notification Steps 3 and 4 are wrong, and this commit fixes them: 3. `PlayerHolder` will now broadcast `ACTION_PLAYER_STARTED` when the service connects, only if the player is not-null 4. `PlayerHolder::tryBindIfNeeded()` is now used to passively try to bind, instead of `PlayerHolder::startService()`
This should solve "Context.startForegroundService() did not then call Service.startForeground()" according to TeamNewPipe#12489 (comment)
Stypox
force-pushed
the
do-not-startService-randomly
branch
from
bff51c2 to
aa2b482
Compare
Member
Author
|
@TobiGr the APK that was tested in #12489 (comment) was based on one further commit (see the diff in my comment on the issue), which I now pushed here |
6 tasks
Member
Author
|
Merging so people can start testing this in nightlies |
Stypox
changed the title
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is it?
Description of the changes in your PR
This PR fixes one way ghost notifications could be produced (although I don't know if there are other ways). This is the call chain that would lead to ghost notifications being created:
PlayerServiceto query information from it, without providingSHOULD_START_FOREGROUND_EXTRA=true, so NewPipe does not start the player nor show any notification, as expectedPlayerHolder::serviceConnection.onServiceConnected()gets called by the system to informPlayerHolderthat the player startedPlayerHoldernotifiesMainActivitythat the player has started (although in fact only the service has started), by sending aACTION_PLAYER_STARTEDbroadcastMainActivityreceives theACTION_PLAYER_STARTEDbroadcast and brings up the mini-player, but then also tries to makePlayerHolderbind toPlayerServicejust in case it was not bound yet, but does so usingPlayerHolder::startService()instead of the more passivePlayerHolder::tryBindIfNeeded()PlayerHolder::startService()sends an intent to thePlayerServiceagain, this time withstartForegroundServiceand withSHOULD_START_FOREGROUND_EXTRA=truePlayerServicereceives the intent and due toSHOULD_START_FOREGROUND_EXTRA=truedecides to start up the player and show a dummy notificationSteps 3 and 4 are wrong, and this PR fixes them:
3.
PlayerHolderwill now broadcastACTION_PLAYER_STARTEDwhen the service connects, only if the player is not-null4.
PlayerHolder::tryBindIfNeeded()is now used to passively try to bind, instead ofPlayerHolder::startService()Fixes the following issue(s)
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.
Testing APK: pr12606.zip
Due diligence