[3.4.0] Multi-user support in SFOS applications

Platform Development
#1

As it has become quite clear that the upcoming SailfishOS 3.4.0 will bring multi-user support, I am interested in the mechanics of it, or more to be more precise, how it affects OpenRepos packages with custom scripts for system and/or user services.

To be even more precise, I would like to prepare my Battery Buddy application for 3.4.0 so that it doesn’t break the update and cause my fellow Early Access members to brick their phone, and needlessly cause trouble and possibly even data to loss to everyone. My application uses both system and user services, so I would like to know how to handle the upcoming situation properly.

As a side note, using hardcoded home path (/home/nemo/) has been always discouraged, and this is something I have to fix, too.

Thank you!

16 Likes
#2

I think you can try to get more info on this from community meet up happening tomorrow

#3

This article
https://together.jolla.com/question/210604/share-only-specific-contacts-group-to-android-secondary-address-book/
on zendesk is not really extensive helpful.
I would also like more detailed information, e.g. will every user have its own contact database, what about user services (as direc85 asked), is only one user at a time active and so on…

What about Android applications, will they be supported in future, each user its own configuratiin?

A roadmap?

1 Like
#4

It looks like my approach worked “well enough” for single user use case in SFOS 3.4. However, systemctl binary had moved from /bin to /usr/bin breaking some of the functionality. After adjusting to that, all functionality seems to work just fine.

I’ll tackle the multi user setup at a later time.

1 Like
#5

Thank You verry much. Since two weeks I search the reason why my proximity-fix.timer not work (sony xperia 10 SFOS3.4.24). This I need because the proximity sensor bug in the hardware of Xperia10. Now I changed the line “ExecStart=/bin/systemctl restart sensorfwd” to “ExecStart=/usr/bin/systemctl restart sensorfwd” in the file proximity-fix.service and its work aggain!

#6

/usr/bin/env systemctl

2 Likes
#7

Hello Coderus
What is the different between:
"ExecStart=/usr/bin/systemctl restart sensorfwd”
"ExecStart=/usr/bin/env systemctl restart sensorfwd”
the first line works perfect by me. Thanks in advance…

#8

I’m not coderus but /usr/bin/systemctl assumes systemctl will always be located in the /usr/bin directory which isn’t always the case for shells or interpreters (I don’t know about systemctl).

/usr/bin/env provides a default environment where it doesn’t matter where, in this case, systemctl is located as long as it is in one of the executable PATHs defined by env. (Although this assumes env is located in /usr/bin :smiley: (but it is by convention, otherwise env usage would break).)

#9

Thanks verry much - now I understand. Perfect description…

#10

It wasn’t actually hard to support multiple users. Just make sure you’re not using hardcoded paths, but $XDG_HOME and friends instead!

2 Likes