feat(sdk): lock-screen media controls via LightMediaSession#100
Draft
tthayer wants to merge 4 commits into
Draft
feat(sdk): lock-screen media controls via LightMediaSession#100tthayer wants to merge 4 commits into
tthayer wants to merge 4 commits into
Conversation
Add a LightMediaSession primitive so a tool can publish its playback to Android's media framework — a MediaSession plus a mediaPlayback foreground service and a MediaStyle notification — which LightOS surfaces on the lock screen and which routes headset/Bluetooth transport keys back to the tool. - plugin: allow FOREGROUND_SERVICE + FOREGROUND_SERVICE_MEDIA_PLAYBACK - client: LightMediaSession API (attach/setControls/update/release) + LightMediaService foreground service + manifest <service> declaration - emulator: NowPlayingReader reads active sessions via MediaSessionManager (MEDIA_CONTENT_CONTROL as the platform-signed system app) and the lock screen renders track title + transport controls that drive the session Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
When the selected media session stops or pauses, re-evaluate which active session to show so the lock screen tracks the currently-playing (or most recently active) tool rather than sticking to a stale one. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
- plugin: disable the NotificationPermission check for tool modules. A tool's only path to posting a notification is the SDK's guarded LightMediaSession (the sandbox blocks direct NotificationManager access), so the check is a false positive that every tool would inherit just by linking the SDK. - client: guard LightMediaSession's notify() behind a POST_NOTIFICATIONS runtime check (best-effort; only shows for tools that opted in). - emulator: tools:ignore ProtectedPermissions on MEDIA_CONTENT_CONTROL, which the platform-signed system-app emulator legitimately holds. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
would be great for the lock screen controls to control generic playing content as well rather than just content routed thru lightmediasession. not sure if that's the behavior already! |
Contributor
Author
|
Here is an example of it working: |
Contributor
Author
|
I think it really just depends on the media player attaching to a LightMediaSession. Whichever attached last is the one that gets controls presented. |
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
2 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.
Addresses #99
Add a LightMediaSession primitive so a tool can publish its playback to Android's media framework — a MediaSession plus a mediaPlayback foreground service and a MediaStyle notification — which LightOS surfaces on the lock screen and which routes headset/Bluetooth transport keys back to the tool.