Situations application feedback

The installation went fine here on xperia 10ii with latest sfos. I have noticed recently some issues with one addin for the when condition : network cells.
In the past, I was pressing register (not sure about the exact English as i am using the French version) and cells would be added. I have a ‘at home’ situation, I deleted it and reinitiated it. What I do is that I register cells every time the condition is not matched so I am adding the cells gradually that are around my home.
This was working nicely in the past. With latest version, I could add at this stage 4 cells but adding more is not working and while I can press “register”, it does not increment to 5 as it should (and used to).
What is tricky is not it works until a certain stage as I could add 4 cells…

By itself it is. But it’s just painfully uncompatible with my ambient.

Unfortunately even after I added trailing slash as requested by error the output was empty in both cases.
But in output of

dconf dump /desktop/ | grep -A 5 "jolla/theme/color"

When wrong (Situation doesn’t change back to the previous Ambient background) I got


and when proper Ambient


I created an alternative Situation to retest if the upgrade import corrupted original Situation but it didn’t help.

For what it’s worth, Situations (current and previous versions) sets ambience just by calling “setAmbience” via dbus “com.jolla.ambienced” service and path to the ambience as an argument.

Well (ff)ffcc80 and (ff)c59d62 are Amber/Orange hues so that’s consistent (the first part is alpha ,where ff is fully opaque).

Where is that Stella Ambience from? Is that that ole Angry Birds one? What is the color code in /usr/share/ambience/stella/stella.ambience (the exact name may vary)?

yes angry birds… :slight_smile:

here it is :

“wallpaper” : “Jolla_Stella.jpg”,
“highlightColor” : “#FFCDE3”,
“secondaryHighlightColor” : “#BBFFCDE3”,
“primaryColor” : “#FFFFFF”,
“secondaryColor” : “#BBFFFFFF”,
“ringerVolume” : 70,
“favorite” : true,
“partnerSpace” : “partnerspace-stella”

I’m lost how that is connected. I use custom Ambient. There is no Stella Ambient in `/usr/share/ambience/ on my X10.

Just to rule out the “wrong” color is actually in the ambience file somehow. Apparently not.

For me doing

dconf dump /desktop/ | grep -A 5 "jolla/theme/color"

is returning


with the wrong accent color,



with the right one.
In my case it is SFOS “Three” ambience.
As you can see after I restart the phone it gets unselected from the list,

even though in the main list it still says it is selected.

If I switch to a different situation their ambience work correctly, and even better, if I switch back to the original situation the colors are now correct and the ambience is selected.

But to me this is a very insignificant problem, that only occurs after reboot and is super easy to fix, by just applying an ambience from the top menu. The WiFi list not updating/clearing old networks is much more problematic.

Attempt at fixing:

  • Import
  • WiFi scanning

Available here: Release Beta release 287 · pastillilabs/packages · GitHub


It appears at least the issue where a WLAN-scan based Situation does not deactivate when the network disappears has been solved.
And the other way around works too.


Yes, same here. Situations based on WiFi scanning are working correctly. Thank you.

Thank you for the confirmations! I forgot to mention that I also may have fixed the issue with active Bluetooth connection detection. Not sure about it since couldn’t test it myself yet.


I’ve noticed a regression since the new sandboxing compatible version. I use a situation to turn off wifi and switch to 4G when I enable mobile data. However it now sometimes thinks I’ve enabled mobile data when I enable VPN.

Thanks for the report. By “sometimes”, do you mean that it does not happen always?

I’ll see if I can reproduce the issue. But in general the code to detect & control mobile data hasn’t really changed since the previous version. Whether that code is correct is another thing (Situations detects & controls mobile data via the “AutoConnect” property of the primary cellular context)…


I don’t think it always happens but I can’t say with 100% certainty. I’m using the Wireguard plugin from Openrepos if that helps.

I’m trying to achieve a situation scenario where when certain conditions are met (at night/asleep), situations app would turn off/kill Android Support.

Since systemctl start/stop aliendalvik needs permission (I suppose this is why), it doesn’t work.
As a workaround im using systemctl --user restart lipstick, instead.

So, I went for Sudo. Installed it and got it successfully configured. It works fine in Terminal without sudo password prompts. I even included Situations app in the sudoers file==>nemo ALL = NOPASSWD: /usr/bin/harbour-situations2application.

On the other hand, I have already made some shortcuts with qCommand that worked fine, and added it to the sudoers file as well. However, I had to use : echo mypasswrd | sudo -S systemctl stop aliendalvik for it to work. The same command didn’t work in Situations app though.

* sudo systemctl stop aliendalvik didnt work in either.

Anyone knows a way?

If sudo is set up correctly, no password is needed. That’s what sudo is designed for.
On the other hand, there is a dbus command to control app support that dosn’t require root privileges, and that can be used in scripts.
BTW, I have been using Situations to stoo app support at night for many years.

I agree. And I already have said that in terminal, i can issue sudo commands without password input. But! I believe that sudo misbehaves/doesnt work as intended in non-interactive contexts, such as when running from a graphical application or script.

Please, do share then :neutral_face:

Thanks mate!

+edit: possibly related:
Seems sudo behaves the same on SfOs with my configuration as it does elsewhere (prompts for the password once (or once in a while?)). Maybe there’s some other configuration that gets rid of pswd prompts completely(?)
My configuration :


## Same thing without a password

## Uncomment to allow members of group sudo to execute any command
nemo ALL=(ALL) ALL

## Additional edits for specific privileged commands
nemo ALL = NOPASSWD: /usr/bin/dbus-send
nemo ALL = NOPASSWD: /bin/systemctl
nemo ALL = NOPASSWD: /usr/bin/connmanctl
nemo ALL = NOPASSWD: /usr/bin/qCommand
nemo ALL = NOPASSWD: /usr/bin/harbour-situations2application

You may use the following command to control app support without sudo

dbus-send --system --dest=com.jolla.apkd.control --print-reply /com/jolla/apkd com.jolla.apkd.control.controlService boolean:false

Simply use boolean:true as last argument to start app support at the end of the situation.

1 Like