Task flag doesn't update on the MLO widget

199 views
Skip to first unread message

Gwen Chenouard

unread,
Mar 6, 2026, 1:56:15 AMMar 6
to MyLifeOrganized
Hello,

Since a few weeks, I notices a problem with tasks flags in the MLO widget. It doesn't update when I change it. The widget show another flag instead. 
The flag is OK on the MLO app, but not on the widget.
The right flag is back after a few hours.

I tried to clear app cache, to reinstall app, to create a new profile: same problem.

I made a video so you can see it.

MLO 5
Pixel 9, Android 16 build BP4A.260205.002.A1

Screen-20260306-071916-1772777910608-1-1.mp4

Alyona (MLO Support)

unread,
Mar 8, 2026, 6:44:29 AMMar 8
to MyLifeOrganized
Hello, 

Thanks for flagging this. 

We haven't been able to reproduce this weird issue. Could you please send us the log from MLO on Android: menu > Settings > Troubleshooting > Send logs.

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:

  1. Tap a task in the widget (this should open the task view).

  2. Tap Edit.

  3. Change the flag.

Does the flag change work correctly in this case? Thanks.


Gwen Chenouard

unread,
Mar 8, 2026, 9:17:01 AMMar 8
to MyLifeOrganized
Thank your for your message. 

I just sent you the logs (with my backup restored) by email.

It worked normally since early 2025 when I get this phone. I'm not sure about the exact date it started to do this, and what happened at that time on my phone. I thought it was a soft bug from MLO (version 4 at that time) so I waited for several updates, but the bug was still there even now on the version 5. Then I reinstalled the app this week to see what happen. And even before I restored my backup or synched ma data with on the cloud, it was already not working properly.

I tried to do what you told me: when I do that, the flag change properly on the app. But when I go back to the widget, it shows the last flag, not the one I picked up. 
I would like to tell you that on the widget, the task move in the list, according to the flag list order. So the task order is correct. And the flag is like "blinking" quite fast with the last and the new choosen one (you can barely see this on the video I did)..
Another precision: when the flags are OK on the widget, if I change one of them, or add a new task, every flag is not correct (like they are shifted). I can see all of them blinking. But sometimes, all of them are shifted, and sometimes just a few are shifted. Very weird...
And sometimes, after a few hours, the flags are OK. 

Moreover, the battery optimization is disabled for the MLO app. And I don't use a soft part like "One UI" on samsung phones (don't know what's the name of this kind of app in english). It's just the native android on a google Pixel phone.


Gwen Chenouard

unread,
Mar 8, 2026, 10:01:59 AMMar 8
to MyLifeOrganized
I made another video where you can see the "blinking effect" on the wrong flags, each time a refresh of the widget data is forced (I did it by enabling or disabling the stars)

Le dimanche 8 mars 2026 à 11:44:29 UTC+1, Alyona (MLO Support) a écrit :
Screen-20260308-145455-1772978009927~2-1-1.mp4

Alyona (MLO Support)

unread,
Mar 10, 2026, 1:05:39 PMMar 10
to MyLifeOrganized

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.

Gwen Chenouard

unread,
Mar 10, 2026, 4:16:01 PMMar 10
to MyLifeOrganized
Thank you. I'll keep you updated !

Gwen Chenouard

unread,
Aug 16, 2026, 5:39:35 AM (2 days ago) Aug 16
to MyLifeOrganized

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:

  • Google Pixel 9 Pro XL
  • Android 17
  • Build: CP2A.260805.005
  • Security patch: 2026-08-05
  • MLO 5.0.0 (versionCode 5030, targetSdk 35)

Since my original report, I performed several controlled tests which may help isolate the problem.

1. A newly created widget initially displays the correct flags

I 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 flags

Starting from a correct widget:

  • I change only the text of one task.
  • The widget refreshes normally.
  • The new text is displayed.
  • All flag images remain correct.

So a normal collection refresh by itself does not seem to cause the problem.

3. Changing a task flag DOES corrupt the widget

Starting again from a correct widget:

  • I change only the flag of one task.
  • The widget refreshes.
  • The correct flag can appear very briefly.
  • Then an incorrect/previous flag image comes back and remains displayed.

After this, the widget stays in the corrupted state.

This is reproducible.

4. A fresh widget can be corrupted by its first flag change

I kept an already corrupted widget and created a second widget displaying exactly the same TestFlags view.

Initially:

old widget: incorrect flags
new widget: correct flags

After changing one task flag:

old widget: still incorrect
new widget: becomes incorrect too

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 wrong

I can have two widgets displaying exactly the same MLO view at the same time:

healthy widget:
task text correct
Star state correct
flag images correct

corrupted widget:
task text correct
Star state correct
flag images incorrect

If I click a Star in the corrupted widget:

  • the Star state updates correctly;
  • the widget visibly refreshes/flickers;
  • the flag images remain incorrect.

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 test

I 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:

11:04:46.827 DynamicWidgetProvider: WIDGET APP onUpdate
...
11:04:47.808 WidgetController widget views sendUpdateMapViews
11:04:47.828 DynamicWidgetProvider: WIDGET APP onUpdate

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 video

The video I originally sent in March already shows an interesting pattern:

wrong flag
→ correct flag appears very briefly
→ wrong flag returns
→ approximately 1 second later
→ sometimes the correct flag flashes again
→ wrong flag returns

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:

flag bitmap update
RemoteViews
setImageViewBitmap()
postponedMapViews
sendUpdateMapViews
the second widget update ~1 second later

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

Gwen Chenouard

unread,
Aug 16, 2026, 5:42:48 AM (2 days ago) Aug 16
to MyLifeOrganized

As a follow-up to my previous message, I am attaching the full diagnostic files from today's controlled tests:

  • mlo_ab_logcat.txt
    Full logcat covering both controlled cases:
    • text-only update → widget remains correct
    • flag update → widget becomes corrupted
  • appwidget_compare.txt
    dumpsys appwidget captured while I had two widgets displaying the same TestFlags view simultaneously:
    • one widget was already corrupted
    • the newly created widget was still correct
  • appwidget_after_corruption.txt
    A second dumpsys appwidget captured after changing a flag and causing the previously healthy widget to become corrupted as well.

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

mlo_ab_logcat.txt
appwidget_compare.txt
appwidget_after_corruption.txt
Reply all
Reply to author
Forward
0 new messages