[🐛] Android: App Check provider factory is only installed from JS, so Firestore/Storage requests go out unattested

[MikeNotInTheFlesh]

Issue

On Android, installAppCheckProviderFactory(...) is only reachable from JavaScript. Firebase requires it to be registered before FirebaseApp is configured, and on Android FirebaseApp is auto-initialized by FirebaseInitProvider (a ContentProvider) before any JS runs. The result: Firestore and Storage requests are sent without an App Check token, and any rule using request.app != null rejects them. Cloud Functions is unaffected.

This is not the iOS debug-provider issue fixed by #9166. That PR states the requirement precisely, though:

Firebase requires the provider factory to be registered before FirebaseApp.configure(), which runs before JS.

On Android there is currently no way for an app to satisfy that, because the only install path is a bridge method.

Where

Both call sites are JS-invoked, and the structure is unchanged on main:

• v23.8.6 — ReactNativeFirebaseAppCheckModule.java:134 (configureProvider), :168 (activate)
• main — NativeRNFBTurboAppCheck.java:148 (configureProvider), :180 (activate)

There is no ContentProvider, Initializer, Application hook, or static block that installs the factory at process start.

Why Functions works but Firestore/Storage don't

Functions requests an App Check token per invocation, at call time, so a factory installed later is still picked up. Firestore and Storage capture App Check provider state when the client/stream is first created — which happens before JS has installed the factory.

Reproduction

1. Android app, App Check debug provider, debug token registered in the Firebase Console.
2. await initializeAppCheck({ provider, isTokenAutoRefreshEnabled: true }) early in app start — before any Firestore or Storage call.
3. Set a Firestore rule requiring request.app != null, and a Storage rule likewise.
4. Read a document and upload a file.

Observed:

firestore: [firestore/permission-denied] The caller does not have permission to execute the specified operation.
storage:   [storage/unauthorized] User is not authorized to perform the desired action.

A callable Cloud Function in the same session, in the same app, succeeds with {"auth":"VALID","app":"VALID"}.

The token is genuinely available — it just isn't sent

This is the part that rules out a configuration mistake:

• RNFBAppCheck: configureProvider - [DEFAULT]/debug/null
• RNFBAppCheck: Provider::getToken - delegating to native provider
• The App Check token cache (shared_prefs/com.google.firebase.appcheck.store.*.xml) is rewritten during the failing run, which only happens after a successful token exchange with the backend.
• App data was never cleared, so the debug secret is the one already allowlisted in the Console.

So a valid token was minted and cached before the failing requests, and Functions demonstrably transmits it. Firestore and Storage do not.

Control

Same APK, same session, same token. The only variable changed is the rule's gate:

Rules	Firestore read	Storage upload
hasAppCheck() → request.app != null	hangs, never returns	[storage/unauthorized]
same file, gate body replaced with return true	succeeds	succeeds

Every other condition in the Storage rule (uid-matches-path, size cap, content type, filename pattern, ban check) is satisfied by the exact request the gate rejected.

Also worth fixing: the Firestore failure is silent

A rules rejection on a Firestore transaction does not reject the promise — the SDK retries indefinitely. With no error surfaced, the call simply never settles. On a cold start this presents as an app hanging on its loading state with nothing at all in logcat, which makes it very hard to attribute. A snapshot listener with an error callback does report permission-denied correctly; it's the transaction path that's silent.

Environment

@react-native-firebase/app          23.8.6
@react-native-firebase/app-check    23.8.6
@react-native-firebase/firestore    23.8.6
@react-native-firebase/storage      23.8.6
@react-native-firebase/functions    23.8.6
react-native                        0.76.9
expo                                52.0.0
newArchEnabled                      false
Android                             API 34 emulator (Play Store image)

Source citations above are against main, so this does not appear to be fixed in 26.x.

Suggested direction

Expose a native-side registration path that runs before FirebaseApp initialization — e.g. an Initializer/ContentProvider ordered ahead of FirebaseInitProvider, or a documented Application.onCreate() hook — so the factory can be installed with the provider choice supplied by build config rather than by JS. Alternatively, document that Android cannot support rule-level App Check for Firestore/Storage today, since the current docs imply otherwise.

[MikeNotInTheFlesh]

Correction to my own report: the install-ordering explanation above is insufficient. I tested the obvious workaround and it does not fix the problem, so the diagnosis needs narrowing.

Two experiments, both on device against rules requiring request.app != null, both still failing:

1. Install the factory natively, before React Native starts. An Expo config plugin injected into MainApplication.onCreate(), immediately after SoLoader.init — before any JS runs, and long before the Firestore client is created:

FirebaseApp.initializeApp(this)
FirebaseAppCheck.getInstance().installAppCheckProviderFactory(
  if (BuildConfig.DEBUG) DebugAppCheckProviderFactory.getInstance()
  else PlayIntegrityAppCheckProviderFactory.getInstance()
)

This is what the Firebase Android docs prescribe, and it satisfies the ordering requirement quoted from #9166. Firestore still sends no App Check token — reads fail with permission-denied.

2. Skip RNFB's JS initializeAppCheck() entirely on Android, in case it was overwriting the natively-installed factory with RNFB's own. Also no effect.

Controls: the APK was rebuilt and reinstalled for both (App Check debug secret preserved, still the registered one), and an ungated control run on that same APK rendered normally — so the build was healthy and the rule gate was the only variable.

So on Android, with the factory installed before FirebaseApp is used and a token demonstrably minted and cached, Firestore still does not attach it — while Cloud Functions in the same session does.

That means the JS-only install path is a real gap but not the cause here. Something further inside the Firestore integration isn't wiring the App Check provider through. I'd suggest the title/label be read as "Firestore/Storage don't attach App Check tokens on Android" rather than the ordering framing I originally gave it, and I'm happy to test a patch if that's useful.

[russellwheatley]

Hey @MikeNotInTheFlesh - Thanks for the thorough writeup, and for testing that the ordering theory doesn't hold up, that saves a lot of back and forth.

I went through the Android app-check/Firestore native code. installAppCheckProviderFactory is only reachable from configureProvider/activate in NativeRNFBTurboAppCheck.java, so the "JS-only install path" part of the original report is accurate. But FirebaseFirestore.getInstance() (in UniversalFirebaseFirestoreCommon) is created lazily, on first JS call into Firestore, not at module construction. So with your sequencing (initializeAppCheck() before any Firestore/Storage call) the factory should already be installed by the time the client is built, and your native-install test (installing Google's real factory before FirebaseApp is touched, and separately skipping RNFB's JS install entirely) rules out install-ordering as the cause here. There isn't anything else in RNFB's Android bridge between App Check and Firestore/Storage, it's a thin pass-through to FirebaseAppCheck/FirebaseFirestore/FirebaseStorage, so I don't think this is fixable on our side without knowing more about where it's actually breaking.

Three things that would help narrow it down:

1. Can you confirm the App Check header is actually missing on the wire, rather than inferred from the rule rejection? FirebaseFirestore.setLoggingEnabled(true) plus a logcat grep for the gRPC metadata (or a proxy) would show whether X-Firebase-AppCheck is present but rejected server-side vs genuinely absent.
2. Can you try bumping (or pinning) the Firebase Android BoM version, same as suggested on [🐛] App Check token not attached to Firestore requests on Android — firestore/permission-denied (v24.0.0) #9007:

   project.ext {
     set('react-native', [
       versions: [
         firebase: [
           bom: "34.13.0",
         ],
       ],
     ])
   }

That's the one lead from a near-identical report (#9007) that never actually got tested before it went stale, worth ruling in or out here.

3. Also, since you're on Expo, could you double check there's only one [DEFAULT] FirebaseApp instance alive? If Expo's config plugin does any native Firebase init separately from RNFB's auto-init, it's possible the factory gets installed on one FirebaseApp object while Firestore/Storage bind to another with the same name but different identity. Logging System.identityHashCode(FirebaseApp.getInstance()) at both the install site and right before the Firestore call would confirm or rule that out.

[MikeNotInTheFlesh]

Ran the wire-level check you asked for (#1) against our own app, which hits this exact failure mode.

Setup: RNFB 23.8.6 (same as the original report), Android emulator, App Check debug provider with the debug token registered in the Console. Rules gate both reads and writes on users/{userId} with hasAppCheck() { return request.app != null; }. Firebase Android BoM is not pinned in our gradle config, so it resolves to RNFB 23.8.6's default — 34.8.0 — below the 34.13.0 you suggested testing.

Method: firebase.setLogLevel('debug') → FirebaseFirestore.setLoggingEnabled(true) natively, then logcat filtered to the Firestore tag. One gotcha worth flagging in case it trips up anyone else: the modular setLogLevel re-exported from @react-native-firebase/firestore's package root is a decoy — it forwards to the app-level JS logger (@react-native-firebase/app's setLogLevel), not FirebaseFirestore.setLoggingEnabled. You have to reach through the legacy namespaced default export (firebase.setLogLevel('debug')) to get the native gRPC logging this actually requires.

Result: the header is attached and accepted, not silently dropped.

I/Firestore( 9603): (26.1.0) [FirestoreCallCredentials]: Successfully fetched AppCheck token.
I/Firestore( 9603): (26.1.0) [WatchStream]: (7383747) Stream received headers: {date=...}
I/Firestore( 9603): (26.1.0) [WatchStream]: (7383747) Stream received (2): # ListenResponse ... target_change_type: CURRENT
...
I/Firestore( 9603): (26.1.0) [WriteStream]: (a1c89a4) Stream received (2): # WriteResponse ... commit_time { ... }

Both the users/{uid} snapshot-listener read and a direct document update() against the same hasAppCheck()-gated path went through cleanly — WatchStream reached CURRENT, WriteStream got a commit_time back. No permission-denied, no hang.

Scope caveat: this exercised the Listen and Write RPCs (snapshot subscription + document update), not a wrapped runTransaction() call specifically, which is the path your original report singles out as silently hanging rather than surfacing permission-denied. FirestoreCallCredentials is the shared layer for all RPC types including transaction Commit, so I'd expect the same result, but I haven't run that exact repro shape yet and don't want to claim more than I checked.

So on this build, at least, it isn't broken across the board — same RNFB version, same unbumped BoM (34.8.0, not just 34.13.0+), same debug provider, gated rules, and the token makes it onto the wire and is accepted. That argues against a blanket "RNFB Android App Check never wires through to Firestore" explanation and toward something narrower in the original reporter's setup.

On #3 (duplicate FirebaseApp instance): we're on Expo too, and our config plugin only injects an AndroidManifest meta-data flag (firebase_app_check_token_auto_refresh_enabled) — no native FirebaseApp.initializeApp() call outside RNFB's own auto-init from FirebaseInitProvider. So a second [DEFAULT] instance looks unlikely in our case, though I haven't logged identityHashCode to confirm it outright.

Happy to run the runTransaction() repro and/or the BoM bump to 34.13.0 next if that'd help narrow it further.

[MikeNotInTheFlesh]

Disclosure: this report and the follow-up testing above were drafted with Claude (Anthropic) assistance, run against a real device/emulator by me — flagging it since it wasn't noted earlier in the thread.

[MikeNotInTheFlesh]

Closing my earlier scope caveat: ran runTransaction() specifically (read + no-op rewrite on the same hasAppCheck()-gated users/{uid} doc), with a 10s stall watchdog and explicit before/after logging.

I/ReactNativeJS: [9227-diag] starting runTransaction
I/ReactNativeJS: '[9227-diag] tx.get resolved, exists=', true
I/ReactNativeJS: [9227-diag] runTransaction committed successfully

Committed in <1s, both times I ran it. No stall, no throw, no permission-denied. FirestoreCallCredentials: Successfully fetched AppCheck token logged right alongside it, same as the Listen/Write paths already confirmed.

One side finding that might explain your "completely empty logcat" symptom: unlike WatchStream/WriteStream, the transaction's RPCs don't get the verbose request/response protobuf dump — only the FirestoreCallCredentials line. So even a successful transaction logs much less than a stream; a failing one would plausibly log close to nothing, independent of whether App Check is involved.

So across Listen, Write, and now transaction Commit, this doesn't reproduce on our setup (same RNFB version, same unbumped BoM). Still think something narrower in the original environment is the better lead than the RNFB bridge itself.