chore(deps): bump the gradle-minor-and-patch group with 4 updates

[dependabot]

Bumps the gradle-minor-and-patch group with 4 updates: com.google.firebase:firebase-database, com.android.application, com.android.library and com.google.devtools.ksp.

Updates com.google.firebase:firebase-database from 22.0.1 to 22.0.2

Commits

• See full diff in compare view

Updates com.android.application from 9.3.1 to 9.4.1

Updates com.android.library from 9.3.1 to 9.4.1

Updates com.android.library from 9.3.1 to 9.4.1

Updates com.google.devtools.ksp from 2.3.11 to 2.3.12

Release notes

Sourced from com.google.devtools.ksp's releases.

2.3.12

What's Changed

Migrating Processors to Support Backing Fields

This release introduces support for explicit backing fields (#2873), which may now be returned by Resolver.getSymbolsWithAnnotation. To prevent breaking existing processors, new language features require an explicit opt-in.

More generally, the KSP API now explicitly models backing fields for properties. The following is an exhaustive list of functions in KSP API where processor may observe the change after opting in:

• Resolver.getSymbolsWithAnnotation: The function now returns a KSBackingField if the given annotation targeted a field. Previously, if a field were targeted, the function would return a KSProperty.
• Resolver.effectiveJavaModifiers: The function returns fewer modifiers for a KSPropertyDeclaration if it has a backing field, since most of the JVM-specific annotations apply to the backing field. If you are interested in the JVM modifiers, you should call the function with the KSBackingField obtained from the property instead.

Additionally, KSP now models Java fields as properties that always have backing fields. Some of the modifiers now apply to the backing field instead.

Processors adapting to new features must opt in via both of the following steps simultaneously (failing to do both may lead to undefined behavior):

1. The processor should call the registerProcessorForNewFeatures function in SymbolProcessorEnvironment immediately when created (and only once). Example: AbstractTestProcessor.kt#L30
2. All implementations of KSVisitor should move to KSVisitorNext. If their processor code does not directly implement the interface but instead extends one of the KSP-provided visitors (such as KSTopDownVisitor), they should instead extend KSTopDownVisitor(enableNewFeatures = true) and override visitBackingField depending on their code and needs.

Let us know if you run into unexpected behavior!

Bug Fixes

• Fix Resolver.getDeclarationsFromPackage returning incomplete declarations from KLibs in Kotlin Multiplatform (#2396)
• Fix KSP CLI process hanging indefinitely when a processor throws an unhandled exception (#3120)
• Fix implicit task dependency error between KSP and Android Lint in Android KMP (#3128)
• Fix NullPointerException by registering PluginProblemReporter as an application service (#3140)
• Do not mark companion objects as JAVA_STATIC in Resolver.effectiveJavaModifiers (#3125)
• Fix JAVA_STATIC modifier resolution for @​JvmStatic members in Resolver.effectiveJavaModifiers (#3124)
• Update minimum supported Android Gradle Plugin (AGP) version to 8.12.0 (#3149)

New Contributors

Thanks to @​KlyneChrysler, @​budindepunk, and everyone who reported bugs and participated in discussions!

Full Changelog: google/ksp@2.3.11...2.3.12

Commits

• a3c3859 Format Resolver file
• a614317 Fix grammatical errors in Resolver doc comments
• c19f255 Merge equal EXPECT NEXT and EXPECT CURRENT in javaBackingFieldUsedInKotlin
• d3df886 Add test for getting default annotation values in KMP
• 3bcac20 Mark testJavaBackingFieldUsedInKotlin as fixed
• e74bb5f Update expected test output in libOrigins
• c9b1d40 Use KSSyntheticJavaBackingFieldImpl in KSPropertyDeclarationImpl
• afefe15 Add KSSyntheticJavaBackingFieldImpl
• 2da07c1 Add test for missing synthetic Java fields
• 7033530 Fix visibility modifiers for Kotlin-based backing fields
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[kikoso]

LGTM

Verified locally on the PR branch with ./scripts/verify_all.sh (assemble + unit tests + lint + doc version check): ALL MODULES PASSED VERIFICATION — ApiDemos java/kotlin/common-ui, FireMarkers, WearOS, all six snippets modules, and tutorials. 12 successful builds, zero failures.

AGP 9.3.1 → 9.4.1, KSP 2.3.11 → 2.3.12, firebase-database 22.0.1 → 22.0.2. The KSP backing-field change is opt-in, so no processor impact here. All CI checks green.

[kikoso]

LGTM — verified locally with ./scripts/verify_all.sh, all modules passed; all checks green.