Don't know about terminal emulators but vim can do this by specifying the URL for g:session_directory. Sessions are simply files and they can be sourced both from your computer or server-side store
The fact that you could buy a Pixel (or Nexus), real hardware sold to consumers as a phone, download AOSP (and proprietary blobs), and get a working build with all hardware supported with no additional work was super appreciated.
Cuttlefish, while it may be a more effective reference device, just doesn't accomplish the same thing because Pixels were used for more than just as a reference target (e.g. GrapheneOS).
Plus, there's just something cooler about running your own build of Android on real hardware v.s. a VM.
> Cuttlefish, while it may be a more effective reference device, just doesn't accomplish the same thing because Pixels were used for more than just as a reference target (e.g. GrapheneOS).
The article mentions that they're also supporting GSI's as a reference target of sorts, and that's way closer to real hardware. GSI's are annoying for other reasons though - for example, there isn't a single "GSI" build type, they vary according to low-level device features (such as partitioning) and what version of Android they first came out with. Still, it's better than nothing.
These days there's also GKI, a "generic kernel build" (minus custom modules and blobs) that's supposed to work on any recent device. Note, this is not a "mainline" Linux kernel at all, it's still very much a downstream fork with lots of custom patches. But it too is supposed to enable testing and development in a unified way, regardless of the actual device.
On Android devices, without a serial console, this is often your best way to get logs for crashes happening before Android starts up enough to stream logs with logcat.
Most likely referring to CVE-2018-6242 aka "Fusée Gelée"
The paperclip was just the easiest way of triggering RCM, which is a standard feature on Tegra. The vulnerability lay in that they didn't bounds check certain types of USB requests properly.
17 out of 20. Was super easy until #10 and I had to stop and think more carefully (which was actually my first mistake), and then I got #14 and #15 wrong. The score was about what I expected, though - would've been surprised if it was <15 correct.
I wonder how much of this would come down to screen calibration / color accuracy? If everything's consistently off in 1 direction I guess not much, but I would imagine certain shades might appear effectively the same on some cheaper screens?
I think a lot of the work is in new device bringup, and given that they can start from official Pixel trees, it shouldn't be too much work to adapt them for whatever GrapheneOS-specific build processes they have, and then I'm assuming the rest of the GrapheneOS customizations are framework side which should be device agnostic. I guess they could have kernel changes for hardening, but not sure how easy or hard porting those would be - is the Pixel 9 series on a newer kernel version than say the Pixel 8?
GrapheneOS has various features requiring hardware integration. Our hardening features also uncover bugs across the code especially in drivers, especially the hardware memory tagging integration in our hardened_malloc project and the standard Linux kernel hardware memory tagging support we use in the kernel. Pixels are very similar to each other though so this work is largely but not entirely done for them.
Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it.
See https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025.
Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
reply