Status Update
Comments
ra...@google.com <ra...@google.com> #2
set title before set Toolbar as ActionBar
Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);
toolbar.settitle("ddidid");
setSupportActionBar(toolbar);
ra...@google.com <ra...@google.com> #3
Thanks for the answer :-).
I am searching for a solution to change the title some times (E. G. changing view). Or should i use for every fragmant an own toolbar?
lb...@gmail.com <lb...@gmail.com> #4
lb...@gmail.com <lb...@gmail.com> #5
ra...@google.com <ra...@google.com> #6
ra...@google.com <ra...@google.com> #7
ra...@google.com <ra...@google.com> #8
Turns out the WorkManager sample app also works as expected barring a bug (in the sample app) where a permission denial causes a Worker
to fail.
02-20 13:18:27.402 1897 3914 W ActivityManager: Permission Denial: opening provider com.google.android.apps.photos.contentprovider.impl.MediaContentProvider from ProcessRecord{523d160 12901:com.example.background/u0a134} (pid=12901, uid=10134) that is not exported from UID 10115
02-20 13:18:27.407 12901 13144 D WM-WorkerWrapper: com.example.background.workers.BlurWorker returned a Failure {mOutputData=Data {}} result.
02-20 13:18:27.410 12901 13144 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=e447146a-2f54-4c8e-8044-09ba89e0ad69, tags={ com.example.background.workers.BlurWorker } ]
lb...@gmail.com <lb...@gmail.com> #9
Doesn't seem like you've tested the sample I've put, otherwise you would have seen them.
The original code of the sample performs the work right away.
What I did is to add a delay of some seconds to let me remove the app from the recent tasks before it gets triggered, and I also added logs (to print "doWork" right when it starts) inside to see whether or not it works.
Here, attached a new video. Please take a good look at what's happening.
Not only that, but I've made a much simpler sample. A worker that doesn't do anything but write to the logs.
Also attached a video for it, including on emulator and Pixel 4 (with Android 11!).
Sometimes Google makes too fancy and complex samples. I think it's better to create tiny samples instead.
That's more proof than you need.
lb...@gmail.com <lb...@gmail.com> #10
Google's sample is too much here.
ra...@google.com <ra...@google.com> #11
I tried using your sample and this is what I saw:
02-20 15:31:11.445 14178 14178 D WM-PackageManagerHelper: androidx.work.impl.background.systemjob.SystemJobService enabled
02-20 15:31:11.445 14178 14178 D WM-Schedulers: Created SystemJobScheduler and enabled SystemJobService
02-20 15:31:11.453 14178 16954 D WM-ForceStopRunnable: Performing cleanup operations.
02-20 15:31:11.458 14178 14178 D AppLog : scheduled
02-20 15:31:11.523 14178 16955 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.RescheduleReceiver enabled
02-20 15:31:11.530 14178 16955 D WM-SystemJobScheduler: Scheduling work ID 72c8139a-40cb-4ad6-9e5b-86b844661923 Job ID 0
At this point I swipe to dismissed the app from recents.
A couple of seconds later:
02-20 15:31:21.700 16326 16326 D WM-PackageManagerHelper: androidx.work.impl.background.systemjob.SystemJobService enabled
02-20 15:31:21.700 16326 16326 D WM-Schedulers: Created SystemJobScheduler and enabled SystemJobService
02-20 15:31:21.704 16326 17009 D WM-ForceStopRunnable: Performing cleanup operations.
02-20 15:31:21.705 16326 16326 D WM-SystemJobService: onStartJob for 72c8139a-40cb-4ad6-9e5b-86b844661923
02-20 15:31:21.735 16326 17010 D WM-Processor: Processor: processing 72c8139a-40cb-4ad6-9e5b-86b844661923
02-20 15:31:21.744 16326 17011 D AppLog : SampleWorker
02-20 15:31:21.747 16326 16326 D WM-WorkerWrapper: Starting work for com.lb.myapplication.SampleWorker
02-20 15:31:21.748 16326 17012 D AppLog : doWork
02-20 15:31:21.749 16326 17011 D WM-WorkerWrapper: com.lb.myapplication.SampleWorker returned a Success {mOutputData=Data {}} result.
02-20 15:31:21.751 16326 17011 I WM-WorkerWrapper: Worker result SUCCESS for Work [ id=72c8139a-40cb-4ad6-9e5b-86b844661923, tags={ com.lb.myapplication.SampleWorker, SampleWorker } ]
02-20 15:31:21.755 16326 17011 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.RescheduleReceiver disabled
02-20 15:31:21.755 16326 16326 D WM-Processor: Processor 72c8139a-40cb-4ad6-9e5b-86b844661923 executed; reschedule = false
02-20 15:31:21.755 16326 16326 D WM-SystemJobService: 72c8139a-40cb-4ad6-9e5b-86b844661923 executed on JobScheduler
02-20 15:31:21.759 16326 17011 D WM-GreedyScheduler: Cancelling work ID 72c8139a-40cb-4ad6-9e5b-86b844661923
02-20 15:31:21.761 16326 17011 D WM-Processor: Processor stopping background work 72c8139a-40cb-4ad6-9e5b-86b844661923
02-20 15:31:21.761 16326 17011 D WM-Processor: WorkerWrapper could not be found for 72c8139a-40cb-4ad6-9e5b-86b844661923
02-20 15:31:21.761 16326 17011 D WM-StopWorkRunnable: StopWorkRunnable for 72c8139a-40cb-4ad6-9e5b-86b844661923; Processor.stopWork = false
Everything works as expected.
lb...@gmail.com <lb...@gmail.com> #12
You also didn't explain what I've shown you.
Show me a video of what you do, as I did. Filter by "applog" in logcat.
I'm sure you didn't try like I did, and that this behavior is what caused various alarm clock apps to stop working for AlarmManager class too, including Timely app that Google itself has bought, and now doesn't work well due to bad backward-compatibility.
Here, a new video. Filtering of showing just "doWork".
Look how long I've waited. Nothing happens.
ra...@google.com <ra...@google.com> #13
I have a couple of suggestions that might help:
- Enable verbose logging using WorkManager's on-demand initialization. Switch to the latest stable version
2.3.2
. - Disable the default content provider based initialization.
- Use the command line and switch to
adb logcat
to get more information. This is because once the process is dead - Studio sometimes does not update the logcat view. This is especially important because you are using swipe to dismiss.
Once you do this, you will start seeing verbose logs which are super useful. That will help you narrow down things.
Your video continues to look at the Logcat view after the process is dead, and therefore not useful.
ra...@google.com <ra...@google.com> #14
If you have more information, please add a comment and I can re-open the bug.
lb...@gmail.com <lb...@gmail.com> #15
Also, updating to it didn't help.
What do you mean by "Disable the default content provider based initialization." ? I don't have any on the sample.
There is no need to use command line for adb. I can already see what's there on Android Studio. I already shown on video that I disabled filtering by process. It should show all logs.
It's incorrect that it "continues to look at the Logcat view after the process is dead," . I already set it to show all logs, without looking at the process. It says "no filters".
I showed that the process is dead, as proof that it doesn't get started.
Here, again, video of 2.3.2. No filters of processes, verbose logging.
Also attached the logs file. You can search there for "dowork".
Please show me a video of what you do. I don't think you've tested it well.
ra...@google.com <ra...@google.com> #16
<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove" />
This is what I meant when i was talking about removing the default initializer.
lb...@gmail.com <lb...@gmail.com> #17
I've made the app show a toast inside the worker.
If this fails to convince you, I can make the sample show a notification instead.
Watch.
lb...@gmail.com <lb...@gmail.com> #18
And if you say that the IDE has a bug with logs, please fix it too. Logs are very important to find issues.
pm...@google.com <pm...@google.com> #19
lb...@gmail.com <lb...@gmail.com> #20
It has nothing to do with the codelab anymore.
It only has a toast and logs.
Please check it out.
pm...@google.com <pm...@google.com> #21
I made a test with your application and it works.
The only thing that may explain why you see something different is if you're launching the app from Android Studio and then swaping it out. In this case (because the app was launched from Android Studio) it behaves differently.
If you launch the application manually, from the device launcher, swiping it out you can see that your Worker is executed correctly after 10s. I've also attached a modified version of the app that enables WorkManager logging so you can get additional information on what WorkManager does.
lb...@gmail.com <lb...@gmail.com> #22
Here, attached a new video (of your own project), showing without letting Android Studio start it, and only from the emulator's launcher itself.
Please stop closing this and fix this issue.
I've shown it to you passing all the obstacles you've written.
It doesn't work!
Add whatever that you want to the worker now. Toast, notifications, writing to file,...
I can show you again and again it doesn't work.
lb...@gmail.com <lb...@gmail.com> #23
Why do you say it works without showing me it works?
I've shown you multiple times it doesn't.
lb...@gmail.com <lb...@gmail.com> #24
Alarms get removed completely.
cu...@gmail.com <cu...@gmail.com> #25
WorkerManager dies as soon as the app is swiped up after being launched from android studio.
if this comment is true: "In this case (because the app was launched from Android Studio) it behaves differently.", fix it. put it in BIG BOLD LETTERS in the WorkManager documentation. Create a blog post about it.
But having to deep dive into issue tracker to find why on earth are our quite vital, and already heavily mermed due to arbitrary power policies on OEM's services being killed is incredibly not okay.
jo...@gmail.com <jo...@gmail.com> #26
Nexus 5x
Api 29
ne...@gmail.com <ne...@gmail.com> #27
even lunching the app from the device itself didn't fix the issue
Samsung A50 , Android 10
Description
Version used:
implementation "androidx.work:work-runtime:2.3.1"
Devices/Android versions reproduced on:
Pixel 4 with Android 10/11 and emulator with Android 10
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).
Both here: