Spotify Tool - SDK components still in progress?

[jonathancaudill]

Hey all!

Very excited about the potential of the SDK. I think people will build a lot of really cool stuff.

I've been working really hard on phono, a standalone Spotify client for the LPIII. As you can imagine, a standalone Spotify client has to do some fairly low-level things, and a lot of those are not currently supported here.

Here are a few things I'm curious about the status of.

1. Foreground services and media services: apps that stream often need foreground services or some equivalent "LightMediaService" flag that allows them to continue to operate in the background. Audio service access or some sort of comprehensive wrapper around MediaSession would be helpful :) we also use androidx.media3 and guava, of course
2. Official stance on NDK / native libraries?: phono uses Rust via JNI + JNA (the core engine is a custom patched and expanded version of librespot, which I know @dupontgu has some experience with from his infamous Spotif-iPod!). I know kotlin-first is the goal, which is great! We use Kotlin--the issue is that 60% of our codebase is Rust due to librespot patches and expansions. (as an aside, would also love some clarity on native init and whether that can be exposed)
3. WebView support: Phono needs webview support to allow the user to sign into Spotify using the modern OAuth flows :) plus, I think exposing this via some kind of LightWebView this could allow for tools that need OAuth while locking it down to prevent browser access, etc.
4. Connectivity and power status access: currently, we access connectivity status and battery status to make informed decisions about streaming quality, etc. I'd imagine this would be really easy to expose in some sort of LightCellStrength/LightWifiStrength/LightBatteryLevel
5. Copying/Pasting text. I know LightOS has a custom copy/paste implementation. Would be nice to have access to that so users can copy song links to send to friends and family!!

That's just a few. Can definitely talk about more things that might be needed! For now, I will just port as much of the UI as I can to use the Kotlin light composables.

It should go without saying that I'll understand if not all these things are exposable. I'm mainly asking because someone already brought up an internet radio streaming tool! I think these sorts of things would benefit all potential tools :)

However, if a Spotify tool like phono is too low-level or somehow against the light SDK ethos, I totally understand and I think many users would be content to install it as an apk!! I just would love to buy in as much as possible to the vision you guys have--I really believe in it! In the meantime, I'll work on getting my other tool (stay tuned) ported over to this ASAP!

[dupontgu]

tl;dr - as much as I want this myself, I would say not impossible, but improbable that we'd be able to add this to the community library any time soon (but we do hope you publish a standalone apk!)

1. re: foreground/media services - we're actively working on this, we absolutely want apps to be able to play audio. What we're still experimenting with is if we're going to allow tools to spin up their own foreground services (if we do, they'll likely be restricted to audio) or if it's simpler to offload all audio playback into the server app (LightOS). We'd build an API around queueing up audio remotely, almost like an internal Chromecast. We should have more on this soon.

2. re: native libs - I'd love to be able to do this in cases where we could build all the native code as well. In other words, I don't think we want to support libraries that just load up an embedded .so file or whatever. But I'm having trouble imagining how we could make our build system flexible enough to handle this. Definitely not a short term thing.

3. re: WebView - we've been thinking about how to tackle this forever. Lack of OAuth in LightOS has made our lives difficult for years. But at the end of the day, it's too easy to blow a hole in LightOS as soon as you allow it to load UI that we don't know about at compile-time. We might be willing to ease up a little bit for third-party tools, but I think we'd need to heavily instrument/sandbox any WebView implementation in order to feel confident that third-party tools couldn't use it to pull a fast one.

4. re: connectivity/power status access: heck yeah good idea

5. re: copy/paste - already working on this.

Other concerns on our end:

• Not sure we're going to be able to allow dependencies that maaaaybe break other companies' terms of service. Not just from a legal standpoint, but we're concerned about distributing tools that are at high risk of being broken by things out of our control. With our current setup, we're taking a bit more responsibility for third-party tools than a standard app store.
• We currently have partnerships for some first-party tools (HERE maps for directions, for example), and we don't want to A) breach any of those existing contracts or B) put things out there that might close doors to others in the future.

[jonathancaudill]

Going to chime in here on the media session because I've been thinking about it some more.

Regardless of which route you guys go for audio routing, it would be really nice for LightOS to separately a) surface MediaSession controls on the home screen, rather than the internal media controls it exposes now, or b) expose its own control surface APIs, which we could then map back into our apps (LightPausePressed, etc.). That would help "gate" the system a little bit. That way users could play, pause, skip etc. from the home screen. Would hopefully be a pretty low lift! Not sure if I'll be able to bring phono into the sdk given the current status, but it would still be fully compatible and functioning within LightOS if I can route some kind of LightPause and LightPlay back into the controller!

[dupontgu]

Yeah we're definitely going to do one of those two - if there's media playing, you should 100% be able to control it from the home screen.

[jonathancaudill]

Thanks for your thoughtful response! All of that makes perfect sense. I'm extremely grateful to be a part of such a cool project--Light has made my life so much better!

Excited to see how things continue to develop :)

[wsturgiss]

Just chiming in to say I'm also interested in this - I want to be able to play my plex music library from my light phone so these same features would help with that as well.

[brunoro]

@jonathancaudill @wsturgiss here's a PR with the first iteration of the audio API. Any architecture we choose for persistent audio will require work on LightOS as well, so we decided to get the ball rolling by exposing in-tool audio support to third-party developers. Please chime in on the API, it’s still evolving and open to changes.

[jonathancaudill]

Thanks so much for all the hard work. Really excited to see this taking shape. Left a comment on the PR with my thoughts in more detail -- potential things that could make it a little more flexible but keep the important stuff owned by the SDK