Rendered at 19:49:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Groxx 54 seconds ago [-]
[delayed]
negative_zero 30 minutes ago [-]
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
pjmlp 46 minutes ago [-]
Maybe the actual solution is to improve, replace the application.
izacus 38 minutes ago [-]
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
mohamedkoubaa 42 minutes ago [-]
There needs to be a wall of shame for apps that abuse hardware owned by users
yjftsjthsd-h 30 minutes ago [-]
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
perching_aix 10 minutes ago [-]
That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
perching_aix 48 minutes 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 39 minutes ago [-]
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
> 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?