37points · 1h ago
GrapheneOS – When an app is slow
blog.wirelessmoves.com·by speckx·1h ago
Discussion 9 comments
bestnew
⌘↵ to post · markdown supported
Groxx·6m ago
Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
0
·35m ago
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
0
·51m ago
Maybe the actual solution is to improve, replace the application.
0
·43m ago
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
0
·4m ago
[delayed]
0
·4m ago
Because they cut costs on hardware and not all ship MTE enabled ARMs.
0
·47m ago
There needs to be a wall of shame for apps that abuse hardware owned by users
0
·35m ago
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
0
·3m ago
The AOSP memory allocator is seldom the one used by OEMs.
0
·15m ago
That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
0
·53m 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?
0
·44m ago
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
0