Also, if you remember any additional details about what happened, please let us know so that we can reproduce it. As we understand it, everything was working normally at first, and then it suddenly stopped working and still doesn't work even after reinstalling the app. Is that correct? Or did it never work properly from the beginning?
If possible, please also test the following scenario:
Tap a task in the widget (this should open the task view).
Tap Edit.
Change the flag.
Does the flag change work correctly in this case? Thanks.
Thank you for providing the information.
We are currently trying to reproduce the issue on an emulator configured similarly to your device, but so far we have not been able to replicate it. Since the app previously worked without this error, it is possible that the issue started occurring after a minor Android OS update on your device.
It is also possible that the problem may be resolved automatically after one of the upcoming minor OS updates for your device. If the issue disappears, please let us know.
In the meantime, we will continue working to reproduce the issue and identify the root cause.
Hello,
I would like to provide an update regarding the widget flag issue I reported in March.
The issue is still reproducible with MLO 5.0.0 on my current device:
Since my original report, I performed several controlled tests which may help isolate the problem.
1. A newly created widget initially displays the correct flagsI created a small MLO view called TestFlags, containing three tasks with different flags.
A newly created widget displaying this view is initially completely correct.
2. Updating task text does NOT corrupt the flagsStarting from a correct widget:
So a normal collection refresh by itself does not seem to cause the problem.
3. Changing a task flag DOES corrupt the widgetStarting again from a correct widget:
After this, the widget stays in the corrupted state.
This is reproducible.
4. A fresh widget can be corrupted by its first flag changeI kept an already corrupted widget and created a second widget displaying exactly the same TestFlags view.
Initially:
After changing one task flag:
Therefore this is not only an old/stale widget instance problem.
A completely fresh widget can enter the bad state as soon as a flag bitmap is changed.
5. Text and Star state remain correct even when flag images are wrongI can have two widgets displaying exactly the same MLO view at the same time:
If I click a Star in the corrupted widget:
This suggests that the task/row data itself is still being updated correctly, while the problem is specifically related to the flag images.
6. Logcat A/B testI also captured a controlled logcat comparing:
A. text-only modification → flags remain correct
and:
B. flag modification → flags become incorrect
Interestingly, both cases use essentially the same MLO widget update sequence.
For example, after a flag change I see:
There is therefore a second update approximately one second after the first one.
The text-only test also contains the same two-stage update mechanism, but does not corrupt the flags.
So the two-stage refresh itself does not appear to be sufficient to trigger the issue. The important difference seems to be when the flag bitmap content changes.
7. This matches the visual behavior from my March videoThe video I originally sent in March already shows an interesting pattern:
The approximately one-second timing is interesting because it closely matches the delayed sendUpdateMapViews / second onUpdate seen in the current logcat.
I am not claiming that this proves the exact cause, but it may be useful to investigate the interaction between:
In particular, it may be useful to check whether both update passes still contain the expected flag bitmap before they are sent to Android.
I can provide the full A/B logcat and dumpsys appwidget captures if useful.
Best regards,
Gwen
As a follow-up to my previous message, I am attaching the full diagnostic files from today's controlled tests:
The two dumpsys captures may be useful for comparing the same widget instance before and after the flag corruption.
In particular, the previously healthy widget had:
views_bitmap_memory = 337920
before the flag change, and:
views_bitmap_memory = 436224
after it became corrupted.
Other MLO widgets also increased their bitmap memory during the same update, so I do not consider this memory increase itself to be the cause or a unique signature of the corruption. I am including it only as an additional observable change associated with the bitmap update.
The full A/B logcat also contains the approximately one-second delayed sendUpdateMapViews / second onUpdate sequence mentioned in my previous message.
I hope these raw files can help identify whether the incorrect bitmap association already exists in the RemoteViews produced by MLO, or whether it occurs later in the Android widget handling.
Best regards,
Gwen