Would Android Auto make sense for Haiku?

So apparently people have went to the trouble of reverse engineering Android Auto… basically streaming a device to your car’s head unit (H.264 and PCM audio), it would be pretty interesting to be able to use that with Haiku, and perhaps a modernized BeIA-ish interface on a car.

https://github.com/f1xpl/aasdk is a library that can be used to implement for instance OpenAuto (a head unit emulator), or Android auto support into new platforms from what I understand. It uses QT and alot of libraries Haiku already has… so perhaps wouldn’t be difficult to get going in some form.

Obviously this has little to nothing to do with Desktop software, but… then BeOS was a personal computer OS, and later by extension ended up in a few appliances, unsuccessfully of course but… still the idea was there even then. It would be interesting to see Haiku software adapted to work in this form factor, I think Media player and maybe even a cut down and iconified tracker scaled up would work just fine with a scroll wheel and button common to most vehicles… in fact that’s basically what Android Auto provides from a phone by default.

Feel free to reuse code from us, but the result won’t be Haiku, it will be something else :slight_smile:

1 Like

That’s awfully presumptuous of you and frankly rather negative. Installing a screen scraping service and running a modified Deskbar does not a fork make. A fork would imply changes to the kernel which I really don’t see as necessary in the least, a fork is also the last thing Haiku needs right now. If anything it would require improving the Bluetooth and Wifi stacks… which is beneficial anyway.

I understand the lack of interest in supporting other modes of interaction and that is completely valid… however that isn’t your problem just yet so perhaps calm down a bit on banhammering ideas… that’s the very opposite of the culture that gave us BeOS.

Both Windows and Linux support running with alternative UIs… And Deskbar is just an application after all (perhaps a special one but still).

Typically how stuff like this is Handled on Linux is it runs on the same base kernel and operating system as every other distro, and you just add a repo for the alternate software. That decidedly is not a fork.

I did not say it would be a fork. It can be a distribution or some 3rd party software running over Haiku. That still doesn’t make it Haiku.


10 posts were split to a new topic: Forks, Distributions etc

It seems like supporting this would mean having an Android Auto car display as an alternative output for Haiku. Whatever Haiku which was outputting to that display would need to be on a laptop or some other Haiku-supported hardware. In that sense it almost seems like it could be implemented as an alternative remote desktop driver. Or as a Media Kit output node.

I think without more background on what Android Auto actually is, this is a confusing idea, which is probably why everyone was responding about an alternative Haiku distro. I think everyone thought you were suggesting Haiku runs on some sort of automotive computer in the car, as opposed to just sending the right protocol to a car display.

It would probably be a fun hack to try this. I personally don’t have an Android Auto compatible vehicle so it is not that interesting to me. Probably most Haiku developers have other more pressing concerns. I wish I had more free time to see if I could get Haiku talking to the emulator. Unfortunately I am finding it hard to carve out time to even fix a few bugs.

Quite possibly, even so, it is better to ask questions, learn and interact in a positive manner than to make assumptions that cause arguments over an idea that barely even exists yet. I certainly did not create this thread thinking that any of that would even come up…

Frankly forking Haiku is about the last think I’d want to do as even a very competent developer with all the time in the world would fall behind. It’s tantamount to exile. Forking should not be something anyone suggests but rather a last resort. Say for instance if someone wants to implement alternate kernel or package management or rip out tracker for something else and distribute it… then yes a fork or at least sub distribution it would have to be. But I was not even going to go that far as that is a ton of work for little gain.

That’s the thing, I was thinking of working on getting OpenAuto working first… which is an Android Auto head unit emulator… no worries, I might try seeing if it builds and if it does that should be fun to poke around with in between testing builds of Haiku on various hardware. I’ll investigate this more as I have time and post back.

1 Like

I don’t know where you got the idea that we suggested a fork. What I’m just saying is, Haiku is an operating system for desktop computers. A car is not a desktop computer, therefore, this is obviously ouside the scope of Haiku. You can still experiment on it. I don’t own a car, I don’t plan to, and I’ll continue to focus my work on desktop computers. That’s all.

Have fun with your project!


What would be interesting, is to maybe take a bmw Idrive ctonrol knob and put haiku on a x86 board computer, and then make it work like andriod auto, that to me would be of interest, becuase I have always thought Haiku might be really good in automotive applications. The market is moving away from the “head unit” concept anyways to integrated in car computers.

Just food for thought.

Well the head unit… is a computer at least. Maybe a 3d Connextion spacemouse… that’s somewhere between a mouse/joystick and a typical jog dial type automotive controller. Nah, that’s a bit silly… still the ability to wire up a jog dial to Haiku and have it control something would be handy.

And to people that keep posting about distribution related things please stop. Imagine if someone told you you needed to fork Haiku or create your own distribution if you wanted to install Libreoffice… or , or of the 3rd party Docks or quicklaunchers for instance.

The BMW i drive knob works like that, and uses a CAN based communication system that sends messages and the protocol is well known. simple usb adapter is all you need.

USB to CAN, right?

Perhaps with a stock controller but USB ones exist also…

As far as that goes a USB HID device isn’t that complex… and could be home grown relatively easily. Or remote the controller form an automotive input device and adapt it to plain old HID input.

I seem to see a recurring pattern there. In general, you should be prepared to face this kind of resistance, this is not certainly an OS targeted at innovating things. I suggest to just work your stuff out, and don’t care about the general ideas hammering around :grinning:

Now now… don’t you start :wink: … also YOU are off topic also lol.

Right. I forgot the most important thing, I think your idea is neat. People needs reasons to switch to another OS and supporting this stuff may potentially get out a killer application, or at least some fun :sweat_smile: