Android Support for Player Module

[mitschwimmer]

Is your feature request related to a problem? Please describe.
I would like to use librespot-java to build a Spotify Player on Android. The current Player Module is not compatible with some Android constraints/idiomatics.

Describe the solution you'd like
Wrapping parts of the implementation behind Interfaces to be able to swap out implementations. So far, I identified the following part.

1. Audiosink/Mixer - "javax.sound.sampled.*" is not available on Android. AudioTrack might be what to look for instead.
2. Configuration - Parts of the configuration should be done in code on the calling side (e.g. disabling zeroconf). Other parts probably should be native app settings (credentials) [Update: No code would need to be changed here as the current codebase does allow configuration as code. I keep this item for future readers]

Describe alternatives you've considered
At first I wanted to see whether this whole undertaking is feasible. I played with a local copy of the codebase and got the player to create a session and authenticate with Spotify's backend. I did this by inlining the configuration and wrapping the calls to "javax.sound.sampled.*" into a stub. This does work, but obviously it can't play any audio yet.
While doing and stepping through your code I realized how much effort has been put into the player module alone. A fork or a reimplementation of the player module to achive Android support seems like a quite massive undertaing.

Additional context
Bonus advantage of my suggestion: Wrapping platform specifics might aid/enable certain automatied "integration" tests.

[devgianlu]

I think the audio part is the only one that utilizes platform specific Java classes. Making a variant for Android shouldn't be too difficult considering that AudioTrack seems to have a good support for various audio formats (we do pass in only raw).

(1) I should be able to genralize AudioSink and wrap the other usages of AudioFormat in the code easily. Will make a PR for that. My only concern is how to make Maven compile Android related code, but there'll be an explanation somewhere.

(2) What's the issue with Zeroconf? If it compiles, you can just disable it by changing the authentication strategy. The default implementation loads the configuration from a file, but you can craft it using builders if you want. Command line arguments are also supported.

I'd really like to have more tests for this, but I am not really sure how to approach it.

[devgianlu]

@mitschwimmer How are you compiling for Android?

[mitschwimmer]

@devgianlu sorry that I kept you waiting. I did my experiment in an Android Studio Project into which I copied the classes of the player-module. This was built with gradle.
Now, I think in this case it would make sense to have the platform specific audio system as their own modules. You could have one as part of librespot-java tackling the JVM side. A seperate one, build with gradle and organized as android library could be its own repo as I do not think Android projects with Maven are particular fun.
I would be happy to contribute the Android part in case you agree to the approach and would like me to help.

[mitschwimmer]

Regarding my item 2. You are right, zeroconf is not an issue per se and the builders are fine. In hindsight it is confusing that I brought it up. I will edit my proposal.

[devgianlu]

I'll start by generalizing the parts of the code that need it. Then I shall create another module (librespot-sink) that takes care of the desktop implementation.

At this point I can make another repo for librespot-android-sink which uses AudioTrack.

[devgianlu]

@mitschwimmer I have created a new repository with a barebone implementation of the sink: https://github.com/devgianlu/librespot-android (invited you as a collaborator too)

[mitschwimmer]

Your pace is impressive, to say the least. I hope to have some time tomorrow to contribute.

[devgianlu]

I think this can be closed as devgianlu/librespot-android#4 is done. I am going to update the README to include librespot-android.

@mitschwimmer I can also include your spoddler project if you continue the development!

[mitschwimmer]

@mitschwimmer I can also include your spoddler project if you continue the development!

Thanks @devgianlu! I have the feeling I am far away from getting it functional, given my current time constraints 😸