When Gradle version was bumped to 7.0.0, it required Java version 11.
In 82b9121 (2022/01/05), .sdkmanrc was adjusted to accommodate. But
app/build.gradle.kts was not.
More recent Gradle releases have started to complain:
,----
| > Could not resolve all files for configuration ':classpath'.
| > Could not resolve com.android.tools.build:gradle:7.4.2.
| Required by:
| project :
| > No matching variant of com.android.tools.build:gradle:7.4.2 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin
| .api-version' with value '8.0.2' but:
| - Variant 'apiElements' capability com.android.tools.build:gradle:7.4.2 declares a library, packaged as a jar, and its dependencies declared externally:
| - Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
| - Other compatible attribute:
| - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
`----
Adjust gradle’s specification to suit.
This is part of an effort to resolve deprecation warnings.
Most of this is simple refactoring of interfaces that change between
the two Player implementations. There are a few other changes that
deserve further explanation.
Testing indicated that the play/pause button was being reset to pause
in MainActivity:refreshCurrentTrack. In the past this was likely
masked by the ordering of other callbacks. We have removed the
nowPlayingToggle.icon update from MainActivity, leaving that UI update
to PlayerService.
One of the bigger refactorings in PlayerService was forced by the
deprecation of Player.EventListener.onPlayerStateChanged. That forced
separation of handling playWhenReady and playbackState transitions.
In the SimpleExoPlayer implementations, where these transitions were
combined, the module attempted to work out playing state from a
combination of these two state variables.
In addition to separating the reaction to these state changes, we have
added a listener to onIsPlayingChanged, eliminating the need for some
of the earlier logic in Player.EventListener.onPlayerStateChanged.
This addition, along with the separation of state transition
processing, seems to provide a simpler implementation. But it is,
certainly, a possible source of bugs.
Renovate Bot
Hugh Daschbach
Christophe Henry
Georg krause
Ryan Harg
Ryan Harg