> Stock Pixel is an awful experience. So many useless notifications, popups, ads, privacy not by default.
Huh? What pixel are you on? You only get notifications from stuff you install after the initial setup is done. And even then you can outright mute applications, completely.
I was on stock recent pixel A17 for a few hours before flashing GrapheneOS. They took over the power button for Gemini, there's gemini in Messages, there's 50 apps you don't need. Yeah you can disable notifications but it was constantly giving tips and tricks and other bullshit. The OS feels super bloated compared to GrapheneOS.
I hate the power button change myself, but 1. It was turned into the Assistant button by default for many years now. 2. Can be switched back easily in settings.
> there's 50 apps you don't need
Where are you getting your pixels? Mine came with all the essentials, I don't remember disabling anything in particular. No game demos, no preloaded meta cancer, just the normal google suite.
> The OS feels super bloated compared to GrapheneOS.
When was that ever not the case? When was a stock OS lighter than a custom flavour on any phone? You can't ship Android in the state that custom OS-es do, you won't pass the certification to get Google's goodies like OTA service and preinstalled play store. Don't quite get the Gemini argument either. You're buying a Gemini phone that touts AI everywhere on its promotional page. What do you expect?
> Hmm... Let's try reframing this: "as much as it seems beloved here, people that install their own operating systems on PCs are the very definition of niche users"
I mean yeah, 99% of people never installed an OS and never will, what's your point here?
> 99% of people never installed an OS and never will, what's your point here?
That the 1% who do build visicalc, Linux, the internet, Google, and every application and innovation that happens outside the corporate wall. The entire ecosystem everyone else ends up using.
And that calling that niche is ridiculous, shortsighted, and shooting oneself as a platform owner in the foot.
What are you talking about? You're making zero sense. I've been in the niche of modifying and installing my own ROMs, then to kernels, and now doing the same things commercially.
It is a niche, it always was. There was never a mass community of users, the most installs you used to see on any given AOSP based project is maybe 20-30K for the most popular devices like Redmis, Pocos or Google Nexus phones.
It's still a niche, and things that users do and used to do to their phones are fundamentally incompatible with Android's security model. Root access, magisk, xposed, overall zero or near zero security validation from the security perspective on all ROMs but Graphene (maybe some others, I haven't followed the sphere for a while).
Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC.
Kinda sounds like you might be younger and didn't live through the 8bit micro -> PC transition. Standardization of the platform led to a cambrian explosion.
> Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC.
Couple of things here. Android was never that open to begin with. There were always (and still going) issues with the kernel sources being withheld indefinitely, AOSP side changes are almost never released at all, iirc only Google released anything. Bootloaders were always an issue, not all manufacturers had unlockable (or easily unlockable) bootloaders.
Ironically, Google were always the spearhead of the standartization in the Android world. Project Treble and stuff resulted in the fact that almost any Android device released these days can run a generic Android image, it's not gonna be as functional as the original Android, but it's something.
Yes, I am on the younger side, that's why I know how it was in the Android world. Nobody is interested in reinstalling OS-es on their phones because the amount of effort to create an Android ISO that's as usable as what's preinstalled is truly gigantic. Android flavours are heavily customized for the needs of the OEM, and for the hardware that they're gonna run on.
It's a niche, always was and always will be. A niche powered by a few large players like LOS or GOS, that actually get paid somehow or heavily work for the idea, and an army of teenage unpaid maintainers, who quit the maintainership as soon as they get a properly paying job that takes most of their time (me).
> Nobody is interested in reinstalling OS-es on their phones because the amount of effort to create an Android ISO that's as usable as what's preinstalled is truly gigantic.
It's pretty clear that you have an extremely limited exposure to the custom Android development space, since you never rebutted any of the points I brought up. Custom android was never easy and never will be. And it's fundamentally incompatible with the concept of having a truly secure env on your device (same as in the PC space, ironically enough).
Son, I've been building and installing custom roms since the HTC Dream, was involved in OpenMoko, and have owned nearly every open or Linux-running phone of the last 30 years back to the Sharp Zaurus and iPaqs.
Your custom rom experience sits wholly within a larger category of computer systems experience about which I've been speaking.
The sort of fragmentation you describe is a symptom, not a foregone conclusion.
> The nearly useless LED added to the back of the Pixel 11 likely costs significantly more than the extra die space for MTE support in the CPU cache.
How is a bunch of LEDs more expensive than literal die space from TSMC? The chip is probably the most expensive part of the phone, a bunch of LEDs at a few cents per unit are infinitely cheaper than extra die space for a feature 99.99% of users won't use.
The amount of die space needed to support MTE is minimal. MTE is used for Android Advanced Protection Mode and will very likely be enabled by default in future Android versions. If the Pixel 11 doesn't enable support for it then it's going to be missing a protection available on the Pixel 8 through Pixel 10a.
You keep repeating this everywhere but this is just plainly wrong. They went from an old big.Little (with middle cores) arrangement that everyone abandoned for flagship chips generations ago, with core arches that were 2-3 generations behind competition, to a modern, up to date arrangement. There's literally nothing newer that they could've gotten from Arm, and other CPUs are releasing with C1 generation.
And I don't get your angle on the GPU. GOS is not gaming oriented, Pixels are not gaming oriented, and never were. They have a decent NPU to handle AI, a decent ISP to handle cameras, what more do you need the GPU for? Why would they put in a PC grade monster like Qualcomm?
Same for the modem, it's well known that Qualcomm are way ahead of the game, but they also charge like crazy for their SOCs and are a horrific partner to work with. They treat clients like shit, I get why Google ditched them when they were able to.
And you keep recommending P10 when it's genuinely a non improvement over P9, with worse battery life and running hotter, and the same modem. What the f is your angle? Is Micay back to GOS?
The CPU is 10-15% faster, that’s incremental in use even if it’s technically interesting.
Lots of apps and websites only run smoothly on newer GPUs, too. You can play the “they’re dumb and I just won’t use them” game, but not everybody has your priorities, and it’s a relevant factor either way.
The modem comment, likewise, is simply correct, and evaluating performance is good even when shortcomings are understandable.
They supported Pixel 10 because they supported every new Pixel that wasn’t a security downgrade and shortly preceding a better alternative. The logic isn’t “performance bad therefore no upgrade”, it’s “no upgrade for a bunch of other reasons, and it’s not like we’re missing out on a 3x performance improvement”.
> Lots of apps and websites only run smoothly on newer GPUs, too.
GPU is barely used in non-3D applications. My OP15 runs normal apps and websites just as well as my Pixel 10 Pro did. Speedometer 3.1 returns 10% higher scores in favour of the OP, even though it has the latest and greatest qcom chip.
UI experience is all about scheduler tuning, drawing pipeline optimizations and (to a much lesser degree) single core performance. Anything above Cortex X1 can have perfect 120 fps anywhere, without a major energy penalty, if the software is well optimized. I know because we did experiments like that when I was still doing custom Android kernels.
Not a single time did we need to do anything to the GPU, most of the time it's in 2D clocks and never wakes up.
> They supported Pixel 10 because they supported every new Pixel that wasn’t a security downgrade and shortly preceding a better alternative. The logic isn’t “performance bad therefore no upgrade”, it’s “no upgrade for a bunch of other reasons, and it’s not like we’re missing out on a 3x performance improvement”.
Not my question. I get why P10 was supported, I don't get why it's recommended by the person running the account, when it's objectively just a more expensive P9 with worse battery life and running warmer.
Pixel 10a is the most recently released recommended device. It has the same SoC as the 9th generation Pixels with a far better cellular radio than the Pixel 9a.
Pixel 9 to Pixel 10 had a bigger incremental CPU upgrade than the Pixel 10 to Pixel 11. GPU was initially a downgrade due to poor drivers but that was resolved already.
Pixel 10 has various small but significant security advantages over the Pixel 9. Pixel 11 would similarly have small security advantages if they hadn't ruined the overall security by removing MTE.
We definitely do want better CPU, GPU and radio performance for flagship devices and haven't been happy with those on Pixels. It doesn't outweigh security updates and security features but it matters to us. We're going to be a lot happier with a next gen flagship Snapdragon SoC for many reasons.
Getting a 15% increase to CPU performance is an incremental upgrade to the CPU performance. We expected a much better improvement from the new CPU architecture. It's quite disappointing and the removal of MTE support is even more disappointing. Using HWASan instead of MTE would have around 2x CPU overhead, 25% memory overhead and would not provide nearly as much of the security benefits due to only working for code instrumented with it. Compared to doing memory tagging using HWASan, decent MTE support is an incredible performance boost.
GrapheneOS works well for running games and people can toggle off hardened_malloc and MTE for a game to eliminate nearly all of the performance difference. It doesn't usually make any noticeable difference. GrapheneOS is intended to be fully usable by everyone including people who care about GPU performance whether it's for games or other apps. Claiming GrapheneOS isn't gaming focused is your opinion. We care a lot about compatibility with games and have put effort into it. Pixels using a GPU with poor gaming compatibility and performance wasn't our choice and doesn't mean we don't care about it.
> and the same modem
Pixel 10a has a drastically better cellular radio than the Pixel 9a. The 'a' series Pixels are consistently the most popular devices supported by GrapheneOS. Pixel 10a is still the latest one so there isn't going to be any gap in people being able to buy a new device for GrapheneOS if we don't add the Pixel 11 and instead skip right to Motorola flagships and then more Motorola devices. We hope the Pixel 12 adds back MTE support but aren't optimistic.
> back to GOS?
You're directing abusive comments towards our team based on highly inaccurate harassment content.
All these funny jabs at Android's security meanwhile Pixels are literally one of the most secure devices in the industry and Google invest tons into security.
Hardware attestation stands unbroken to my knowledge, only software attestation can be faked, and even then it's a constant cat and mouse game which Google continues playing until they are done with Pixel 3 generation.
C2PA is not immune to the analogue hole, sure, but dark room + photo of a photo approach falls apart the moment you bake in depth data into the image, which is already done.
Pixel 2 and later had hardware attestation, not the Pixel 4 and later. Devices launched with Android 8 or later were required to support it.
Android hardware attestation using root-based verification is highly insecure. It depends on the weakest links in the overall ecosystem. There are tons of leaked keys from insecure TEE implementations. People can often even downgrade to an ancient TEE implementation to exploit it when anti-rollback wasn't used for updates. Devices never updated since launch can be used to get keys via known vulnerabilities. Google doesn't revoke all the known leaked keys because it would break compatibility across many devices. Originally, private keys were provisioned to 100k or more devices in batches. They've moved to a system where each can get a unique key and then the ones used by apps are dynamically rotated but it's only the Pixel 7 and later using it in practice for Pixels and other devices took far longer to adopt it. That only got forced in the past year or so for other devices.
Android hardware attestation using pinning is highly secure on devices with a good implementation but that doesn't work for this use case. It could work for giving out phones to people and then verifying those are still genuine, not tampered with and have continued applying updates on an ongoing basis.
The swapiness section is incorrect. If I remember correctly swapiness does the same thing for swap and zram, which is how quickly the given partition starts to fill up. So for swap on hard drives you want it as low as possible, so you're using swap as late as possible. For zram you kinda really want it as high as possible, especially when the amount of ram is low, so it starts compressing early.
Some Android OEMs experimented with zram swapiness over 100, up to 200, so it would start compressing immediately.
reply