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.
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.
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?
Really? They're not using Scudo? The hardened_malloc used in GrapheneOS has a bunch of performance issues that were trade-offs against security. Every other major android distribution uses scudo as far as I know. Which OEMs are you thinking of?
Edit: Did some research after writing this? It appears that Samsung may be still using jemalloc, albeit a newer version than the one from the Android 11 days.
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.
Let's first start with y'all providing any proof that it was "benchmaxxing" that causes OEMs not to ship hardened allocators (and not - for example - breaking compatibility with users' software).
And then we can move the goalposts to "more secure distro with GrapheneOS" which isn't part of the conversation until you dragged it out.
If you're expecting some leaked internal document that says "priorities: 1. benchmarks, 2. security", no, that probably doesn't exist. But their priorities are revealed by their actions.
GrapheneOS typically ships security updates within a day. But most of Samsung's phones get quarterly security updates[1]. There will never be a primary source with a Samsung insider saying "we're fine with our customers being vulnerable to widely exploited security bugs for the next 89 days, in order to save our massive corporation a few thousand dollars a month." But their priorities are revealed by their actions.
If the statement "OEMs don't care about security" is trivially proven false, as you said, then you should be able to prove it trivially by naming even just a single OEM whose update cadence matches GrapheneOS's.
Also look at their advertising. Endless "X% faster" mentions that often get significant visual space, but when was the last time you saw "security updates 7 days earlier" or "tagged memory for better safety"? Even a single mention of "security" on a phone's manufacturer page is uncommon, and that's usually just mentioning a normal Android feature, or something like Knox or Secure Folder and not "we made choices that make a common class of attacks much more difficult or impossible".
The numbers aren't zero, certainly. Nor does it imply directly proportional levels of effort. But they are incredibly obviously given wholly different levels of attention on nearly all phones, by nearly all phone manufacturers.
> 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?
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
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.
I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
Waze works perfectly fine for me
Anyone writing about apps compatibility should specify if it's with or without the play services
Can you even run Waze/GMaps without Play services?
Yes.
For more precision:
Waze is fairly easy to run without play services. GMaps I haven't yet found a way to run, but also haven't looked in quite some time.
Waze and Here Maps work well.
Osmand and OrganicMaps work flawlessly for me. Waze on 6 (not pro), works better than on my 9 Pro.
Weirdly how? CoMaps seemingly works fine out of the box on my device
Have had no noticable problems with organic maps.
And yet problems exist. Live Updates are not rendered if both OsmAnd V2 rendering and hardened memory allocator are enabled: https://github.com/osmandapp/OsmAnd/issues/20190
Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
https://news.ycombinator.com/item?id=45358216
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.
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.
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.
> Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.
?? GrapheneOS does respect horrid play integrity (it provides basic integrity only).
Not that this has any bearing on how an app runs performance-wise.
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?
Maybe the actual solution is to improve, replace the application.
There needs to be a wall of shame for apps that abuse hardware owned by users
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
The AOSP memory allocator is seldom the one used by OEMs.
Really? They're not using Scudo? The hardened_malloc used in GrapheneOS has a bunch of performance issues that were trade-offs against security. Every other major android distribution uses scudo as far as I know. Which OEMs are you thinking of?
Edit: Did some research after writing this? It appears that Samsung may be still using jemalloc, albeit a newer version than the one from the Android 11 days.
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
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.
That's trivially provable as false.
If so, I'd love to know which OEM you're thinking of who ships an Android distro more secure than GrapheneOS.
Let's first start with y'all providing any proof that it was "benchmaxxing" that causes OEMs not to ship hardened allocators (and not - for example - breaking compatibility with users' software).
And then we can move the goalposts to "more secure distro with GrapheneOS" which isn't part of the conversation until you dragged it out.
If you're expecting some leaked internal document that says "priorities: 1. benchmarks, 2. security", no, that probably doesn't exist. But their priorities are revealed by their actions.
GrapheneOS typically ships security updates within a day. But most of Samsung's phones get quarterly security updates[1]. There will never be a primary source with a Samsung insider saying "we're fine with our customers being vulnerable to widely exploited security bugs for the next 89 days, in order to save our massive corporation a few thousand dollars a month." But their priorities are revealed by their actions.
If the statement "OEMs don't care about security" is trivially proven false, as you said, then you should be able to prove it trivially by naming even just a single OEM whose update cadence matches GrapheneOS's.
[1]: https://security.samsungmobile.com/workScope.smsb
Also look at their advertising. Endless "X% faster" mentions that often get significant visual space, but when was the last time you saw "security updates 7 days earlier" or "tagged memory for better safety"? Even a single mention of "security" on a phone's manufacturer page is uncommon, and that's usually just mentioning a normal Android feature, or something like Knox or Secure Folder and not "we made choices that make a common class of attacks much more difficult or impossible".
The numbers aren't zero, certainly. Nor does it imply directly proportional levels of effort. But they are incredibly obviously given wholly different levels of attention on nearly all phones, by nearly all phone manufacturers.
> Let's first start with y'all providing any proof
Your trivially proving things can't involve asking other people to prove the opposite of things. You've instantly backed down.
> And then we can move the goalposts
Why? You haven't done anything except ask others to do things. You've moved the goalposts from trivially falsifiable, and started begging.
Because they cut costs on hardware and not all ship MTE enabled ARMs.
Maybe... legacy?
"Before installing, please turn off all anti-virus and firewall software."
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?
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
The core is C++ afaik.
C++ memory allocator choice probably wouldn't affect Java code, which has its own heap algorithms.