I would like to ask for your technical assistance with a media integration issue on my DUDU7 head unit.

My unit is based on Android 13 / platform 6318, and the AutoUI version I am currently using is:

com.dudu.autoui
DuduLauncherPro7870 1.015091
versionCode 1015091

The application involved is NavRadio+ (com.navimods.radio).

I have spent considerable time investigating the issue because I wanted to make sure that I was not simply reporting a normal NavRadio problem or an FM tuner problem. I have collected runtime logs and also studied the behavior of the AutoUI media integration offline.

The main symptom is the following.

NavRadio may be selected as the current media application, and its MediaSession can already be alive and contain the correct station metadata, but the DUDU MainScreen music widget and statebar can still display:

“Playback Pending”
“Unknown Singer”

At the same time, the NavRadio session itself can already expose the correct station information.

I have reproduced a particularly useful case in which:

NavRadio process and RadioService were alive.
The same NavRadio MediaSession remained alive.
The session contained the correct FM metadata.
AutoUI still showed Playback Pending / Unknown Singer.
Pressing Play restored FM audio and the vendor FM source, but did not restore the title metadata.
Opening NavRadio fullscreen also did not restore the AutoUI title.
Changing to another station caused the correct metadata to appear immediately in both AutoUI title surfaces.
Changing back to the original station also worked correctly afterwards.

This strongly suggests that the tuner itself and NavRadio's MediaSession are not the main problem. The problem appears to be related to the synchronization/replay of an already-existing MediaSession state when a new AutoUI media consumer becomes active.

During my investigation I found behavior that appears relevant.

When AutoUI creates/selects the NavRadio media integration again, the UI can first reset its displayed media information to Playback Pending / Unknown Singer.

At the same time, the music information service may still retain the previous NavRadio MediaController and the previous title/artist values.

The controller acceptance logic appears to treat two controllers with the same package name as already equivalent. In that situation, a fresh metadata/playback snapshot may not be requested.

There also appears to be a separate duplicate suppression for TITLE + ARTIST. Therefore, even if the current MediaSession still contains exactly the correct station information, the service can regard that metadata as “already known”, while the newly activated UI consumer has never received it after its reset.

In other words, there seems to be a distinction between:

“the service has already seen this metadata”

and

“the currently active AutoUI consumer has received this metadata”.

This would also explain why changing station fixes the problem: the title becomes different, so a new metadata event passes through normally.

I may of course be missing internal details of your implementation, so I would be very grateful if your developers could confirm or correct this interpretation.

The behavior I believe would solve the problem safely is conceptually very small:

When the NavRadio AutoUI consumer becomes current again, AutoUI should obtain one current snapshot from the currently valid NavRadio MediaSession and deliver that snapshot to the newly active consumer even when TITLE/ARTIST are identical to values previously seen by the service.

Ideally this replay should be associated with the current MediaSession and current media consumer so that an old callback cannot update a later application after the source has changed.

Importantly, such a refresh should not need to:

press Play or Pause;
change the FYT audio source;
request FM audio focus;
reopen NavRadio;
change station;
restart the NavRadio process.

The MediaSession can already be correct.

I also noticed that progress information appears to be a separate issue. When returning from LocalMusic to FM, the widget can retain the previous LocalMusic timer. For live FM I would expect progress to be unavailable/not applicable rather than retaining the previous track duration. I mention this separately because I do not want the metadata-title issue and the progress issue to be treated as one problem.

I would therefore be very grateful if you could tell me whether:

This metadata replay/synchronization behavior is already known to your developers.
There is a newer AutoUI build in which this behavior has already been corrected.
There is an internal or supported API/event that forces AutoUI to request a fresh snapshot of the currently selected MediaSession without changing playback or audio source.
Your developers could add a consumer/session-aware initial metadata snapshot when the NavRadio media controller becomes active.
The same mechanism could also be useful for other third-party media applications that already have a valid MediaSession but occasionally show Playback Pending after source/application changes or wake.

If your developers are willing to test a correction, I would be very happy to test an officially signed experimental AutoUI build and provide detailed before/after logs.

Because AutoUI is the launcher/system UI on the unit, I do not want to replace it with an unofficially signed build or modify the ODM installation directly. If you provide a test build, I would therefore also appreciate the supported installation and rollback procedure so that the original version can be restored safely if necessary.

I am not asking for any private signing keys, proprietary source code, or security bypass. An officially signed test build, an official update package, or simply technical guidance about the correct supported refresh mechanism would be more than sufficient.

I can also provide additional diagnostic material if your developers need it, including:

exact reproduction steps;
Android MediaSession state before and after the failure;
AutoUI/source state;
timestamps;
logcat extracts;
the exact sequence where playback/source recover while metadata remains stale.

My goal is not to alter the tuner/source architecture. NavRadio is already successfully using the FYT radio source and can expose correct metadata. I am only trying to make the AutoUI presentation reliably synchronize with the already-correct current MediaSession.

Thank you very much for your time and for any information you can provide. Even confirmation of the intended AutoUI media-refresh mechanism would be very helpful.

Best regards,
Antonis