[ddfreiling]

What

Adds an androidAllowedBrowsers property to AuthorizationRequest, AuthorizationTokenRequest and EndSessionRequest. Each entry is either one of six presets that map to AppAuth's VersionedBrowserMatcher constants, or a custom descriptor naming any browser by package name and signature hashes. The list becomes a BrowserAllowList on the AppAuthConfiguration. A null or empty list keeps the existing behaviour of allowing any installed browser.

The browser matcher is fixed when an AuthorizationService is built, so the two pre-built services are replaced with a cache keyed by connection security and browser list. Caching rather than recreating avoids disposing a service while an authorization flow is still in progress.

Also wraps the end session intent launch in the same ActivityNotFoundException handling that performAuthorization already had. Without it, an allow list that matches no installed browser would throw instead of returning a no_browser_available error.

Why

Discussed here as an improvement: #537

Added after review

Added getInstalledAndroidBrowsers()

Adds FlutterAppAuth.getInstalledAndroidBrowsers(), which lists the browsers installed on an Android device with their package name, version, Custom Tab mode and signature hashes. It wraps AppAuth's BrowserSelector.getAllBrowsers, so the hashes are exactly what an AndroidBrowser.custom entry is matched against.

It's a development aid for finding the hashes of a browser to pin: look them up once on a test device, then hard-code them. Hashes read at runtime and passed straight back into androidAllowedBrowsers would also allow a look-alike app installed under the same package name, and the README and dartdoc say so. It isn't implemented on iOS or macOS.

⚠️ Custom Tabs warm-up change

@MaikuB

Behaviour change you should be aware of: the plugin used to create two AuthorizationServices in onAttachedToEngine and keep them until the engine detached. AppAuth binds to the Custom Tabs service and calls warmup(0) in that constructor, so the browser was pre-warmed from app start. This PR now creates a fresh service for each authorize/token/endSession call and disposes the previous one when the next call starts. That fixes the browser choice going stale: a browser installed, uninstalled or replaced under the same package name was never reselected. It also keeps the number of open services at one.

Cost: binding now happens just before each Custom Tab intent is built. AppAuth waits up to 1 s for the connection (CustomTabManager.CLIENT_WAIT_TIME) on the main thread, so the first Custom Tab of each sign-in or sign-out may open slightly slower, and it is no longer pre-warmed. I haven’t exactly measured it; but it still felt instant on both emulator and real device.

Alternative

If you’d rather keep warm-up, an alternative is to keep one service and rebuild it only when the browser settings change, at the cost of the stale-selection problem above (the one CoPilot review found). Happy to switch to that if you prefer.

[Copilot]

🟡 Changes recommended

Nullable custom-browser parameters can trigger uncaught Android exceptions during discovery-based requests.

3 open issues

• Require non-null custom browser constructor parameters · New
• Document generating browser signature hashes from PackageInfo · New
• Clarify exact signature-set matching for browser signers · New

What changed in this PR

Adds Android browser restrictions to authorization and logout requests, addressing #537 while preserving unrestricted browser selection by default.

Changes:

• Adds browser presets and custom descriptors to the Dart API and method channel.
• Caches Android authorization services by browser policy and connection security.
• Handles missing browsers during logout and documents the new options.

File	Description
flutter_appauth/​README.md	Documents browser restrictions and custom descriptors.
flutter_appauth/​lib/​flutter_appauth.dart	Exports AndroidBrowser.
flutter_appauth/​CHANGELOG.md	Records Android enhancements.
flutter_appauth/​android/​src/​main/​java/​io/​crossingthestreams/​flutterappauth/​FlutterAppauthPlugin.java	Applies browser matchers, caches services, and handles logout launch errors.
flutter_appauth_platform_interface/​test/​method_channel_flutter_appauth_test.dart	Tests browser option serialization.
flutter_appauth_platform_interface/​lib/​src/​method_channel_mappers.dart	Serializes browser restrictions.
flutter_appauth_platform_interface/​lib/​src/​end_session_request.dart	Adds logout browser restrictions.
flutter_appauth_platform_interface/​lib/​src/​authorization_token_request.dart	Accepts browser restrictions for combined authorization.
flutter_appauth_platform_interface/​lib/​src/​authorization_request.dart	Accepts authorization browser restrictions.
flutter_appauth_platform_interface/​lib/​src/​authorization_parameters.dart	Defines the shared browser option.
flutter_appauth_platform_interface/​lib/​src/​android_browser.dart	Defines presets and custom descriptors.
flutter_appauth_platform_interface/​lib/​flutter_appauth_platform_interface.dart	Exports the browser model.
flutter_appauth_platform_interface/​CHANGELOG.md	Records the new public API.

_{Review effort: Balanced}

[MaikuB]

Based on my understanding, this would require developers to write their own Java or Kotlin code to do this? Can you confirm if this is correct? If so, I would recommend this is made more explicit as Flutter developers may not realise this. I also wonder if there's an opportunity to provide more guidance on this and/or if this plugin can provide some way to return the hashes by exposing a Dart API that can do what is stated

[ddfreiling]

Yes, that's correct. Until now you'd have had to write your own Kotlin/Java to compute the hashes, which isn't obvious for a Flutter developer.

I've now added FlutterAppAuth.getInstalledAndroidBrowsers(). It wraps AppAuth's BrowserSelector.getAllBrowsers and returns each installed browser's package name, version, Custom Tab mode and signature hashes, computed exactly the way the matcher compares them. I checked it on my phone, where Chrome's reported hash matches AppAuth's built-in Chrome constant.

It's mostly meant as a development aid: run it once on a test device, then hard-code the hashes in AndroidBrowser.custom. Hashes read at runtime and passed straight back into androidAllowedBrowsers would pin nothing, because a look-alike app installed under the same package name would be allowed too. The README section now says this and includes a short example.

I also addressed the Copilot findings. Custom entries now require a non-null package name and hashes, and invalid entries fail with an error instead of crashing the app.
The docs now also explain that a browser has to match the complete set of hashes, not just one of them.

[Copilot]

🟡 Changes recommended

Service caching can bypass signature restrictions after browser replacement and retain an unbounded number of browser service connections.

2 open issues

• Refresh cached browser selection after package changes · New
• Bound authorization service cache and dispose inactive services · New

3 resolved since last review

• Require non-null custom browser constructor parameters
• Clarify exact signature-set matching for browser signers
• Document generating browser signature hashes from PackageInfo

_{Review effort: Balanced}