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 Sign out inside the Apple Music app. Start authentication from the third-party app (AuthenticationManager.createIntentBuilder(devToken).build()). Apple Music presents its sign-in screen; complete the sign-in. 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 With Apple Music signed in (active subscription). Start authentication exactly the same way. 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. 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.

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.