SUMMARY
Rare race condition on boot causes empty desktop due to duplicate homescreen instance from invalid currentActivity.

STEPS TO REPRODUCE
1.Use a device running Plasma Mobile.
2.Reboot the device repeatedly.
3.The issue occurs statistically approximately once every 1000 reboots. It is a race condition and is not reliably triggered by specific user actions.

OBSERVED RESULT
After boot, the user is presented with an empty desktop (no wallpaper, panels, or widgets) and an empty application launcher. The system is otherwise operational. Investigation of the source code shows that an extra instance of the homescreen class is created because KActivities::Controller::currentActivity() returns a null UUID ("00000000-0000-0000-0000-000000000000") during the screen loading process.

EXPECTED RESULT
The device should boot consistently every time, loading the default Plasma Mobile desktop with the correct wallpaper, panels, widgets, and a functional application launcher. The currentActivity() method should always return a valid activity ID, preventing the creation of duplicate homescreen instances.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
I am using Plasma Mobile on my smartphone for a home project and have encountered a strange, intermittent issue. Approximately once in every 1000 reboots (a very rough estimate), the system boots to an empty desktop and an empty application launcher.

I investigated the source code and found that during initialization, an extra instance of the homescreen class is created. The root cause appears to be that when the load() method is called, KActivities::Controller::currentActivity() returns a null UUID ("00000000-0000-0000-0000-000000000000") at the stage when the screens are being loaded. This incorrect activity ID leads to the creation of a duplicate homescreen.

Furthermore, I looked at the checkActivities() method, which is called earlier in the same function. I believe the logic there is flawed. You correctly check the serviceStatus, but then the code contains:

cpp
Q_ASSERT_X(!existingActivities.isEmpty(), "isEmpty", "There are no activities, and the service is running");
Q_ASSERT_X(existingActivities[0] != QLatin1String("00000000-0000-0000-0000-000000000000"), "null uuid", "There is a nulluuid activity present");

This is where the problem lies. In this specific race condition, the existingActivities list contains valid activities, but the currentActivity() remains invalid (null UUID). This leads to a very subtle and hard-to-reproduce bug that I can only trigger with fairly specific methods.

Please feel free to contact me via email or another method so we can work together to find a solution. I can provide more details on my environment and the specific steps I use to model the problem.