Status Update
Comments
ya...@gmail.com <ya...@gmail.com> #2
I also tried moving sharedElement to BoxWithConstraints (rather than in its content), but did not help.
So the layout hierarchy looks like this (with more details and with "..." I replaced series of "normal" layouts):
NavHost -> ... -> AnimatedVisibility -> ... -> BoxWithConstraints with sharedElement -> some content
\> ... -> AnimatedVisibility -> ... -> LazyList -> ... -> Animated Visibility -> Selection container -> BoxWithConstraints with sharedElement -> some content
Any ideas?
su...@google.com <su...@google.com>
ap...@google.com <ap...@google.com> #3
In your BoxWithConstraints
do you do any conditional composition? Things like:
if (constraintsExceedsCertainThreshold) composeSomeContent() else someOtherContent()
ya...@gmail.com <ya...@gmail.com> #4
Also note `sharedElement` is put on `BoxWithContraints` now, not on the content.
Thanks!
su...@google.com <su...@google.com> #5
Based on the stacktrace, it seems like the item in question is composed but never placed. Do you use custom precompose
or prefetch logic in your lazy list?
ya...@gmail.com <ya...@gmail.com> #6
There is also one `AnimatedContent` above the `BoxWithConstraints`. Could this cause issues?
Thank you for looking into this.
su...@google.com <su...@google.com> #7
The AnimatedContent never skips measuring/placing children after it composes them. So I don't expect that to be the issue.
Since you mentioned the modifier is on BoxWithConstraints
rather than on the children of BoxWithConstraints
, my guess is it's most likely related to LazyList.
Can you clarify what type of LazyList you are using? Is it LazyColumn/Row or LazyGrid, or something else?
ya...@gmail.com <ya...@gmail.com> #8
It's a LazyColumn.
su...@google.com <su...@google.com> #9
One interesting observation is that this stack trace did not seem to come from the ComposeView
with our app's Activity
content. Because I did a release with copy pasted setContent
+ ComposeView
subclass that is catching exceptions in dispatchDraw
and it did not catch this crash. Is the animations framework doing content composition outside the app's composition context? One note: at the time I tried this exception catching, sharedElement
was applied to the content of BoxWithConstraints
(rather than to the BoxWithConstraints
itself), but I don't think this would have caused the exception catching not to work.
ya...@gmail.com <ya...@gmail.com> #10
Hey, sorry to insist - any more ideas here?
su...@google.com <su...@google.com> #11
I'm investigating what would cause items to be composed but not placed.
We'll submit a fix in shared element in 1.8 to account for that scenario if that's an intended behavior.
Have you tried a recent 1.8 release and see if it's reproducible?
zh...@kuaishou.com <zh...@kuaishou.com> #12
Thank you!
Unfortunately we cannot release publicly with 1.8 alpha, and we never reproed this issue locally even with 1.7.x.
si...@gmail.com <si...@gmail.com> #13
I'll prepare a fix to account for the use case where content may be composed but never participate in either measurement or placement. Keep in mind, the fix likely will only land in 1.8.
mr...@gmail.com <mr...@gmail.com> #14
Awesome, thank you! If there's any chance to have it in 1.7.6, would be absolutely amazing, but no worries if not. Thanks a lot again for the help!
bh...@gmail.com <bh...@gmail.com> #15
Project: platform/frameworks/support
Branch: androidx-main
Author: Doris Liu <
Link:
Require shared element to draw in place before drawing in overlay
Expand for full commit details
Require shared element to draw in place before drawing in overlay
This change fixes a rare issue where a shared element is composed
in both incoming and outgoing content, but measured and placed in
neither. The fix involves checking the shared element has been
drawn for at least frame before drawing it in the overlay. This
accounts for not only the requirement to measure and place shared
elements, but also ensured that when the draw is skipped by
a parent, shared element will not draw.
Fixes: 371802474
Test: New test added
Change-Id: I35108ce255cf4728a9ca3ef7834d6962abcc94c0
Files:
- M
compose/animation/animation/src/androidInstrumentedTest/kotlin/androidx/compose/animation/SharedTransitionTest.kt
- M
compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/SharedContentNode.kt
- M
compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/SharedElement.kt
Hash: baae6769d3323d141b17e0d916323cf6487034ea
Date: Wed Nov 13 15:27:39 2024
pt...@gmail.com <pt...@gmail.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.animation:animation:1.8.0-alpha07
androidx.compose.animation:animation-android:1.8.0-alpha07
androidx.compose.animation:animation-jvmstubs:1.8.0-alpha07
androidx.compose.animation:animation-linuxx64stubs:1.8.0-alpha07
ah...@safarifoneict.com <ah...@safarifoneict.com> #17
ds...@servicetitan.com <ds...@servicetitan.com> #18
if (!Application.class.equals(getApplication().getClass())) {
// During auto-backup, we don't get a custom Application subclass. This code path
// indicates we are either performing auto-backup or the user never used a custom
// Application class (or both).
throw new IllegalStateException("WorkManager needs to be initialized via a "
+ "ContentProvider#onCreate() or an Application#onCreate().");
}
li...@gmail.com <li...@gmail.com> #19
this issue on workManager 2.5.0 when initialize WorkManager in background thread, bring it back to UI thread
[Deleted User] <[Deleted User]> #20
Stacktrace:
Caused by java.lang.IllegalStateException
WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:73)
android.app.ActivityThread.handleCreateService (ActivityThread.java:3833)
android.app.ActivityThread.access$1500 (ActivityThread.java:229)
android.app.ActivityThread$H.handleMessage (ActivityThread.java:1881)
android.os.Handler.dispatchMessage (Handler.java:106)
android.os.Looper.loop (Looper.java:226)
android.app.ActivityThread.main (ActivityThread.java:7178)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:503)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:942)
For now, the device affected is
android 9 Realme.
Work Manager version: 2.6.0
d4...@gmail.com <d4...@gmail.com> #21
Still happening with WorkManager 2.7.1 Samsung Galaxy S21 Ultra 5G Android 12 (SDK 31)
java.lang.RuntimeException:
at android.app.ActivityThread.handleCreateService (ActivityThread.java:4953)
at android.app.ActivityThread.access$1900 (ActivityThread.java:310)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2300)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8669)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by: java.lang.IllegalStateException:
at androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:158)
at androidx.work.impl.foreground.SystemForegroundDispatcher.<init> (SystemForegroundDispatcher.java:105)
at androidx.work.impl.foreground.SystemForegroundService.initializeDispatcher (SystemForegroundService.java:96)
at androidx.work.impl.foreground.SystemForegroundService.onCreate (SystemForegroundService.java:59)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:4940)
at android.app.ActivityThread.access$1900 (ActivityThread.java:310)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2300)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8669)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
ps...@pinterest.com <ps...@pinterest.com> #22
We recently moved our WorkManager initialization to the default pattern and have started seeing this same issue.
java.lang.RuntimeException: Unable to create service androidx.work.impl.background.systemjob.SystemJobService: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
at android.app.ActivityThread.handleCreateService(ActivityThread.java:5073)
at android.app.ActivityThread.-$$Nest$mhandleCreateService(Unknown)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2425)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8741)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
Caused by: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
at androidx.work.impl.background.systemjob.SystemJobService.onCreate(SystemJobService:73)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:5060)
at android.app.ActivityThread.-$$Nest$mhandleCreateService(Unknown)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2425)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8741)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
ra...@google.com <ra...@google.com> #23
I would check to make sure that the app is not a multi-process app. If it is, you will need your Application
to additionally sub-class Configuration.Provider
or additionally define a second provider for the other process.
Description
Version used: 2.1.0-beta01
Devices/Android versions reproduced on: Android 7.1, Android 8.1, Android 9 / W_P200 (W_P200), Xperia Z5 Compact (E5823), ZenFone, Xperia Z5 Compact, V30, FP2, ...
I'm not able to reproduce but I can see a significant number of crash at production live
java.lang.RuntimeException:
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3265)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1598)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:241)
at android.app.ActivityThread.main (ActivityThread.java:6274)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:776)
Caused by: java.lang.IllegalStateException:
at androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:142)
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:53)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3255)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1598)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:241)
at android.app.ActivityThread.main (ActivityThread.java:6274)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:776)
My detailed finding is as follow. So far, I have no idea how it happens. I cross post at
We are using the following WorkManager library
def work_version = "2.1.0-beta01"
implementation "androidx.work:work-runtime:$work_version"
Our Application class is being modified as follow so that it will work well with WorkManager
public class WeNoteApplication extends MultiDexApplication implements DefaultLifecycleObserver, Configuration.Provider {
private static WeNoteApplication me;
@Override
public void onCreate() {
super.onCreate();
me = this;
...
}
public static WeNoteApplication instance() {
return me;
}
@NonNull
@Override
public Configuration getWorkManagerConfiguration() {
return new Configuration.Builder()
.build();
}
}
We do not add any WorkManager related code in AndroidManifest.xml. We solely rely on Default initialization
This is how we construct WorkManager
public static WorkManager getWorkManager() {
WeNoteApplication weNoteApplication = WeNoteApplication.instance();
return WorkManager.getInstance(weNoteApplication);
}
The above function is called in 4 different places
Activity
Fragment
BroadcastReceiver
IntentService
Still, we receive the following crash log in production. It happens in Android 7.1, Android 8.1, Android 9 (so far)
java.lang.RuntimeException:
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3265)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1598)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:241)
at android.app.ActivityThread.main (ActivityThread.java:6274)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:776)
Caused by: java.lang.IllegalStateException:
at androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:142)
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:53)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3255)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1598)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:241)
at android.app.ActivityThread.main (ActivityThread.java:6274)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:776)
As you can see in the crash, the crash origins from WorkManager internally, and not from our app.
By looking at
WorkManagerImpl
/**
* Retrieves the singleton instance of {@link WorkManagerImpl}.
*
* @param context A context for on-demand initialization.
* @return The singleton instance of {@link WorkManagerImpl}
* @hide
*/
@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
public static @NonNull WorkManagerImpl getInstance(@NonNull Context context) {
synchronized (sLock) {
WorkManagerImpl instance = getInstance();
if (instance == null) {
Context appContext = context.getApplicationContext();
if (appContext instanceof Configuration.Provider) {
initialize(
appContext,
((Configuration.Provider) appContext).getWorkManagerConfiguration());
instance = getInstance(appContext);
} else {
throw new IllegalStateException("WorkManager is not initialized properly. You "
+ "have explicitly disabled WorkManagerInitializer in your manifest, "
+ "have not manually called WorkManager#initialize at this point, and "
+ "your Application does not implement Configuration.Provider.");
}
There are 2 possibilities of the crash
appContext is null. (How can it be null?)
appContext does not implement Configuration.Provider (But we already implement in our WeNoteApplication?)
To figure out how context is being passed to WorkManagerImpl from SystemJobService, we look at the code of androidx.work.impl.background.systemjob.SystemJobService.onCreate
SystemJobService
@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
@RequiresApi(WorkManagerImpl.MIN_JOB_SCHEDULER_API_LEVEL)
public class SystemJobService extends JobService implements ExecutionListener {
private static final String TAG = Logger.tagWithPrefix("SystemJobService");
private WorkManagerImpl mWorkManagerImpl;
private final Map<String, JobParameters> mJobParameters = new HashMap<>();
@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
Look fine at first sight. But, why WorkManagerImpl cannot obtain Configuration.Provider although I already implement Configuration.Provider in my Application? Is it because I'm using MultiDexApplication?