Canonical Demos Early Stage Android-On-Ubuntu
An anonymous reader notes Ars Technica's report from the Ubuntu Developer Summit in Barcelona, where Canonical has unveiled a prototype Android execution environment that will allow Android applications to run on Ubuntu and "potentially other conventional Linux distributions." "Android uses the Linux kernel, but it isn't really a Linux platform. It offers its own totally unique environment that is built on Google's custom Java runtime. There is no glide path for porting conventional desktop Linux applications to Android. Similarly, Java applications that are written for Android can't run in regular Java virtual machine implementations or in standard Java ME environments. This makes Android a somewhat insular platform. Canonical is creating a specialized Android execution environment that could make it possible for Android applications to run on Ubuntu desktops in Xorg alongside regular Linux applications. The execution environment would function like a simulator, providing the infrastructure that is needed to make the applications run. Some technical details about the Android execution environment were presented by Canonical developer Michael Casadevall... They successfully compiled it against Ubuntu's libc instead of Android's custom libc and they are running it on a regular Ubuntu kernel."
Makes sense, considering they're both Linux-based. Though, what does this mean for Ubuntu Netbook Remix? Of the MID edition I've seen elsewhere.
Anybody want my mod points?
If well are being tested to put Android directly in netbooks, having ubuntu netbook remix (or maybe even Moblin) along with Android applications could be the perfect match
Android has proved that people prefer linux over windows, OS X, Palm OS, etc. However, only when X/gnome/kde/SWING/etc are ditched. They're holding desktop linux back and it's time to move forward.
I would rather Ubuntu spent money and time on fixing known issues (in addition to future projects such as this) Hibernate and Suspend did not work through out various editions. I still think Suspend may still not work in Jaunty
I even heard mint Linux have graphics cards such as nvidia working on their platform but Ubuntu has not.
"Java applications that are written for Android can't run in regular Java virtual machine implementations or in standard Java ME environments." Is this not exactly what Sun sued Microsoft for? It's ok for Google, but M$ gets sued?
the problem with this was hardware issues and the fact that the software stack was dumped on the users in such a primitive state (the official line was that it would be worked on as things progressed). a lot of users bought these things expecting them to work out of the box and were disheartened so interest dropped off quickly. with a few hardware issues worked out and a more familiar front end (android or ubuntu) i think it would be an incredibly different story.
If Canonical do see Android as a beneficial software stack, perhaps they'll focus a bit more energy on the Java-related developer tools too.
.deb archives should be so difficult (Fedora manage to do it for rpm)but this bug entry has been open for almost 2 years! :-( Shuttleworth commented on it 15 months ago, yet still no progress.
Specifically Eclipse. Android's developer plugin requires Eclipse 3.3 or higher, whereas Ubuntu comes with 3.2. I don't know the technical details of why packaging eclipse in
Sure, one can download it manually but it kinda defeats the purpose of having a package manager for such scenarios.
Yeah, but that company had no clue what they were doing. They contracted someone to do the UI in gtk, then they were convinced by some tard (guess who?) to rewrite the whole thing in Evas. Then when that didn't work out, rather than go back to the existing GTK-based code they had and finishing it up I think they started all over again using Qt.
I'm not trying to start a toolkit discussion.. this is just an illustration of how poor the decision making process was for OpenMoko.
*IF* Ubuntu ever wanted to go into the smartphone market, I think they'd have more success. Mark is a fucking smart guy and isn't going to throw money away the way OpenMoko did.
Similarly, Java applications that are written for Android can't run in regular Java virtual machine implementations or in standard Java ME environments.
I can't find this Ok, but object to Microsoft doing the same thing wit Java back when they were making their own version, and got (rightfully) sued for it.
If it's a custom compiler, I think they should not call it Java anymore. If it's a custom Library, it should be a portable library, that can be used on any Java system.
What do you think? :)
(Please, no fanboyism.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Now the obvious question: How is [manufacturers' failure to cooperate] linux's fault?
It is not Linux's fault, but it is still Linux's problem.
I agree. But the problem is not as large as you seem to make it out to be. Won't you agree that it is constantly becoming less of a problem?
My hardware is not supported on my operating system hence it is my operating systems fault, unless of course I am running Windows - in that case it is the vendor's fault.
It's the vendors' fault for not putting a penguin logo on any products that I can buy at Best Buy. But because it's equally the fault of every vendor, end users place the blame elsewhere.
I struggle to understand exactly what you are getting at here. Do you mean that it is the vendors fault for not specifying "not linux ready" if the hardware is not Linux supported, or are you saying it is the vendors fault for not providing drivers and then specifying "linux Ready?"
While it is wrong for people to place the blame elsewhere (i.e. at Linux's door) it is a symptom of the way Operating Systems are perceived. Windows = Right, Linux = Not Right.
So what if Linux drivers do not come on CD's? I live in South Africa where broadband is only just becomeing readily available
So how do you use the Internet to download the driver for your modem or network card?
I have never needed to download a driver for a modem or network card in Linux.
For WIFI (and I make here a distinction between WIFI card and NETWORK card) I have needed to get the broadcom driver from the repo, and once I got alerted that my internal wintel modem had a proprietary driver available.
For my USB LG WIFI card I could install with NdisWrapper the driver that is available on the CD, though the NdisWrapper was not always available in a clean install. With Ubuntu I needed to downloaded NdisWrapper, with Mint and Mandrive I had a NdisWrapper driver available.
Using my phone as a GPRS modem (Nokia) I came right with KDE based environments without Internet Access because KPPP supported it without the need to download anything.
Lately with UBUNTU 3g cards work out of the box, no drivers needed.
Previously I did one of two things - took my laptop to an internet cafe to download and install everything I needed driver wise via LAN (this was usually limited to a broadcom WIFI driver, and once to KPPP for Ubuntu) or I got the repo's on DVD from a local LUG for free and installed everything I needed from there.
Shipit, from Canonical, also provides the base install for free via e-mail. It is a pain though that Ubuntu does not have mainstream codec support by default though.
Like you said - Windows almost guarantees that you can use the enclosed driver
But "almost" is still better than no driver being enclosed at all, which is the case for the vast majority of hardware that one would want to use on Linux.
"Vast Majority Of Hardware" is a very strong statement. You will have to support it because I can count the unsupported hardware that I needed (or need) to download hardware for on one had.
1. Broadcom Wifi Card.
2. Wacom Tablet (now supported out of the box with Karmic Koala)
3. Nvidia Proprietary drivers.
4. My Microdia Webcam - works fine BTW.
5. Internal Intel software modem.
Honorable mention: Ndiswrapper (not technically a driver - but I'll add it here in any case since it enables the using of the hardware driver) (also not true with all distributions)
And hardware that completely fails to work with Linux.
Lexmark Printers - Some have claimed to have gotten these to work properly.
My one friend has a music centre (amplifier, auto drum set, sound board) that he had to fiddle around with to work - no official support. He is a musician and us
Seven Days with Ubuntu Unity
While I don't care to run ubuntu on my phone (non-ideal UI for the task), what I would like to see is a C API for android.
My phone is SLOW!!! Memory is tight, and applications take forever to switch. The browser is fairly glacial (even when rendering pages that are stored locally in flash so it isn't just the mobile network).
I think that half the problem is Davlik. It is a non-JIT JVM-like implementation (though it isn't really Java).
While I like the app management that android provides, the requirement that everything be written in a completely-interpreted language definintely is slowing things down. Sure, it isn't a supercomputer, but that mobile CPU has more power than any desktop had more than 13 years ago or so. I suspect that if it could spend more of its time actually running instructions it would be a whole lot faster, and compiled code would use far less RAM and would have far fewer cache misses.
Sure, you could lose some platform-independence that way. I'm all for making the API smart - abstract the hardware as much as possible. You might still need different binaries for different CPUs, but you could minimize this to a great degree. If Google came out with some kind of davlik compiler (turns apks into mostly-native code) they could process the apps as they are installed (maybe centrally). That might be the best of both worlds.
It just seems like there is a lot of room to grow. Don't get me wrong - I realize they're just getting started and I'm pretty happy with my phone. It just isn't a finished product yet...