Pandora Should Move To Android

[Klepto]

While I accept the benefits of Android on Pandora I for one won't be using it, and I would be very unhappy if it was to become the preferred operating system for the device. I'm a Linux guy, have been for more than a decade, I have no intention of going back to proprietary operating systems. If the Pandora had been developed as an Android device I'd never have pre-ordered. If this had been a vote I'd have voted against.

 

[Exophase]

I think he meant the Dalvik VM. Would still be problematic though.

Actually, that's kinda interesting.. Although a very different and much more limited question, is there any prospect of porting the Dalvik VM to Pandora, or maybe Dalvik binaries can be converted back to JVM ones? If typical JNI code in apps really does tend to just do number crunching with the Java part still handling all the abstraction then maybe not much of Android proper is really needed to run them.

 

[femngi]

Write once, debug everywhere. The problem isn't just porting android, it isn't even getting marketplace access. The main problem will be persuading app developers to support your hardware platform.

 

[MiniSinisterMinister]

It doesn't make any sense in my opinion.

Firstly, Android software is not made with the Pandora hardware design in mind. You mostly get software that is basically a "frontend" making web-content easlily accessable on a very small device with limited input options. And the rest of the software is typically the kind of application that is reduced to very basic core functionality. Why would one use software on the Pandora that does not take advantage of the classic gaming controls, the keyboard, Nubs etc.? These are the things people buy the Pandora for in the first place...


Secondly Android software is not tested on the Pandora. Unoptimzed software puts consumers off instead of attracting them. If I wanted to use Android software, I would buy one the top-selling Android phones not one of the thousands of crappy Android mee-too tablets or cheap laptops.

If commercial developers want to support the Pandora, they will have to optimize their software anyway.

 

[skeezix]

Exophase -- I've wondered the same thing; it is presumably not too difficult to convert JVM->DVM, since the Eclipse bundle distributed as Android SDK has drag-and-drop .jar conversion. Doing the reverse (or porting DalvikVM to Pandora) may not be brutal (or maybe it is.) How much additional lib support etc is needed? I wonder what subset of Android apps/games could be pulled over and work without rewriting/porting half the Android-specific stack?

jeff

 

[XxionxX]

Didn't read the thread, just thought I'd give my 2 cents.

I really like that I can put other OS's on my Pandora. While I like the idea of being a super awesome, gotta have it, make everything for this device right now super media blitzkrieg. I would not like being saddled with a less then optimal OS for the Panda. It seems to me like the android OS would be kinda slow and maybe even a little boring. I don't know what the android's capabilities are, but I am willing to be persuaded if it sounds like a good deal.

 

[Grench]

@Grench :
About books, the most recent book I've enjoyed is 1984 which should be copyleft by now. So no I wasn't kidding.
Harry potter isn't the kind of book I enjoy. I Mind you : I don't like what neo-Holywood produce either. So I may be just too old to understand.

Thank you, but I, like many others, have an interest in reading books published after 1949.

About the rest : you don't know what you're talking about.
exemple : To use a VM, you have either to emulate, para-virtualize or virtualize (using hardware instruction). ARM have no support for virtualisation instructions. para-virtualisation kernel modules aren't avail for an other plateform then x86. qemu-arm on arm will do something between full emulation and para-virtualisation. Don't expect any form of performance.

OK. Clearly I'm an idiot. Good to know.

 

[Grench]

I think he meant the Dalvik VM. Would still be problematic though.

Actually, that's kinda interesting.. Although a very different and much more limited question, is there any prospect of porting the Dalvik VM to Pandora, or maybe Dalvik binaries can be converted back to JVM ones? If typical JNI code in apps really does tend to just do number crunching with the Java part still handling all the abstraction then maybe not much of Android proper is really needed to run them.

Exophase -- I've wondered the same thing; it is presumably not too difficult to convert JVM->DVM, since the Eclipse bundle distributed as Android SDK has drag-and-drop .jar conversion. Doing the reverse (or porting DalvikVM to Pandora) may not be brutal (or maybe it is.) How much additional lib support etc is needed? I wonder what subset of Android apps/games could be pulled over and work without rewriting/porting half the Android-specific stack?

jeff

You two get it. I think it is worth looking into from a, 'can it be done?' perspective anyway.

Maybe a third option is to try to run it in an extend, much like Stuckie did with Debian and Ubuntu:
http://www.gp32x.de/board/index.php?/topic/54651-debian-in-an-extend/
Android is Linux on ARM after all.

Running additional operating systems as if they were applications is rather entertaining in itself.

As for missing buttons, GPS, accelerometer... We have plenty of buttons. GPS via bluetooth has been conquered - it would have to be punched into the VM/whatever to make it appear to Android. An accelerometer is essentially the same input as a joystick. I don't know where we could possibly get an analog joystick signal from...

 

[dflemstr]

I think he meant the Dalvik VM. Would still be problematic though.

Actually, that's kinda interesting.. Although a very different and much more limited question, is there any prospect of porting the Dalvik VM to Pandora, or maybe Dalvik binaries can be converted back to JVM ones?

Possible but difficult. To convert JVM binaries to DVM binaries, you just replace every stack push by a register store instruction in a round-robin fashion. But it's more difficult to convert register stores to stack instructions, since you'll have to somehow find the order that was used when the code was a JVM binary and reuse it (or else you'll have unnecessary pops when you want to reach a value that was pushed in the wrong order). And let's not forget that some other instructions (related to class loading) can't be mapped 1:1 between JVM and DVM. But it is at least theoretically possible, because every DVM binary once was a JVM binary (there is no javac for DVM so you always have to first use javac and then use a JVM→DVM compiler) so...

If typical JNI code in apps really does tend to just do number crunching with the Java part still handling all the abstraction then maybe not much of Android proper is really needed to run them.

Well, there's the issue of the Android library itself. Android doesn't run the Java standard library; it uses an altered (stripped down) version of it with less cross-dependencies, and it adds its own extensions to replace some of the Java standard library. Which is good in a way, because most of the standard Java library consists of horribly deprecated, pre-generics code that is slow and badly designed (especially the collections and IO libraries). But the problem is that the new Android library uses JNI to add its new features (The standard Java library also uses JNI for its native functionality - file, sound, raster and memory access etc - but libjli and related libraries are available for virtually every platform already).

It uses OpenGL ES bindings, native audio system bindings - probably ALSA or similar; bindings to new IO and threading libraries and of course bindings to some kind of "core Android library" that controls things such as user elevation, DRM management, access policies, the "window manager" aka the library that controls the frame buffer, etc. All of the code for these libraries is licensed under Apache 2.0, so it *can* be ported, but the C code needs to actually *be* ported, compared to the rest of the (Java part of the) core library, which makes the task a tad more difficult.

Quickly analyzing the Android JAR, I see that the following Java packages are non-standard:
com.android
com.android.internal
res.* (← These packages only contain resources such as images/sounds/data)
assets.* (← Ditto)
android.speech (← Uses ESpeak)
android.speech.tts
android.webkit (← Uses WebKit (durr))
android.appwidget
android.media
android.os (← Kernel interface + rights management + more)
android.accessibilityservice
android.location (← GPS dependency)
android.widget
android.graphics (← This seems to be a port of the AWT drawing API, dunno if it adds dependencies yet)
android.graphics.drawable
android.graphics.drawable.shapes
android.util
android.opengl (← OpenGL ES API)
android.app (← Process management)
android.app.admin
android.app.backup
android.preference
android.gesture
android.bluetooth
android.service
android.service.wallpaper
android.database (← SQLite dependency afaict)
android.net
android.net.wifi
android.net.http
android.text
android.text.util
android.text.method
android.text.style
android.text.format
android.inputmethodservice
android.telephony (← Obviously not portable to the Pandora; should be replaced by mock methods)
android.telephony.gsm
android.telephony.cdma
android.content
android.content.pm
android.content.res
android.provider (← Provider specific info; uses clearly defined interfaces so the Pandora could implement this package)
android.test (← Only for the SDK; not part of the internal RT lib)
android.test.suitebuilder
android.test.suitebuilder.annotation
android.test.mock
android.sax (← Port of the org.w3c....sax package afaict)
android.hardware (← Limited interface for non-standard devices + SD cards and the like)
android.view (← Interface to some kind of rasterization slave library)
android.view.animation
android.view.accessibility
android.view.inputmethod
dalvik (← Dalvik standard library stuff)
dalvik.bytecode
dalvik.annotation
dalvik.system

I can't tell exactly which libraries each of the packages depend on, because there's no equivalent of ldd for Java (all native libraries are linked ad-hoc at runtime) but it seems like the suite can be compiled without any non-standard native libs (there are no Android-specific native libraries) since the SDK doesn't contain any glue code what I can see.

 

[iampanis]

About books, the most recent book I've enjoyed is 1984 which should be copyleft by now. So no I wasn't kidding.

<off topic>
While I certainly agree that it should be, that doesn't mean that it is. At least in the US, Orwell's works are all still copyrighted, and will be for 10 more years (assuming another copyright term extension doesn't occur before then). Though it is out of copyright in Australia. I don't know what copyright terms are in other countries.
</off topic>

About Android, I will concur with the near-unanimous opinion that it would be nice as an option, but not so nice as a default. And a way to run Android apps in Angstrom would of course be nice, even though I don't know of any Android apps I would actually use (but that's hopefully because I've never looked, not owning an Android device on which to run them).

 

[valhalla]

(...)
Never say never - we don't even know what the certification rules are. Can the certification be applied to an isolated virtual machine run on the device? We don't know. At this point the whole discussion is hypothetical anyway.(...)

With a quick googling I've found a page on "android compatibility" that includes a link to the Android Compatibility Definition Document (CDD)

Starting from page 20

Paragraph 8.9: "Device implementations MUST include a camera."
Paragraph 8.10: "Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at 50 Hz or greater."
Paragraph 8.11: "Device implementations MUST include a 3-axis compass"
Paragraph 8.12: "Device implementations MUST include a GPS"

I'd say that hopes for a google certified android on pandora are quite low.

 

[Eversmile]

I love android, and I think the idea is clever. The first dedicated Android gaming machine will really boost sales. Even if it's just a simple alternative.

 

[Dead1nside]

I love android, and I think the idea is clever. The first dedicated Android gaming machine will really boost sales. Even if it's just a simple alternative.

Isn't this all Odroid territory?

 

[WizardStan]

Paragraph 8.11: "Device implementations MUST include a 3-axis compass"

Wait what?
Why? What possible benefit could a 3 axis compass provide? I could understand requiring a 1-axis compass, maybe even one with tilt compensation, maybe even 2-axis because they need it to be usable in both landscape and portrait mode, but to require 3 axis? I don't get it.
Second question: what if all those things were included in an add-on device plugged into the EXT or/and USB port?

 

[Exophase]

dflemstr, thanks for your indepth response. I think that this is definitely something that should be looked into more, even if it ends up being somewhat of a larger scale and longer term project. A framework for running Android apps in a vanilla Linux environment would be useful beyond Pandora support. Right now it looks like Google offers a qemu-based system-wide platform emulator for Android development. While obviously good to have, a native solution would have its own benefits for development, and would obviously be preferable for actually porting.

I think it's OK if a naive conversion to Java bytecode is done, at least initially. A good JITing JVM will probably recognize a lot of copy propagation and dead operations once it's turned back into native code.

I wasn't really aware of the state of the Java runtime, although I meant to ask. Of course Android made the right decision (IMO) in providing a more optimized library. Being able to really port a lot of it will help. Maybe it should be identified what categories some things fall under:

- Is a more streamlined/alternative style version of a Java library, could be redirected to the Java library (although going from JNI back to Java might be difficult, maybe there's a more direct way?)
- Uses some standard available library on Linux, map directly to that library
- Uses some Android system specific features, provide emulation or reimplementation to map to support on standard Linux kernel
- Uses some Android required hardware, stub it out to nothing possibly for the time being..

Since I'm sure lots of software won't be using many packages you can probably do this really incrementally.

I dunno, is this very interesting to anyone? Worth making a project out of?

 

[sebt3]

I dunno, is this very interesting to anyone? Worth making a project out of?

If I understand correctly your discussion with dflemstr, you plan on going the same road as this which have been hyped a lot 1 year ago.
He didn't give back much, and it look like he stopped working on this after the hype, but he might be a good resource to start with.

I would realy prefer this approch to a "plain" android distribution, as no reboot would be required and it could be packaged as PND.
But from what I gathered now, this would required way more work than I initially imagined. Probably way more than creating an android port ( as applying "our" current kernel patches on the android kernel sound easier).

I'm not sure I want to see one of the high profile around here spend his time on such large projet with that few benefits (no google apps, no market make this moot imho, sure the rooting community could help on this, but that just means more work).
But who am i to tell someone where to spend his *free* time

 

[Exophase]

Oh cool, I should have known someone has already invested time in this. I wonder how they execute Dalvik, if they've maybe ported the Dalvik VM. I am a little confused about what makes this such an Ubuntu-centric project, though, as opposed to one that's more readily portable to other distros.

I like this approach particularly because it means that people aren't going to be turning their Pandoras into Android-exclusive devices, and there isn't going to be an impetus to develop Android apps for Pandora instead of the standard apps. It wouldn't change the established environment or require any kind of big installation.

You're probably right about the workload and relative value.. I guess it's only really good if someone really into Android who would really enjoy it picks it up. It just has so many potential benefits outside of Pandora. I'm surprised Google or other big Android developers haven't themselves pushed for something like this. What is the point is using an abstract environment like this when it's so locked down in low level implementation?

 

[Glom]

Haven't read the entire thread, btw.


I think a complete move over to an Android OS would be a mistake and that this discussion is a little premature. Getting various SDK and guides for the system, etc, up and running first is more important. The only reason I've ever bought a gaming console/handheld/whatever is to tinker with it and in a lesser way, play games on them. I've been looking into NDS for sometime now(2yrs), but the cost of it didnt seem to justify me bying it as a tinkering toy. Pandora on the other hand does so greatly. An open system with all documentation provided and a community..joy

For me it's not important if the pandora runs the android OS. For me the only thing important, speaking of java, is being able to run java code. I love the language and use it for all of my coding.. well mostly. (the closer you get to the hardware it becomes more of a pain.) So for me a Java VM would be enough, and I dont see the need for an entire OS(yes, I realize it would be convenient to run android appz).


Bottomline: Being able to run at least java bytecode would be nice, but I can live with "merely" coding in C if I must

 

[torpor]

Android should definitely *work* on the Pandora, but it shouldn't ship with it installed, imho .. better would be for people to just boot from an Android SD card if they want Android software ..

 

[mali]

The Maemo folks had an Android version once which could be started from within Diablo. Maybe they did some chroot thingamabob, dunno. The version had disappeared last time I checked and I dind't bother to install Nitdroid yet, because it's sloooooow compared to the default Maemo 4, which is Debian based.