REPRODUCIBILITY: permanent state since updating to 5.0.0.73
OS VERSION: 5.0.0.73
HARDWARE: Xperia 10 V
UI LANGUAGE: Polish, English, doesn’t matter
REGRESSION: no
DESCRIPTION:
Right after installing the 5.0.0.73 update (which otherwise went just fine, with no other perceptible issues) icons of newly installed Android apps no longer get added to the SFOS launcher app grid, and icons of uninstalled apps do not get removed from it. Waiting (hours), rebooting the device and restarting AAS (multiple times) don't have any effects. The newly installed applications themselves work just fine in AAS but must be started from e.g. Android settings / Applications, because there is no icon in SFOS launcher. Icons of uninstalled applications stay in SFOS launcher and (obviously) no longer launch the no longer installed app. It happened directly after the update and it persists. I've also manually restarted (using systemctl) all AAS related services (including those in the --user space), to no avail.
PRECONDITIONS:
5.0.0.73 update conducted
STEPS TO REPRODUCE:
Install 5.0.0.73 OS update
Install new Android application (no matter if from within AAS, e.g. Aurora store, or from SFOS by e.g. opening an APK file in SFOS File browser), or uninstall some Android app (using Android settings / Applications / Uninstall, as clicking and holding the icon and then the X in SFOS launcher does not uninstall it despite the remorse timer being shown)
Observe how after the installation there is no icon added to SFOS launcher, or how after uninstallation the icon stays in SFOS launcher
EXPECTED RESULT:
After installing an Android app its icon should be added to SFOS laucher (i.e. a corresponding .desktop file should be automatically created in /usr/share/applications/ or ~/.local/share/applications/), and it should be removed after uninstallation of the app
ACTUAL RESULT:
Nothing happens in SFOS launcher - icons of newly installed Android apps are not created on the SFOS side, and icons of existing Android apps do not get removed after uninstalling them. Clearly, some service responsible for handling .desktop files of Android apps on the SFOS side stopped working as it should.
MODIFICATIONS:
None
ADDITIONAL INFORMATION:
I've originally reported this problem in the 5.0.0.73 update thread , where I was asked by @keto to create a separate bug report for it.
I think this is still working for most devices, so maybe something went wrong on upgrade of yours. Can you get journal and logcat logs so we might see what’s going on? I think I could find some guides if you’re not familiar with that.
I will take the logs when I’m home tonight. What I observed for now, is a huge mess in the ~/local/share folder. For instance, there is an apkd-bridge folder there, which contains .ini files for Android apps (and here everything seems to be OK, as there are .ini files for newly installed apps and there’s no .ini file for the one I removed) and launcherIcon folder with .png icons of Android apps (and this is where icons of newly installed apps are absent, and icon of a freshly removed Android app remained intact). So….. it looks that .ini files get correctly created (or removed) but not the corresponding .png icons.
Additionally, in ~/.local/share/applications there are .desktop files for Android apps (and in this case again .desktop file of a removed app persists while for a newly installed one isn’t created) and additionally folders starting with appsupport- (and then name, e.g. appsupport-com_aurora_store) containing an icon.png and info.yaml pair - and there is no folder here for the newly installed Android apps, nor for the recently removed one.
So I have no idea what all this mess comes from, probably some kind of some failed migration (?). Anyway, it’s been 3-4 days past the update and the problem persists.
Yes, both are installed, versions 1.4.3-1.6.1 and 2.3.0-1.9.1 respectively.
I’ve just manually reinstalled aliendalvik package ( zypper in --force aliendalvik ) and it installed without any errors or missing dependencies, so it looks that everything is installed…
That’s tricky, I guess it’s there but failing somehow. Log will help. If you know where the qtlogging.ini file goes, then setting com.jolla.apkd.launcher.plugin.debug=true will give you some more detail in that launcher generator. I can’t look it up right now though sorry.
Those ini files are the basic host side storage for launchers on every platform, which has plugins to write the particular launcher format for the current one (fdo-ext on SailfishOS).
I’ll post the logs but I can’t do it atm and it may take me until tomorrow evening. Sorry for that and thank you very much for looking into this. I will provide it the soonest possible.
No worries. I think we’re definitely in the territory of something weird happening to your device. You could also check the permissions of that .local/share/applications dir and the launcher icon dir to make sure they’re still writeable. Something along those lines.
I had something similar years ago. You can still open the installed apps by searching them in the store, then they’re displayed as installed and you can click to open.
Tomi just noticed the yaml part of your comment. Do you have apkd-plugin-launchers-appman installed? You really shouldn’t, and I’m not sure how you could. But if you do, remove it and restart AppSupport and all your launchers should sort themselves out.
YES! Indeed, apkd-plugin-launchers-appman was installed and turned out to be responsible for all this mess. Just uninstalling it instantly fixed the problem - all missing icons appeared within seconds and now get correctly updated. The question is where did that apkd-plugin-launchers-appman ackage come from…. It must have been absent prior to the 5.0.0.73 update as everything worked OK until then…. Nevermind, what’s important is that everything is back to normal and the problem is 100% fixed.
Thank you VERY much for your help and apologies for slow response. My wife broke her arm on a slippery sidewalk and we spent a lot of time at the doctors.
You could do some sleuthing in /var/log/zypp/history, that will give you a hint at least when that package was installed.
Look for lines that have install in the second field (|-separated). The 6th field will tell you “what” caused the package installaion. If it’s root@xxx then it was a user. If it’s another name, it’s an app that installed it. If it’s empty then it was a dependency of some package.
It’s strange because it says root and I really don’t remember doing anything at that time which might have resulted in that package getting installed. Heck, I didn’t even know that such package existed, let alone manually installing it. Even more bizarre is that installation time stamp is very similar as the 5.0.0.73 update (few minutes later). Strange. Nevermind, the good thing is that now everything works OK. Once again, thank you VERY MUCH guys for your help and apologies for all this mess!
Was there anything else installed at the same time as that? It would be good to know if there’s some danger that others might end up installing it accidentally, and how it could happen.
Well, no. The logs and zypper history clearly tell me that it must have been me who manually installed it via zypper It was a few minutes past the .73 update, and nothing else got installed at the same time. Why and what for did I possibly do that? I just can’t recall or identify. Maybe I wanted to install some other package and I somehow installed wrong one due to not paying enough attention to its name? No idea. Well, s**t happens…. I was applying the OS update while waiting in a doctor’s waiting room for my wife (she broke her arm at that time), so it was quite a disturbing environment and a stressful situation. I recall that at some point my wife left the doctor’s room and we had to go to some other place (RTG or something), so I was finishing things in a hurry. Definitely not a place and time to do such things, so next time I will certainly do it in more suitable circumstances. To recap, this must have been a ‘human error’ and there’s nothing to fix on your side. Sorry & thanks for your assistance.