Fixed
Status Update
No update yet.
Comments
su...@google.com
Here's a sample app that shows this issue:
https://github.com/SimpleNexus/simplecallerid/
When you import it and update gradle version as the IDE suggests, it fails to build.
When you import it and update gradle version as the IDE suggests, it fails to build.
qu...@gmail.com
Hi there, thank you for reporting this issue.
This was a problem with the constraint layout library, which used attributes under declare styleables without defining them. This has been fixed in constraint layout version 2.0.0 beta 3. You can read more about the issue inhttps://issuetracker.google.com/136103084
This was a problem with the constraint layout library, which used attributes under declare styleables without defining them. This has been fixed in constraint layout version 2.0.0 beta 3. You can read more about the issue in
jb...@google.com
@3 Hello, I can't use beta 3 and beta 2, because of serious issues that I've reported about.
Here's about beta 3:
https://issuetracker.google.com/issues/143411144
Here's about beta 3:
qu...@gmail.com
You can workaround the missing attribute issue by *temporarily* adding it locally in your values/attrs.xml: <attr name="flow_horizontalSeparator"/>
jb...@google.com
@5 Just a single attribute?
But why is it considered missing only when I use this gradle version?
But why is it considered missing only when I use this gradle version?
qu...@gmail.com
In the linked issue https://buganizer.corp.google.com/issues/136103084 there is a full list of attributes to add, but in
The newer version of AGP included a fix to aapt2. The bug in aapt2 was that it accidentally allowed non-explicit definition of attributes, when it shouldn't have. Pre 3.0.0 it was disallowed, but the bug was only noticed recently.
The newer version of AGP included a fix to aapt2. The bug in aapt2 was that it accidentally allowed non-explicit definition of attributes, when it shouldn't have. Pre 3.0.0 it was disallowed, but the bug was only noticed recently.
jb...@google.com
@7 I wrote "..." because it was very long.
If you look at the video, you will see the rest...
Why are those attributes missing on a library? How could the library be made without having errors before publishing it?
If you look at the video, you will see the rest...
Why are those attributes missing on a library? How could the library be made without having errors before publishing it?
qu...@gmail.com
It was a bug, that went unnoticed because of a bug in aapt2. Both have been fixed now, but since https://issuetracker.google.com/issues/143411144 is preventing you from updating to the newest version of constraint layout, you can use the workaround mentioned in https://buganizer.corp.google.com/issues/136103084 until that one is fixed.
Add to your res/values/attrs.xml:
<resources>
<attr name="motionProgress"/>
<attr name="motionTarget"/>
<attr name="layout_marginBottom"/>
<attr name="motionPathRotate"/>
<attr name="duration"/>
<attr name="flow_verticalSeparator"/>
<attr name="flow_horizontalSeparator"/>
<attr name="waveDecay"/>
</resources>
(beta 3 of constraint layout includes these in its own values file, so then there's no need for adding them locally)
Add to your res/values/attrs.xml:
<resources>
<attr name="motionProgress"/>
<attr name="motionTarget"/>
<attr name="layout_marginBottom"/>
<attr name="motionPathRotate"/>
<attr name="duration"/>
<attr name="flow_verticalSeparator"/>
<attr name="flow_horizontalSeparator"/>
<attr name="waveDecay"/>
</resources>
(beta 3 of constraint layout includes these in its own values file, so then there's no need for adding them locally)
jb...@google.com
@9 I can't use the workaround on the link you've put, because I can't access this link.
Maybe I should join Google to make it easier? Seems I could be a good QA there ...
:)
I tried to add the attributes you wrote, while updating to com.android.tools.build:gradle:4.0.0-alpha04 .
Seems to fix it, but the same issue exists on this dependency :
https://github.com/JcMinarro/RoundKornerLayouts
I don't get yet how this could happen. Do those libraries have the attributes or not? How can gradle know what's missing?
How could a library use its attributes without declaring them in the resources files, and still be able to be built and used by other apps?
It doesn't make sense. The IDE should show a build error in this case, and even if it succeeds to build for some reason, it should crash...
No?
Maybe I should join Google to make it easier? Seems I could be a good QA there ...
:)
I tried to add the attributes you wrote, while updating to com.android.tools.build:gradle:4.0.0-alpha04 .
Seems to fix it, but the same issue exists on this dependency :
I don't get yet how this could happen. Do those libraries have the attributes or not? How can gradle know what's missing?
How could a library use its attributes without declaring them in the resources files, and still be able to be built and used by other apps?
It doesn't make sense. The IDE should show a build error in this case, and even if it succeeds to build for some reason, it should crash...
No?
qu...@gmail.com
Whoops, sorry. :) Here's the correct link: https://issuetracker.google.com/136103084
These libraries were build with the older version of AGP that had that bug, so that's why it went unnoticed. Now when someone tries to release a library without these attributes they will get a build error. The IDE is also warning about this now.
These libraries were build with the older version of AGP that had that bug, so that's why it went unnoticed. Now when someone tries to release a library without these attributes they will get a build error. The IDE is also warning about this now.
jb...@google.com
ap...@google.com
@11 I meant how on previous versions it was on the side of the library.
How could they use R.attr.some_attribute, if some_attribute wasn't declared anywhere?
How could they use R.attr.some_attribute, if some_attribute wasn't declared anywhere?
qu...@gmail.com
Seems fixed
sa...@google.com
@13 Thanks for confirming!
@12 The attribute that'd be accessed would be empty, and could lead to crashes at runtime. It was a bug in aapt2 that it didn't fail when it detected these at build time (as it does now).
@12 The attribute that'd be accessed would be empty, and could lead to crashes at runtime. It was a bug in aapt2 that it didn't fail when it detected these at build time (as it does now).
il...@google.com
re...@livedrive.com
@14 So now, suppose a library wishes to use an attribute, could it use something that's existing, should it use its own...?
na...@google.com
A library (or an app) can use its own resources or resources from any of its dependencies. The issue here was that attributes need to be declared explicitly, so if you had:
<declare-styleable name="foo">
<item type="attr" name="bar"/>
</declare-styleable>
the attr bar was not defined anywhere, yet is used here. It should be defined anywhere, either this file, this module, library or any of the dependencies, so you could have:
lib A depends on lib B
lib B contains:
<resources>
<attr name="bar" format="string"/>
</resources>
lib A contains:
<resources>
<declare-styleable name="foo">
<attr name="bar"/> //using the attr bar from lib B
</declare-styleable>
</resources>
And of course you can use your own resources as well, for example:
my module/main/res/values/styleables.xml:
<resources>
<attr name="bar" format="string"/>
<declare-styleable name="foo">
<attr name="bar"/> //using the attr bar defined above
</declare-styleable>
</resources>
And in the case where you're consuming a library affected by this bug (declare styleable using an attr without a definition) you can do the "hack" mentioned in previous comments:
app depends on lib
lib contains:
<resources>
<declare-styleable name="foo">
<attr name="bar"/> //trying to access not existing attr bar
</declare-styleable>
</resources>
app needs to contain:
<resources>
<attr name="bar" format="string"/> // fixing libs resources
</resources>
This issue has been fixed a while ago, and if a library owner tries to publish a library with missing resources, their build will fail during a release build, because the VerifyLibraryReleaseResources task will alert them to the missing attribute.
Hope this helps!
<declare-styleable name="foo">
<item type="attr" name="bar"/>
</declare-styleable>
the attr bar was not defined anywhere, yet is used here. It should be defined anywhere, either this file, this module, library or any of the dependencies, so you could have:
lib A depends on lib B
lib B contains:
<resources>
<attr name="bar" format="string"/>
</resources>
lib A contains:
<resources>
<declare-styleable name="foo">
<attr name="bar"/> //using the attr bar from lib B
</declare-styleable>
</resources>
And of course you can use your own resources as well, for example:
my module/main/res/values/styleables.xml:
<resources>
<attr name="bar" format="string"/>
<declare-styleable name="foo">
<attr name="bar"/> //using the attr bar defined above
</declare-styleable>
</resources>
And in the case where you're consuming a library affected by this bug (declare styleable using an attr without a definition) you can do the "hack" mentioned in previous comments:
app depends on lib
lib contains:
<resources>
<declare-styleable name="foo">
<attr name="bar"/> //trying to access not existing attr bar
</declare-styleable>
</resources>
app needs to contain:
<resources>
<attr name="bar" format="string"/> // fixing libs resources
</resources>
This issue has been fixed a while ago, and if a library owner tries to publish a library with missing resources, their build will fail during a release build, because the VerifyLibraryReleaseResources task will alert them to the missing attribute.
Hope this helps!
qu...@gmail.com
I see. So it needs to be defined.
But what if I use 2 libraries, and each declare the same attribute, while each has a different type for it?
Would it cause an issue? Or would it magically work somehow, letting me use both ?
But what if I use 2 libraries, and each declare the same attribute, while each has a different type for it?
Would it cause an issue? Or would it magically work somehow, letting me use both ?
il...@google.com
@17 Now this is where things get interesting. :)
Because in the current situation, resources do not have namespaces or packages, like Java/Kotlin classes do. Because of that, we merge all resources at the app level, with "overrides" or "overwrites" strategy of "higher one wins". This means if a resource is defined in an app and in a lib, at runtime (and compile time) the one from the app "wins". Similarly, when you have an app that depends on lib A and on lib B (separately, A does not depend on B and vice versa), and both A and B define the same resource, whichever one is higher in Gradle's dependency hierarchy wins (by the order the implementation/api dependency on them were added in build.gradle). Of course, if these conflict, e.g. have different formats, this mean that the one that gets overridden might result in unexpected behaviour (for example format="integer" getting overridden by format="string"). These are rare cases, but definitely possible.
In the future, we might introduce the concept of resource namespaces, which would mean that if both A and B define the same resource you can use both at the same time, accessing them using the full package name, e.g. lib.a.package:attr/foo and lib.b.package:attr/foo. However, this would not work yet, because, as I mentioned above, all resources are merged at app level and effectively have the same package name of the app (side note: exception is the "android:" namespace, as you might have noticed, e.g. "android:color/white" or similar). Either way, please follow release notes and updates in videos from future conferences (e.g. Google IO, Android Dev Summit) and be on the lookout for any upcoming features! :)
Because in the current situation, resources do not have namespaces or packages, like Java/Kotlin classes do. Because of that, we merge all resources at the app level, with "overrides" or "overwrites" strategy of "higher one wins". This means if a resource is defined in an app and in a lib, at runtime (and compile time) the one from the app "wins". Similarly, when you have an app that depends on lib A and on lib B (separately, A does not depend on B and vice versa), and both A and B define the same resource, whichever one is higher in Gradle's dependency hierarchy wins (by the order the implementation/api dependency on them were added in build.gradle). Of course, if these conflict, e.g. have different formats, this mean that the one that gets overridden might result in unexpected behaviour (for example format="integer" getting overridden by format="string"). These are rare cases, but definitely possible.
In the future, we might introduce the concept of resource namespaces, which would mean that if both A and B define the same resource you can use both at the same time, accessing them using the full package name, e.g. lib.a.package:attr/foo and lib.b.package:attr/foo. However, this would not work yet, because, as I mentioned above, all resources are merged at app level and effectively have the same package name of the app (side note: exception is the "android:" namespace, as you might have noticed, e.g. "android:color/white" or similar). Either way, please follow release notes and updates in videos from future conferences (e.g. Google IO, Android Dev Summit) and be on the lookout for any upcoming features! :)
qu...@gmail.com
Well, I haven't checked proguard files in a long time, but I can see they got somehow worse. I see hundreds of things that get mapped to JUST "d"!
mi...@gmail.com
I have:
androidx.lifecycle:lifecycle-runtime:2.6.0-alpha03
androidx.navigation:navigation-fragment-ktx:2.5.3
androidx.navigation:navigation-ui-ktx:2.5.3
and got crash:
java.lang.RuntimeException: Unable to destroy activity {<package name hidden by me>.MainActivity}: java.lang.IllegalStateException: no event down from INITIALIZED in component androidx.navigation.NavBackStackEntry
with reason:
Caused by: java.lang.IllegalStateException: no event down from INITIALIZED in component androidx.navigation.NavBackStackEntry
(I see that issue is connected with NavBackStackEntry thanks update to :lifecycle-runtime:2.6.0-alpha03)
In my MainActivity there is NavHostFragment with NavController and queue of NavBackStackEntries inside.
When I navigate from Acitivity to some fragment using code below:
Log.i("showSomeFragment","state just before navigate: ${findNavController().currentBackStackEntry?.lifecycle?.currentState}")
findNavController().navigate(
MainNavgraphDirections.actionShowSomeFragment(...)
)
Log shows that NavBackStackEntry's lifecycle's is in state RESUMED, but in target fragment's onCreate (after navigation)
NavBackStackEntry's lifecycle's is in state INITIALIZED
Therefore, when I minimize app being on that fragment - app crashes, because I go from INITIALIZED to DESTROYED state (skipping other states).
When I navigate similarly between fragments (using findNavController().navigate in fragment, not in activity) ->
NavBackStackEntry's lifecycle's state is in state RESUMED in target's fragment onCreate an there is no crash after minimize.
Do I don't understand something/do you have any hints for that, or there is bug in navigation library?
For clarity: Yes, I understand that when we go from INITIALIZED directly to DESTROYED state - error SHOULD be thrown
androidx.lifecycle:lifecycle-runtime:2.6.0-alpha03
androidx.navigation:navigation-fragment-ktx:2.5.3
androidx.navigation:navigation-ui-ktx:2.5.3
and got crash:
java.lang.RuntimeException: Unable to destroy activity {<package name hidden by me>.MainActivity}: java.lang.IllegalStateException: no event down from INITIALIZED in component androidx.navigation.NavBackStackEntry
with reason:
Caused by: java.lang.IllegalStateException: no event down from INITIALIZED in component androidx.navigation.NavBackStackEntry
(I see that issue is connected with NavBackStackEntry thanks update to :lifecycle-runtime:2.6.0-alpha03)
In my MainActivity there is NavHostFragment with NavController and queue of NavBackStackEntries inside.
When I navigate from Acitivity to some fragment using code below:
Log.i("showSomeFragment","state just before navigate: ${findNavController().currentBackStackEntry?.lifecycle?.currentState}")
findNavController().navigate(
MainNavgraphDirections.actionShowSomeFragment(...)
)
Log shows that NavBackStackEntry's lifecycle's is in state RESUMED, but in target fragment's onCreate (after navigation)
NavBackStackEntry's lifecycle's is in state INITIALIZED
Therefore, when I minimize app being on that fragment - app crashes, because I go from INITIALIZED to DESTROYED state (skipping other states).
When I navigate similarly between fragments (using findNavController().navigate in fragment, not in activity) ->
NavBackStackEntry's lifecycle's state is in state RESUMED in target's fragment onCreate an there is no crash after minimize.
Do I don't understand something/do you have any hints for that, or there is bug in navigation library?
For clarity: Yes, I understand that when we go from INITIALIZED directly to DESTROYED state - error SHOULD be thrown
fr...@gmail.com
Exactly same problem as
il...@google.com
Re
pe...@gmail.com
I have a same problem
Fatal Exception: java.lang.RuntimeException: Unable to destroy activity {path to MainActivity}: java.lang.IllegalStateException: no event down from INITIALIZED
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:5253)
at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:5282)
at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:44)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2146)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:8057)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
Fatal Exception: java.lang.RuntimeException: Unable to destroy activity {path to MainActivity}: java.lang.IllegalStateException: no event down from INITIALIZED
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:5253)
at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:5282)
at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:44)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2146)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:8057)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)
il...@google.com
Re
en...@gmail.com
Comment has been deleted.
ah...@gmail.com
Comment has been deleted.
pu...@grabtaxi.com
Comment has been deleted.
pu...@grabtaxi.com
Hi also having the same problem here, and not able to reproduce it locally, seems from the log that it happened when onBackPressed is triggered. I have tried to put dismiss inside init function of my dialog fragment also not able to reproduce it. Is there any thing I can look into?
I'm using
Lifecycle 2.6.1, happened as well in 2.5.1
androidx.lifecycle.LifecycleRegistry.moveToState (LifecycleRegistry.kt:126)
androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent (LifecycleRegistry.kt:119)
androidx.activity.ComponentDialog.onStop (ComponentDialog.kt:87)
androidx.appcompat.app.AppCompatDialog.onStop (AppCompatDialog.java:134)
android.app.Dialog.dismissDialog (Dialog.java:382)
android.app.Dialog.dismiss (Dialog.java:358)
androidx.appcompat.app.AppCompatDialog.dismiss (AppCompatDialog.java:140)
android.app.Dialog.cancel (Dialog.java:1269)
android.app.Dialog.onBackPressed (Dialog.java:684)
androidx.activity.ComponentDialog.onBackPressedDispatcher$lambda$1 (ComponentDialog.kt:94)
androidx.activity.OnBackPressedDispatcher.onBackPressed (OnBackPressedDispatcher.kt:216)
androidx.activity.ComponentDialog.onBackPressed (ComponentDialog.kt:99)
android.app.Dialog.onKeyUp (Dialog.java:661)
android.view.KeyEvent.dispatch (KeyEvent.java:2729)
android.app.Dialog.dispatchKeyEvent (Dialog.java:814)
androidx.appcompat.app.AppCompatDialog.superDispatchKeyEvent (AppCompatDialog.java:209)
androidx.core.view.KeyEventDispatcher.dispatchKeyEvent (KeyEventDispatcher.java:86)
androidx.appcompat.app.AppCompatDialog.dispatchKeyEvent (AppCompatDialog.java:215)
androidx.appcompat.view.WindowCallbackWrapper.dispatchKeyEvent (WindowCallbackWrapper.java:60)
androidx.appcompat.app.AppCompatDelegateImpl$AppCompatWindowCallback.dispatchKeyEvent (AppCompatDelegateImpl.java:3413)
com.android.internal.policy.DecorView.dispatchKeyEvent (DecorView.java:346)
android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent (ViewRootImpl.java:5214)
android.view.ViewRootImpl$ViewPostImeInputStage.onProcess (ViewRootImpl.java:5082)
android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:4601)
android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:4654)
android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:4620)
android.view.ViewRootImpl$AsyncInputStage.forward (ViewRootImpl.java:4760)
android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:4628)
android.view.ViewRootImpl$AsyncInputStage.apply (ViewRootImpl.java:4817)
android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:4601)
android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:4654)
android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:4620)
android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:4628)
android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:4601)
android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:4654)
android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:4620)
android.view.ViewRootImpl$AsyncInputStage.forward (ViewRootImpl.java:4793)
android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent (ViewRootImpl.java:4956)
android.view.inputmethod.InputMethodManager$PendingEvent.run (InputMethodManager.java:2580)
android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback (InputMethodManager.java:2090)
android.view.inputmethod.InputMethodManager.finishedInputEvent (InputMethodManager.java:2081)
android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished (InputMethodManager.java:2557)
android.view.InputEventSender.dispatchInputEventFinished (InputEventSender.java:141)
android.os.MessageQueue.nativePollOnce (MessageQueue.java)
android.os.MessageQueue.next (MessageQueue.java:326)
android.os.Looper.loop (Looper.java:165)
android.app.ActivityThread.main (ActivityThread.java:6861)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:547)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:873)
Description
Fatal Exception: java.lang.IllegalStateException: no event down from INITIALIZED
at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:35)
at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:9)
at androidx.fragment.app.Fragment.performDestroy(Fragment.java:9)
at androidx.fragment.app.FragmentStateManager.destroy(FragmentStateManager.java:147)
at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:266)
at androidx.fragment.app.SpecialEffectsController$FragmentStateManagerOperation.complete(SpecialEffectsController.java:5)
at androidx.fragment.app.SpecialEffectsController$Operation.cancel(SpecialEffectsController.java:18)
at androidx.fragment.app.SpecialEffectsController.forceCompleteAllOperations(SpecialEffectsController.java:228)
at androidx.fragment.app.SpecialEffectsController.executePendingOperations(SpecialEffectsController.java:14)
at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:268)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:81)
at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:21)
at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:38)
at androidx.fragment.app.FragmentManager.dispatchActivityCreated(FragmentManager.java:11)
at androidx.fragment.app.FragmentController.dispatchActivityCreated(FragmentController.java:4)
at androidx.fragment.app.FragmentActivity.onStart(FragmentActivity.java:20)
at androidx.appcompat.app.AppCompatActivity.onStart(AppCompatActivity.java)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1435)
at android.app.Activity.performStart(Activity.java:8231)
at android.app.ActivityThread.handleStartActivity(ActivityThread.java:3872)
at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:221)
at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2336)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8653)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130
or
Fatal Exception: java.lang.IllegalStateException: no event down from INITIALIZED
at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:35)
at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:9)
at androidx.fragment.app.Fragment.performDestroy(Fragment.java:9)
at androidx.fragment.app.FragmentStateManager.destroy(FragmentStateManager.java:147)
at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:266)
at androidx.fragment.app.SpecialEffectsController$FragmentStateManagerOperation.complete(SpecialEffectsController.java:5)
at androidx.fragment.app.SpecialEffectsController$Operation.cancel(SpecialEffectsController.java:18)
at androidx.fragment.app.SpecialEffectsController.forceCompleteAllOperations(SpecialEffectsController.java:228)
at androidx.fragment.app.SpecialEffectsController.executePendingOperations(SpecialEffectsController.java:14)
at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:268)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:81)
at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:21)
at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:38)
at androidx.fragment.app.FragmentManager.dispatchActivityCreated(FragmentManager.java:11)
at androidx.fragment.app.FragmentController.dispatchActivityCreated(FragmentController.java:4)
at androidx.fragment.app.FragmentActivity.onStart(FragmentActivity.java:20)
at androidx.appcompat.app.AppCompatActivity.onStart(AppCompatActivity.java)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1391)
at android.app.Activity.performStart(Activity.java:7348)
at android.app.ActivityThread.handleStartActivity(ActivityThread.java:3138)
at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:180)
at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:165)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:142)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:70)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1948)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7050)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:965)
(about 50 different lines with the same stack)
Since it comes 100% from Google code there's nothing we can do about it, unless of course someone could explain what " no event down from INITIALIZED" means...