Extending our Sandboxed Google Play compatibility layer to support Android Auto is currently a top priority. It’s nearly ready to ship.
11 Likes
I guess that’s cool for those who use it. Still pretty sad that there isn’t an open standard for these car dashboard things though 
6 Likes
Just mount a Pixel Tablet running GrapheneOS in your car /hj
4 Likes
Do the pixel tablets have GPS?
3 Likes
Aww no, that’s a good point. I guess my half-joking dreams of a car mounted Pixel Tablet are dead. Weird that it doesn’t though.
1 Like
Yea bummer. Would be a great infotainment replacement if they did.
This is an absolute game changer! Can’t wait.
1 Like
The wait should not be too much longer 
While I don’t plan to use this feature, I am very grateful for the work of the GrapheneOS devs and contributors, and hope that this update chips away at the “not usable as primary device / daily driver” argument against GrapheneOS that’s perpetuated online.
3 Likes
Android Auto coming is good, but I was kinda hoping there would be work put into internationalizing the keyboard 
Not being able to input other languages with the default keyboard and needing to use Gboard is a big issue to me. I use my car’s internal navigation system instead of Organic Maps from my phone already. The international keyboard is probably the only thing that I’m missing from GrapheneOS of any significant notoriety.
Privacy-wise, I’d prefer Gboard without internet permissions to using any sort or built-in gps on a car
What do you mean exactly by internationalizing the keyboard? I have two languages set up in the AOSP keyboard and I can switch between the two with a long press on the space bar. It doesn’t have gboard’s clever 2 languages at the same time, but I can quickly select the language I’m about to type in before I start typing.
I have the two languages added as system languages (settings, system, languages) and the keyboard set up to use the system languages (settings, system, keyboard, on-screen keyboard, keyboard, languages)
May not be a GOS issue, could be upstream?
Why would GrapheneOS waste time with something like that? Users are free to install any keyboard they like, so there is no need for a first-party solution.
1 Like
Yes, specifically Japanese support.
What private, secure, open source Japanese keyboard would you recommend?
Don’t know anything about Japanese keyboards, but I nevertheless don’t think that developing a keyboard is a good invest of resources for GrapheneOS. In general I haven’t found anything better than Gboard for a lot of multi-language use and it has reasonable privacy and security. You could also try florisboard and openboard. Or you contribute your time and money to a keyboard project to make Japanese support better.
2 Likes
It was a trick question, because the answer is it doesn’t exist. Florisboard doesn’t support Japanese. Openboard doesn’t support Japanese. Any keyboard that does is at least 5 years out of date or proprietary.
I’d happily donate hundreds of dollars to a project that would take it (I’ve already donated to GrapheneOS), but there are no projects that will take it. I’m not going to learn Kotlin and read up on CJK Unicode specs to implement this or further develop mozc myself.
As long as we’re disagreeing, I would like to see GrapheneOS properly develop and extend all of the AOSP apps so they’re as featureful as the proprietary alternatives, as Google all but abandoned them years ago. And I’d like a calendar app.
Obviously this will never happen, but that doesn’t mean I can’t want it.
2 Likes
Sorry but I am going on a rant here… I know GOS team is working hard on a lot of features. Yet, and I am sorry to say this, using the “upstream problem” card is starting to bother me lately as it has been thrown out way too often in their forums or twitter/X.
Now, I understand that AOSP has bugs, but if I am a simple user of GOS, I should not care if it is “upstream” or “GOS” bug.