IssueTracker

This is a hard one. We can't easily read native crashes from that Motorola device since their system image is not public. I assume you can't reproduce this either, but if possible can you try using WorkManager 2.0.0 or 1.0.1-rc01? This would help track down the possible changes that might have introduced this issue. Thanks!

We actually did reproduce it, the current store version of Pocket Casts has WorkManager 2.0.0 and this bug if you want to try and test something. I will try 1.0.1-rc01 and report back.

Is there a difference between 1.0.1 and 2.0.1? We tried 2.0.1 and it was crashing, if there is a difference I can try 1.0.1 but I thought they were the same?

Can you also describe how you trigger the bug and which devices manifest the problem?  Is it just running the app?  Is it doing something specific?

We are testing on a Moto X running Android 6.0 but our play store report shows numerous motorola devices are crashing as the attached screenshots show. We just downloaded a bunch of episodes (which uses workmanager) and eventually it started crashing, it would then crash at start up every time.

So to answer your earlier question, 1.0.1 should be equivalent but I think there may be some small differences in Room between 1.0 and 2.0 and since this crash seems related to Room, that's why we were asking if you could check to see if you can reproduce it on 1.x.

Regarding the initial crash, do you have any logs for that?

This is the log I have. Hope it helps. Will test 1.0.1 for you

The logs are too short its just the crash and not much else before. :(

If the phone happens to be rooted and you are OK with sharing DB queries then you can enable SQL logging so we can see the queries that are occurring:
adb shell setprop log.tag.SQLiteStatements VERBOSE
adb shell stop
adb shell start

It would also be great if you can send us a bigger set of logs, or even better yet a bugreport after the crash occurs. (https://developer.android.com/studio/debug/bug-report)

We can't root the phone sorry, we might be able to send a bug report though

We have a bug report from the crash already actually

We haven't been able to get the crash to happen on 1.0.1 so far

With a version of WorkManager that you are able to reproduce the issue, can you try adding Room 2.1.0-alpha06 as a dependency, effectively upgrading WorkManager's runtime dependency of Room?

Can you also enable WorkManager logs using setMinimumLoggingLevel(Log.DEBUG) https://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration

If you observe the crash please do take a bug report. If possible also dump dbinfo for the app's package: adb shell dumpsys dbinfo <package-name>

We have gone back to 2.0.0 and haven't been able to make it crash again unfortunately. Will keep trying. We are rolling out an update next week that reverts to 1.0.0 and will let you know if the crash goes away in production as well

I just want to distinguish between which versions you are using/experiencing this on.

1. The bug title lists 2.0.0
2. The first update lists 2.0.1-rc01
3. #14 lists 2.0.0

Can you reproduce at all with any version of WorkManager 2.x at this point?  And if so, which ones work and which ones don't?

Our store version had 2.0.0 and is what the screenshots come from, we reproduced locally using that. We upgraded to 2.0.1rc1 and the phone was still crashing. We downgraded to 1.0.0 and the crash went away. To help with this testing we went back to 2.0.0 to try and get it to crash again but we haven't been able to get it to happen again.

We rolled out an update to the Play Store using WorkManager 1.0.0 and the issue has persisted unfortunately

Not sure it helps but this trace has a few more lines in it.

backtrace:
  #00  pc 0000000000000000  <unknown>
  #01  pc 0000000000025cdd  /system/lib/libsqlite.so
  #02  pc 0000000000025011  /system/lib/libsqlite.so
  #03  pc 000000000000eb95  /system/lib/libsqlite.so
  #04  pc 000000000002d60d  /system/lib/libsqlite.so
  #05  pc 000000000003b409  /system/lib/libsqlite.so
  #06  pc 0000000000010931  /system/lib/libsqlite.so (sqlite3_step+536)
  #07  pc 000000000007f175  /system/lib/libandroid_runtime.so
  #08  pc 00000000018a0a33  /system/framework/arm/boot-framework.oat (android.database.sqlite.SQLiteConnection.nativeExecute+102)
  #09  pc 00000000018a34b9  /system/framework/arm/boot-framework.oat (android.database.sqlite.SQLiteConnection.execute+260)
  #10  pc 00000000018b3741  /system/framework/arm/boot-framework.oat (android.database.sqlite.SQLiteSession.endTransactionUnchecked+364)
  #11  pc 00000000018b3ee5  /system/framework/arm/boot-framework.oat (android.database.sqlite.SQLiteSession.endTransaction+144)
  #12  pc 00000000018ac61d  /system/framework/arm/boot-framework.oat (android.database.sqlite.SQLiteDatabase.endTransaction+72)
  #13  pc 00000000000a91c1  /system/lib/libart.so (art_quick_invoke_stub_internal+64)
  #14  pc 00000000004031e9  /system/lib/libart.so (art_quick_invoke_stub+232)
  #15  pc 00000000000b0455  /system/lib/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+136)
  #16  pc 00000000001ec389  /system/lib/libart.so (_ZN3art11interpreter34ArtInterpreterToCompiledCodeBridgeEPNS_6ThreadEPNS_9ArtMethodEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+200)
  #17  pc 00000000001e6939  /system/lib/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+492)
  #18  pc 00000000003fd663  /system/lib/libart.so (MterpInvokeVirtualQuick+322)
  #19  pc 000000000009fd94  /system/lib/libart.so (ExecuteMterpImpl+29972)
  #20  pc 00000000001ca783  /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+290)
  #21  pc 00000000001cf2eb  /system/lib/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+114)
  #22  pc 00000000001e691f  /system/lib/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+466)
  #23  pc 00000000003fb92b  /system/lib/libart.so (MterpInvokeInterface+826)
  #24  pc 000000000009c214  /system/lib/libart.so (ExecuteMterpImpl+14740)
  #25  pc 00000000001ca783  /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+290)
  #26  pc 00000000001cf2eb  /system/lib/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+114)
  #27  pc 00000000001e691f  /system/lib/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+466)
  #28  pc 00000000003fd663  /system/lib/libart.so (MterpInvokeVirtualQuick+322)
  #29  pc 000000000009fd94  /system/lib/libart.so (ExecuteMterpImpl+29972)
  #30  pc 00000000001ca783  /system/lib/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+290)
  #31  pc 00000000001cf255  /system/lib/libart.so (_ZN3art11interpreter30EnterInterpreterFromEntryPointEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameE+92)
  #32  pc 00000000003f269f  /system/lib/libart.so (artQuickToInterpreterBridge+706)
  #33  pc 00000000000adc13  /system/lib/libart.so (art_quick_to_interpreter_bridge+34)
  #34  pc 000000000064b125  /system/framework/arm/boot-core-libart.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+344)
  #35  pc 0000000000652b47  /system/framework/arm/boot-core-libart.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+42)
  #36  pc 00000000005f749d  /system/framework/arm/boot.oat (java.lang.Thread.run+48)
  #37  pc 00000000000a91c1  /system/lib/libart.so (art_quick_invoke_stub_internal+64)
  #38  pc 00000000004031e9  /system/lib/libart.so (art_quick_invoke_stub+232)
  #39  pc 00000000000b0455  /system/lib/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+136)
  #40  pc 0000000000314031  /system/lib/libart.so (_ZN3artL18InvokeWithArgArrayERKNS_33ScopedObjectAccessAlreadyRunnableEPNS_9ArtMethodEPNS_8ArgArrayEPNS_6JValueEPKc+56)
  #41  pc 0000000000314dfd  /system/lib/libart.so (_ZN3art35InvokeVirtualOrInterfaceWithJValuesERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDP6jvalue+256)
  #42  pc 000000000032be19  /system/lib/libart.so (_ZN3art6Thread14CreateCallbackEPv+848)
  #43  pc 0000000000046eb3  /system/lib/libc.so (_ZL15__pthread_startPv+22)
  #44  pc 0000000000019acd  /system/lib/libc.so (__start_thread+6)

Unfortunately, this is still not telling us anything we can diagnose.  Paired with the fact that we haven't gotten any other reports of this issue, it's not clear how we should proceed.  We would need Motorola system images to proceed at this point.  I can suggest one more thing: if you go back to the last version that worked fine for you and simply change your WorkManager dependency (but *not* any of the rest of your app's code changes), does it immediately exhibit the crash?  Basically, I'm wondering if something else with your code is triggering or exacerbating the issue.

Ping to the original reporter(s).

Sorry I have been on leave for Easter. I think you are right about some other code change triggering this bug, will see if I can work anything out. I am at I/O next week as well if you want to have a look yourself.

Thanks, closing this out for now - feel free to reply if there's anything else we can assist you with on this matter.

This is a definite stab in the dark but do you use a ForeignKey with Room? This is the only reference I can find to similar crashes online. https://stackoverflow.com/questions/50662521/tombstone-using-foreignkey-with-room

We do use foreign keys, but we've been doing that since our early alpha versions so I'm not sure that's it.

Fair enough, both crash reports have this sqlite3_step+536 in common. Will keep trying to work it out.

We seem to have narrowed this down to calling

WorkManager.initialize(applicationContext, workManagerConfig)
WorkManager.getInstance().getWorkInfosByTagLiveData(DownloadManager.WORK_MANAGER_DOWNLOAD_TAG).observeForever {}

If we wrap the second line in a coroutine to main just to delay it a cycle then the crash goes away, at least on our test device. We might roll out the fix to test it.

Hi, I'm glad you have some reproducible steps.  It would help us a lot if you could actually boil this down to a minimal sample app that can reproduce it so you can share it with us and we can also examine what is going wrong.

Done! This crashes for us on the second launch, you need a large amount queued jobs for it to happen. Testing on a Moto X 2014 victara running Android 6.0.

We managed to get a test device, and I can reproduce it.

I see this:

05-21 10:18:50.804   352   352 D SFPerfTracer:        layers: (6:13) (FocusedStackFrame (0xb8370eb8): 0:108)* (DimLayer (0xb83412c0): 9:12) (StatusBar (0xb83bbf38): 0:701) (NavigationBar (0xb8389d10): 0:550) (com.android.systemui.ImageWallpaper (0xb83b23f8): 0:234) (DimLayer (0xb83989f0): 0:45)- (DimLayer (0xb83907e0): 0:8)- (com.example.workmanagercrash/com.example.workmanagercrash.MainActivity (0xb836c948): 0:31)- (com.android.systemui/com.android.systemui.recents.RecentsActivity (0xb838d188): 0:58)- (thumbnail anim (0xb834e7a0): 0:23)- (com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (0xb834e7a0): 0:13) (Application Error: com.example.workmanagercrash (0xb83989f0): 8:14)
05-21 10:18:50.804   463   463 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-21 10:18:50.804   463   463 F DEBUG   : Build fingerprint: 'motorola/victara_tmo/victara:6.0/MPES24.49-18-7/7:user/release-keys'
05-21 10:18:50.805   463   463 F DEBUG   : Revision: 'p2bf'
05-21 10:18:50.805   463   463 F DEBUG   : ABI: 'arm'
05-21 10:18:50.805   463   463 F DEBUG   : pid: 9165, tid: 9180, name: WorkManager-Wor  >>> com.example.workmanagercrash <<<
05-21 10:18:50.805   463   463 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
05-21 10:18:50.819   463   463 F DEBUG   :     r0 b9b04660  r1 af9ece50  r2 00000000  r3 00000002
05-21 10:18:50.819   463   463 F DEBUG   :     r4 b9b044b8  r5 b692e118  r6 00000000  r7 b9b04f08
05-21 10:18:50.819   463   463 F DEBUG   :     r8 00000001  r9 b9b044b8  sl 00000000  fp 00000002
05-21 10:18:50.819   463   463 F DEBUG   :     ip b692ddfc  sp af9ece28  lr b6881e5b  pc 00000000  cpsr 200f0010
05-21 10:18:50.823   463   463 F DEBUG   :
05-21 10:18:50.823   463   463 F DEBUG   : backtrace:
05-21 10:18:50.824   463   463 F DEBUG   :     #00 pc 00000000  <unknown>
05-21 10:18:50.824   463   463 F DEBUG   :     #01 pc 00024e59  /system/lib/libsqlite.so
05-21 10:18:50.824   463   463 F DEBUG   :     #02 pc 00024173  /system/lib/libsqlite.so
05-21 10:18:50.824   463   463 F DEBUG   :     #03 pc 0000e759  /system/lib/libsqlite.so
05-21 10:18:50.824   463   463 F DEBUG   :     #04 pc 0002be41  /system/lib/libsqlite.so
05-21 10:18:50.824   463   463 F DEBUG   :     #05 pc 00039ad7  /system/lib/libsqlite.so
05-21 10:18:50.824   463   463 F DEBUG   :     #06 pc 0000ffc5  /system/lib/libsqlite.so (sqlite3_step+724)
05-21 10:18:50.824   463   463 F DEBUG   :     #07 pc 00075021  /system/lib/libandroid_runtime.so
05-21 10:18:50.824   463   463 F DEBUG   :     #08 pc 02287663  /system/framework/arm/boot.oat (offset 0x1fda000)
05-21 10:18:51.062  1769  2069 V AlarmManager: sending alarm {f6ba791 type 3 *alarm*:android.content.jobscheduler.JOB_DELAY_EXPIRED}
05-21 10:18:51.065  1769  1769 V AlarmManager: done {f6ba791, *alarm*:android.content.jobscheduler.JOB_DELAY_EXPIRED} [3ms]
05-21 10:18:51.131   463   463 F DEBUG   :
05-21 10:18:51.131   463   463 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_01
05-21 10:18:51.131   463   463 E DEBUG   : AM write failed: Broken pipe
05-21 10:18:51.133  1769  1786 I BootReceiver: Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
05-21 10:18:51.184   485   485 I Zygote  : Process 9165 exited due to signal (11)
05-21 10:18:51.214  1769  2729 I ActivityManager: Process com.example.workmanagercrash (pid 9165) has died
05-21 10:18:51.215  1769  2729 W ActivityManager: Scheduling restart of crashed service com.example.workmanagercrash/androidx.work.impl.background.systemjob.SystemJobService in 1000ms
05-21 10:18:51.238  1769  1769 I ActivityManager: Start proc 9188:com.example.workmanagercrash/u0a106 for service com.example.workmanagercrash/androidx.work.impl.background.systemjob.SystemJobService
05-21 10:18:51.256  9188  9188 I art     : Late-enabling -Xcheck:jni
05-21 10:18:51.301  9188  9188 W System  : ClassLoader referenced unknown path: /data/app/com.example.workmanagercrash-1/lib/arm
05-21 10:18:51.476  9188  9202 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9202 (WorkManager-Wor)
05-21 10:18:51.578   463   463 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-21 10:18:51.578   463   463 F DEBUG   : Build fingerprint: 'motorola/victara_tmo/victara:6.0/MPES24.49-18-7/7:user/release-keys'
05-21 10:18:51.579   463   463 F DEBUG   : Revision: 'p2bf'
05-21 10:18:51.579   463   463 F DEBUG   : ABI: 'arm'
05-21 10:18:51.579   463   463 F DEBUG   : pid: 9188, tid: 9202, name: WorkManager-Wor  >>> com.example.workmanagercrash <<<
05-21 10:18:51.580   463   463 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
05-21 10:18:51.609   463   463 F DEBUG   :     r0 b9b048c0  r1 af9ece50  r2 00000000  r3 00000002
05-21 10:18:51.609   463   463 F DEBUG   :     r4 b9b04718  r5 b692e118  r6 00000000  r7 b9b05170
05-21 10:18:51.609   463   463 F DEBUG   :     r8 00000001  r9 b9b04718  sl 00000000  fp 00000002
05-21 10:18:51.609   463   463 F DEBUG   :     ip b692ddfc  sp af9ece28  lr b6881e5b  pc 00000000  cpsr 200f0010
05-21 10:18:51.615   463   463 F DEBUG   :
05-21 10:18:51.615   463   463 F DEBUG   : backtrace:
05-21 10:18:51.616   463   463 F DEBUG   :     #00 pc 00000000  <unknown>
05-21 10:18:51.616   463   463 F DEBUG   :     #01 pc 00024e59  /system/lib/libsqlite.so
05-21 10:18:51.616   463   463 F DEBUG   :     #02 pc 00024173  /system/lib/libsqlite.so
05-21 10:18:51.616   463   463 F DEBUG   :     #03 pc 0000e759  /system/lib/libsqlite.so
05-21 10:18:51.616   463   463 F DEBUG   :     #04 pc 0002be41  /system/lib/libsqlite.so
05-21 10:18:51.616   463   463 F DEBUG   :     #05 pc 00039ad7  /system/lib/libsqlite.so
05-21 10:18:51.616   463   463 F DEBUG   :     #06 pc 0000ffc5  /system/lib/libsqlite.so (sqlite3_step+724)
05-21 10:18:51.616   463   463 F DEBUG   :     #07 pc 00075021  /system/lib/libandroid_runtime.so
05-21 10:18:51.616   463   463 F DEBUG   :     #08 pc 02287663  /system/framework/arm/boot.oat (offset 0x1fda000)
05-21 10:18:51.902   463   463 F DEBUG   :
05-21 10:18:51.902   463   463 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_02
05-21 10:18:51.902   463   463 E DEBUG   : AM write failed: Broken pipe
05-21 10:18:51.903  1769  1786 I BootReceiver: Copying /data/tombstones/tombstone_02 to DropBox (SYSTEM_TOMBSTONE)
05-21 10:18:51.952   485   485 I Zygote  : Process 9188 exited due to signal (11)
05-21 10:18:51.966  1769  2757 I ActivityManager: Process com.example.workmanagercrash (pid 9188) has died

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 957adb282e41c2662fff6221325e6b51cd7377f9
Author: Rahul Ravikumar <rahulrav@google.com>
Date:   Tue May 21 14:37:00 2019

    Fixes SQLite issues on some devices.
   
    * Always beginTransaction() outside a try.
    * Make sure SystemJobScheduler marks transactions as successful.
   
    Test: Existing tests pass.
    Fixes: b/130182503, b/132697495
    Change-Id: I55092537781fbfee97f4336eb7cf1a49e647d62a

M       work/workmanager-gcm/src/main/java/androidx/work/impl/background/gcm/WorkManagerGcmDispatcher.java
M       work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java
M       work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java
M       work/workmanager/src/main/java/androidx/work/impl/utils/ForceStopRunnable.java

https://android-review.googlesource.com/966057
https://goto.google.com/android-sha1/957adb282e41c2662fff6221325e6b51cd7377f9

Will it be fixed in a maintainance release of 2.0, or will we have to wait for 2.1 next RC or release?

This will show up in the next 2.1.0 release.

same issue

How long does bugs like this usually take to resolve?

same issue, plz upgrade deps, this blocks firebase-related modules to upgrade

Same issue.
Is it possible to force a specific version of GoogleDataTransport in the Pod file like this:
pod 'GoogleDataTransport', '9.4.1'

OR

Use Dependency Overrides in pubspec.yaml like this:
dependency_overrides:
  google_data_transport: 9.4.1

Can someone test this and give feedback?

Same same!

I was able to fix this bug temporarily with the Podfile of my ios build. Please see the $FirebaseSDKVersion = '10.29.0' at the top of my Podfile. This is the important part:

# Temporary fix for Google ML Kit bug - https://issuetracker.google.com/issues/362452861
$FirebaseSDKVersion = '10.29.0'

# Uncomment this line to define a global platform for your project
platform :ios, '13.0'

# CocoaPods analytics sends network stats synchronously affecting flutter build latency.
ENV['COCOAPODS_DISABLE_STATS'] = 'true'

project 'Runner', {
  'Debug' => :debug,
  'Profile' => :release,
  'Release' => :release,
}

def flutter_root
  generated_xcode_build_settings_path = File.expand_path(File.join('..', 'Flutter', 'Generated.xcconfig'), __FILE__)
  unless File.exist?(generated_xcode_build_settings_path)
    raise "#{generated_xcode_build_settings_path} must exist. If you're running pod install manually, make sure flutter pub get is executed first"
  end

  File.foreach(generated_xcode_build_settings_path) do |line|
    matches = line.match(/FLUTTER_ROOT\=(.*)/)
    return matches[1].strip if matches
  end
  raise "FLUTTER_ROOT not found in #{generated_xcode_build_settings_path}. Try deleting Generated.xcconfig, then run flutter pub get"
end

require File.expand_path(File.join('packages', 'flutter_tools', 'bin', 'podhelper'), flutter_root)

flutter_ios_podfile_setup

target 'Runner' do
  use_frameworks!
  use_modular_headers!

  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)
  end
end

Same issue. Please fix asap.

same issue

When this issue will be fixed?

please fix it

Please help!! same issue

This is critical:

Mac OS Sequoia requires Xcode 16
Xcode 16 is incompatible with Flutter's firebase_core v3.4.0 and higher
Another Flutter plugin (mobile_scanner) depends on this thing
-> This completely blocks anyone who accidentally updated to Sequoia and now has broken dependencies

This is critical:

Mac OS Sequoia requires Xcode 16
Xcode 16 is incompatible with Flutter's firebase_core v3.4.0 and higher
Another Flutter plugin (mobile_scanner) depends on this thing
-> This completely blocks anyone who accidentally updated to Sequoia and now has broken dependencies

Anxious waiting

We got the same issue here, blocking mobile_scanner.

Any update?

Same issue here

Same issue here

Same issue here

Same issue here

Same issue here

Same issue, please put more priority on it.

Same issue here

So no news, it’s starting to become blocking. I can't release a version of my app...

same problem with... hope the fix this problem

I am blocked by this.

same issue

Same issue here

Same issue

I am blocked by this.

I am also blocked by this.

Same issue here, i am blocked by this

Same. Please look at this ASAP

Same issue

Very blocking issue. Please fix it asap. Google's credibility is at stake. Will be taken into account for our next projects.

Blocked here as well. It's getting critical.

same issue

It looks like Google is planning to kill Flutter. A month passed — no response, no updates.

Come on, Google!
Let's get this sorted... this is a regression that's breaking things.

Very urgent issue that needs to be solved!

Same issue

same issue here

same issue here

you should fix it ASAP, this is so unprofessional to provide solution that is not compliant with other your services

same issue here

Same issue here

Same issue here

+1

I have the same issue

+1

+1

+1

+1, This really is critical!

Critical for everyone, but not for Google :)

+1...

same issue

same issue

same issue

workaround:

add $FirebaseSDKVersion = '10.29.0' to your podfile

Any updates on this issue ??

Temporary solution is to not use latest firebase versions on xcode 16 for the moment. If you use flutter, you can downgrade them in your pubspec.yaml.

All MLKIT components (IOS) that rely on GoogleDataTransport are affected due to the conflict with Firebase SDK 11.

same issue here

Impacted by it and can't release my next upgrade of iOS app 'scoreblox: LIVE cricket scores'. Android side is fine. mobile_scanner iOS plugin dependency issue.

same issue

Downgrading previous firebase versions doesn't work anymore because some other dependencies require higher versions of firebase libraries. So now we are stucked.

Very blocked by this issue.
Flutter/Google studd is not mature I think, which proved by this issue.
And it is opened quite a while now...

Very blocked by this issue.
Flutter/Google stuff is not mature I think, which proved by this issue.
And it is opened quite a while now...

Same here

I don't understand why this issue is P4.

I understand that maintainers have a lot of other work to do and it's difficult to deal with this, but if they can't maintain it, they'll have to consider migrating to another package, so I'd like them to let you know that. Or they could just announce that they're considering it. In any case, without some kind of information, users can't make a decision.

We appreciate the maintainers' hard work, but this issue requires some action.

Do we have any other alternatives to MLKit/BarcodeScanner? Seems Google doesn't want to support it.
It's just a disgrace to ignore your own library and community and do nothing.

How can this be P4 ???!!

Come on, how hard could this be? Or at least leave a response so that we, the developers/package users, can decide whether to wait or try another package.

We’d appreciate any updates. Given that it’s been over a month and this issue has had around 1000 views this week alone (far more than the next most-seen issue with only 60 views, which is a duplicate of this one), clearly P4 doesn't reflect how critical this issue is.

+1

Same issue!

[!] CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 4.1.3, which depends on
      Firebase/Crashlytics (= 11.2.0) was resolved to 11.2.0, which depends on
        FirebaseCrashlytics (~> 11.2.0) was resolved to 11.2.0, which depends on
          GoogleDataTransport (~> 10.0)

    mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 5.2.3, which depends on
      GoogleMLKit/BarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
        MLKitBarcodeScanning (~> 5.0.0) was resolved to 5.0.0, which depends on
          MLKitCommon (~> 11.0) was resolved to 11.0.0, which depends on
            GoogleDataTransport (< 10.0, >= 9.4.1)

That's a big problem for me too...

    GoogleMLKit/TextRecognitionDevanagari (~> 6.0.0) was resolved to 6.0.0, which depends on
      MLKitTextRecognitionDevanagari (~> 3.0.0) was resolved to 3.0.0, which depends on
        MLKitCommon (~> 11.0) was resolved to 11.0.0, which depends on
          GoogleDataTransport (< 10.0, >= 9.4.1)
I promis my users to update my app every Week, I'm stuck now, please Google, do something...

Same issue here

Same Issue
` MLKitCommon (from `MLKitCommon.podspec.json`)

    MLKitVision (from `MLKitVision.podspec.json`) was resolved to 5.0.0, which depends on
      MLKitCommon (~> 9.0)

    mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 5.2.3, which depends on
      GoogleMLKit/BarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
        GoogleMLKit/MLKitCore (= 6.0.0) was resolved to 6.0.0, which depends on
          MLKitCommon (~> 11.0.0)`

Same here

come on, do something

This is a big problem for us. Can you please fix it?

Also blocked by this. Huge problem for us

+1

Same here

+1

+1

+1

+1

+1

+1

Please try to prioritise this. You are doing a great job! <3

Same here

Same here

Maybe google is shutting down this product.

If you would open-source it we could fix it ourselves....

+1

Please Google, escalate this problem. It is getting critical.

any update on this issue ? Whole world waiting for ya

+1

I have similar problem with the current releases using cloud_firestore and mobile_scanner

         cloud_firestore (from `.symlinks/plugins/cloud_firestore/ios`) was resolved to 5.4.4, which depends on
          Firebase/Firestore (= 11.2.0) was resolved to 11.2.0, which depends on
            FirebaseFirestore (~> 11.2.0) was resolved to 11.2.0, which depends on
              FirebaseFirestoreInternal (= 11.2.0) was resolved to 11.2.0, which depends on
                nanopb (~> 3.30910.0)

       mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 5.2.3, which depends on
          GoogleMLKit/BarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
            GoogleMLKit/MLKitCore (= 6.0.0) was resolved to 6.0.0, which depends on
              MLKitCommon (~> 11.0.0) was resolved to 11.0.0, which depends on
                GoogleDataTransport (< 10.0, >= 9.4.1) was resolved to 9.4.1, which depends on
                  nanopb (< 2.30911.0, >= 2.30908.0)

+1

+1

+1

+1

Hmm, Google seems unmotivated. If you just want to make some kind of reaction (for example, responding, not responding, discussing...), it seems like it can be done in 30 seconds.

Now, realistically, how do we switch from this plugin? Don't you need to consider how to respond?

Blocked by this too! +1

blocked as well

+1

GoogleMLKit shipped a new release (7.0.0)

https://developers.google.com/ml-kit/release-notes#september_30_2024

It upgraded its version range of GoogleUtilities/UserDefaults dependency in MLKitCommon from ">= 7.13.0, < 8.0" to "~> 8.0" and should have fixed this dependency conflict issue.

Thanks heaps for the new release. pub.dev library mobile_scanner 6.0.0 uses this fix version and seems to work fine. No errors so far! Thx again!

Can confirm, works again
Flutter users remember to do:

flutter clean && flutter pub get
pod repo update
flutter build ipa

Confirmed as fixed. GOOGLE: THANK YOU FOR YOUR COMPLETE LACK OF COMMUNICATION ON THIS. The 40 hours I spent in the last week trying to sort out a new solution (because we could only assume you had abandoned this after months of silence) using the disaster that is MediaPipe (on Flutter) only to find out, with no notice, that you've finally bothered to fix this problem, WAS REALLY FUN.

Thank you for your response.

However, it is unfortunate that there was no announcement at all and that the priority was set at P4, which caused a lot of confusion. We believe that proper announcements and prioritization would be helpful to users, so we would appreciate it if you could consider this as a future issue.

I understand and respect that maintaining a free library is a lot of hard work, but I would like to raise the issue as a problem.

First of all thank you so much for your response!