Media3 simply will not tolerate me doing this. I am basically stuck
at the mercy of the Android OS now, until I can have my own unified
source of truth with cover loading.
Break up the monster AuxioService into sub-classes, keeping just the
major lifecycle and music stuff in AuxioService for now (which will
likely be split out itself eventually)
ExoPlayer method for fetching next media item respects Repeat All, which
on the last song of a queue causes playNext to wrap around and insert
the songs at the start of the queue. New code fetches next song as if
repeat were turned off, so the songs will always be added to the end of
the queue.
FixesOxygenCobalt/Auxio#735. ExoPlayer method for fetching next media
item returns C.INDEX_UNSET (-1) when used on the last song of a queue,
which is not a valid index for ExoPlayer.addMediaItems(). New code just
adds songs to the end of the queue if there isn't a next song.
Again, a two-fold problem:
- Was not properly giving the right StateAck to the state holder
- ShuffleOrder not properly handling the index given when adding to
queue internally
Resolves#727.
Caused by the new state restoration code being bugged and applying on
playlist changes, then combined with the playlist code not properly
switching to the main context when dispatching a library update.
Playback and indexing now occur in the same service through a new
bridge called AuxioService.
AuxioService contains the existing service instances as Fragment
implementations, and then forwards typical service events to them
(albeit this will drift more and more as I continue to deal with
lifecycle issues).
This should be the first step in enabling true service independence,
as it means that the service will now immediately initialize and load
music as soon as possible.
This time, actually wait for the save to complete before stopping the
foreground state. This requires some checks to make sure that we don't
have any "randomly smashing on buttons" errors, but I'm unsure if that
will be enough.
The last case in which this becomes an issue is when the service
is killed outright. I can't do much here to make the state more sane
unless I did some playback position monitoring.
This setting allows you to remain playing/paused when you move in the
queue or edit the queue. Useful for some people who like this behavior
more than always playing.
Resolves#568.
This is apparently the standard behavior that media apps should use to
allow the foreground state to be exited. I personally don't want to
make it really unilateral like that, so if playback is already ongoing
I'll keep the foreground state going.
