[Automotive] Sandboxing for System Installed Application

[Martin Kampas]

Hi Jürgen,

> This should be only be useful if you create a custom live enabled runtime which is installed on a device (for example a tablet) and is not allowed to write into its installed folder. In this case it need to find a writeable place for it’s data. Correct?
> Or is it more the use case that there is a read-only workspace on a remote device and still we would like to update the user interface?

It applies also to the case when the standard QmlLive Runtime is used. I updated the documentation, explaining:

"""Not all projects are designed so that they allow working on isolated panels or
screens and it may be necessary to deploy whole project to a target device in
order to execute it. Receiving updates normally requires write access to the
deployed files. Depending on the target platform, the project may be deployed to
a location which is not user writable. In most cases hacking on the file
permissions after deployment can help, but a more convenient method is available
- let the runtime store all updates in a writable workspace overlay. Use the \c
-updates-as-overlay option to enable this feature."""

> So we could either lookup a temporary folder or ask QStandardPaths for a writeable location. In both cases the implementation makes a choice.
> Personally I would like to see that there is a default strategy to find a writeable workspace location, which is not inside the implementation but can be set onto the livenode in case something is not writeable.

It uses QDir::tempPath() to find such a location. It can be influenced by setting a platform specific environment variable. The following change set further extends this to also use application and company name in order to get app specific path, much like it is done by QSettings (this needs to be a bit tuned for the case with the standard runtime).

I considered to allow overriding the location with a dedicated environment variable but I abandoned this idea as too dangerous - the location is subject to "rm -rf" and I do not want to imagine someone misunderstanding and setting it to $HOME or $PROJECTS or whatever valuable location :)

Every project may have its specific constraints - I would rather let the user control the mechanism used.

This also serves as a preparation step for adding support to receive updates for compiled-in resources (qrc).

I am thinking maybe the overlay should be persistent by default?

BR,
Martin