AppSupport randomly crashes until device reboot

Bug Reports
1

REPRODUCIBILITY: 100% (always)
OSVERSION: 5.0.0.72
HARDWARE: Xperia 10 III - xqbt52 - xqbt52 - 1.0.1.48 - aarch64
UI LANGUAGE: English (UK) (user: en_GB, os: en_GB.utf8)
REGRESSION: not specified

DESCRIPTION:

The AppSupport randomly crashes and refuses to start - it hangs indefinitely in the starting state. Journalctl only says that it’s waiting for hwservicemanager and nothing else.

I can’t find any exact regularity to it but it happens multiple times a day, forcing me to reboot my the phone.

Is there any way to fix it without nuking whole AppSupport?

Edit: Now I’m down to minutes between phone reboots, this is yet again making the phone unusable.

PRECONDITIONS:

STEPS TO REPRODUCE:

No idea, newly flashed phone

EXPECTED RESULTS:

No crash

ACTUAL RESULTS:

Crash

MODIFICATIONS:

  • Patchmanager: yes
  • OpenRepos: yes
  • Chum: yes
  • Other: none specified

ADDITIONAL INFORMATION:

Device Owner User: defaultuser
Home Encryption: enabled

the initial version of this bug report was created using Bugger 0.9.16+git2
2 Likes
2

Surely there are already threads about this.

1 Like
3

Didn’t find any relevant to my situation. All of them are pre-5.0 where AppSupport got some significant changes.

But why am I telling you - surely you know that, otherwise you wouldn’t comment, right?

4

Here is one example

Sure, entry points are a bit different for different users it seems - but refusing to (re-)start after the latest update seems like a clearly common thing.

1 Like
5

When Appsupport crash appeared on my device, it was enough to restart the GUI with Sailfish Utilities and then it worked again for long time. No full restart was necessary.

3 Likes
6

This sounds like an important hint.

2 Likes
7

Not in my case (xperia 10ii). Only reboot allow to restart AAS…

4 Likes
8

Yesterday had this exact problem with the same specs. Only reboot solved the problem.

9

As already described here, [10 III] [5.0.0.71] Android App Support does not start when “Start Android App Support when device starts” is enabled I also have this problem.
However, there has been an improvement for me. I had major problems with the Tusky app for Mastodon. It started to freeze, took forever to load, crashed several times a day, and then saillfishOS also froze and took several minutes to run smoothly again. Sometimes it didn’t work at all, and often AAS crashed afterwards.

I uninstalled Tusky, deleted all data and reinstalled it. The problems are gone and AAS no longer crashes daily.
Is there a bug in the memory management?

10

Is this an intentional change that on SFOS 5.x if AAS isn’t running MIME assignments of Android apps are not visible to SFOS? For example, on SFOS 4.x if I click some link to a web page, I am presented with a list of web browsers including Android ones (e.g. Firefox), even if AAS is not started, and if so then selecting an Android app automatically stats AAS and then lauches it. On SFOS 5.x, however, if I click a link to a web page and AAS isn’t started, I am only shown a list of native SFOS browsers to choose from, no Android apps shown until AAS is running. Of course, the same applies to any other MIME type, e.g. music files, images, documents, etc.

Is this change intentional or should I file a bug report for it?

1 Like
11

This is controlled by .desktop files in ~/.local/share/applications.
I also remember it working, but now (relatively fresh install) it doesn’t, and yes, the appropriate apkd_launcher*.desktop files do not have a MimeType line in them. If I add it back in it works again as desired.
Weird.

So, you can open these files in any plain text editor and add this line for URL MimeType association (under the [Desktop Entry] heading):

MimeType=x-scheme-handler/http;x-scheme-handler/https;

2 Likes
12

Just so you know, that’s not how AppSupport registers its MIME and URL handlers anymore - it was too inaccurate. Lipstick now queries Android directly for supported apps. But that mechanism will still work if you want to use it! I’d recommend copying launchers for that, setting the new ones to hidden. That way they won’t get overwritten by AppSupport.

3 Likes