Hi everybody,
My last topic with the same title turned into a discussion about Bootloader //AVB Keys used and hence was renamed accordingly. So, my next attempt to start this topic.
@SkewedZeppelin I have been having Divest Os for a week now (FP3 with upgraded cameras).
One thing i notice, the responsiveness of the apps are very slow. Apps take upto 10 seconds to open, depending on which app ( for eg: Fair Email). I also tried to change the energy settings to maximum performance, but to no avail.
Why is this happening and anything I can do to help research on this and solve this?
17.1 and 18.1 now sports a toggle to disable and enable the exec spawning feature thanks to GrapheneOS. You might consider using it if you don’t want the app launch delay or increased memory usage.
16.0 and higher now feature the powerful exec spawning patchset from GrapheneOS.
Also even on the oldest devices I tried it on like the 2012 Nexus 4, it was at most 7 seconds.
2016+ devices should be under 2 seconds.
It also only affects the initial start of the app.
I was wondering why my Nexus 4 suddenly became almost unusable, should have read the changelog
Thanks for the hint
Interesting feature, but if you regularly turn off your device (or it’s old and crashes sometimes), only for the initial start often means every start…
Not only that.
I interpret it like that:
Closing an app via the app switcher screen and open it again is a initial start and take long again to start. Right?
Thanks for this information.
I actually measured it with a clock…Launch time with this setting turned on: 7 -8 seconds.
With this setting turned off, 4-5 seconds. It is only for the Fair Email App.
All other apps take around 1-2 seconds to launch. There are some heavy apps like Joplin and Super Productivity, which launch within 1-2 seconds, but take time until the contents are loaded: this was already the case before…
What is it about Fair Email which causes this behaviour? Clearing cache did not help…
My uneducated guess would be that’s related to FairEmail needing to spawn background workers to keep syncing your mail accounts when it’s not in the foreground.
That would apply to Joplin as well though…
keep calm
It’s not about if i want to shut down this discussion or if i am not interested in DivestOS.
not my intension.have never claimed that I have no interest in it
It’s about an issue that IMHO cannot be solved here by the community.
It’s about a special app that doesn’t work because of a special feature that is only used in DivestOS and GrapheneOS.
This is IMHO only solvable by one or the other developer. Therefore, my suggestion is to contact them directly in order to find a solution as quickly as possible.
That is all
Thanks everybody for your reply. I will try to reach out to Divest OS community support through the XMPP Chat Room. I thought @SkewedZeppelin could help, but I guess it would be too much work for him to be present in every forum and help troubleshoot. Once I find out and have the solution, I will keep you all posted.
Answer from XMPP Chatroom:
FairEmail is a large app and also initializes a webview on start.
the mulch webview recenetly switched from 32-bit to 64-bit processes when possible for greater security.
Only thing I could think of.
DivestOS is one of many projects I maintain by myself
I saw @vthejay eventually ask in my chatroom and after I sorted other things out on my plate I did give a response, which I would’ve done here eventually.
Anyone is welcome to ask questions about DivestOS here and I will answer them.
Can maybe crosschecked with another app using webview or webview for itself
or contacting Marcel Bokhorst from FairEmail. He’s a tough guy and reacting very fast with updates of his app…
@SkewedZeppelin thanks for your efforts on DivestOS!
Last evening was fully booked with: changing from LineageOS to DivestOS on my FP3(+). Eventually, I got it working (after almost bricking my device). However, step 8 in the fastboot-installation-process didn’t work exactly as expected. Thus:
A/B devices only without firmware enabled: `$ adb sideload copy-partitions-device.zip
In this stage, adb-commands were “unauthorized”. In order to make this step work I had to cherry-pick this from installation-step 9:
Choose apply update, then via sideload (…)
Furthermore, it wasn’t completely clear to me that step 5 and 6 were sort of “exclusive or’d”, thus: either there is a fastboot image available, or a recovery-image. If that is indeed the case, it would make more sense to me to explicitly mention this in the install steps (e.g. create a step 5a and 5b).
At last: is it expected that the currently installed DivestOS-version-update never disappears? When I go to my settings → system → updater (can’t verify the exact path right now, phone is busy) I still see one update available which I am allowed to download. However, that’s also the currently installed version afaik. Nothing big, just wondering if that’s expected.
I hope this feedback is somehow useful for the project. Don’t hesitate to make me clarify things
I’ve moved your post to this more general Divest OS topic since it isn’t directly related to questions about the bootloader.
The Divest OS developer isn’t that active in this forum, maybe try reaching him through one of the other ways of reporting bugs: https://divestos.org/index.php?page=bug_reporting
There’s also a Matrix bridge available to their XMPP chat:
I wasn’t able to. I somehow rebooted into my bootloader (active slot a) without that option, whereas a moment before I ended op in my bootloader with active slot b, where it was possible to enable adb sideload mode
