Our initial port to Android 16 has been completed and can be built for the emulator from our 16 branch. All of the device-independent #GrapheneOS code has been ported. There are some parts of the port which will be redone better and a lot of testing and fixing regressions to do.

Normally, we would have announced the availability experimental releases based on Android 16 already. Unfortunately, Android 16 dropped device/hardware support from the Android Open Source Project and we're going to need to put it together ourselves without being prepared for it.

We'll be starting from the Android 15 QPR2 device support code and stripping it down to a bare minimum. Pixel 9a is a special case and will be more work.

Our hardware-based USB-C port control feature will no longer work with this approach and we need to replace half of the code.

We received early notice of Android 16 removing the device support code from AOSP but were unable to confirm it or determine the details. We have existing automated tooling for this we can significantly extend to generate what we need. It will be difficult and a major regression.

Paying an ODM to make a Snapdragon device for us is increasingly appealing. We would have all the device support code we need, could build it with compiler-based hardening and would be able to harden a lot of the device's firmware. We could also make secure element applets.

We want to be building privacy and security features. We don't want to be wasting our efforts on adding device support and other basic functionality to AOSP. It appears the only way we're going to be able to do that is paying millions of dollars to an ODM to have a proper base.

As an example of what we would be able to do even with an entirely standard reference device, we could add hardware support for our duress PIN/password feature to the secure element so that successfully exploiting the OS could not bypass it. We could do a whole lot with firmware.

Pixels meeting our requirements is why many of them were and are being purchased. We've reported MANY vulnerabilities over the years which have been fixed for Android and Pixels. We've proposed hardware, firmware and many software level security enhancements they've adopted.

We would prefer not having to pay millions of dollars to have a phone produced for us. It's entirely doable but we would need to repeat it every few years. We'd rather work with an OEM with aligned goals and willing to provide first class GrapheneOS support to sell more devices.

Pixels have substantially benefited from meeting our requirements and having GrapheneOS available for them. We know there's a significant market for an OEM working with us to make a more secure device with hardware-based security features not available on Pixels or iPhones.

Reply to this note

Please Login to reply.

Discussion

I heard https://www.generalmobile.com/ is considering using grapheneOS, maybe worth to reach out.

Sent it to the right people. I know we are in contact with numerous parties about what we could do.

GitHub page for the Pixel AOSP porting effort:

https://github.com/pixel-aosp-16

Yeah, this sounds rough. Google dropped support, so now you have to build it yourself. That takes time and energy you’d rather spend on real security work. Making your own phone or working with a good OEM makes sense, even if it costs a lot. People want what you're building.

We have early builds based on Android 16 booting on Pixels but will need to do a lot more work to reach production quality.

We're also beginning building/testing backports of Android 16 firmware updates to Android 15 QPR2 with the aim of releasing those patches to Alpha today.

It seems the time has come to realize that it is time to go to Plan B and build both privacy focused hardware and software. I'll bet there are many folks in the bitcoin/nostr/privacy space who would support/promote this work

Looking at folks like nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyehwumn8ghj7mnhvvh8qunfd4skctnwv46z7ctewe4xcetfd3khsvrpdsmk5vnsw96rydr3v4jrz73hvyu8xqpqsg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q8dzj6n nostr:nprofile1qyv8wumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wsq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgqgzx3h nostr:nprofile1q9z8wue69uhnvmr9dp58jernwf6xsct8d45hxdn4w5m8gatrdej8v7nhxa3h2cnsw94ksanc09unw6n0d9hkxdp4d44hxu35v4skgtn0de5k7m30qy88wumn8ghj7mn0wvhxcmmv9uqzq44xkafh8j8hhy79809wsmv0lw46nu4pkwqjyp20ekml80mytde8phfu08 nostr:nprofile1qythwumn8ghj7enfd36x2u3wdehhxarj9emkjmn9qy2hwumn8ghj7mn0wd68ytndd9kx7afwd3hkcqpqtr4dstaptd2sp98h7hlysp8qle6mw7wmauhfkgz3rmxdd8ndprushmlfze nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcqypu8xwr40lp96ewdj2fef408wy70gd3carf9n6xu7hrnhq6whpgly925h0z nostr:nprofile1qyf8wumn8ghj7cnfw3ehgctrdvhxzursqythwumn8ghj7cmp9ehhyctwvajhq6tvdshxgetkqqs0rxy6jmt44guxkny8z4pkym9mxckqxfytygxuntjn6l80hj409sggjrzcm nostr:nprofile1qythwumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t6qy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqqgzccaq65ccv9k3454480sws2wqepz73q5z0m5kckslhyhh6d533jc25xncl nostr:nprofile1qyt8wumn8ghj7ct5d3shxtnwdaehgu3wd3skueqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqqgyymmnwvah9hdnmft2wqsk0wr9as6q32hd4xk2zlnr2q5ectznjgqd27v94

"We would prefer not having to pay millions of dollars to have a phone produced for us. It's entirely doable but we would need to repeat it every few years. We'd rather work with an OEM with aligned goals and willing to provide first class GrapheneOS support to sell more devices."

Wanting to have our own devices doesn't mean that the campaign to have OEMs making a device we can use now is not still ongoing. If all the currently supported Pixels become end-of-life and all we have is devices we created, then all that has happened is we have moved the goalposts.

OEMs should be more open to allow users installing other operating systems and to support more hardware security features. They benefit from having us able to use their platform, just like we have reported numerous security vulnerabilities upstream to Google.

If a device manufacturer is making a device like this without us needing to pay them for a bespoke product, funding can go elsewhere which is good for us.

Wanting vs. actively pursuing (vs. keeping it on the backburner as a plan B for the future) are two different things. My point is simply it may be time to prioritize that effort vs. thinking you'll be able to convince google to continue being open to installing alternative OS on their hardware.

Everything points to them pivoting in the other direction.

When you say the Pixel 9a is a special case, are you saying there are issues with using GrapheneOS on this device? Could you please clarify?

The stock Pixel OS and GrapheneOS on the Pixel 9a are missing Android 15 QPR2 features since it's branched off QPR1 when it released.

Slightly more work needs to be done on that device but once Android 16 port work is complete all devices will be on the same.

Does missing Android 15 QPR2 features make it a security risk? Is there any reason not to use the 9a with GrapheneOS as is? Or are you saying it isn’t possible to use the 9a with GrapheneOS until Android 16 port work is complete?

It's mostly just Android features than security related, but still better to be forward.

You can use the 9a with GrapheneOS now, it just doesn't have the QPR2 features. It will skip straight to 16.