GrapheneOS – When an app is slow (blog.wirelessmoves.com)
69 points by speckx 4 hours ago
negative_zero 3 hours ago
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
BlackRabbit1 2 hours ago
CoMaps behaves very very weirdly on GrapheneOS. Same with OrganicMaps.
Osmand and GMaps are working fine.
Waze is almost melting the poor thing. Beside of that working fine.
pizzaiolo 14 minutes ago
Weirdly how? CoMaps seemingly works fine out of the box on my device
subscribed an hour ago
Osmand and OrganicMaps work flawlessly for me. Waze on 6 (not pro), works better than on my 9 Pro.
broodbucket 2 hours ago
Waze works perfectly fine for me
DuncanCoffee 2 hours ago
ThePowerOfFuet 2 hours ago
I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
aucisson_masque 24 minutes ago
What is the point of this hardening feature if you got to disable it ?
You can tweak Android as much as you want, the OS was not made to be private nor secure. App developers will never check if it breaks the grapheneos memory allocating feature (amongst others) so by default you disable it.
Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.
progval 14 minutes ago
It's meant to protect apps against their own bugs. It's an improvement to be enabled by default and disabled for the few apps where it's an issue.
Groxx 2 hours ago
Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
WalterGR 2 hours ago
Groxx an hour ago
I mean OsmAnd - other mapping apps don't slow down anywhere near this much.
OSM-rendering apps are a fair bit more computationally-expensive than many apps, so I do expect them to show the allocator's cost more, but OsmAnd stands out quite starkly against every other app on my phone.
hadi77ir 2 hours ago
I wonder if a website using leaflet.js has better or worse performance in the said case. If it does better, then maybe the problem is on OsmAnd's side?
pjmlp 3 hours ago
Maybe the actual solution is to improve, replace the application.
izacus 3 hours ago
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
Groxx 2 hours ago
The fairly obvious answer here is "OEMs don't care about security because very few people will pay for it, either with $ or time". Benchmaxxing sells better.
izacus 2 hours ago
pjmlp 2 hours ago
Because they cut costs on hardware and not all ship MTE enabled ARMs.
palata 2 hours ago
Maybe... legacy?
mohamedkoubaa 3 hours ago
There needs to be a wall of shame for apps that abuse hardware owned by users
yjftsjthsd-h 3 hours ago
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
pjmlp 2 hours ago
perching_aix 3 hours ago
RKearney an hour ago
"Before installing, please turn off all anti-virus and firewall software."
perching_aix 3 hours ago
If you have two apps, both maps...
> The reason behind it is the hardened memory allocator, which seems to create a significant overhead for Osmand. That might be because scrolling a map requires constant loading and discarding of data.
... is this really the right hunch, over e.g. the OpenStreetMaps app lacking in discipline with its heap allocations?
himata4113 3 hours ago
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
someonebaggy 30 minutes ago
C++ memory allocator choice probably wouldn't affect Java code, which has its own heap algorithms.
RedComet 2 hours ago
The core is C++ afaik.