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.

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.

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.

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?

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

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

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