Product Request: Android 'Froyo' 2.2 - Large Novel, not for the weak hearted
*Please folks, if you do not like to read, HIT 'BACK' NOW*
I am currently building a Carputer system using a Lenovo Q110 nettop (with VESA mount bracket): http://computershopper.com/desktops/...deacentre-q110 which has an Intel Atom N230 1.6gHz processor, 3GB RAM, and a Lilliput 7" HDMI monitor which I've disassembled and fitted with a 3M 7" Capacitive (glass) touch screen sensor to it. My goal here is to provide a similar 'feel' in look and operation to my Droid phone. The capacitive screen upgrade is to provide accurate touch input from your bare finger just like how it is on your smartphone.
Now I've been trying to find a good front end software and figure out the best operating system for my project of course, and it seems most people like the Centrafuse UI running with XP but I've looked into the GPS options that work with Centrafuse and they all look buggy or feature-limited. I have NEVER seen any GPS program that even comes close to Google Android's 'Maps' application, which uses their own detailed online maps database, plus their own Navigator module, with 'Places' directory, and if you install the 'Google Tracks' app, which uses the same Google Maps structure, you can mark your global position and leave a breadcrumb trail, etc to find your way back easily and there are tons of other good Google, and non-Google apps available for both free and some with a cost which you can get through the app store. The whole GPS thing (and everything else) works flawlessly on my Droid at all times. The only problem with my Droid is the screen is too small for my liking while in a car (or I would just use the USB car dock). Plus, I like the idea of having everything all hard-wired in so the music and all the other tools like OBD-II scanner and all that are already connected to the stereo system and all systems are integrated into the car well.
So my feature request would be if some developer(s) familiar with the MP3car-type world could use the appropriate release of Android 'Froyo' 2.2 source code, and build it to work on x86/x64/Atom-based processors, and all of the other common hardware associated with car PCs. I read that Intel has released or is releasing soon, some Android 2.2 source code that does support the x86/Atom processors.
Intel has stated in press releases that they are doing this because they want other Android OS system hardware manufacturers whom do not currently use Intel Atom processors (many use ARM processors), to give them some code support for the Atom processor, because Intel feels if they offered this support, that more of these hardware manufacturers WOULD more often choose to use the Atom processor in their hardware. ( http://www.tomshardware.com/news/Goo...tom,10733.html ).I also read that Acer has also ported over the Android 2.2 source code to work on their Intel Atom-based netbooks recently. So the code is there. We just need people to patch it all together with driver (kernel modules) support to work with all our commonly used hardware pieces, and since Android uses a Linux kernel (2.6), there are lots of drivers out there that may either just work out of the box, or could work with small modification.
The Atom is a perfect processor for Android, because it is a leaner, meaner, faster OS (with a lightweight kernel) than Vista/Windows 7 with its heavy kernel (which just seems to get heavier with every new release). For this reason, most people with carputers prefer to run good'ol XP, but XP/Vista/7 is not really the best choice for any carputer in my opinion, since it was originally designed as a mouse-driven OS by nature (designed and built for laptops and desktops decades ago), and it has too many unnecessary services included in the kernel that a car PC really would never use, and it is not modular enough to cut out the fluff and make it run as fast as it can. And the last problem is is is closed-code so you cannot trim it down yourself. The Android OS was designed and built by design, specifically for no mouse, and capacitive touch screen sensor equipped devices, versatile and modular, for mobile application use. And even the standard UI (typical home screen) that ships in Android, is already far better suited for mobile ease of use (for minimal driving distraction), than the Windows desktop or even the Linux X-windows desktop based design and a stylus in hand.
If we had a working Android OS in the Mp3car world, we would have all the same benefits as our Droid smartphones already have now: Full gmail / Google account support including Google calendar sync, email sync, Google Docs sync, Android system settings backup / app backup sync, Google Maps, Google App Market support, Google Checkout etc. Then developers whom write single OS compatible programs now in the Mp3car world could then write or port over their current apps to Android code that all adhere to a single format (one single SDK toolkit will reach a larger audience). If those same devs wrote good apps that worked well for carputers, many Android smartphone owners whom have USB car docks in their cars would likely also purchase those same car apps, since the apps are compatible across all Android devices.
Developers for frontend UIs could then write or port over their custom 'home launcher' programs which are the frontends known in the Android world. I have 2 different home launcher apps installed on my Motorola Droid phone now (ADW Launcher, and Launcher Pro), with one set, as the default launcher, but I can pick whichever launcher I want to use. A developer could then build a UI kinda like the Centerfuse frontend to really just be a home launcher you install, so then it could also be designed to just have an entire array of custom widgets which are just puzzle pieces so the user could build his own dashboard panel right on the home app, using any one of the 7 different scrolling home screens, with all the control widgets placed best for his own liking, and optimal use. Or, the developer could just build a frontend as a simple app for now, which could at least perform all the necessary functions in their own custom panel(s).
Android is the FASTEST growing OS on Earth right now, so now is a good time to get on the bandwagon. I'm learning how to program right now, so it is still too early for me to figure out exactly how to build Android on my Atom 230 equipped Q110, or build apps to sell or anything right now, but I just thought I'd post this here today so that if there are any people here who can share my vision and see how logical this idea sounds here, and those people may know how to get this job done, then perhaps someone would like to tackle this task. Even though I can't do it now, I'm still studying about how to do it anyway. I do hang out a little in the xdadeveloper.org website, which those guys do a lot of this kind of stuff over there.
I currently own a Motorola Droid phone that I've rooted, and I run a custom ROM (JRummy's Lithium Mod) with a custom kernel (jdlfg 250mHz-1000mHz) which was built to be very lightweight and have only the modules it needs to run what my ROM needs, and it runs super fast even though I only have the CPU clocked at 1000mHz when on the max slot. If my Atom 1.6gHz had an optimized build of Android 2.2 on it, it should fly. My Lenovo Q110 carputer has the Nvidia ION video chip in it, so it supports playback of 1080p full HD video playback with hardware acceleration enabled.
I have my Droid set up with WiFi tethering hotspot enabled on it so I can connect up to 16 clients to it, and use the 3G service across multiple devices. My plan is, I have a scheme where I will install a wireless WiFi client adapter into the carputer, and set it to 'automatically connect' to my saved profile which would be my Droid phone, and then just leave that setting on the carputer on all the time, but not the Droid. So then on my Droid, it's a 2-keystroke sequence to turn on the WiFi AP router mode...tap on the homescreen shortcut, then app opens, then there is a button on there to actually turn on WiFi AP service daemon. Well, continuing with my scheme, is to use the Droid's USB cradle charger (will have it permanent mounted in center console), and at such time when you plug the Droid into that dock, it proceeds to connect using the USB charge profile (not the A/C charge profile which is the home charger) because Android phone has the ability to see the difference when you connect to the A/C charger (1000mA chg), and the USB charge profile (500mA charge), since USB by spec only supplies a specified 500mA of 5v power), which is what I will use is the USB dock with a 500mA DC-to-DC power supply. Then I will make a small script on my Droid so when the power profile changes to USB charge profile, the script will automatically run, and it will run a couple sh commands to enable the WiFi hotspot daemon and then, the carputer, being the good carputer that she is will just automatically connect to the Droid AP when she sees it broadcasting, and then all the online Google services will just start working automatically. In fact, if a guy really wanted it, he could make a script so that upon connecting the USB charger to the Droid, it would enable the WiFi AP, and carputer client would connect as said before, but also add a command into the script that would forward all of your normal cellphone calls over to your Google Voice account (fully supported in Android 2.2), then the carputer would be set up with Google Voice and so then when someone calls your phone, it will ring on the carputer through the stereo speakers and you can have a microphone up on the sun visor. But this would have advantages for me, since I use Verizon and on CDMA networks, when someone tries to call you, it interrupts the 3G data while in that call, so by forwarding the calls to Gvoice, then your cell wont ever ring while on the cradle, but the datalink would still bring that call to your Gvoice app, which will use the system speakers and microphone for communication. Then as soon as you unplug off of the car dock cradle, and the power profile changes again, you can have a reversal script to disable the WiFi AP router mode, and unforward the call back to your normal cell number.
So as you can see, the possibilities are endless if we had Android in the carputer world. Are there any pioneers who want to help? I will do what I can. If somebody else does it all, I can at least help test the builds as they are made. I am a professional QA Engineer so testing software is what I do best. But if nobody wants to help or can not help, then I am still going to try to do it on my own anyway. It might take me years though...
It looks like Intel may have already done all of the dirty work, getting us some source code to build from that can support tradition CPU architectures, but we just need some good carputer-enthusiast devs who may want to try to build this Android code from source, and get it working with all the driver modules we need, common to the hardware that we like to run in our carputers, like our GPS sensors, and video cards, bluetooth modules, etc, and all that good stuff.
Really, how hard can it be?
SORRY SO LONG, but this is as much as I could trim it down...