Apps organization bug

Dear /e/ community,

I pack my apps using “bubbles” on the launcher screen. Eventually, for a reason i do not understand, the bubbles (or packages) are gone and the apps are just listed back on the screen without any organization. The apps in the bar at the bottom of the screen are also back on the screen.

I experience this bug since I use v.1.1 and now 1.2. I did not experience the bug with 0.x (and directly upgraded to 1.1). My phone is a Galaxy S7.

Some of you have a similar experience or an idea to solve it?

The bugs goes on… Screenshots to show the issue:

Before the bug:

After the bug:

1 Like

I guess you are experiencing this so badly as you adopted the technique of nicely using “bubbles” for compartmentalisation.

The use of folders (or bubbles) for apps does not work well with Bliss, the launcher which provides the home screen. Changes have been happening to Bliss from v1.0, I don’t know why it appears quite so extreme for you. You describe the order as random but it looks quite close to (extracted from folders but) alphabetical?

I can reproduce this by setting up Bliss “to order” then

Settings > Apps and notifications > Show all … apps > BlissLauncher > Storage & cache > Clear storage.

All apps now revert to alphabetically organised.

You might https://doc.e.foundation/support-topics/report-an-issue – or consider changing the launcher to one that suits you better.

2 Likes

there’s a trail of issues to this extend (“exploded blisslauncher organisation”) in gitlab - some closed. You can search an open issue and vote or say it’s happening for you

2 Likes

Thank you both for your replies!

Yes indeed, folder works well for bubble @aibd ^^

Clearing Bliss’ storage gives this:

In my case, when the bug happen, the bar below gets empty and only one folder (or bubble!) remains at the top left of the screen without its name (it takes back the default name, here in French) and contains only one app.

I noticed the bug happens when I use the central physical button of my S7. But this action does not always trigger the bug.

Thank you for suggesting to change the launcher @aibd, I’ll consider it even though I would prefer to keep a full /e/ setup.

Thank you @tcecyk for pointing out the related or similar issues raised on github, I’ll look into it.

1 Like

it would be valuable to get a logcat of the exception/crash. You can fetch this right after it occured. Then the blisslauncher state matters, it’s sqlite db cann be pullled via adb root. With this in hand I guess one can debug further

2 Likes

Yes I would be happy to get material to debug further.

@tcecyk, could you please advise how to do that? What “get a logcat of the exception/crash” and “it’s sqlite db cann be pullled via adb root” mean?

Thank you!

you’d need this ready next time the bug occurs and the log is still in buffer, so this won’t help right now:

another option is to create a bugreport (this can be done on-device)

if you’re lucky the raised error of blisslaunch is still in the log, but it get’s purged after a bit (actually don’t know how long android holds onto log)

2 Likes

Thank you @tcecyk, both options are now ready. I just expect the bug to happen again.

Could you please advise how I am supposed to identify the interesting lines in the report? The on-device report gives a zip files with different files in it. I guess I should look into the “bugreport-heroltexx- … .txt” file. And then? What should I look at? “Blisslaunch” appears very often in this file.

Thank you again!

I participated/commented a bit on crash logs in Random reset of ALL icons order. Happening several times (#4286) · Issues · e / Backlog · GitLab - you look for classic stack-traces when an exception occurs… it has an easily identified visual pattern, as the lines leading up to the failing function will be indented a few spaces from the left:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: foundation.e.blisslauncher, PID: 3404
E AndroidRuntime: java.lang.IndexOutOfBoundsException: Index: 2, Size: 1
E AndroidRuntime: 	at java.util.ArrayList.get(ArrayList.java:437)
E AndroidRuntime: 	at foundation.e.blisslauncher.features.launcher.AppProvider.prepareLauncherItems(AppProvider.java:383)
E AndroidRuntime: 	at foundation.e.blisslauncher.features.launcher.AppProvider.handleAllProviderLoaded(AppProvider.java:284)
...

(the IndexOutOfBoundsException got a bugfix, so it will be something new at best)

search for the keyword “exception”. adb logcat also allows to filter by log-level. The “E” is for error, so you could go through a log either be searching for " E " (mind the spaces) or use “adb logcat *:E

but it will be hard to recreate the conditions of the crash I think.

2 Likes

To get practice reading the log one might explore Create a log @/e/ with a computer.

The biggest thing missing from this page is mention of the built in help for adb logcat

A device must be connected then

adb logcat --help

shows the ways you can be more selective.

-d = Dump the log and then exit

can dump a very big log, sometimes from the moment the device has booted.

A bit of practice when all is calm helps get used to actual bug tracing.

2 Likes

Thank you both for your replies and guidance. I’ll keep you posted if/when I get something out of the report / bug tracing.

It crashed again, but this time I was waiting for it. I’ve looked into the bugreport, thanks to @aibd and @tcecyk guidance.

Based on the fact it crashed around 8:38 / 8:40, I’ve found the following exception happened before and after the crash:

WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring

The first time it appeared was 9 minutes before the crash, in this context:

09-08 08:30:15.085  1000  3756  3786 W Looper  : Slow dispatch took 177ms android.ui h=com.android.server.policy.PhoneWindowManager$PolicyHandler c=com.android.server.policy.-$$Lambda$PhoneWindowManager$DisplayHomeButtonHandler$ljCIzo7y96OZCYYMVaAi6LAwRAE@30901a2 m=0
09-08 08:30:15.089  1000  3756 10064 E WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring
09-08 08:30:15.155  1000  3756 13566 E WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring
09-08 08:30:15.447  1000  3756  3789 I WindowManager: Screen frozen for +526ms due to Window{408f644 u0 com.android.systemui.ImageWallpaper}
09-08 08:30:15.499  1000  3756  5986 E WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring

The exception happened 15 times between 8:30 and 8:31, then 1 time at 8:36, 1 time at 8:38, and 4 time at 8:39, concluding with:

09-08 08:39:49.308  1000  3756 13566 E WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring
09-08 08:39:49.380  1000  3756 13566 I chatty  : uid=1000(system) Binder:3756_1F identical 1 line
09-08 08:39:49.404  1000  3756 13566 E WindowManager: App trying to use insecure INPUT_FEATURE_NO_INPUT_CHANNEL flag. Ignoring
09-08 08:39:50.039  1000  3756  3788 W WindowManager: App freeze timeout expired.

The last line, “App freeze timeout expired” happens only one time in the bug report and fits with the crash time. Maybe the “crash” means that the “timeout” (number of exceptions being “ignored”?) has expired?

Any idea or suggestion would be much appreciated!

2 Likes

Can you check the whole log for sensitive info and post it to a pastebin? I wonder for context, if process id of error loglines match up with the blisslauncher pid

Thank you for your reply, @tcecyk.

I do not know how to check what is a sensitive info in the log. Could you please explain how to do that, or if (and how) I can directly check myself “if process id of error loglines match up with the blisslauncher pid”?

Thanks!

search the log for (parts of) your email address , keywords as “imsi” and “imei”, " cookie" - if no adjacent strings seem like a disclosure or you just blank them then you’re good.

pid: order of integers in the log is “uid ppid pid” - your userid 1000, the parent process id that spawned the process bliss runs under, the pid. If I’m not mistaken. Whenever you have bliss mentioned, check the line for rightmost id, that’s bliss. Then you can search the log for all lines emitted by bliss with its pid (use enclosing spaces to not get false hits)

2 Likes

Thank you again for your guidance @tcecyk and please excuse the late reply.

As I have not looked at the report structure (yet!) which may be full of personal data, I’d prefer to limit the extract only to the relevant parts for the analysis, if you do not mind.

Blisslauncher pid seems to be 4758 but pid 6708 seems important as well. Here are the lines where one of these two are appear: 4758 and 6708 - Pastebin.com

What do you see? What else could I provide?

Thanks again

not the same intent, but

Not allowed to start service Intent

didnt have a hit for your error exactly

search too for other exceptions, but you could file a bug for the specific intent it fails on if you’re on latest

Hello and thanks for the reply @tcecyk

Could you please advise how I am supposed to file a bug please? In which section should I document the bug? Should I re-explain all the details on the Gitlab file and/or direct to this topic?

Thanks!

1 Like

there’s a doc entry on how to report in the bug tracker: Report an issue

depending on the email you use to register with the e-gitlab, you’d need to send a mail to get an account: E.foundation GitLab doesn't allow registration - #3 by Manoj

as I already checked if there is a prior bugreport on the same error message of yours you can go straight to report at Issues · e / Backlog · GitLab - it has a reporting template guiding you along. You can link the 3 similar crash reports and this forum thread. Make sure to include the exceptions you run into.

it’s work, yes…

2 Likes