Status Update
No update yet.
Comments
je...@gmail.com
Ignore.
ra...@google.com
ap...@google.com
It seems like we can repro the issue with embedded emulator. I used a stopwatch to record how long it takes for Google Sign-In page to load for the first time.
1, stand-alone emulator version (31.3.10): 4 seconds
2, embedded emulator (31.3.10): 15 seconds.
I am using Windows 10 with Intel Core i7-11850H@ 2.50GHz with 32GB RAM.
jo...@gmail.com
Ranjit is also able to repro the issue on Windows with Intel CPU. The problem is essentially in the first network connection. I asked Ranjit to help me with bisection mentioned in #3.
ra...@google.com
Time taken to show the Gmail Sign In page when AVD launched in embedded mode (Used Pixel_4a_API_31)
- Emulator Version : 31.3.9-8716652 about 17 seconds
- Emulator Version : 31.3.10-8779787 about 18 seconds
- Emulator Version : 31.3.10-8803787 about 20 seconds
di...@gmail.com
RE#6 Thanks Ranjit for helping out with bisecting. I think the issue probably existed before I checked in the network related CLs. We will keep bisecting.
dr...@gmail.com
According to ranjitkumar@, "It took about 28 seconds with Emulator version 31.3.6-8376731 and It took about 35 seconds for me with Emulator version 31.2.10-8420304" So we are probably chasing down a problem that might just be lingering for very long time.
And our observation is somewhat contradictory to what the user had reported because they believe it's a regression from 31.2.10.
ra...@google.com
@ranjitkumar
Here is the verification steps for this bug.
Host Operating System: Windows 10
Set up: Disable ipv6 manually in Windows by referring to the
Repro step: 1, Create AVD with API 31 and wipe data before each run.
2, Run AVD and make sure it is cold boot.
3, Immediately after the device boot completes, go to Gmail or Google and try to load the Google Sign In page.
4, Google Sign In page should take more than 1 minute to load for the buggy version (32.3.10).
Google Sign in page should take less than 20 seconds for the new version (with fix in
ar...@gmail.com
Thanks for the steps Weilun.
When I tried to load the sign in page after disabling the ipV6 manually it takes more than 2 minutes for the sign in page to show up with stable Emulator 31.3.10.
I will verify the fix in the upcoming Emulator build.
ra...@google.com
It takes about 20 seconds for the Gmail sign in page to show up on AVD(Pixel_4a_API_31) with Emulator 31.3.11-9032202 using ipv4 in stand alone mode.
OS : Windows 10
[Deleted User] <[Deleted User]>
128RM 8
mi...@charter.com
Doing so, forced our work manager to version up to 2.0.0, even though we are still declaring 1.x in our dependencies (Gradle automatically chooses the latest version to resolve dependency version conflicts).
This introduced the same crash and logs mentioned in earlier comments on this issue tracker ticket.
This crash bug was likely not fixed until 2.2.0-rc1:
So our attempted solution was to adopt the latest stable version of work manager (2.3.4 according to the documentation). However, with this new gradle build tools version, the dependency appears to be locked to 2.0.0 no matter what we try. Using "strictly" or "force" as described in the gradle documentation seems to have to no effect. And using exclude does not make much sense.
When using Gradle's dependency insight, we can see that for some reason after the migration, the dependency now has a new selection reason.
"Selected by rule : ENABLE_JETIFIER is enabled".
So at this point, it seems our options appear to be:
- Waiting for fix from Google or Gradle,
- Disabling jetifier and refactoring everything in order to avoid using AndroidX components.
- Revert our migration to Android Studio 3.6
- Remove work manager dependency altogether for the OS versions / device models affected
Hopefully this information helps, and hopefully it gets resolved soon!
il...@google.com
Re #15 - make sure you're using androidx.work and not the android.arch.work group ID in your dependency (using android.arch.work will cause the behavior you're seeing) as per the
mi...@charter.com
Yes, it works when migrating to the androidX group id. Perhaps the AndroidX migration guide needs to add this dependency as well:
Description
Version used: 2.0.0
Devices/Android versions reproduced on: reported on Android 5.0/5.1 (Play Console) / Android 4.4.2/4.4.4/5.0-5.1.1 (Firebase Crashlytics). Multiple devices from various manufacturers, including Samsung, Lenovo, LG, Motorola, HTC, Sony and Asus.
After updating our app from android.arch.work:work-runtime:1.0.0-rc02 to androidx.work:work-runtime:2.0.0, we're seeing crashes when WorkManager starts a job for a significant amount of our users, which doesn't make much sense because the code should be similar to the previous version but it is still a problem.
Unfortunately, we haven't been able to replicate the issue on our 4.4.2 test device. Because the issue is limited to Android versions where JobService isn't used (and the stack trace, see below), it seems like the issue is caused by WorkManager's scheduling and not the job itself.
The worker is set up by a periodic request:
Constraints workerConstraints = new Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build();
PeriodicWorkRequest userUpdateWorker = new PeriodicWorkRequest.Builder(UserUpdateWorker.class, 8, TimeUnit.HOURS)
.addTag(UserUpdateWorker.class.getName())
.setConstraints(workerConstraints)
.build();
WorkManager.getInstance().enqueue(userUpdateWorker);
Stack trace from the Crashlytics/Play Console crash reports:
Fatal Exception: java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 (has extras) } in androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver@42849958
at android.app.LoadedApk$ReceiverDispatcher$Args.run (LoadedApk.java:941)
at android.os.Handler.handleCallback (Handler.java:739)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:145)
at android.app.ActivityThread.main (ActivityThread.java:6117)
at java.lang.reflect.Method.invoke (Method.java)
at java.lang.reflect.Method.invoke (Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1194)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2ac263d0 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@320e0fc9[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution (ThreadPoolExecutor.java:2011)
at java.util.concurrent.ThreadPoolExecutor.reject (ThreadPoolExecutor.java:793)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute (ScheduledThreadPoolExecutor.java:298)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule (ScheduledThreadPoolExecutor.java:503)
at java.util.concurrent.Executors$DelegatedScheduledExecutorService.schedule (Executors.java:644)
at androidx.work.impl.background.systemalarm.WorkTimer.startTimer (WorkTimer.java:82)
at androidx.work.impl.background.systemalarm.DelayMetCommandHandler.onAllConstraintsMet (DelayMetCommandHandler.java:100)
at androidx.work.impl.constraints.WorkConstraintsTracker.onConstraintMet (WorkConstraintsTracker.java:150)
at androidx.work.impl.constraints.controllers.ConstraintController.updateCallback (ConstraintController.java:134)
at androidx.work.impl.constraints.controllers.ConstraintController.onConstraintChanged (ConstraintController.java:141)
at androidx.work.impl.constraints.trackers.ConstraintTracker.setState (ConstraintTracker.java:103)
at androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver.onReceive (NetworkStateTracker.java:170)
at android.app.LoadedApk$ReceiverDispatcher$Args.run (LoadedApk.java:931)
at android.os.Handler.handleCallback (Handler.java:739)
at android.os.Handler.dispatchMessage (Handler.java:95)
at android.os.Looper.loop (Looper.java:145)
at android.app.ActivityThread.main (ActivityThread.java:6117)
at java.lang.reflect.Method.invoke (Method.java)
at java.lang.reflect.Method.invoke (Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1194)