yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: the notification permission dialog is asked from the play button and blocks playback #212

New Issue
Open
opened 2026-08-23 20:36:42 +00:00 by yonlu · 0 comments
yonlu commented 2026-08-23 20:36:42 +00:00
Owner
Copy Link
Copy Source

Symptom

On the phone, pressing play on a fresh install pops the system
POST_NOTIFICATIONS permission dialog, and playback does not start
until the dialog is answered. The first thing the app does when asked
to play music is ask a question about notifications.

Reproduction

  1. Install the APK on an Android 13+ device (fresh, or after clearing
    the app's data so the permission has never been answered).
  2. Open the app, pick a track, press play.
  3. The permission dialog appears over the app; nothing is heard until
    it is dismissed.

Where it comes from

push() in backend/mediacontrols/android.go calls
application.Android.StartForegroundService(payload) the moment the
state stops being StateStopped — which is correct, and is what the
comment on running says it is for. The Java half is what asks:
WailsBridge.startForegroundService
(build/android/app/src/main/java/com/wails/app/WailsBridge.java,
~line 1222) does

if (Build.VERSION.SDK_INT >= 33 && activity.checkSelfPermission(
        "android.permission.POST_NOTIFICATIONS") != PERMISSION_GRANTED) {
    activity.requestPermissions(new String[]{"android.permission.POST_NOTIFICATIONS"}, 1003);
}

immediately before starting the service — scaffold code, but
build/android/ is committed and hand-edited like source here, so it
is ours to change. postNotification (~line 757) does the same thing
with request code 1001.

That request is on the playback path, which is what makes it both a
badly-timed question and a plausible cause of the block: while a
system dialog is up the app is not top-of-stack, and on API 31+ a
startForegroundService from that state is refused
(ForegroundServiceStartNotAllowedException), so the transport
service is exactly the thing that cannot start at the moment the
permission is being asked about. Worth confirming with logcat which
half of "nothing happens" is which — no audio at all, or audio with no
notification.

Direction

Two claims, and the second is the one that matters:

  • Denying the permission must not stop playback. A
    mediaPlayback foreground service still starts and still runs
    without POST_NOTIFICATIONS on Android 13+; what is lost is the
    notification being shown. So the request should be fire-and-forget
    beside the start, never a gate in front of it, and the start should
    not be issued from a state the framework will refuse.
  • The question does not belong on the play button. Ask it once,
    where it can be explained — first-run, or a Settings affordance
    about lock-screen controls — so the first press of play is a press
    of play. Failing that, ask it after the service is running rather
    than before.

Worth checking on a device while fixing: whether audio genuinely stops
or only the notification is absent, and whether the service start is
refused (ForegroundServiceStartNotAllowedException in logcat).

Not covered by any tier here

Per AGENTS.md, no tier in this repo compiles the android files or
can see a permission dialog; .pi/skills/yellowjacket-dev/references/android-tier.md
is where the device check belongs.

## Symptom On the phone, pressing play on a fresh install pops the system POST_NOTIFICATIONS permission dialog, and playback does not start until the dialog is answered. The first thing the app does when asked to play music is ask a question about notifications. ## Reproduction 1. Install the APK on an Android 13+ device (fresh, or after clearing the app's data so the permission has never been answered). 2. Open the app, pick a track, press play. 3. The permission dialog appears over the app; nothing is heard until it is dismissed. ## Where it comes from `push()` in `backend/mediacontrols/android.go` calls `application.Android.StartForegroundService(payload)` the moment the state stops being `StateStopped` — which is correct, and is what the comment on `running` says it is for. The Java half is what asks: `WailsBridge.startForegroundService` (`build/android/app/src/main/java/com/wails/app/WailsBridge.java`, ~line 1222) does ```java if (Build.VERSION.SDK_INT >= 33 && activity.checkSelfPermission( "android.permission.POST_NOTIFICATIONS") != PERMISSION_GRANTED) { activity.requestPermissions(new String[]{"android.permission.POST_NOTIFICATIONS"}, 1003); } ``` immediately before starting the service — scaffold code, but `build/android/` is committed and hand-edited like source here, so it is ours to change. `postNotification` (~line 757) does the same thing with request code 1001. That request is on the playback path, which is what makes it both a badly-timed question and a plausible cause of the block: while a system dialog is up the app is not top-of-stack, and on API 31+ a `startForegroundService` from that state is refused (`ForegroundServiceStartNotAllowedException`), so the transport service is exactly the thing that cannot start at the moment the permission is being asked about. Worth confirming with logcat which half of "nothing happens" is which — no audio at all, or audio with no notification. ## Direction Two claims, and the second is the one that matters: - **Denying the permission must not stop playback.** A `mediaPlayback` foreground service still starts and still runs without POST_NOTIFICATIONS on Android 13+; what is lost is the notification being *shown*. So the request should be fire-and-forget beside the start, never a gate in front of it, and the start should not be issued from a state the framework will refuse. - **The question does not belong on the play button.** Ask it once, where it can be explained — first-run, or a Settings affordance about lock-screen controls — so the first press of play is a press of play. Failing that, ask it *after* the service is running rather than before. Worth checking on a device while fixing: whether audio genuinely stops or only the notification is absent, and whether the service start is refused (`ForegroundServiceStartNotAllowedException` in logcat). ## Not covered by any tier here Per `AGENTS.md`, no tier in this repo compiles the `android` files or can see a permission dialog; `.pi/skills/yellowjacket-dev/references/android-tier.md` is where the device check belongs.
yonlu added the Area/Player
Priority
High
2
Platform/AndroidKind/Bug labels 2026-08-23 20:36:42 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Player Kind/Bug Platform/Android
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#212