firebase-auth calls ContextCompat.registerReceiver(Context, BroadcastReceiver, IntentFilter, int) but declares no androidx.core dependency
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Lĩnh vực
- build-system, mobile
Hướng nghiên cứu
Bắt đầu bằng cách xác định khai báo dependency Gradle firebase-auth và tái hiện vấn đề với dependency graph tinh gọn bằng dependencyInsight cùng lệnh gọi phone-auth được mô tả. Hoàn tất khi graph bảo đảm androidx.core ít nhất ở phiên bản 1.9.0 và SMS retriever không còn lỗi với NoSuchMethodError đã báo cáo.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[REQUIRED] Step 2: Describe your environment
- Android Studio version: n/a — Gradle build, AGP 8.12.0 / Gradle 8.14.3
- Firebase Component: Auth
- Component version: 23.2.1 (via firebase-bom 33.15.0); also verified against 24.2.0
[REQUIRED] Step 3: Describe the problem
firebase-auth calls ContextCompat.registerReceiver(Context, BroadcastReceiver, IntentFilter, int) when it sets up the SMS retriever for phone auth. That overload was added in androidx.core 1.9.0.
firebase-auth does not declare a dependency on androidx.core at any version. Its POM declares:
androidx.browser:browser:1.4.0
androidx.collection:collection:1.0.0
androidx.credentials:credentials:1.2.0-rc01
androidx.credentials:credentials-play-services-auth:1.2.0-rc01
androidx.fragment:fragment:1.1.0
androidx.localbroadcastmanager:localbroadcastmanager:1.0.0
androidx.fragment:1.1.0 is far too old to pull in a suitable androidx.core, so nothing in the declared graph guarantees the method exists. The highest androidx.core reachable from firebase-auth alone is 1.2.0, via play-services-base:18.0.1 / play-services-basement:18.4.0.
The result is that any consumer whose dependency graph does not otherwise contain androidx.core >= 1.9.0 gets a hard crash on the first phone auth call.
This is masked for most apps, because appcompat, activity, Compose and core-ktx all bring androidx.core 1.13–1.19 and conflict resolution picks those. It is not masked for consumers with a lean graph — in our case an instrumented-test APK for a library that wraps the Firebase SDKs, which depends on firebase-auth and androidx.test but not on any UI artifact.
Steps to reproduce:
- Create an Android module that depends on
com.google.firebase:firebase-authwithoutappcompat,activity, Compose, orcore-ktx. - Confirm the resolved version is old —
./gradlew :module:dependencyInsight --configuration debugRuntimeClasspath --dependency androidx.core:corereportsandroidx.core:core:1.2.0, selection reasonBy conflict resolution: between versions 1.2.0, 1.1.0 and 1.0.0. - Call
PhoneAuthProvider.verifyPhoneNumber(...). - It crashes as soon as the SMS retriever is registered.
Verified that androidx.core:core:1.9.0 contains the overload and 1.2.0 does not, by decompiling both:
$ javap -classpath <core-1.9.0> androidx.core.content.ContextCompat | grep registerReceiver
public static android.content.Intent registerReceiver(android.content.Context, android.content.BroadcastReceiver, android.content.IntentFilter, int);
public static android.content.Intent registerReceiver(android.content.Context, android.content.BroadcastReceiver, android.content.IntentFilter, java.lang.String, android.os.Handler, int);
$ javap -classpath <core-1.2.0> androidx.core.content.ContextCompat | grep registerReceiver
(no such overload)
Relevant Code:
java.lang.NoSuchMethodError: No static method registerReceiver(Landroid/content/Context;Landroid/content/BroadcastReceiver;Landroid/content/IntentFilter;I)Landroid/content/Intent;
in class Landroidx/core/content/ContextCompat; or its super classes
(declaration of 'androidx.core.content.ContextCompat' appears in /data/app/~~-GawQ-mLA-xVH6tujzcrdw==/dev.gitlive.firebase.auth.test-YTNifziXwZqfmlaaSKp6KQ==/base.apk)
at com.google.android.gms.internal.firebase-auth-api.zzafu.zza(com.google.firebase:firebase-auth@@23.2.1:115)
at com.google.android.gms.internal.firebase-auth-api.zzaef.zza(com.google.firebase:firebase-auth@@23.2.1:148)
at com.google.android.gms.internal.firebase-auth-api.zzaee.zza(com.google.firebase:firebase-auth@@23.2.1:9)
at com.google.android.gms.internal.firebase-auth-api.zzafj.run(com.google.firebase:firebase-auth@@23.2.1:3)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0$com-google-firebase-concurrent-CustomThreadFactory(CustomThreadFactory.java:47)
at com.google.firebase.concurrent.CustomThreadFactory$$ExternalSyntheticLambda0.run(D8$$SyntheticClass:0)
at java.lang.Thread.run(Thread.java:1012)
Suggested fix
Have firebase-auth declare the minimum androidx.core its code actually requires, either as a dependency or as a constraint:
api("androidx.core:core:1.9.0")
1.9.0 is the exact floor for the overload in use. Declaring it would let Gradle's conflict resolution do the right thing for lean consumers, while apps that already bring a newer androidx.core are unaffected.
We have worked around it locally by pinning androidx.core on the affected test source set, so this is not blocking us — filing because the underdeclaration looks unintentional and still applies in 24.2.0.
- Ngôn ngữ chính
- Java
- Star
- 2.6k
- Fork
- 733
- Merge trung bình
- 2 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 72
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của firebase/firebase-android-sdk
-
api: remoteconfig
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
firebase/firebase-android-sdk#8827 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Crashlytics plugin writes build ID lists in directory listing order, so APKs can differ between machinesCó thể đã có người làm @mrober đã nhận 8 ngày trước. Đang mởapi: crashlytics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
firebase/firebase-android-sdk#8789 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
firebase/firebase-android-sdk#8835 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
firebase/firebase-android-sdk#8832 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Firestore: NoSuchElementException in SQLiteIndexManager.encodeValues for a != query with a trailing orderBy when cache index auto-creation is enabledCó thể đã có người làm @dconeybe đã nhận 2 ngày trước. Đang mởapi: firestore
firebase/firebase-android-sdk#8831 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của firebase/firebase-android-sdk
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
NationalSecurityAgency/ghidra#10220 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
RIS export splits an organization name containing “and” into multiple authorsCó thể đã có người làm @Gautam-aman đã nhận hôm nay. Đang mởstatus: needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
JabRef/jabref#17821 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
FailureContext.java rounds down thresholds in lastedAtLeast()Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày