Thanks for the detailed answer. I filed the following: FB25452094 (library-only songs in the catalog queue), FB25452140 (delay before each new item plays), and FB25452189 (crash in LibraryPlaybackQueueItemProvider on “i.…” ids). I haven’t filed the prefetch request or the documentation report. For my use case the first two would already help: if the start delay goes back to what it was before, I don’t need prefetching.

@DTS Engineer Thanks for pointing to 1.1.4. I integrated MusicKitAuth 1.1.5 and MediaPlayback 1.1.4 into a shipping app and tested on a Samsung Galaxy A52 5G (Android 14, Apple Music app 7.0.0), always on Wi-Fi. Sign-in and playback of normal catalog songs work. I did not test IDs above 2,147,483,647. I have three findings that currently keep me on a WebView-based MusicKit JS player instead: Every skip takes about 2 seconds (sometimes up to 5), because the next item is not prepared. After skipToNextItem(), onCurrentItemChanged fires within 50–80 ms and onBufferingStateChanged(true) at about 200 ms. Then nothing happens for roughly 1.4 s except several DNS lookups, then the decoder initialises and audio starts at about +2.0 s. This repeats for every new song, even though the songs are in the catalog and play instantly in the Apple Music app on the same phone and network. Skipping back to a song just played takes about 1.9 s as well. Is there a way to preload or prepare the next item, or to enable gapless/prefetch behaviour? If not, could this be considered? Also: I did not notice this delay in the old SDK. Songs that are only in the library (uploaded or purchased) cannot be played, and the failures are misleading. With CatalogPlaybackQueueItemProvider, library-only songs can’t be resolved. In an 81-item queue with startItemIndex(71) I got MediaPlayerException: Network is unreachable with current settings, even though the device was online and other items played fine. A clearer error would help. I then tried LibraryPlaybackQueueItemProvider, as shown in the “Android MediaPlayback Usage” guide, with the library ids that the Apple Music API returns ("i.xxxxxxxxxxxxx"). The queue is built correctly (99 of 99 items), and songs that have a catalog match play. When the SDK advances to a library-only song, the app crashes on the SDK’s handler thread: java.lang.NumberFormatException: For input string: "i.3VBaV7mSgBJR8" at LibraryPlaybackQueueItemProvider.a(MusicSDK:355). Is a numeric library id expected there, and where would a third-party app get it? Please also document how unresolvable ids are handled. Integration pitfalls that should be documented: createLocalController throws NullPointerException: tokenProvider cannot be null if the TokenProvider is not ready at that moment, and the new getAppleMusicStoreFrontId() is easy to miss. SDKUriHandlerActivity now extends AppCompatActivity without a theme. Apps whose theme isn’t AppCompat crash with IllegalStateException: You need to use a Theme.AppCompat theme right after sign-in. The activity’s android:exported="false" conflicts with the true that older integration guides tell apps to add, which breaks the manifest merge. On the positive side, the arm64 libraries are now 16 KB page aligned, which I verified in the AAR. Thanks for your support!