Fixed
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
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!
la...@gmail.com <la...@gmail.com> #3
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.
ja...@gmail.com <ja...@gmail.com> #4
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?
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #5
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?
ap...@google.com <ap...@google.com> #6
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.
il...@google.com <il...@google.com> #7
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?
Regarding the initial crash, do you have any logs for that?
ja...@gmail.com <ja...@gmail.com> #8
This is the log I have. Hope it helps. Will test 1.0.1 for you
Description
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: 7.0, 9.0 (Emulators)
According to
if a destination is opened with IMPLICIT deeplink and WITHOUT Intent.FLAG_ACTIVITY_NEW_TASK flag, then the destination is opened in the same task. After that if user clicks UP, then the actual parent should be recreated in a separate task, but it doesn't work. The UP button in this case does nothing, as well as manual navigateUp() method call.
I tried to modify the code to check both Toolbar and ActionBar approaches and also tried to create the NavHostFragment via xml and code. In all this cases, the behavior of UP button remained the same.
I attached a simple project that shows this situation. It contains 2 modules:
- app - an app with 2 fragments (root and child). The child fragment's destination supports a deeplink.
- deeplinkstarter - one button app, that starts an implicit deeplink to the child fragment of the 'app'.
I consider this as major defect because the library doesn't behave as it is explicitly said in the documentation.
Please, improve.