Skip to content

Bump the Firebase Android BoM to 34.18.0 - #72

Merged
nbransby merged 3 commits into
masterfrom
bump-firebase-bom-34
Oct 26, 2026
Merged

nbransby merged 3 commits into
masterfrom
bump-firebase-bom-34

Conversation

@nbransby

@nbransby nbransby commented Oct 26, 2026 •

Copy link
Copy Markdown
Member

Moves the ported Android libraries from BoM 32.7.0 to 34.18.0: Firestore 26.6.0, Realtime Database 22.0.1, Cloud Functions 22.1.1, Remote Config 23.1.0 and Installations 19.1.2 (README table updated).

The motivation is firebase-kotlin-sdk's com.google.firebase compatibility layer (GitLiveApp/firebase-kotlin-sdk#882), whose header stubs are verified against the real classes: Functions 22.1.1 is the Kotlin rewrite of the module, in which FirebaseFunctionsException's constructors, Code.fromValue / Code.fromHttpStatus and the HttpsCallableOptions fields are public as the Android SDK's API declares them, where 20.4.0 kept them package-private. With this release the Kotlin SDK can drop its jvmMissingMembers exclusions for the module.

What the newer libraries need from the port:

  • OkHttp 4. Functions 22.1.1 is compiled against OkHttp 4 (MediaType.Companion and friends), so the call thread died with NoSuchFieldError on OkHttp 3 and the Task never completed. okhttp moves to 4.12.0, the version the Functions POM declares, and FirebaseAuth moves to the OkHttp 4 API (toMediaType(), toRequestBody(), the body / code / message / url / method / dispatcher properties).
  • The heartbeat DataStore. firebase-common 22 keeps its heartbeat store in a preferences DataStore, through JavaDataStorage. Its DataStore artifacts are KMP modules the attribute-less aar configuration picks no variant of, so they were silently missing and the first RPC's getHeartBeatCode failed with NoClassDefFoundError, which Firestore reports as an internal error and stops its queue. The JVM variants of datastore-core and datastore-preferences-core are added, and Context gains filesDir, backed by a new overridable FirebasePlatform.getFilesDir() defaulting to the temp directory like getDatabasePath, which the DataStore file lives under.
  • One DataStore per file. firebase-common's JavaDataStorage creates a DataStore per instance through the Android preferencesDataStore delegate, and a DataStore stays active for the life of the process, so a FirebaseApp initialised again after delete() or clearInstancesForTest() (as this repository's own tests do between classes) failed intermittently with "There are multiple DataStores active for the same file". The port replaces the class with one that keeps a single DataStore per file, built with the core PreferenceDataStoreFactory and no SharedPreferences migration (the port never kept heartbeats there), which also makes the Android DataStore AARs unnecessary.
  • Plain-jar dependencies. Functions 22 returns a Reactive Streams Publisher from HttpsCallableReference.stream() and Firestore 26 evaluates regex and like filters with re2j. Both are plain jars the aar configuration resolves but the port never shipped, so reactive-streams is an api dependency and re2j an implementation one. The other plain jars the graph resolves without shipping (annotation artifacts, concurrent-futures, kotlinx-coroutines-play-services) were already missing on master and are left as they are.

Verified with this repository's test suite under the emulator (12 tests, two consecutive clean runs), and with the Kotlin SDK's JVM test suites run against a local build of this branch: firebase-app, firebase-functions (6, including the error-code mapping through the Functions emulator, with the stub verifier accepting the members without exclusions), firebase-database (17) and firebase-firestore (80) all pass.

Firestore 26.6.0, Realtime Database 22.0.1, Cloud Functions 22.1.1, Remote
Config 23.1.0 and Installations 19.1.2. Functions 22.1.1 is the Kotlin
rewrite of the module, in which FirebaseFunctionsException's constructors,
Code.fromValue and Code.fromHttpStatus and the HttpsCallableOptions fields are
public, as the firebase-kotlin-sdk compatibility layer declares them.
…eat store needs

Cloud Functions 22.1.1 is compiled against OkHttp 4, so FirebaseAuth moves to
its API too. firebase-common 22 keeps its heartbeat store in a preferences
DataStore: the JVM variants of the core artifacts and the Android datastore
and datastore-preferences AARs (KMP modules the attribute-less aar
configuration picks no variant of) are added, and Context gains filesDir,
backed by a new overridable FirebasePlatform.getFilesDir().
Copilot AI balanced review requested due to automatic review settings October 26, 2026 08:19

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

The multi-major SDK upgrade and manually assembled dependency graph need human validation of published compile-time and runtime compatibility.

1 open issue
What changed in this PR

Upgrades the JVM port to Firebase Android BoM 34.18.0, supporting the Kotlin SDK’s compatibility layer and newer Firebase runtime requirements.

Changes:

  • Updates Firebase versions and migrates authentication code to OkHttp 4.
  • Adds DataStore dependencies and an overridable files directory for heartbeat storage.
  • Refreshes the README’s supported-version table.
File Description
src/​main/​java/​com/​google/​firebase/​FirebasePlatform.kt Adds an overridable files-directory provider.
src/​main/​java/​com/​google/​firebase/​auth/​FirebaseAuth.kt Migrates request creation and accessors to OkHttp 4.
src/​main/​java/​android/​content/​Context.kt Exposes the platform-provided files directory.
README.md Updates documented Firebase versions.
gradle/​libs.versions.toml Updates Firebase and OkHttp versions; adds DataStore entries.
build.gradle.kts Adds Android and JVM DataStore dependencies.

Review effort: Balanced

Comment thread gradle/libs.versions.toml
…p one heartbeat DataStore per file

Functions 22 returns a Reactive Streams Publisher from HttpsCallableReference.stream()
and Firestore 26 evaluates regex and like filters with re2j: both are plain jars the
aar configuration resolves but never shipped, so they become api and implementation
dependencies.

firebase-common's JavaDataStorage creates a DataStore per instance through the
Android preferencesDataStore delegate, and a DataStore stays active for the life of
the process, so a FirebaseApp initialised again after delete() or
clearInstancesForTest() failed with "multiple DataStores active for the same
file". The port replaces the class with one that keeps a single DataStore per file,
built with the core PreferenceDataStoreFactory, which also drops the need for the
Android datastore AARs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants