Osmand and GMaps are working fine.
Waze is almost melting the poor thing. Beside of that working fine.
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.
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.
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.
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.
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.
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.
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.
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 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?