Feature Request: External "System Service"

[janwiesemann]

Description of the feature you're suggesting.

In the pats few months I've learned a lot about the Flipper firmware and even started to develop a few small applications. One thing I've had in mind was to develop some sort of Task Manager. This would include a graph with the CPU load over time. For this feature to work well, the application has to be loaded at system startup to constantly monitor the system usage. While doing some research, I came across the FlipperAppType.SERVICE.

As far as I understand it, scripts/fbt_tools/fbt_apps.py is generating the source file for applications/services/applications.h at compiletime and it can not be expanded at runtime/startup.

Enabling the expansion of such lists could enable a whole bunch of new and exiting features for third party app developers.

I'm not super familiar with all of the firmwares internals or the STM32WB55RG features, but since the RAM is quite limited, it could be a good idea to dynamically flash such apps onto the STM's internal flash. If the application is directly executed from the flash, it would remove the need of dynamically loading it into your precious RAM.

Anything else?

No response

[hedger]

Flipper app subsystem design and underlying APIs were created within a single foreground task paradigm. Background services must be carefully implemented with that in mind, and introducing user-created system threads might lead to hard-to-diagnose usability issues - resource leaks, heap management, conflicting access to peripherals, etc.

Flashing and managing of externally-supplied pieces of code is problematic on its own.

Overall, while there are valid reasons for that feature, its use-cases are severely limited on our current platform. You can look into hacky ways of creating background threads from a regular application by abusing the furi_record subsystem and manual app plugin loading, but that's something we do not officially support and you're on your own here.