- 110comments
- 5comments
- 8comments
- 14comments
- 34comments
- 2comments
- 217comments
- 131comments
- 7comments
- 10comments
- 17comments
- 17comments
- 210comments
- 50comments
- 79comments
- 82comments
- 13comments
- 28comments
- 12comments
- 111comments
- 47comments
- 107comments
- 32comments
- 34comments
- 987comments
- 3comments
- 89comments
- 5comments
- 39comments
- 51comments
If you have two apps, both maps...
... 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.
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.
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.
Because they cut costs on hardware and not all ship MTE enabled ARMs.
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
CoMaps behaves very very weirdly. Same with OrganicMaps.
Osmand and GMaps are working fine.
Waze is almost melting the poor thing. Beside of that working fine.
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