Status Update
Comments
jo...@gmail.com <jo...@gmail.com> #2
I was able to repro locally using the snippet in #1. The slide should never be applied to the content for state == 0, i.e. the green box.
Will take a look. Thanks for the repro steps, Jeremy.
je...@gmail.com <je...@gmail.com> #3
I'm having an issue with Compose navigation-animation which might be caused by this.
I have two screens: List and Details.
List screen uses default transitions.
Details screen uses the following transitions:
enterTransition = {
slideIntoContainer(
AnimatedContentScope.SlideDirection.Up,
animationSpec = tween(400)
)
},
popExitTransition = {
slideOutOfContainer(
AnimatedContentScope.SlideDirection.Down,
animationSpec = tween(200)
)
},
The video is showing the bug vs expected. It's hard to describe: after clicking the back button before the transition to the Details screen was completed, the List screen moves up a little.
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #4
Branch: androidx-main
commit 7e3b52b20e73c397019f474ab15eb8ea64a872d3
Author: Doris Liu <tianliu@google.com>
Date: Thu Sep 29 18:06:42 2022
Fix incorrect interruption animation in AnimatedContent
Bug: 238662479
Test: included
Change-Id: I86bb98800070f4584e30a1d0a4edec274b0c7e5c
A compose/animation/animation/integration-tests/animation-demos/src/main/java/androidx/compose/animation/demos/visualinspection/AnimatedContentWithInterruptions.kt
M compose/animation/animation/src/androidAndroidTest/kotlin/androidx/compose/animation/AnimatedContentTest.kt
M compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/EnterExitTransition.kt
M compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/AnimatedContent.kt
M compose/animation/animation/integration-tests/animation-demos/src/main/java/androidx/compose/animation/demos/AnimationDemos.kt
jo...@gmail.com <jo...@gmail.com> #5
The following release(s) address this bug:
androidx.compose.animation:animation:1.4.0-alpha01
ra...@google.com <ra...@google.com> #6
Why is this not released as a hotfix so stable users can get the bug fix right away?
di...@gmail.com <di...@gmail.com> #7
[Deleted User] <[Deleted User]> #8
dr...@gmail.com <dr...@gmail.com> #9
li...@gmail.com <li...@gmail.com> #10
Affected Android Version
62% Android 5
37% Android 4
1% Android 6
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@42203f30
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:769)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
Caused by java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@421dec00 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@4222d1a8[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:759)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5433)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
at dalvik.system.NativeStart.main(NativeStart.java)
ra...@google.com <ra...@google.com> #11
ar...@gmail.com <ar...@gmail.com> #12
ra...@google.com <ra...@google.com> #13
[Deleted User] <[Deleted User]> #14
used work manager version = '2.3.0'
implementation "androidx.work:work-runtime:2.3.0"
This is Top most crash in my App Account.
mi...@charter.com <mi...@charter.com> #15
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 <il...@google.com> #16
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 <mi...@charter.com> #17
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)