r134a

r134a It will eventually be supported but it could be in the far future.

GrapheneOS version 2025031300 released:

https://grapheneos.org/releases#2025031300

See the linked release notes for a summary of the improvements over the previous release.

Schmucks Now, I found out, when still using 4G, it had changed with both Pixel 8 and my old Samsung (which also had been not keeping up connecting all the time a few months back). Interesting is also, even when Mobile data is switched off, the 4G connection still is continuously keeping up connection with antenna towers and sending little data around each second! So this seems to be an issue of the new 4G system.

Perhaps.

As is the case with Wi-Fi access points, which can support various forms of client-side power-saving modes with various parameters, it seems quite likely that a given cell site can influence how often a registered device transmits.

But based on the information provided so far it's not 100% clear exactly what is being detected. Mentions have been made of multiple "RF meters" and "gadgets", but the details of those have not been provided. For all we know one of those "gadgets" is measuring something that isn't cellular transmissions... maybe it is Wi-Fi, or Bluetooth, or perhaps a spurious emission occurring when the GPU is powered down.

Schmucks So, to ask all grapheneOS developers: it would be wonderful for the future to have an option in my mobile where you can switch your mobile in an "only phone call mode" [...] That would be a great contribution to everybody's health!

Perhaps.

But I think a lot more details and experimental data would be required, and the phenomenon would need to be repeatable by others.

For example... which "RF meters" and which "gadgets"?

NotJamie A few seconds later I saw a lot of parallel connections in RethinkDNS from ANDROID to hundreds of IPs

ANDROID is a preset system user 0 (see this discussion on our github).

NotJamie How to find out what is causing this, what is the source?

At times, when getting owner UID for a socket, the Android APIs return ANDROID instead of the actual owner UID (in your case, you've empirically deduced that it was Syncthing). Rethink doesn't know any better and trusts what the Android API tells it.

NotJamie I don't have a good feeling about this.

This doesn't happen often, but I've predominantly seen it with apps that create a LOT of ephemeral (very short-lived) UDP sockets. Syncthing could be doing that for NAT traversal? I am not sure, you could clarify with the Syncthing developers.

n3t_admin I believe RethinkDNS is buggy with how it displays the origin of established connections or DNS lookups.

There may be bugs that we haven't fixed or don't know about, but for the most part Rethink is pretty accurate (given the Android APIs that Rethink uses are accurate) in accounting for network packets.

n3t_admin I see this mostly with my own domain, where supposed requests will go out to different subdomains, that are definitely in no way related to that app

The way domains <> IPs are mapped is what's problematic. A single group of IPs can be shared by multiple domains (common with Games and BigTech apps, like Google apps). It is also possible for a single domain to point to different group of IPs each time it is queried for. Rethink may end up mixing domains <> IPs mapping in a bid to be consistent with what the DNS layer in Android may have cached. That is, the "implementation details" (of the interaction between dnsproxyd in Android and Rethink's resolver) are what brings about the issues you're reporting.

For the next version, v055o (due in weeks from now... but I've been saying this since Sept 2024 ;), we'll see if there's a better way (without disabling caching in dnsproxyd) to keep dnsproxyd (and by extension, all Android apps that use it) happy and not incur this mixup.

TrustExecutor MTE can be used within virtual machines. GrapheneOS has been using it in microdroid virtual machines for a while which is a stripped down, very minimal form of the OS for running sandboxed low-level code without functionality like the higher level app runtime. Microdroid is barely used right now though.

nesakysiu1 We could give it a new icon later but it's also not only going to be a terminal app but rather a VM management app able to run GUI applications. Initial GUI support is shipping with our next release.

The Terminal app can still be used after you disable Developer options. 👍

block connection without VPN need to be disabled, since the terminal need to connect to the Debian VM on a local port. I didn't run it in Private Space.

Correct me if I'm wrong, currently this terminal interacts with the Debian VM but has no option to interact with the underlying Android host??

ToolTimeTim7 Afaik aosp, stock etc also do ahead-of-time, but only on major Upgrades. Question is: why is it useful to do this every time?

As clearly evidenced in the threads reporting on leaked Cellbrite documentation, GrapheneOS is more secure than Google's stock Pixel OS. So expecting GrapheneOS to do (or not do) things the same way as the stock OS is somewhat contradictory.

As another example, the GrapheneOS memory allocator paves over memory more often than the allocator on the stock OS.

I don't know exactly why GrapheneOS recompiles applications on every update. But I can readily imagine that somebody inside Google might have figured that recompiling less often would be a better user experience while being "safe enough". And I can readily imagine that the GrapheneOS authors decided it would be better to be safer instead of "safe enough".

in_search_of_privacy Some keyboards act as USB hubs. Others have built-in track pads.

Plugging in a USB device you own while the phone is unlocked is arguably a reasonable risk (and not clearly more risky than activating the Bluetooth stack).

relay I have build 2025030800 installed on my Pixel 8. I enabled Linux development environment and installed Terminal app. It constantly keeps crashing. Is it not stable yet?

The first words of the first post in this thread are "For our next release after 2025030800". If you are running 2025030800 then you are not running the release after 2025030800.

oldschoolmemories It's for running other operating systems in a virtual machine, not running them side-by-side with the main OS. Stock Pixel OS is built to run on Pixels, not in a virtual machine. GrapheneOS builds for the virtual machine environment can be added eventually and turned into a way to seamlessly run apps in a virtual machine.

For our next release after 2025030800, we've added support for the Android 15 QPR2 Terminal for running other operating systems using hardware virtualization. It's currently only a terminal but Android is adding support for graphics and GPU acceleration for a future release.

Android has a greatly overhauled desktop mode on the way to replace the current primitive proof of concept in developer options. 6th gen Pixels added hardware-based virtualization support and 8th gen Pixels added USB-C DisplayPort alternate mode. It will all come together soon.

Overhauled desktop mode is already partially shipped as a disabled-by-default feature. Android enables some of it for the Pixel Tablet already but not Pixel phones. We plan to enable the same feature flags for phones too. Either way, it's an experimental developer option for now.

Beyond using a phone or tablet as a desktop by connecting a display, keyboard, mouse, etc. to the USB-C port, we want to eventually have support for GrapheneOS on laptops. There's currently no laptop close to meeting the hardware requirements we cover at https://grapheneos.org/faq#future-devices.

On Pixels, virtualization implemented based on pKVM (see https://source.android.com/docs/core/virtualization/security for how it's different from KVM) and CrosVM from extended with Android specific code. CrosVM is written in Rust so it fits in well with Android using Rust for new or rewritten low-level components.

This post is also available on social media platforms as a thread:

Bluesky: https://bsky.app/profile/grapheneos.org/post/3ljxaoabcds2j
Mastodon: https://grapheneos.social/@GrapheneOS/114132940314692519
X: https://x.com/GrapheneOS/status/1898742463277207630

Jeff

but this doesn't really work out for my use case at least, because of how it separates files, when I take a picture, it's only accessible on the profile it was taken on.

Use a Private Space for more convenience. It's still separated but it's possible to share files between them, etc. with the system file management interfaces.

Chipper portable 4g router

I wouldn't use one of those. The project has a thread about a lot of what's being discussed in this thread and touches on mobile routers here: https://grapheneos.social/@GrapheneOS/113319956422621755. Some relevant quotes about mobile routers are as follows:

Dedicated Hotspot devices aren't good for privacy/security.

[B]ear in mind that carrying around a Wi-Fi access point (AP) is the opposite of private. An AP has a persistent MAC even if it's random upon creating the AP such as making a hotspot with a phone. Wi-Fi does not have MAC rotation like Bluetooth Low Energy privacy extensions.

GrapheneOS uses per-connection MAC rand and per-connection DHCP as improvements over the standard Android Open Source Project. The MAC still remains the same while connected, and an AP isn't going to cycle until it's reset. Wi-Fi does not try to do what BLE privacy extensions do.

r134a It's not even that you need an email, if you want to sign up now you need an identity provider to sign up, using Google, apple, Ms etc..

This is not private nor anonymous. Which as I said is both good and bad, but for me this is a no go and unneeded hurdle.

K8y If your looking at a portable 4g router such as the mudi you may also be interested in this
https://www.srlabs.de/blog-post/blue-merle