Destroyed AuthenticationActivity retained by CustomTabsController.authTabLauncher (4.1.0; unchanged in 5.0.0-beta.0)

Start in CustomTabsController.java, specifically its authTabLauncher, TWA launcher and service-connection handling, and trace how AuthenticationActivity is referenced through ActivityResultRegistry. The issue has not been reproduced on a running build, so first reproduce the leak with LeakCanary on the 5.0.0-beta.0 sample or a consuming app. Done means the destroyed-activity chain no longer appears after sign-in and cancellation, and the existing controller tests still pass. Ask a maintainer to confirm the cleanup approach before you change it.

Description

CustomTabsController can retain a destroyed AuthenticationActivity through its authTabLauncher and activity result registry after browser authentication has ended and service unbinding has run.

Observed at runtime on Auth0.Android 4.1.0. Reporting for consideration in 5.0.0-beta.0 because its CustomTabsController.java is byte-identical to 4.1.0 (Git blob f8c484692ebcc0c4da307058244814a52bae2a64). We have not reproduced this on a running 5.0.0-beta.0 build.

Expected: destroyed authentication activities should become collectible after cleanup, even if native browser callbacks temporarily retain the service connection/controller.

Reproduction / observed workflow

Observed in an integrating Android application, not yet reduced to the official sample app. Exact minimal reproduction and frequency remain unconfirmed.

1. Start hosted browser sign-in using WebAuthProvider with Chrome available.
2. Exercise browser cancellation and a subsequent sign-in, with portrait/landscape rotation in the native app and during browser authentication.
3. Complete or cancel authentication, then background the app and inspect LeakCanary.

The baseline heap captured this chain after activity destruction:

GC root: global variable in native code
CustomTabsClient$3.this$0
  -> CustomTabsServiceConnection$1.this$0
  -> CustomTabsController.authTabLauncher
  -> ActivityResultRegistry$register$2.this$0
  -> ComponentActivity$activityResultRegistry$1.this$0
  -> destroyed com.auth0.android.provider.AuthenticationActivity

Retained: 41,693 bytes / 603 objects
Retained duration: 505,682 ms
LeakCanary signature: e9b26f477f8329d40efcd1423486f13912bac553

The presence of authTabLauncher in the retained chain does not by itself mean the browser was launched in Auth Tab mode; the tested launch log reported the Custom Tabs path.

Proposed lifecycle cleanup and local verification

We tested a source-pinned 4.1.0 modification limited in production behavior to CustomTabsController:

• During the existing owner's destruction/unbind path, release the Auth Tab launcher, TWA launcher, session references, and weak context.
• Make teardown idempotent, balance service-binding attempts, and destroy the detached TWA launcher.
• Mark the controller closed and reject late service connections or queued browser launches after closure.
• Keep the existing activity lifecycle, callback recovery, PKCE, and token behavior intact. No reflection, forced browser termination, or suppression of leak detection.

After this modification, the same physical tablet passed browser-X cancellation, native rotation, browser rotation, and successful hosted sign-in returning to the native app. A fresh, user-requested LeakCanary heap analysis reported 0 application leaks, 0 library leaks, and 0 unreachable objects. The original one-leak report was retained in history.

Local automated verification: 25 controller tests plus 37 consuming-app authorization/setup tests passed; debug lint and APK assembly passed. This is bounded evidence, not a claim that every lifecycle path is leak-free.

Could maintainers confirm whether clearing these activity-owned references belongs in the controller's unbind/destruction cleanup and consider an upstream fix for this retention path?

Version comparison

• 5.0.0-beta.0 release PR #1081
• 4.1.0 to 5.0.0-beta.0 comparison
• The browser-provider change in that comparison only updates documentation links in WebAuthProvider; the leaking controller is unchanged.

Environment

• Auth0.Android: 4.1.0 runtime reproduction; 5.0.0-beta.0 source comparison only.
• Android 14 / API 34, Samsung SM-T220 physical tablet.
• Browser: Chrome (exact browser version not captured in this report).
• LeakCanary 2.14.

No heap dump is attached because it may contain credentials or other sensitive application data. Open issues were searched for CustomTabsController and leak; no matching open issue was found. Official-sample reproduction and the remaining template checklist checks have not been completed.