Thread: Android enter car entertainment

I've been reading bits on this forum for ages, mainly for research purposes, and I've seen a few anti-android posts. I've avoided posting in the past but now I'm signing up to find out just what is so wrong with it.

First...

Originally Posted by justchat_1

but the reality is that the car environment is very unique and software needs to be designed as such.

I agree absolutely, the UI is the most important design aspect in making a system suitable for use in a moving vehicle.

Originally Posted by justchat_1

What kev was alluding to in his earlier post was that in order for android to be useful you would need to put a full FE layer over it. But at that point you might as well just use linux and save the translation layer.

I'm going to assume that you DO work with software. I do, professionally for about 12 years. The focus of my job for the last 7 years has been Linux/UNIX and my preferred operating system is Linux. I also work on Windows projects, and some work in web front-ends. I've worked on various mobile platforms, though not Android, yet. I am not associated with Google or the Open Handset Alliance and currently have no published Android work. I do have an Android based phone and have spent a lot of time playing with the SDK and researching it as a potential platform for a Car entertainment system. I haven't decided whether to use it yet.

The Android framework/API provides a lot of facilities that are highly relevant to in car entertainment systems. Media playback, touch interfacing, graphics (2D and 3D), bluetooth, storage, image display and manipulation, GPS interfacing... the list goes on. It also provides a relatively quick and simple platform to develop applications on, and is very focussed on touch based UI design.

So, assuming someone takes the trouble to design an appropriate user interface that runs on Android for use in a vehicle, what exactly makes it so unsuitable for use in this way?

As for giving nothing back to FOSS.... you what!? It is an open project in itself, the source is available for download, and changes to the kernel have been provided even if they are currently excluded from the trunk. Grab the source and have a look, you may surprise yourself and find something useful!

No doubt there are people out there that think Android is great for an in-car system for all the wrong reasons; but there are a lot of good reasons for considering it.

So, as software developers, what are the practical reasons that make Android so unsuitable for ICE?

To further illustrate why android apps just won't work in the car, I came across this whilest watching the Linux Action Show:



That is the web cam app. If you notice, android is fullscreen but the app was designed around a much smaller screen and it doesn't scale. Sure it works, but it looks like utter nonesense with 90% whitespace in all your apps. You may as well do what Tidder is doing and just run android on your phone with the smaller screen.

Originally Posted by Confuzed

I've been reading bits on this forum for ages, mainly for research purposes, and I've seen a few anti-android posts. I've avoided posting in the past but now I'm signing up to find out just what is so wrong with it.

First...



I agree absolutely, the UI is the most important design aspect in making a system suitable for use in a moving vehicle.



I'm going to assume that you DO work with software. I do, professionally for about 12 years. The focus of my job for the last 7 years has been Linux/UNIX and my preferred operating system is Linux. I also work on Windows projects, and some work in web front-ends. I've worked on various mobile platforms, though not Android, yet. I am not associated with Google or the Open Handset Alliance and currently have no published Android work. I do have an Android based phone and have spent a lot of time playing with the SDK and researching it as a potential platform for a Car entertainment system. I haven't decided whether to use it yet.

The Android framework/API provides a lot of facilities that are highly relevant to in car entertainment systems. Media playback, touch interfacing, graphics (2D and 3D), bluetooth, storage, image display and manipulation, GPS interfacing... the list goes on. It also provides a relatively quick and simple platform to develop applications on, and is very focussed on touch based UI design.

So, assuming someone takes the trouble to design an appropriate user interface that runs on Android for use in a vehicle, what exactly makes it so unsuitable for use in this way?

As for giving nothing back to FOSS.... you what!? It is an open project in itself, the source is available for download, and changes to the kernel have been provided even if they are currently excluded from the trunk. Grab the source and have a look, you may surprise yourself and find something useful!

No doubt there are people out there that think Android is great for an in-car system for all the wrong reasons; but there are a lot of good reasons for considering it.

So, as software developers, what are the practical reasons that make Android so unsuitable for ICE?

I'll jump right in from a software developers point of view then....

When you design an application for android whats your target platform? A cell phone? A PMP? a tablet? A tv? an in car device?
The answer would be yes...your designing an application that could be used for all of those and more. As such, theres nothing specific about your design. In 95% of the cases that would be ok, but in a moving vehicle its not!

A carPC os/fe/etc. should be designed specifically around the unique constraints of being inside a moving vehicle. The UI should require minimal attention, minimal menus, minimal distractions, etc. When the vehicle is in motion, your allowed activities and even the way the FE interacts with the user should change to minimize distraction and maximize usability. I could jump in with specific examples if you need but hopefully you get the idea.

Then comes what I see as a huge downside to the multi-application design of android-integration suffers. An application designed by xyz has no way of communicating with an application designed by abc. A notification has no way of knowing what a user is currently doing and as such, could be interrupting an important interaction with trivial details. Applications in android may have access to your current location but they have no access to your destination, the current navigation state or important details like how long until you will need a gas station among dozens of others.

edit:
I should add I have an android phone...and think it works very well for what it was originally designed for...this isn't so much an anti-android thread as an anti-android-in-car thread.

Originally Posted by Confuzed

The Android framework/API provides a lot of facilities that are highly relevant to in car entertainment systems. Media playback, touch interfacing, graphics (2D and 3D), bluetooth, storage, image display and manipulation, GPS interfacing... the list goes on. It also provides a relatively quick and simple platform to develop applications on, and is very focussed on touch based UI design.

I'm not going to argue that the Android framework/API isn't relevant for the car if put in the right hands. I would argue that by using such Android specific API's you isolate yourself from the rest of Linux and open source. You become locked into a single platform.

You may not see this as a downpoint right now, but what if some awesome Linux-based-distro comes out that totally pwns android in every way. Porting your apps from using the non-standard stuff to using the standard stuff is going to be more pain for you and anyone else that wants to try it. You end up rewriting the apps, fragmenting the userspace and wasting effort.

As for giving nothing back to FOSS.... you what!? It is an open project in itself, the source is available for download, and changes to the kernel have been provided even if they are currently excluded from the trunk. Grab the source and have a look, you may surprise yourself and find something useful!

The Linux kernel maintainers didn't see it as useful code and that's why it was tossed out. The whole point of the GPL is to provide a mechanism where I give you my code, and if you improve on it, myself and everyone else benefit from it as well. I've already used the example of Intel's fastboot patches they made for Moblin that ended up making desktops and servers boot fast as well. I don't know of *any* android code that has been very useful to the broader Linux community or for mobile devices running Linux for that matter. Android is called pseudo-opensource for that reason, it's opensource for the sake of calling it open, but it isn't aligned with the spirit of opensource.

Then comes what I see as a huge downside to the multi-application design of android-integration suffers. An application designed by xyz has no way of communicating with an application designed by abc. A notification has no way of knowing what a user is currently doing and as such, could be interrupting an important interaction with trivial details. Applications in android may have access to your current location but they have no access to your destination, the current navigation state or important details like how long until you will need a gas station among dozens of others.

FWiW, Linux in general has IPC (ie DBus) mechanisms that allow multiple applications from multiple vendors to integrate. Android has a mechanism for this that is non-standard which is one of the reasons apps developed for android don't work outside in a standard Linux-based environment. Also, Moblin developed an Audio API known as AudioManager. This allows application writers to specify priority levels for applications that want sound. Apps that are using sound when something of higher priority needs to use it are muted or, if the app is AudioManager-aware, can pause or do whatever it needs to when notified that a higher priority app is going to play something.

All that needs to happen for apps to be aware of the destination, is for the navigation app to publish that onto the bus for any app to grab and use. Of course, you have to get the navigation app to do this and the vendor of that app may not agree. I really don't see how this differs from what a single-process app has to do in order to achieve the same objective. The objective is the same, the path is different.

Originally Posted by justchat_1

When you design an application for android whats your target platform? A cell phone? A PMP? a tablet? A tv? an in car device?
The answer would be yes...your designing an application that could be used for all of those and more. As such, theres nothing specific about your design. In 95% of the cases that would be ok, but in a moving vehicle its not!

That's not right. The hardware you target is your choice as the developer. It is more than possible to target specific platforms and SDK versions with the Android SDK, and because the platform itself is completely open source it is possible to lock the platform itself to whatever hardware platfrom you choose. So the answer is... your target platform is whatever you decide it is.

A carPC os/fe/etc. should be designed specifically around the unique constraints of being inside a moving vehicle. The UI should require minimal attention, minimal menus, minimal distractions, etc. When the vehicle is in motion, your allowed activities and even the way the FE interacts with the user should change to minimize distraction and maximize usability. I could jump in with specific examples if you need but hopefully you get the idea.

I agree. This is why I sold my Kenwood DNX-7200... Kenwood's team didn't understand any of that. It was dangerous to use on the move. I don't understand why you think this is a problem with Android though? It is all just design decisions you need to make as the developer. Unless you think the Home app on Android based phones "is android"? Which of course it isn't, that's just an application running on the Android platform. I wouldn't propose you use the standard set of phone oriented app's for a car system.

Then comes what I see as a huge downside to the multi-application design of android-integration suffers. An application designed by xyz has no way of communicating with an application designed by abc.

Eh? Android is based completely around Activities and Intents. The Intents are used to pass information between Activities. There are various mechanisms for apps to share data and live information. Using the NDK gives you further interprocess access (remember its Linux under there). I suggest you read up on both the SDK and NDK for Android. Even then, keep in mind that the Android platform is open, you can add anything you really think is missing.

Applications in android may have access to your current location but they have no access to your destination, the current navigation state or important details like how long until you will need a gas station among dozens of others.

Sorry but that is all just wrong

I should add I have an android phone...and think it works very well for what it was originally designed for...this isn't so much an anti-android thread as an anti-android-in-car thread.

Yeah I understand that, but I don't agree with the reasons getting brought up on this forum. I think some people here haven't got the full facts about Android. You are telling people here that Android doesn't do things that it has been built from the ground up to do!

Don't get me wrong, I am far from decided on what I would do, I haven't even made the decision that I will build ANYTHING, I like my current ICE... but I've done a lot of research and code experiments... enough to know that some "facts" here are just wrong. I just want to bring in some counter arguments so that Android has a fair fight!

Originally Posted by Confuzed

That's not right. The hardware you target is your choice as the developer. It is more than possible to target specific platforms and SDK versions with the Android SDK, and because the platform itself is completely open source it is possible to lock the platform itself to whatever hardware platfrom you choose. So the answer is... your target platform is whatever you decide it is.

I agree. This is why I sold my Kenwood DNX-7200... Kenwood's team didn't understand any of that. It was dangerous to use on the move. I don't understand why you think this is a problem with Android though? It is all just design decisions you need to make as the developer. Unless you think the Home app on Android based phones "is android"? Which of course it isn't, that's just an application running on the Android platform. I wouldn't propose you use the standard set of phone oriented app's for a car system.

I think part of the problem here is were discussing two different things. Your talking about designing a solution from the ground up on top of the android sdk, i'm referring to leveraging the existing app ecosystem for in car use. The most common argument for using android is leveraging the thousands of applications available. I couldn't disagree more to that and hence my usual android (as an ecosystem) is not designed for in car use. The majority of applications available are not designed for any specific platform. I'm not in any way discussing the apps you write yourself.

Yea I did a review of kenwoods new system and couldn't believe it took a full 18seconds to spin the menu. Just imagine how many things you could hit spending 18seconds to change sources

Originally Posted by Confuzed

Eh? Android is based completely around Activities and Intents. The Intents are used to pass information between Activities. There are various mechanisms for apps to share data and live information. Using the NDK gives you further interprocess access (remember its Linux under there). I suggest you read up on both the SDK and NDK for Android. Even then, keep in mind that the Android platform is open, you can add anything you really think is missing.

Sorry but that is all just wrong

Yeah I understand that, but I don't agree with the reasons getting brought up on this forum. I think some people here haven't got the full facts about Android. You are telling people here that Android doesn't do things that it has been built from the ground up to do!

Don't get me wrong, I am far from decided on what I would do, I haven't even made the decision that I will build ANYTHING, I like my current ICE... but I've done a lot of research and code experiments... enough to know that some "facts" here are just wrong. I just want to bring in some counter arguments so that Android has a fair fight!

I haven't been inside the sdk since cupcake was released so I'm going to dig into the sdk for some better examples. Hang on for post two to discuss more of the ins and outs of the android sdk.

Why is there sooooooo much hating on Android? Is it because iphone didn't come out with something like this. I'm sure you can't get on the net when the car is moving.

The way I see it...is iphone is and android is . You see alot more android

Originally Posted by tripzero

I'm not going to argue that the Android framework/API isn't relevant for the car if put in the right hands. I would argue that by using such Android specific API's you isolate yourself from the rest of Linux and open source. You become locked into a single platform.

I agree, but I don't see how that's different to saying that using Linux specific features prevents you running an application on HP-UX, Mac OS X, or Windows. Ultimately we have to make a decision to target a platform at some level. In the case of designing an ICE system I was looking at it as a whole system solution, in a box, so the idea of being locked in to a platform is not a problem in this instance.

The Linux kernel maintainers didn't see it as useful code and that's why it was tossed out.

I don't know of *any* android code that has been very useful to the broader Linux community or for mobile devices running Linux for that matter. Android is called pseudo-opensource for that reason, it's opensource for the sake of calling it open, but it isn't aligned with the spirit of opensource.

We'll have to agree to disagree on this. I can't see what's "pseudo" about it. You can download the whole source, people contribute to it, and you can modify it to your own needs and distribute it. The changes made to the kernel, though rejected from the trunk because they weren't really useful beyond Android (and uses odd file locks), are available should anyone want them.

FWiW, Linux in general has IPC (ie DBus) mechanisms that allow multiple applications from multiple vendors to integrate. Android has a mechanism for this that is non-standard which is one of the reasons apps developed for android don't work outside in a standard Linux-based environment. Also, Moblin developed an Audio API known as AudioManager. This allows application writers to specify priority levels for applications that want sound. Apps that are using sound when something of higher priority needs to use it are muted or, if the app is AudioManager-aware, can pause or do whatever it needs to when notified that a higher priority app is going to play something.

All that needs to happen for apps to be aware of the destination, is for the navigation app to publish that onto the bus for any app to grab and use. Of course, you have to get the navigation app to do this and the vendor of that app may not agree. I really don't see how this differs from what a single-process app has to do in order to achieve the same objective. The objective is the same, the path is different.

Yep, I agree.

Originally Posted by justchat_1

I think part of the problem here is were discussing two different things. Your talking about designing a solution from the ground up on top of the android sdk, i'm referring to leveraging the existing app ecosystem for in car use.

Well I would certainly agree that Android in the form you see it on a phone today... as in the UI and apps... are not suitable for use in the car. I suppose this was my point though... the phone UI is not suitable, but the Android platform ought to be given some consideration as there are some strong benefits when put in the Car system context.

Yea I did a review of kenwoods new system and couldn't believe it took a full 18seconds to spin the menu. Just imagine how many things you could hit spending 18seconds to change sources

LOL, sounds about right. I don't know what the system you reviewed was like, but on my 7200 the controls were also very small, they were fiddly even when the car wasn't on the move, so how Kenwood thought you could manage safely while driving is beyond me!

Originally Posted by soloxp

Is it because iphone didn't come out with something like this. I'm sure you can't get on the net when the car is moving.

Mate, this isn't an iPhone versus Android debate, it isn't about phones at all. As a software engineer I'm interested in the opinions of these guys who feel that Android is not a good platform for developing a car entertainment system. I'm sure their views have got nothing to do with the iPhone.