Google’s got a new update coming for the Pixel 4a that could have a negative impact on battery life. Luckily, Google’s offering some generous compensation options.

  • @[email protected]
    link
    fedilink
    English
    42 days ago

    That i am not sure of. I assume it uses whatever kernel is required by the Android version that it’s running on. So only if the Android version requires a new kernel, would there be one? At least that’s my guess. I think GKI from android 12 and above was supposed to make kernel updates easier but im not sure.

    • @j4k3
      link
      English
      22 days ago

      This is what you should be looking into. Most ROMs on other phones are jacked using a kernel vulnerability. The Pixel has the TPM chip and the ability to use it to secure a side loaded and encrypted OS. Android relies heavily on a totally locked down and immutable Linux kernel. Everything you see in the mobile user space is basically a single application running on top of Linux. The reason root and all of the binaries that can modify the base system have been removed is because all apps have the same privileges as the user under the hood. This is how users do not need to understand OS security or networking but the thing just works. It just works because every app is a whole user on your device. There is also an element of failsafe safety built into the system. If any app runs bad code that would do terrible stuff on a full version of Linux, it simply does nothing in Android by default. All the bad stuff is limited, constrained, or missing. When you run a custom ROM, you need to understand how this works, like how SELinux uses app access context to allow or deny many behaviors, or why packages are set to certain permissions or missing.

      All of this is happening within one application that is running on Linux. The Linux part has little to do with the Android applications space. This is not an open source Linux kernel. Google’s scam is that it repackages a kernel for Android that only requires manufacturers to add the binary support for their hardware at the last possible moment. The hardware support is not open source. This is not code uploaded to the mainline kernel. This is called an orphaned kernel. No one can recompile the kernel again without the source code for the hardware modules of the device. The only thing someone can do is for an extremely advanced dev to backport fixes to the old kernel while tracking all changes to the new mainline kernel. Only very advanced devs are capable of understanding both the ancient kernel from the device, and mainline in such a way that they can make the security changes without altering the kernel in a way that breaks the SoC or Modem modules. It takes someone that is very motivated to do this kind of support. More often, the kernel is not supported. While you may be able to install the OS, the kernel is unlatched and full of vulnerabilities. There may be a big difference between use case intentions of supporters and end users. Some dev may be using the device as a limited use monitoring camera or something, and expects everyone to know not to use the device for anything secure or serious.