I've thought about building something like this, but it just seems like a ton-o-work. This project seems to have maps+camera, no media player yet.
I do run/build a lot of my own stuff (my own web/email server managed via ansible/docker), I run custom Android roms and I do like building things myself, but with the time tradeoff, I just find it easier to get a Pioneer nav/media unit. (Tried the Joyen Android versions for a bit too, but it's difficult to get a good/safe car UI setup in Android).
People had a very hard time believing that all of those songs were "in the player".
Feels like the dawn of history now. Good Lord I'm old.
Wish someone still made these displays, even in just smaller sizes!
I'm not at all sad to have traded them in for even lousy LCD. But don't sweat it, OLED is a worthy replacement!
I bet now you'd get a RIAA lawyer in your face before that newspaper hit your doorstep.
And you do need a good car UI if you want to use something in your car, a normal phone interface isn't well suited to safe operation in a car. You want large, oversize buttons, large, oversized text, extremely high contrast (basically, throw Material Design out the window), and the key, where relying on random Android apps is going to fail: You want a unified UI across your functions.
A lot of other UI assumptions go out the window in a car, you need people to be able to interact with it, drop what they're doing, and pick it up again later, so you can't have things that time out or assume you are done with them. You ideally want people to be able to touch-feel some controls if possible, but at the least, you want minimal borders so people can aim for the center of a button and probably hit it without looking at it the whole time. Swipe is a complete no-go, you're in a moving vehicle.
So you don't want phone apps that aren't designed for a car really... at all, which removes most of the perks of using an Android.
I'd much rather build my own system that does the basics I need as quickly as possible than try to get a phone OS to be halfway safe in a car. Command line utilities on a Linux box thrown behind a simple UI screen is a pretty easy bet. (I'm running a Windows box, but I condemn myself at my own risk.)
If you're developing for yourself, you can get much further much faster writing simple code purpose-built to do what you want.
Android Auto sucks because VNC over USB 2 sucks (same as MirrorLink).
"Hey google, open audible"
"hey google, play"
<audible closes, google play music opens and starts playing music>
"hey google, read message"
<proceeds to spout intelligible garbage because the message contained a long URL, or wasn't in English>
No, thanks, I'll take a good tactile interface over this nonsense any day.
Android is still better than everything the manufacturers are pumping out, despite being very obviously for phones.
So far, I got music streaming and voice calls working over bluetooth and I'm currently working on cleaning up the UI. I'm also considering upgrading my board to the i.MX8 which recently came out. Next I''m planning on adding an LTE modem, OTA updates and some kind of basic music app.
In the car, I run an Intel NUC on the floor of my car, and the display I use is an Adafruit serial backpack-based unit (https://learn.adafruit.com/usb-plus-serial-backpack/overview) inside a plastic enclosure along with a small USB hub and the GPS receiver. The enclosure's attached to my dashboard using the same 3M strips available for IPASS/EZPASS devices.
My first question is always "what do you want to do?" What frustrations do you have, what would make your life easier to automate? A lot of times it is less than you think.
I was just thinking about this today. Is it possible to set up an arm VM for “dev” and port the binaries over to the RPI?
Rust is much, much nicer to cross compile but lacks a nice GUI. I've been poking at Cursive.rs for TUI stuff in an attempt to hack up my own scan tool so we'll see where that goes.
Does Virgil3D not work in DBT QEMU targets?
Generally agree that cross-compilation is a better solution, but I think it could also be nice to have everything (except the drivers for your actual hardware) tested as delivered.
I assume you talk about gpsd? or libgeoclue?
gpsd is slow to start because it tries to detect the baudrate as stated in the manpage
Autobauding on the Trimble GPSes can take as long as 5 seconds
I didn't find any solutions to disable this behaviour.
libgeoclue is a giant ecosystem relying on tons of libraries to work with and it does not work on my system.
I mean if he's targeting one GPS device, this might work fine, but GPS targets a lot of devices with lots of fixes for broken protocol implementations.
Would it be possible to use this to, say, look for a hotword and then just always return the rest of the command to a single program, since I have my own command structure already in play? I need the on-device voice recognition and hotword detection, but not the actual assistant.