the “android” applications do not systematically close when you close them and they often remain in the background.
That’s a (normal) Android thing. “open” and “closing” apps in Android is about opening and closing their windows (The “views” in MVC parlance) not the actual application.
I wrote a HOWTO on the previous Question-forum. Basically, you have to hunt down all the way which could automatically start an app in the background (autostart, cloud messaging, notifications).
It’s not 100% complete, there are still way to start an application.
Notably, the “share” function in Android: applications have to option to directly list destination. E.g.: chat applications list your most frequent contact so you can directly send them a picture from the share screen - instead of needing to , e.g.: select the contact in WhatsApp. AliExpress’ app is an example that gets started this way (whenever you share a picture, AliExpress also starts to suggest chat threads to share it into) and it manages to stay active even after.
A circumvention to avoid that is to install AlienDalvik Control and share photos from within Sailfish: ADC will add an extra “Share to Android” entry in Sailfish’s “Shareto” function, and that one only list accepting application, it does not start the applications themselves to obtain a list of most frequent contacts.
You still have to stop apps manually who refuse to exit when you close their windows (but again, that’s standard Android function, it’s the same on android tablets).
the kernel stack bug is not solved and its size increases over the days except by rebooting the smartphone
Also @elvarr:
Compass does not work on Sony Xperia 10 Plus.
This whole class of problem would completely go away if Jolla accept to sell Sailfish X (complete with AlienDalvik, etc.) on devices that support upstream vanilla kernel.
Most of it arise due to old kernel on whatever blob the manufacturer provided at the time Jolla ported the adaptation layer. Even if some companies - like Sony for Xperia X - do provide some firmware updates (unlike Qualcom for Jolla 1), it seems that the Jolla devs lack the time/ressources to port a new adaptation on top of it.
e.g.: The PinePhone from Pine64 is supported by a standard kernel. Any new update to kernel and driver done by the larger linux community can be used directly, without needing to have someone battle against some android firmware blob with libhybris.
Now specifically:
its size increases over the days
Not a solution, but a workaround: buy some “High Endurance” µSDHC or µSDXC(*) card, and make a 4GiB swap partition there.
Leaked unusude memory will get swaped out and won’t eat your RAM.
(*): Just make sure to reformat the main partition from exFAT to something supported in Sailfish. I personally go for BTRFS, but EXT4 would be a perfectly valid solution. Use FAT32 if you want to share easily with a Windows latpot.