Sailfish OS: set AppSupport settings on boot

The Sailfish OS mobile operating systems offers an integrated Android compatibility solution called AppSupport (also known as AlienDalvik). This is a surprisingly complete implementation, including support for the Google Play Services or microG as a replacement. Even the settings app is included and can change the behaviour of the runtime.

Changing AppSupport settings

The settings app for the Android runtime does not have a Sailfish OS launcher entry. This means it cannot be started from the GUI showing us the other regular apps. But the app is included and can be started from the command line.

AppSupport provides a collection of programs to interface with over the CLI. For example, to launch an app, you open a terminal emulator on your Sailfish OS device - or connect via SSH - and type the following command:

$ apkd-launcher com.android.settings

The settings app will now launch on your device and you can change a wide range of settings.

Though, I have noticed that settings (or at least, not all settings) will not persist on the next reboot. For example, I wanted to change the “display size” settings under the accessibility settings, as the default setting was set too big for my liking, wasting too much screen space on my device (Sony Xperia XA2 Ultra).

But after a reboot, the change has always been reverted and I had to call the settings app over the terminal to re-set the display size.

Persisting the settings

Persisting might not be the correct term for this approach, as all I do is re-set the settings after every boot, using a systemd unit. The AppSupport runtime runs in a container and offers the possibility to open a shell in this container. This way, you can run Android binaries directly to modify the runtime to your liking.

The application to open a shell in the AppSupport runtime container is called appsupport-attach. This program allows us to either open an interactive shell in the container, or directly send single commands into the container.

Now, on Android you can control many things by calling the appropriate binary on the device. In the case of the “display size” in the accessibility settings, Android provides the binary wm (window manager I would assume) to control different aspects of the display settings. In particular, the setting wm density allows you to change the pixel density and thereby modify the size of displayed elements.

Now, to set this on bootup, I added the following script under /usr/local/bin/custom_setup_appsupport:

#!/bin/bash

# setup screen density, changing the size of displayed elements
appsupport-attach /bin/wm density 408
exit $?

The line that explicitly exits with the exit code from the last command is a basis for a longer script that potentially adds more commands that are being run on boot. Here, you’d check after every command if it ran successfully, exiting in case the return code would not be 0 to signal systemd that the script failed.

The systemd unit to start the script on boot is called /etc/systemd/system/custom-setup-appsupport.service and looks like this:

[Unit]
Description=Modifications for the appsupport runtime
After=aliendalvik.service
StartLimitBurst=5
StartLimitIntervalSec=300s

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/usr/local/bin/custom_setup_appsupport
RestartSec=60s
Restart=on-failure

[Install]
WantedBy=graphical.target

The 60 second wait period in RestartSec allows the AppSupport runtime to start up before sending the commands into the runtime. If you send the commands too early, the runtime may not be fully booted up or single commands inside the runtime may behave unexpectedly (such as, for example, the wm command complaining that it cannot find a window).

The script will try to execute a total of 5 times before finally aborting for good. This is the reason we explicitly exit with the exit code of the appsupport-attach command. This way, systemd will notice when a command failed, and thus know that it should wait and then try again. This together with the 60 second sleep before the script is re-ran should give ample opportunity for the AppSupport runtime to boot up fully.

Finally, enable the systemd unit and, after the next boot, the given commands should be executed and the AppSupport runtime behaviour should be altered.