Fixed
Status Update
Comments
ra...@google.com <ra...@google.com> #2
That seems quite bad :/ weird.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
st...@baramundi.de <st...@baramundi.de> #3
Let me see what I can do on the reproduction as I am anyways blocked on this. I will try to extract out the DB module in a new project and see if it reproduces the issue.
ra...@google.com <ra...@google.com> #4
Attaching the sample project. When I run the project through the android studio or even command line, I see the described issue.
Try uncommenting room-compiler dependency from app's build.gradle, it does not have the issue because room compiler is not at work.
Try uncommenting room-compiler dependency from app's build.gradle, it does not have the issue because room compiler is not at work.
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #6
FYI. I see that if I comment out applying google-services plugin (at the end of the app's build.gradle file), that fixes the issue too. Hence, you may need to apply a google-services plugin with a json file to reproduce the issue.
Not sure what is going on but certainly, somethings are not playing well together.
Not sure what is going on but certainly, somethings are not playing well together.
st...@baramundi.de <st...@baramundi.de> #7
Above comment is NOT TRUE, it seems I did not do a code change after commenting out apply google-services plugin. That's why the build passed.
ra...@google.com <ra...@google.com> #8
Thanks for the sample app. I haven't gotten to the bottom of the issue yet but I wanted to give you an update and it does seem indeed that Room is taking a very long time to parse and understand your queries via the ANTLR generated parser that Room uses. I'm not sure what is so special about your queries that is causing this, but I'll comment back with an update once I find out. Sadly for now I don't have a recommendation on a workaround.
Description
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on: Moto G5s Plus, Android 7.1.1 / Huawai P20 lite, Android 8.0.0
We can reproduce a crash of the workmanager on some devices.
In our code we enqueue a UniqueWork with ExistingWorkPolicy.REPLACE, as soon as it finishes with State.SUCEEDED we enqueue it again. There is always only one job at the time.
After about 100 jobs the workmanager crashes with: java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs.
It looks like the workmanager does not prune the finished jobs fast enough, and they count as 'sheduled' job, even if they are finished?
The crash is reproducible on the Moto G5s Plus and Huawai P20 lite. But it behaves very inconsistent, sometimes it occurs on the first run, sometimes only after a few restarts of the app. But we cannot reproduce it on the Pixel 2 XL or the emulator.
Calling pruneWork() before enqueue() doesn't fix the problem.
Reducing the result lifetime by calling keepResultsForAtLeast(..) doesn't work as well.
We provided a sample app which triggers the issue.