Android

[TheRain]

First off I want to get a few things out of the way, and to note that I'm merely throwing this out there to hear others thoughts-
I have an EE degree, work for a mobile phone software company and I have experience with low level programming and embedded systems. Having said that, I don't have much experience with linux drivers or kernel porting and tweaking. I do have the potential to learn I think.
The second thing I want to say is I don't want to annoy any of the Pandora devs who are working hard on the Angstrom distro for Pandora. From what I've seen of the Angstrom port it will do much more than I originally expected and the menu UI that one of the pandora devs is working on looks really awesome.

However, I can't help but think that Android might have been a really nice choice for a main OS on Pandora because:
1. Would cause lots of buzz around the net
2. Would enforce more handheld form factor focused UI design
3. Would have all of the cool apps that come with Android distro

On the other hand:
1. Android tries to force use of it's java system and frameworks
2. I know you CAN code C or C++ for android using a cross compiler for creating native code, but is there even a way to link back to that from Androids Java system? If there is, then this might be workable for porting/developing emulators and the like.
3. I'm wondering how possible it would be to make full use of hardware graphics acceleration features from Android. If this is a huge road block, it might not be worth it really.

Anyway, I think it might be worth pursuing the development of a fully functional Android port if the itches above can be worked out. Even if they can't, it might be somewhat worth it to be able to dual boot to android to use some of the applications that run on it.

Thoughts?

 

[lulzfish]

The thing is that Angstrom is much more established.
The Pandora is basically like a portable BeagleBoard, and Angstrom already has a decent software library on the BeagleBoard.

Android is aimed more at phones than UMPCs. People are looking into it, but for now Angstrom is the best OS for the Pandora by far.

 

[Kramy]

Good post/thread. You listed both positives and negatives.

I remember hearing that someone was going to try to port Android - but not all of the drivers would work, so don't expect something polished and totally functional right away.

Angstrom is very polished, and that's something that Ubuntu/Gentoo/Android (for Pandora) don't have just yet. As they mature, we'll see where they go. Everyone is free to use whatever fits their fancy.

 

[second exodous]

Short Answer:
Porting any Linux distro to the Pandora after Angstrom is working on it shouldn't be that hard. If you or someone else wants to get another Linux distro running on the Pandora I'm sure you or whoever is porting it could go to Angstrom/Pandora team for help. You either need to help Android get ported or simply wait, it's popular and I'm sure it will be ported.

Long Answer:
Open source isn't like the commercial worlds of Windows or OSX, they help each other out and share how they did things, it's a very friendly community actually. If you ask someone from the Angstrom/Pandora team for help they aren't likely to say 'Angstrom is superior and you shouldn't use operating systemX' like Microsoft would say about anything with Windows installed or what Apple would say about the iPhone.

I myself am partial to Gentoo as it's my favorite distro and Ubuntu is my second because it's what I recommend to people trying Linux, so I would much rather run one of those two on my Pandora. It isn't that I don't like Angstrom, heck after using it for a while I might love it and it will become one of my favorite distros, it's just right now on my notebook I run Gentoo as my main OS and Ubuntu as my second so I can help people that I recommend it to.

I, however, am just a user, I'm good at helping someone troubleshoot a problem, walking someone through what I did, or submitting bug reports, but that's about it. I'll wait until someone ports one of those two distros to the Pandora, as far as coding or working with a architecture other than x86 I'm really at a loss.

Anyway, as far as a 'main' OS for the Pandora it is and probably going to be Angstrom. That doesn't mean there won't be other users that run other distros though, and I'm sure Gentoo will have a thread on it's forums on how to install Gentoo on the Pandora. Ubuntu I don't know, I only occasionally visit their forums.

 

[hells_dark]

Can you run non-android programs on android ?

 

[dflemstr]

I don't see why we could make a small special-purpose JVM with android library wrappers that would be able to run Android applications. Would be pretty easy actually. If someone bothers, that is.

 

[TheRain]

Can you run non-android programs on android ?

I don't think many non-android linux apps would just run... probably most even console apps would have to be recompiled and linked against an android toolchain (my guess).

Any X Windows apps would for sure *not* work, even if recompiled because android has it's own windowing system.

A few C and C++ apps have been ported to Android, like mplayer, but I believe they had to be modified to use the framebuffer directly. Once I get my paws on Android for Pandora I will definitely be looking for a way to push frames from a C or C++ native app to a Java front end that has access to all of the Android UI prettiness.

-Collin

 

[TheRain]

So, after some research I've found some interesting things on the Android front:

1. One *CAN* indeed mix native code AND make use of Android's Java based UI frameworks. It is done by making what they term a "Platform Library". It requires building a native library using some tools and methods found in the Android platform source tree. The native code library can then be called to and otherwise integrated with a standard Android java application. I think this is something the homebrew and hacking communities have not fully caught on to because I don't see any homebrew apps making use of it for the T-mobile G1/Dev Phone etc.

2. A new development is that there is a team of people working to make Android apps run on top of Ubuntu. This is an idea that has been suggested around here a couple of times, like "Why not just impliment just enough of android to make the Apps run on top of Angstrom?". It's an interesting idea, but I think it's probably somewhat doomed to only add to the "too make UI toolkits" clutter that standard linux desktops suffer from. Anyhow, here's a linky to a quick article about that http://arstechnica.com/open-source/news ... ubuntu.ars

 

[dflemstr]

So, after some research I've found some interesting things on the Android front:

1. One *CAN* indeed mix native code AND make use of Android's Java based UI frameworks.

JNA/JNI has been around for ages, nothing new here. Heck, you can even get C code and convert it into Java if you want to (while still retaining memory access compatibility); at least if you don't abuse stack hacks too extensively .

2. A new development is that there is a team of people working to make Android apps run on top of Ubuntu. This is an idea that has been suggested around here a couple of times, like "Why not just impliment just enough of android to make the Apps run on top of Angstrom?". It's an interesting idea, but I think it's probably somewhat doomed to only add to the "too make UI toolkits" clutter that standard linux desktops suffer from.

First off, many GUI toolkits aren't necessarily a bad thing. But I would really love the rest of the world if we could all just use Qt and be happy with it as much as anybody else. Vut we all have to give up on our dreams, it simply won't happen.
However, I see some other obstacles when implementing an Android lib: Even if Java is cross-platform, there might arise difficulties when porting some of the core GUI toolkits. A JVM with its security protocols won't allow access for an external library to its display buffers. This can of course be avoided by copying the whole buffer into native memory every frame, or just keeping the whole thing in native memory constantly, which would eliminate the problem completely if this indeed was the present case.

 

[dflemstr]

Posting system messed up AGAIN!! Ignore this...

 

[TheRain]

JNA/JNI has been around for ages, nothing new here. Heck, you can even get C code and convert it into Java if you want to (while still retaining memory access compatibility); at least if you don't abuse stack hacks too extensively .

Thanks dflem,

I wasn't aware of that until recently. My main hope was that there was a way to do this, and that it would make porting things like emulators and maybe parts of ffmpeg a little more feasible.

I guess I'm sort of a UI purist and the multiple toolkits in Linux desktops have always made me very annoyed. I've been using Linux since like 1995 and it's still a major urk for me. Also, I really like the recent trend in making very fluid and finger friendly UI's the standard in the newer mobile OS's. So I'm trying to be proactive about making what I want and presumably what other similar minded people want, happen on this system since it is so open I've noticed quite a few people resisting my ideologies with regard to this, saying that they want the device to be like a tiny desktop computer in their hands. Which is cool, everyone wants to be able to do as much as possible with a small device in their pocket... but I really think that the new mobile OS's on the scene have the better balance of usability and functionality for this type of form factor.

If JNA/JNI is so widely known, why (for instance) did skinman port MPlayer to android by doing a purely native implementation and writing frames directly to the framebuffer? Also, why haven't I seen more attempts at porting cool software like gpSPhone, making use of the native code parts and interfacing to them with a new UI using the Android platform? Maybe I'm wrong that most homebrew developers are not aware that it's possible and maybe even simple with Android, maybe it's just that less homebrewers are interested in the Android platform right now.

 

[TheRain]

Another aside with regard to your mentioning QT... I suppose once I have the Pandora in my hand and I'm using this stuff, I might find that the way it is is fine for me, and no sense in making a lot of effort to port emu's and other toys to android just to have a nice UI experience.

I have been wondering about QT, since it has recently been adopted by Nokia for the Maemo platform... I wonder how difficult it would be to set up QT on top of angstrom in a way that makes it more of a mobile friendly toolkit and also with all of the nice fluid trimmings that the Maemo implimentation will no doubt have?

 

[Poem58]

I just saw an article on Engadget saying that a new version of Ubuntu was being made that would have built in Android support. Since I've seen on the boards that Ubuntu was a possible port to Pandora this might be of interest to this discussion.
Hope that helps.

http://www.engadget.com/2009/05/26/cano ... roid-apps/

 

[dflemstr]

@TheRain:1: The reasons why people port native libraries to Android are (afaik, there might be even more):
- C is way faster than Java (surprise, surprise). Java can approach 90% C-speed but in practice this usually doesn't happen. And you of course have more control in C or similar over how your app behaves which boosts performance even more (reuse the stack with uninitialized vars? Fine-grained register access? Unsafe static casts? ) Assembly is one thing that's completely out of reach for Java, while you are able to combine ASM and C in any way you like.
- Java already has a huge multimedia framework and libraries for most things that you "normally" use native libs for, so porting things like ffmpeg to Java would be redundant since there are other options available. These alternative (pure Java) libs then of course are useless to other native apps that you want to port, thus preventing the porting of anything.
- It's tedious to make Java interfaces to C code. Yes, you can generate them by parsing .h files but the tools available for this aren't widely known to hobbyist C programmers, and there are always problems (mainly with pointer mapping; Java doesn't allow unsafe memory).

That being said, there are a lot of wrappers available anyways; all of the big native libraries have Java wrappers: Qt, GTK, SDL, etc (just naming GUI libs here but yeah you get the picture), the only problem is that no one's wrapping things the other way around: Java code to C wrappers. If the Android devs were to do that with their library, then it would be more available to C devs.

If I were an Android dev, I would just code in Java and be happy about it. Then I would avoid all problems, and even have a cross-platform app that wouldn't need recompilation for every single Android platform out there.

@TheRain:2: Look at that menu system that is being developed for the Pandora (pangea or something? I forgot and am too lazy to check ); it's written completely in Qt and reminds me of the new Moblin interface somehow. Awesome stuff.

And, the more apps that use Qt on the Pandora, the more integrated the apps are going to look
Many people agree that Qt is the only GUI toolkit that's organized enough to enable us to unify the whole open-source world onto it if we wanted to. Just look at where KDE's going, it's an awesome library with a lot of potential. That's why I wish that everyone just would use Qt; no more unintegrated and ununiform GUIs.

@Poem58: Saw it on Digg, too It's no surprise really, Android is made to be portable, so it's no surprise that it now runs on yet another platform. We should easily be able to port the Ubuntu libs to the Pandora, too, if we wanted to.

PS: I'm really really tired so if something in this post doesn't make sense I blame it on that. G'night.

 

[TheRain]

@TheRain:1: The reasons why people port native libraries to Android are (afaik, there might be even more):
- C is way faster than Java (surprise, surprise). Java can approach 90% C-speed but in practice this usually doesn't happen. And you of course have more control in C or similar over how your app behaves which boosts performance even more (reuse the stack with uninitialized vars? Fine-grained register access? Unsafe static casts? ) Assembly is one thing that's completely out of reach for Java, while you are able to combine ASM and C in any way you like.
- Java already has a huge multimedia framework and libraries for most things that you "normally" use native libs for, so porting things like ffmpeg to Java would be redundant since there are other options available. These alternative (pure Java) libs then of course are useless to other native apps that you want to port, thus preventing the porting of anything.
- It's tedious to make Java interfaces to C code. Yes, you can generate them by parsing .h files but the tools available for this aren't widely known to hobbyist C programmers, and there are always problems (mainly with pointer mapping; Java doesn't allow unsafe memory).

That's why I brought it up ??? I'm not talking about interfacing to C (and assembly) code just for the heck of it! The whole point is that there are certain large code bases out there that do things that need native code and often times assembly code to do what they do efficiently.

And, I think you're wrong that there is a Java equivalent to ffmpeg libraries. There may already be Java libraries that wrap around ffmpeg libraries to achieve some decoding functionality efficiently however. Java just wouldn't cut it for this I think. If you can point me to a totally Java implementation of xvid/divx with sound support, you can consider me proven wrong and also pretty surprised. But I think you'll find that any implementation out there for Java is either slow, or is using native code for decoding.

I realize it's not entirely simple to have to rewrite as much code as would have to be written to take advantage of Android UI, while using existing C and assembly code to do the work that needs to be very very fast and efficient. I'm just trying to point out A WAY that it might possibly be accomplished.

 

[dflemstr]

@TheRain:1: The reasons why people port native libraries to Android are (afaik, there might be even more):
- C is way faster than Java (surprise, surprise). Java can approach 90% C-speed but in practice this usually doesn't happen. And you of course have more control in C or similar over how your app behaves which boosts performance even more (reuse the stack with uninitialized vars? Fine-grained register access? Unsafe static casts? ) Assembly is one thing that's completely out of reach for Java, while you are able to combine ASM and C in any way you like.
- Java already has a huge multimedia framework and libraries for most things that you "normally" use native libs for, so porting things like ffmpeg to Java would be redundant since there are other options available. These alternative (pure Java) libs then of course are useless to other native apps that you want to port, thus preventing the porting of anything.
- It's tedious to make Java interfaces to C code. Yes, you can generate them by parsing .h files but the tools available for this aren't widely known to hobbyist C programmers, and there are always problems (mainly with pointer mapping; Java doesn't allow unsafe memory).

That's why I brought it up ??? I'm not talking about interfacing to C (and assembly) code just for the heck of it! The whole point is that there are certain large code bases out there that do things that need native code and often times assembly code to do what they do efficiently.

And, I think you're wrong that there is a Java equivalent to ffmpeg libraries. There may already be Java libraries that wrap around ffmpeg libraries to achieve some decoding functionality efficiently however. Java just wouldn't cut it for this I think. If you can point me to a totally Java implementation of xvid/divx with sound support, you can consider me proven wrong and also pretty surprised. But I think you'll find that any implementation out there for Java is either slow, or is using native code for decoding.

I realize it's not entirely simple to have to rewrite as much code as would have to be written to take advantage of Android UI, while using existing C and assembly code to do the work that needs to be very very fast and efficient. I'm just trying to point out A WAY that it might possibly be accomplished.

Yeah, ok, I was pretty tired yesterday; might have written some nonsense...

Anyways, the most well-known of the media libraries written in "pure Java" is JMF; it has support for MP3, FLV, MPEG-1 and some of the non-patented other codecs (just mentioning this to show that pure Java codecs exist). JMF is pretty darn powerful, too; it can dynamically use plugins like this to get support form native libs when/where available and thereby encode pretty much anything. So yeah, you really needn't rely on native libraries since you can rely on a Java library that uses the stuff available on the platform to the best of its abilites to play your media.

There are countless other "pure Java" frameworks available too for other hi-perf uses. Remember: the problem isn't that Java is too slow (it's the fastest alive and popular language out there besides C and C++), but rather that noone bothers writing stuff in Java (it's got some ugly syntax and can be difficult to use, hence the creation of Scala btw). Example of a high-perf Java library (optimized for the Sun Java HotSpot VM, btw, so if you have something else you might get problems)
Other examples: Java3D/Java2D, the whole JSP stack, Java ASM, the Scala high-performance scalable language (my favourite language, btw), related to Scala: the Lift web framework, etc

And of course, to make this perfectly clear: all Java libraries have native code as their backend; you can never write anything in "pure Java" since it wouldn't be able to access the outside world. But usually, only the core libraries of the Java platform are used, so the library still remains portable.

 

[TheRain]

Yah, I get all that. I do understand how all of this works.

I think you're convoluting the conversation with some slightly unrelated garbage. The point is, most likely, on a device of this nature, you'd have to compile most of the codecs in to native byte code, and often with assembly language in parts to be nice and full speed. By purely Java, I think you already know what I meant. If the bulk of the codec is actually running in java code, not native code, the codec is implimented in Java. If the Java library is just a high level library wrapped around native code, the bulk of what is happening is happening in native code and the Java developer that makes code that sits on top of this is mostly writing more simplistic interface code and other code specific to his/her application.

I disagree that Java can be as efficient as C, C++ and assembly, it probably depends more on what you're doing with it. For UI stuff and maybe some more like "productivity" app types of things, maybe so. Most of the time Java is not used to do the kinds of byte pushing a good low level programmer does in C, C++ and assembly languages. I just don't believe it's possible to get that kind of efficiency from anything that has that level of interpretation layer (Java VM) between it and the hardware.

 

[Kramy]

Java is maybe 10-20% slower than C/C++ on Windows using Hotspot, if you factor in the time spent garbage collecting.

The way the program is designed will have a bigger impact than the language. I've seen Python apps that are extremely responsive and fast, and I've seen C apps that are clunky, slow, render incorrectly, and crash a lot.

The choice of language matters very little compared to say... the skill of the coder, and the program having a solid design

Parts of Java are slow, like Java2D. But it's also very feature complete and accurate, which is why it's almost ubiquitous for medical imaging apps.

JOGL allows access to OGL at the same speed and feature parity as C; but OGL ES doesn't seem quite as well supported, which again goes back to a lack of java libraries being the limiter.

The only thing you can really slight java for is memory usage. An optimized C program might easily have a fourth the memory usage. Then again, most C programs aren't optimized. I remember way back when uTorrent first came out. Doing the same task, it had about 15MB memory usage, when Azureus(Java) had 40MB, and the official C client had about 120MB.

Clearly Java won that one, since at the time Azureus was the only feature complete torrent client; but now it's a bloated steaming pile of crap.

 

[dflemstr]

(Note: I removed some of TheRain's redundant whitespace so as to be able to quote him easier; don't convict me for quote forgery please)

I think you're convoluting the conversation with some slightly unrelated garbage.

Just trying to answer your questions here (And I wanted to futher strengthen my point that it mostly isn't neccessary to port a native library which is what we're kind of talking about after all)

The point is, most likely, on a device of this nature, you'd have to compile most of the codecs in to native byte code, and often with assembly language in parts to be nice and full speed.

Native bytecode? That's a new one. But, yeah, I get what you mean. For that purpose, there's of course the Java ASM library (it can compile Java code into native machine code and execute it, and still remain platform-independent), and it's widely used in codec libraries etc. It compiles this at runtime, though, so the first time you run an application that uses Java ASM, it needs a few seconds to compile it's code parts. Yet another reason not to rely on native libraries.

By purely Java, I think you already know what I meant. If the bulk of the codec is actually running in java code, not native code, the codec is implimented in Java. If the Java library is just a high level library wrapped around native code, the bulk of what is happening is happening in native code and the Java developer that makes code that sits on top of this is mostly writing more simplistic interface code and other code specific to his/her application.

Yes, I know the definition of native; however you have to remember that there isn't a fixed "line" between Java and native code. You can for example compile Java into machine (native) code, aswell (look at gcj). Then you get an application that could have been written in C by the looks of it: It's purely native. Please don't segregate Java and native code; it's not right to say that "all Java apps use loads of memory" or "all Java apps run slow as heck" or "You can't write native apps in Java" because there are different kinds of Java (as I was trying to show in my last post with the example porgrams).

I disagree that Java can be as efficient as C, C++ and assembly, it probably depends more on what you're doing with it. For UI stuff and maybe some more like "productivity" app types of things, maybe so. Most of the time Java is not used to do the kinds of byte pushing a good low level programmer does in C, C++ and assembly languages. I just don't believe it's possible to get that kind of efficiency from anything that has that level of interpretation layer (Java VM) between it and the hardware.

I never said that Java can be as efficient as C (it's the fastest popular, active thing out there BESIDES C, C++).

And now that we're really talking performance: Where Java excels is at purely ALU-related operations: Not IO, not graphics, but at purely mathematical stuff. Just to get that out of the way. It's still slower than C though, but "fast enough" most of the time, which is why people chose to sacrifice that extra speed for portability and ease of programming. And please remember that many Java VMs use JIT, so there isn't any "interpretation layer" to think about, only the JIT compilation process.

Anyways, to clarify that we still are on topic: There are loads of ways to interface native libraries in Java, but there's really no point in doing it (except maybe for very low-level stuff like Kernel interfacing or something), since you can use various methods to speed up Java code, make it automatically compile into machine code, using various hi-perf Java technologies, etc that make native code redundant, which in turn is why noone's using it.

BTW: If you find my inclusion of "unneccessary facts" (to put it mildly) to be annoying, I'm sorry to say that I can't change anything about it. My modus operandi of posting is to write whatever bloody is on my mind at the time. Get used to it
I try to read through my posts again from time to time and remove some of the weird stuff, though.

 

[warmi]

Java is maybe 10-20% slower than C/C++ on Windows using Hotspot, if you factor in the time spent garbage collecting.

Maybe for stuff like GUI glue code and related ... but if you are trying to write something like particle processing inner loops together with cache aligned particle classes/structures etc ... Java doesn't even come close.

You know there is a reason why just about 100% of all commercial games are written in C++ and not Java.