Musickit SDK for Android broken after Apple Music app update

I’m experiencing the same issue.

Device: Google Pixel 8a

Apple Music version: 6.5, installed from Google Play

After the user successfully signs in through the new Apple Music authentication UI, the activity returns RESULT_CANCELED, and authManager.handleTokenResult(data) reports USER_CANCELLED, even though the user did not cancel the flow.

Logcat shows Successfully authenticated the account, followed by Failed to post account changed event with ams.error Code=1, and then DialogConnectorViewModel.cancelAction().

This flow worked correctly before the Apple Music update.

I can confirm the same regression with a standalone minimal reproduction app.

Environment: Device: Google Pixel 8

Android: 16 / API 36

Apple Music: 6.5.0 (versionCode 1580)

MusicKit authentication AAR: musickitauth-release-1.1.2.aar

Developer token endpoint returns HTTP 200

Developer token was tested with two separate Apple Media Services keys/configurations

The user completes Apple Music sign-in and does not cancel. Logcat then shows:

Successfully authenticated the account.

Successfully completed IdMS authentication

AMSIDMSAuthenticationCompleteAction succeeded

Failed to post account changed event: ams.error Code 1

DialogConnectorViewModel.cancelAction()

The Activity subsequently returns:

resultCode = RESULT_CANCELED

returned Intent = non-null

Intent extras = [music_user_token_error]

music_user_token_error = 0

TokenResult.isError = true

TokenResult.error = USER_CANCELLED

musicUserToken = null

The same result occurs in both the production application and a brand-new minimal Android app using Apple’s documented authentication flow. It also persists after using a completely new Media ID, private key, and Key ID. The equivalent iOS authentication works with the same backend.

This appears to be an Apple Music 6.5.0 Android regression after successful IdMS authentication, specifically during the internal account-change/dialog completion step. The SDK is reporting a user cancellation even though the user completed authentication.

Could Apple please confirm whether this is a known issue and whether an Apple Music Android update is planned?

Update: I downgraded the Apple Music Android app from 6.5.0 to 5.2.1 using APKMirror. Without changing my application, backend, developer token, Media ID, or Media Services key, authentication immediately succeeded. RESULT_OK was returned, TokenResult.isError=false, and a valid Music User Token was received. Upgrading back to 6.5.0 reproduces the USER_CANCELLED failure. This strongly indicates the regression was introduced in the Apple Music 6.5.0 Android app.

Update: I downgraded the Apple Music Android app from 6.5.0 to 5.2.1 using APKMirror. Without changing my application, backend, developer token, Media ID, or Media Services key, authentication immediately succeeded. RESULT_OK was returned, TokenResult.isError=false, and a valid Music User Token was received. Upgrading back to 6.5.0 reproduces the USER_CANCELLED failure. This strongly indicates the regression was introduced in the Apple Music 6.5.0 Android app.

@joneswr is right. I am facing same issue. its works with old apple music app version 5.2.1 but not with new version 6.5.0.

Still broken on 6.5.1 / 6.5.2 — and the symptom has changed: it no longer returns at all

Adding a data point that may help narrow this down, and one distinction that I think is worth drawing clearly.

Environment

• Apple Music for Android 6.5.2 (1586) and 6.5.1 (1583)
• MusicKit auth AAR: musickitauth-release-1.1.2.aar
• Pixel 7 / Pixel 8
• Apple Account with an active Apple Music subscription — Home, Library and Recently Played are all populated and playback works normally, so this is not a "no subscription" case.

The outcome depends on whether the Apple Music app is already signed in.

Case A — Apple Music is signed OUT: this works

1. Sign out inside the Apple Music app.
2. Start authentication from the third-party app (AuthenticationManager.createIntentBuilder(devToken).build()).
3. Apple Music presents its sign-in screen; complete the sign-in.
4. The approve/consent screen appears and a valid Music User Token is returned. RESULT_OK.

Case B — Apple Music is already signed in: the flow never returns

1. With Apple Music signed in (active subscription).
2. Start authentication exactly the same way.
3. Apple Music opens its SDK landing screen and shows a loading spinner — and stays there indefinitely. We left it for over 100 seconds with no change. The approve/consent screen is never shown, the screen never closes, and no result is ever delivered to the calling app. There is no timeout.
4. The only way out is the Back button, which then delivers USER_CANCELLED to the calling app.

Note that a successful Case A run leaves the account signed in — so an immediate retry reproduces Case B.

This is not the same symptom that was reported for 6.5.0.

As I understand the earlier reports in this thread, on 6.5.0 an already-signed-in account would cause the Apple Music screen to close itself and return CANCELLED more or less immediately. The flow terminated — it just terminated with the wrong result.

On 6.5.1 / 6.5.2 the trigger looks the same (already signed in), but the ending is different: the screen does not close and nothing is returned at all. The USER_CANCELLED we end up seeing is produced by the user pressing Back to escape the stuck screen, not by the SDK deciding anything.

From an integrator's point of view this is worse than 6.5.0. On 6.5.0 control at least came back to the calling app, so the app could show an error and offer a retry. Now the user is left sitting on a screen that never resolves, and the app is never told that anything failed.

Why this matters in practice: the case that works is the one where the user is not an active Apple Music user. Anyone who actually uses Apple Music is signed in, and therefore lands in Case B every time. The "sign out of Apple Music first" workaround does not hold up in production, and it will also bite on token renewal — by then the user is signed in again, so they are back in Case B.

Our reading is that the already-signed-in path inside the SDK landing screen never reaches a terminal state: when the account step has nothing left to do, the screen neither advances to the consent screen nor returns an error to the caller.

An official acknowledgement would be very welcome here. This has now been broken across 6.5.0, 6.5.1 and 6.5.2, the failure mode has changed without being fixed, and there is no workaround an integrating app can apply on its own.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

I have submitted Feedback with the above information as well as additional information.

FB24520173

I completed another controlled test with Apple Music 6.5.2. Environment: Google Pixel 8 Android 17 / API 37 Apple Music 6.5.2, versionCode 1586 musickitauth-release-1.1.2.aar Standalone minimal reproduction app The developer-token endpoint returned HTTP 200. Apple Music opened SDKLandingActivity, then logged: ams.error Code 8: failed to load the Mescal prime session ams.network Code 303: failed to parse a Finance response Missing bag key: isEligibleForPhoneCreate WebContainer subsequently reported Bootstrap: Succeeded Despite reporting a successful bootstrap, SDKLandingActivity remained on its loading spinner. It did not show consent or return any Activity result. After approximately 66 seconds, I pressed Back to escape the stuck screen. Only then did the caller receive: resultCode=RESULT_CANCELED music_user_token_error=0 TokenResult.isError=true TokenResult.error=USER_CANCELLED musicUserToken=null This independently confirms the 6.5.2 non-terminating authorization behavior. The USER_CANCELLED result is generated only after the user presses Back to escape Apple Music’s stalled SDK screen; it is not the original cause of the failure. The same standalone application and developer-token service successfully returned a valid Music User Token with Apple Music 5.2.1.

I am also facing the same loader issue with Apple Music authentication using MusicKit. It was working with Apple Music version 6.5.1, but after updating to version 6.5.2, it is not working again. It just keeps loading, and nothing happens.

Additional impact: Apple Music 6.5.2 authentication regression prevents playback of newly released music

I want to emphasize the urgency and practical impact of this issue.

Apple Music 5.2.1 can still complete MusicKit for Android authentication, but it cannot reliably play some newly released songs whose current Apple Music catalogue IDs are larger than the range handled successfully by that older player.

For example, newly released tracks returned by the Apple Music API have valid catalogue/playback IDs such as:

6778161147

6797908352

6798544240

The API returns valid metadata, playParams, duration, and preview information for these records. PartyAux preserves the complete ID as a string and passes it to MusicKit without truncation or numeric conversion. However, with Apple Music 5.2.1, the selected item may be acknowledged while playback position never advances and no audio begins. Older catalogue IDs continue to play on the same device.

Updating to Apple Music 6.5.2 is not currently a solution because MusicKit authorization stalls inside Apple Music’s SDKLandingActivity. It remains on the loading spinner and never returns a Music User Token. If the user presses Back to escape, the calling application receives:

RESULT_CANCELED

music_user_token_error=0

TokenResult.isError=true

TokenResult.error=USER_CANCELLED

musicUserToken=null

This leaves Android MusicKit applications trapped between two incompatible outcomes:

Apple Music 5.2.1 authenticates, but cannot reliably play some newly released catalogue records.

Apple Music 6.5.2 should support the current catalogue, but its MusicKit authorization handshake does not complete.

There is no viable application-side workaround for newly released songs. Catalogue IDs cannot be truncated or replaced because Apple documents them as string identifiers, and the Apple Music API does not provide third-party applications with an alternative full-track streaming mechanism.

Please prioritize a fix for the MusicKit authorization flow in Apple Music for Android 6.5.2 or provide an updated, supported Android MusicKit authentication SDK. This regression now prevents third-party Android MusicKit applications from both authenticating with the current Apple Music app and reliably supporting newly released music.

Existing Feedback report: FB24599163

Related Feedback report: FB24520173

Related forum thread: https://developer.apple.com/forums/thread/838633

Can you provide any feedback regarding whether or not apple sees this as a priority? It cripples my app development

I am thrilled to see Apple is working on this. version 6.5.3 correctly handshakes / allows sign-in now. There remains a persistent issue with songs recently added to the Apple Music Catalogue having large catalogue ids that cant be played by musickit, here is a more verbose description

Update: Apple Music 6.5.3 fixes MusicKit authentication, but newer catalogue IDs still do not play I tested Apple Music for Android 6.5.3 (versionCode 1599) on a Google Pixel 8. The MusicKit authentication regression seen in versions 6.5.0–6.5.2 appears to be fixed: The authorization interface completes successfully. HOORAY The Activity callback returns normally. A valid Music User Token is generated. Third-party MusicKit applications can authenticate without installing an older Apple Music APK. However, a separate playback problem remains for newer Apple Music catalogue IDs that exceed the signed 32-bit integer limit. Controlled example: Cellophane by Stanley Simmons Catalogue IDs tested: 6798551300 and 6797908353 Both IDs exceed 2147483647. Apple Music accepts the playback request and reports the requested song as the current item. The playback state reports playing, but the playback position remains -1. No audio is produced. During the same session, an older catalogue item played successfully: Heaven Ain’t Hard 2 Find by 2Pac Catalogue ID: 1588482071 Playback position advanced normally and audio played. This suggests—though does not prove—that the Android playback path or MusicKit Android SDK may still be treating catalogue identifiers as signed 32-bit integers somewhere internally. The application preserves the identifiers as strings/full-width values and submits the complete IDs without truncation. So the current status is: Apple Music 6.5.3: MusicKit authentication fixed No APK downgrade is required Older catalogue IDs play successfully Newer IDs above 2,147,483,647 are accepted but remain silent The remaining failure appears to occur inside Apple Music’s Android playback integration Could Apple confirm whether the Android MusicKit playback stack fully supports catalogue IDs larger than a signed 32-bit integer?

Additional finding: the failure may involve Apple’s outdated Android Media Playback AAR I investigated the remaining large-catalogue-ID playback failure after confirming that Apple Music for Android 6.5.3 fixes MusicKit authentication. The application is using the latest Android MusicKit binaries I can locate in Apple’s currently published resources: musickitauth-release-1.1.2.aar mediaplayback-release-1.1.1.aar

The Media Playback AAR identifies itself as version 1.1.1, targets Android SDK 28, and appears to date from 2020.

Current public discussions still identify these same raw AAR files as Apple’s distributed Android SDK. I could not find a newer official Media Playback AAR.

The application sends catalogue IDs through Apple’s documented string-based API:

new CatalogPlaybackQueueItemProvider.Builder() .items(MediaItemType.SONG, catalogId) .build();

Apple documents the items parameter as String... itemIds. The application preserves the full catalogue ID as a string and does not parse, truncate, or convert it to a 32-bit integer. Controlled results with Apple Music 6.5.3: Catalogue ID 1588482071 plays normally and its playback position advances. Catalogue ID 6798551300 is accepted and appears as the current item, but playback remains silent and its position is -1. Alternate exact-match ID 6797908353 behaves identically. 2,147,483,647 is the maximum value of a signed 32-bit integer. This consistent boundary suggests that an Apple component may still be treating newer catalogue IDs as signed 32-bit integers internally. The possible location is: mediaplayback-release-1.1.1.aar; its bundled libappleMusicSDK.so; Apple Music’s Android playback service; or the interface between the playback AAR and Apple Music. Because these components are closed source, I cannot determine which internal layer performs the incompatible conversion. However, the calling application demonstrably passes the complete identifier as a string. Current status: Apple Music 6.5.3 successfully completes MusicKit authentication. A valid Music User Token is returned. Older catalogue IDs play correctly. Newer catalogue IDs above Int32.MAX_VALUE load metadata but produce no audio. The current Android playback AAR is still mediaplayback-release-1.1.1.aar. Could Apple please confirm: Whether mediaplayback-release-1.1.1.aar is still the newest supported Android playback library. Whether it and libappleMusicSDK.so support catalogue identifiers greater than 2,147,483,647. Whether an updated Android Media Playback AAR is planned or available for testing.

Update after testing Apple Music 7.0.0 beta build 1609:

Apple Music 7.0.0 beta still cannot play newer large catalogue IDs through MusicKit for Android I completed a controlled playback test with the latest Apple Music Android beta. Environment: Google Pixel 8 Android 17 / API 37 Apple Music 7.0.0-beta Apple Music versionCode/build 1609 PartyAux using Apple’s MusicKit for Android playback SDK Existing valid Music User Token was retained after the in-place Apple Music update The tested song was: Title: Don’t Leave Me Here Like That Artist: Stanley Simmons Catalogue IDs tested: 6797908352 and 6798544240 Observed behavior: Apple Music search successfully returned the song and its catalogue IDs. PartyAux passed each catalogue ID to MusicKit without converting it to a 32-bit integer. MusicKit accepted each item as the current playback item. The displayed title and artist were correct. The playback state reported that playback had started. No audible song playback occurred. The playback position remained -1. Retrying with the alternate exact-match catalogue ID produced the same result. Relevant diagnostics: Playback request catalogId=6797908352 Playback confirmed current=6797908352 Playback progress state=1 position=-1 The alternate ID behaved identically: Playback request catalogId=6798544240 Playback confirmed current=6798544240 Playback progress state=1 position=-1 Control test: Title: Joy of My Life Catalogue ID: 1528423159 The control song played successfully, and its playback position advanced to 6346 ms. This confirms: Authentication remains functional. Apple Music catalogue search returns the newer song. PartyAux preserves the complete catalogue ID as a string. The room, queue, and developer-token service are functioning. MusicKit accepts the newer item but does not produce advancing audio. Older catalogue IDs continue to play normally. Therefore, Apple Music 7.0.0-beta build 1609 does not appear to resolve the MusicKit for Android playback failure affecting newer catalogue IDs above the signed 32-bit integer range. The failure occurs inside the MusicKit playback stack after the correct catalogue item has been selected.

Update: I created a focused Apple Feedback report for the remaining MusicKit for Android playback defect: FB25260402. Apple Music for Android 7.0.0-beta build 1611 authenticates successfully, but MusicKit still cannot play newer catalogue items whose IDs exceed the signed 32-bit integer range. Tested failing catalogue IDs: 6797908353 6798551300 MusicKit accepts the item and reports playback as active, but playback position remains -1 and no audio is produced. Control catalogue ID 1528423159, which is below the signed 32-bit limit, plays normally and its position advances. The report includes complete logs, screenshots, reproduction steps, and environment details. Although FB25260402 was closed, the underlying defect remains reproducible. I am requesting that this issue be routed to the MusicKit for Android playback engineering team.

Thanks for filing these reports, and for posting your logs and version-by-version results here. Your comparisons against Apple Music 5.2.1, and the control songs with IDs below 2,147,483,647, make each problem easy to follow. I checked the two authentication reports, FB24520173 and FB24599163, and the playback report, FB25260402. All three remain open and under investigation. I can't comment on future releases.

The SDK versions named in this thread are musickitauth-release-1.1.2.aar and mediaplayback-release-1.1.1.aar. The current MusicKit SDK for Android is version 1.1.4, from May 2026, listed as "Android MusicKit" on the developer downloads page. Version 1.1.4 contains MusicKitAuth-release-1.1.5.aar and MediaPlayback-release-1.1.4.aar, along with usage guides for both libraries. The 1.1.4 API takes catalog IDs as strings, and the documentation doesn't state a range for them.

When you have a chance, please try the 1.1.4 SDK and add the results to your report, including whether catalog IDs above 2,147,483,647 play. If you filed one of the authentication reports and Apple Music for Android 6.5.3 completes sign-in for you as well, please add that too. As new versions of Apple Music for Android and the SDK become available, please keep testing and add your results each time.

Holy Cow it Works! Thanks.

Confirmed: Android MusicKit SDK 1.1.4 successfully plays the previously failing catalogue IDs

Thank you for directing me to the updated SDK. On November 5, I tested:

• Google Pixel 8, Android 17 / API 37
• Apple Music 7.0.0 stable, build 1614
• MusicKitAuth-release-1.1.5.aar
• MediaPlayback-release-1.1.4.aar
  Both previously failing “Cellophane” recordings by Stanley Simmons now play successfully:
• 6797908353: playback position advanced to 11,085 ms.
• 6798551300: playback position advanced to 12,803 ms.
  I confirmed audible playback. The current catalogue IDs matched the requested IDs, with no alternate-recording substitution. The older control, 1528423159 (“Joy of My Life”), also played normally.

Authentication succeeded. The diagnostic follows the updated storefront-provider guidance and uses prepare(provider, true).

For comparison, playback library 1.1.1 failed on the same Apple Music build 1614: the newer recording reported PLAYING while its position remained −1.

These results confirm that the updated SDK and documented integration resolve the two reproduction cases reported in FB25260402. I have also integrated the SDK into PartyAux 3.3.0 and installed it for further testing.

This is a significant step forward for supporting Apple Music subscribers on Android. Thank you for the guidance and assistance.

@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:

1. 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.

2. 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.

3. 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!

I'm glad both recordings play now. Thanks for testing 1.1.4 on the same Apple Music build as 1.1.1, and for posting both results. If you haven't already, please add them to FB25260402.

Thanks also for the detailed 1.1.4 results from a shipping app. Here's what the 1.1.4 documentation says about your two playback findings:

• Library songs. The MediaPlayback guide documents LibraryPlaybackQueueItemProvider "For content from the user's personal library (purchased or added songs)", and its example passes IDs of the form i.library123. It also says "Songs use their catalog or library ID". The documentation doesn't say what CatalogPlaybackQueueItemProvider does with IDs it can't resolve. The only related error the guide describes is MediaPlayerException.TYPE_PLAYBACK_QUEUE, a "Queue load/resolution error".
• Preparing the next item. Neither the MediaPlayback guide nor the API reference in 1.1.4 documents a way to preload or prefetch the next item, or gapless playback.

I suggest filing four separate Feedback Assistant reports because each one is a separate work item:

• A bug report about library-only IDs in CatalogPlaybackQueueItemProvider, covering the shifted queue positions and the "Network is unreachable with current settings" error.
• A bug report about the delay before each new item plays, with your timings and the SDK versions you compared.
• An enhancement request, with your use case, for a way to prepare or prefetch the next queue item.
• A documentation report covering the TokenProvider requirement for createLocalController, getAppleMusicStoreFrontId(), the AppCompat theme crash you hit after sign-in, and the exported attribute. It can also ask what happens to IDs a queue provider can't resolve.

Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing.

Please post the Feedback numbers here, and I'll check their status next time I do a sweep of forums posts where I've suggested bug reports.

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.