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.
Add a 1x3/1x4 widget that displays the cover and controls
Also requires another widget type that just displays controls to
accomodate landscape devices.
Resolves#420.
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.
More or less, the paths being selected for were extremely malformed,
stuff like storage/emulated/0Music. This completely broke music folders
below API 29.
Turns out there are two ways the selector can go malformed. One was the
complicated issue where you can't resolve a directory, the other was me
*missing a character* and not even building the selector right.
It's mostly identical to prior, albiet pausing on repeat now leaves the
player position at the end of the song rather than the beginning.
That's the only regression I couldn't figure out how to resolve.
Mirror the last playback state of the holder inside
PlaybackStateManager.
This is generally more efficient and will enable better handling of
when state holders attach and detach.
Add a currently-unused ShuffleOrder implementation with fixes for media
item insertion.
This will be used as the basis of the new gapless playback system,
assuming all else goes well.
OPUS has another volume adjustment field on top of the existing R128
adjustments. I was under the impression this was handled by the android
system, but apparently not. This commit applies the base gain to files
by just adding them onto the existing ReplayGain values.
Resolves#521.
Handle back presses gracefully without finicky behavior when doing back
gestures.
I've spent far too much time trying to make this sensible. I'm going to
take a break.
The stock overlay is not sufficient for our needs, as:
1. It seemingly cannot be set up without missing certain touch areas or
disabling the touch area of the speed dial itself
2. The scrim can't be evenly applied everywhere in the app due to the
nested expore UI.
So, modify the speed dial to work without a scrim and reimplement the
overlay touch behavior manually.
When reimporting an M3U file into a playlist, if the name differs, then
initiate a rename dialog so the user has a choice on whether they want
to use the new name or not.
This does kinda desecrate the "Rename" decision a bit, but it's still
to the user the same.
