IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

https://android-review.googlesource.com/1396827

Same issue here!

The worst thing for me, beyond the crash itself, is that after it happens, there is NO WAY to recover. I removed most of the WorkManager code, but it keeps crashing (since tries to do the jobs, which it can't, on every start).

Yeah, you have to clear app data or disable the content provider in your manifest.

I also just filed this: https://issuetracker.google.com/79950952

Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.

Sorry folks. This is a bug in alpha01. The fix should be a part of alpha02. Hang tight.

Do you know when the fix will be available?

We're aiming for later this week.

Awesome, I'll get to merge my branch! 😉

Hi, may I know,

1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?

2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?

Thanks.

No, you don't need to perform cleanup and no, there aren't any limits.

1. You don't need to perform any cleanup.  Completed OneTimeWorkRequests will not re-execute,
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time.  The rest will be queued up and sent when appropriate.  (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)

I still have this issue with 1.0.0-alpha02, like others it seems ( https://github.com/googlecodelabs/android-workmanager/issues/16 ).
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.

Here's a sample project that reproduces the issue. I use ADB Idea Plugin with the "ADB Restart App" feature to triggers the issue.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.

If your issue is specific to periodic work, I'd file a new issue since this one is a little different.