Announcement

Collapse
No announcement yet.

Android enter car entertainment

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Android enter car entertainment

    http://androidcommunity.com/google-a...unit-20100303/

    We might be able to get maps Nav to work on our pc's. I also find this

    http://phandroid.com/2009/11/23/andr...rchermind-cns/

    http://www.youtube.com/watch?v=WnMyb...layer_embedded

  • #2
    I'm really going to have to blog about why Android is not going to work for carpc's. but here's a preview:

    Firstly, Linux is an ecosystem of hundreds of companies, projects and people working in a symbioses. Anything anyone does to improve their little portion of Linux benefits everyone else. For example when Intel's moblin project improves booting for mobile devices, amazingly enough, my desktop, servers, and every other Linux device started booting faster. Imagine that!!?

    Subsequently, things i develop for linux have the potential to run on other linux devices. nGhost can run on my n900 phone. The maemo 5 on-screen-keyboard can run in my car. GPS and media subsystems are the same from the desktop to the server to the car to the phone.

    Android is based on Linux, but it's not Linux. Everything android does to improve itself helps noone but android. Apps developed for android don't run on my ubuntu desktop, they can't run in my car. Android takes from the Linux ecosystem and gives literally nothing back.

    Google nav will never come to your PC. the x86 version of of android is *banned* from using the android app store. Even if you could get google nav (illegally), android is meant to work with a non-standard gps subsystem which likely doesn't support your bu-353 or your wifi card, or your 3G modem etc.

    Android devices may be created for the car, but that won't mean you will be able to run android in your car without that device.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

    Comment


    • #3
      It's just a matter of time before the Android x86 guys get GPS working. Google Maps/Nav will install just fine on the x86, it just won't do anything... yet.
      Tidder

      Try RevFE
      The best resurrected frontend I've ever used, period.


      I Wish I could ban people

      Comment


      • #4
        Originally posted by Tidder View Post
        It's just a matter of time before the Android x86 guys get GPS working. Google Maps/Nav will install just fine on the x86, it just won't do anything... yet.
        That'll be nice.... but i still won't be able to run it on anything non-android.

        Yes, i'm just ****ed that nothing android does helps me in LinuxICE. On the other side of the scale, almost everything that MeeGo does can potentially help LinuxICE... hmm. amazing how that works.
        Former author of LinuxICE, nghost, nobdy.
        Current author of Automotive Message Broker (AMB).
        Works on Tizen IVI. Does not represent anyone or anything but himself.

        Comment


        • #5
          I get what you're saying, and I'm definitely onboard with the open source. A rising tide raises all boats and that sort of stuff.

          However, other models have been shown to work. Windows and OSX are two examples of closed OS's that can provide broad appeal if the right resources are put behind them. Why can't a company like Google manage to do the same for the mobile phone?

          Sure, I agree that it's crummy that it doesn't help Linux when Linux helped them. But that doesn't mean it won't work. Just that it sucks. The number of mobile devices is far smaller than the number of desktops and the battle for the mobile OS has not yet been won. Why shouldn't Android have a shot at that?
          Originally posted by ghettocruzer
          I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
          Want to:
          -Find out about the new iBug iPad install?
          -Find out about carPC's in just 5 minutes? View the Car PC 101 video

          Comment


          • #6
            kev you picked the wrong rant! this is where you pull out the why android doesn't belong in a car rant.... much better argument and i know you have that one nicely polished

            i'll basically leave it at this....nice idea but I would love to see the retail price. My guess is after the first two idiots kill someone browsing the internet while driving, this company will get sued into bankruptcy. Android is very open which has advantages in the cell phone market but will be disastrous in the car market. Applications which were designed to require your focus or don't take vehicle speed into account when choosing allowed activities are downright dangerous. Not to mention android is a general purpose OS...it has nowhere near the integration required to be successful in the car environment.
            Moblin is the only OS i've seen with any potential to do things right but its too touch screen dependent atm. Well see how meego turns out but honestly my hopes aren't much higher.
            openMobile - An open source C# Front End (why choose openMobile?)
            - Always Recruiting Developers -
            Like what you see? Donations are always welcome

            Comment


            • #7
              hehe, yeah, this was a slightly different anti-android-in-the-car rant than I normally give. I think the two of us have driven the other point to the point where it's obvious, but maybe it's not yet. I'm looking at it now from a slightly different mathmatical viewpoint:

              Android + Car designed UI could work

              Compare with:

              Meego + Car designed UI could work.

              The apps part is useless as JC said. The phone apps will be a bane more than a boon in the car. RSS feed apps, twitter and facebook apps are useless in MeeGo or Android in a vehicle environment unless they do text to speech so you can hear it without taking you away from driving. And 99% of those apps don't even have that usage model in mind. So if you take away the apps, what's a better platform? I say MeeGo is a better platform, but I'm biased because I work on MeeGo for a living. Don't take my word for it. Take a look at each on a technical level and decide for yourself.

              Moblin is the only OS i've seen with any potential to do things right but its too touch screen dependent atm. Well see how meego turns out but honestly my hopes aren't much higher.
              The MeeGo UI will be touch-centric. I'm not sure what other usage models you have in mind.
              Former author of LinuxICE, nghost, nobdy.
              Current author of Automotive Message Broker (AMB).
              Works on Tizen IVI. Does not represent anyone or anything but himself.

              Comment


              • #8
                No offence to your work Tripzero but the main difference is Android is a shipping product and MeeGo isn't.

                And I hope I am wrong but I doubt we will ever see a great offline sat nav app (e.g. Copilot) on MeeGo. So the app part is still relevant.

                I really hope MeeGo can succeed, but if not then I'll probably go for an Android tablet.

                Comment


                • #9
                  Originally posted by wywywywy View Post
                  No offence to your work Tripzero but the main difference is Android is a shipping product and MeeGo isn't.

                  And I hope I am wrong but I doubt we will ever see a great offline sat nav app (e.g. Copilot) on MeeGo. So the app part is still relevant.

                  I really hope MeeGo can succeed, but if not then I'll probably go for an Android tablet.
                  Ovi nav already works offline, as Hitler points out. Of course, it may or may not be available for MeeGo. Who knows at this point? But I wouldn't count it out just yet. Furthermore, Maemo and Moblin (both parts of MeeGo) predate android. Maemo has been in 3 generations of internet tablets, 2 of which predate android.

                  Besides, we are talking about two products, neither of which are a drop in solution for the car right now. We'll see who's got the better platform when they get there.
                  Former author of LinuxICE, nghost, nobdy.
                  Current author of Automotive Message Broker (AMB).
                  Works on Tizen IVI. Does not represent anyone or anything but himself.

                  Comment


                  • #10
                    Originally posted by wywywywy View Post
                    No offence to your work Tripzero but the main difference is Android is a shipping product and MeeGo isn't.

                    And I hope I am wrong but I doubt we will ever see a great offline sat nav app (e.g. Copilot) on MeeGo. So the app part is still relevant.

                    I really hope MeeGo can succeed, but if not then I'll probably go for an Android tablet.
                    I'll just go straight for the heart of this....... a common misunderstanding by those that aren't software developers is a carPC is just a collection of applications. Hackware like rr kind of perpetuates the belief, but the reality is that the car environment is very unique and software needs to be designed as such.

                    In order for software to be safe to use while on the road it needs to be 100% designed to require minimum attention, be fully integrated and be aware of the surrounding environment. You will not see a professional in-car product that doesn't accomplish those goals and yet its something that on the most basic level android is incapable of. Android was designed for smartphones and tablets-not for use in a car.

                    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.
                    openMobile - An open source C# Front End (why choose openMobile?)
                    - Always Recruiting Developers -
                    Like what you see? Donations are always welcome

                    Comment


                    • #11
                      I got a window mount for my droid and use it in the car everyday...
                      Tidder

                      Try RevFE
                      The best resurrected frontend I've ever used, period.


                      I Wish I could ban people

                      Comment


                      • #12
                        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 View Post
                        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 View Post
                        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?

                        Comment


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

                          Click image for larger version

Name:	android-doesnt-scale.png
Views:	1
Size:	192.7 KB
ID:	2277265

                          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.
                          Former author of LinuxICE, nghost, nobdy.
                          Current author of Automotive Message Broker (AMB).
                          Works on Tizen IVI. Does not represent anyone or anything but himself.

                          Comment


                          • #14
                            Originally posted by Confuzed View Post
                            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.
                            openMobile - An open source C# Front End (why choose openMobile?)
                            - Always Recruiting Developers -
                            Like what you see? Donations are always welcome

                            Comment


                            • #15
                              Originally posted by Confuzed View Post
                              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.
                              Former author of LinuxICE, nghost, nobdy.
                              Current author of Automotive Message Broker (AMB).
                              Works on Tizen IVI. Does not represent anyone or anything but himself.

                              Comment

                              Working...
                              X