Your platform looks promising. I have one important question though: Will it be possible to develop and install C++ written applications on Android-based phones, rather than Java applications produced by your SDK?
I'm not sure. I believe that only the Libraries and runtime are coded in C++ and all top layer applications use java. If anyone knows different, please tell me.
Currently we are focusing our efforts on application development using the Java programming language. The SDK does not support native application development at this time.
- Dan
On Nov 12, 2007 9:06 AM, Tom Savage <daboomonl...@gmail.com> wrote:
Provided all the source to the Java-like virtual machine innards (Dalvik VM) are released, then it would be possible to extend the functionality in C/C++ if that is necessary.
> Your platform looks promising. I have one important question though: > Will it be possible to develop and install C++ written applications on > Android-based phones, rather than Java applications produced by your > SDK?
> Currently we are focusing our efforts on application development using the > Java programming language. The SDK does not support native application > development at this time.
> - Dan
> On Nov 12, 2007 9:06 AM, Tom Savage <daboomonl...@gmail.com> wrote:
> > Also the application framework is Java so I guess C++ development > > isn't possible thought it may be.- Hide quoted text -
It might make things interesting, but we do not have hardware specifics at this time either. I believe that their approach for a unified platform at this time is the best one.
On Nov 12, 12:16 pm, Kurt <p...@worldvoice.info> wrote:
> If there is no support for C / C++, this is a significant limitation.
> Kurt
> On Nov 12, 11:02 am, Kevin <kevinlandverwoes...@gmail.com> wrote:
> > Hi Android team,
> > Your platform looks promising. I have one important question though: > > Will it be possible to develop and install C++ written applications on > > Android-based phones, rather than Java applications produced by your > > SDK?
On Nov 12, 5:16 pm, Kurt <p...@worldvoice.info> wrote:
> If there is no support for C / C++, this is a significant limitation.
Well it is and it isn't. Sure it means if you have an existing C / C++ app you can't simply stick an android gui on it and release it. But it does save you from having to ship lots and lots of versions for every architecture that happens to use android. Imagine the download page of an Android apps web site. There would need to be lots and lots of photos of handsets which use android so the user could pick the correct one, not to mention the headache in keeping all those builds up to date.
Java really is a pretty good platform for app development if you over look the gui and the lack of operating system integration. With Android Java is its the main platform for development so it won't look alien to the user because of the Android GUI and they have provided what looks like a comprehensive set of api's so apps can integrate really well.
On Nov 12, 9:16 am, Kurt <p...@worldvoice.info> wrote:
> If there is no support for C / C++, this is a significant limitation.
In what way? What exactly are the limitations on the kind of application you would like to build?
Yes, it is significant, but it's pretty clearly an extremely deliberate choice on Google's part. They're trying to ensure that Android apps will be unable to crash the phone at the OS level, while also being runnable on any OHA-compliant handset regardless of CPU details. There is no way to achieve those two goals while still allowing C and C++ applications. (At least, there's no way that doesn't involve tons of advanced engineering that the Java strategy makes completely unnecessary.)
So, if lack of C / C++ is a dealbreaker for you, then Android is not for you -- at least not in the foreseeable future. I strongly doubt Google is putting any serious effort into support for non-JVM applications.
Well, it's literally true that we simply haven't focused on it. That shouldn't be taken to mean that we like or dislike native programming, just that to date we've focused on the developer experience for apps written in the Java language.
It seems that you perceive some limitations with that approach. Can you describe what it is that you feel you can't achieve with the current model?
- Dan
On Nov 12, 2007 9:32 AM, Kevin <kevinlandverwoes...@gmail.com> wrote:
Regarding the desire for C/C++ to be executable on the Dalvik VM--is the question "is it possible to run code 'natively' on the underlying CPU/hardware" or "will there be a gcc target for the Dalvik VM?"
The former is cool to be able to do, but technically uninteresting or at least not very useful--having to build binaries for every hardware platform your app supports just isn't worth the effort given the wide variety of hardware platforms you'll want to target.
The latter, IMHO, is a must-have requirement. Having to write everything in Java (urk) is a non-starter for me and perhaps lots of others. It shouldn't be unreasonable to add dalvik-vm as a gcc target along with a libandroid library, such that I can cross-compile C code into .dex formatted executables.
Is someone already working on such an effort? Please speak up.
-- Dossy
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
On Nov 12, 10:28 am, Dossy Shiobara <do...@panoptic.com> wrote:
> The latter, IMHO, is a must-have requirement. Having to write > everything in Java (urk) is a non-starter for me and perhaps lots of > others. It shouldn't be unreasonable to add dalvik-vm as a gcc target > along with a libandroid library, such that I can cross-compile C code > into .dex formatted executables.
Whoa. How would this work? You're talking about compiling your pre- existing C code into JVM bytecodes? What kinds of restrictions does that put on your C code, and how does the compiler handle pointer arithmetic to target the JVM bytecode set?
Basically, that sounds very cool, but is it even possible given the definition of pointers in C?
I don't see how it's a limitation. What is "native" about C? It's a programming language which ultimately gets linked into machine code. Java is a programming language which is executed as runtime bytecodes.
In both cases you are limited by the API/System calls which are exposed to you.
It seems that if Android exposes APIs for all the underlying hardware then that's good enough.
Remember that in the PC world, we're kinda complacent because everything is i386 compatible. The idea of cross-compiling apps to a variety of CPUs, and testing on all those CPUs and maintaining the SKUs is a nightmare most developers can do without.
On Nov 12, 5:16 pm, Kurt <p...@worldvoice.info> wrote:
"Summary: It is very desirable to run programs on a variety of platforms. The only programs today that can run on different platforms are those written in Java. Although methods have been developed to allow cross-language applications, these applications are still mostly be hardware and/or operating system platform dependent. In this paper, we describe a platform-neutral compiler for a C++ like language that generates Java bytecode to run on any platform where a Java runtime is available."
"Axiomatic Multi-Platform C (AMPC) is a C compiler suite with an IDE that generates Java bytecode (Java class files) to produce platform independent applications. This is for Write Once Run Anywhere (WORA) with C. AMPC supports a very large subset of ANSI C (1989). It can be used to develop new applications using C as well as port existing applications written in C to run on JVM enabled devices. A JNI (JVM Native Interface) feature is available for calling native C or C functions. Also, numerous Java methods can be called from AMPC. The asm() directive can be used to embed Jasmin assembly code within C source code."
Apparently, a possible approach is to use GNU gcc to emit assembler source, which you then post-process into a format that can be fed into Jasmin <http://jasmin.sourceforge.net/>, an assembler for the JVM.
Naturally, it'd be most convenient to be able to just specify "gcc -mjasmin" and/or "-mjvm" ... which of course is entirely outside the scope of the Android project itself, but something that might be useful to implement.
Or, we just punt altogether and say "it's 2007 already--who still seriously tries to use Java?"
-- Dossy
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
First of all, it's pretty clear that C/C++ is possible (unless Google ported Quake to JAVA... which I doubt). And since this is an open platform, sooner or later you/we can write applications in C/C++ to it... at least this is how I see it.
About Java and "write once run anywhere"... I was developing mobile phone games for 3-4 years... and we had to deliver several tens of binaries for the different phones. Of course the huge number of binaries was due to the different implementation of the java virtual machine and api (meaning the different bugs the phones had). With android it would be better, since the same software stack would be used. However as I see it: if devices will be similar enough, then basically one binary package can cover the devices (mostly because these gadgets use the same CPU core (that is ARM) anyway. If there will be huge differences between devices then there will be need for different java packages as well.
On Nov 12, 7:26 pm, "Dan Morrill" <morri...@google.com> wrote:
> Well, it's literally true that we simply haven't focused on it. That > shouldn't be taken to mean that we like or dislike native programming, just > that to date we've focused on the developer experience for apps written in > the Java language.
> It seems that you perceive some limitations with that approach. Can you > describe what it is that you feel you can't achieve with the current model?
Hi,
As a developer of native mobile games and applications for Smartphone I'm quite disapointed by the fact that the Android platform seem to be only Java oriented so far.
It took me some years to write a cross platform abstraction layer and framework to be able to run my games on many "open" platforms (Windows Mobile, Symbian, Linuw), it's written in C and ARM asm and it supports all the variant of the ARM architecture.
We'll be very glad to work on the Android Platform and quickly port this library if it's possible to run native applications, gcc and access to the classic Linux API (devices like the framebuffer, audio, input) is just what we are waiting for.
You can have a look at what my company is doing here : http://int13.net
Android is not an "open" platform if it does not support native applications.
You should really think about opening it for real, just think about what can be done if SDL is ported?
Not every developers are eager to write applications in Java or worse, rewrite them when they are already done in C/C++.
There's a Quake demo in Sergey Brin & Steve Horowitz video. Does it mean a native SDK is already available but not yet (-?) released to public? It looks quite similar to Apple's approach, "Oh, no native SDK, you absolutely don't need it!" and a half year later - "here it is!"
Real time image processing, speech and signal processing, and applications like that are hard to write in Java. Furthermore, most of the heavy-duty libraries for these kinds of tasks are written in C/C ++.
Cheers, Tom.
On Nov 12, 7:26 pm, "Dan Morrill" <morri...@google.com> wrote:
> Well, it's literally true that we simply haven't focused on it. That > shouldn't be taken to mean that we like or dislike native programming, just > that to date we've focused on the developer experience for apps written in > the Java language.
> It seems that you perceive some limitations with that approach. Can you > describe what it is that you feel you can't achieve with the current model?
> - Dan
> On Nov 12, 2007 9:32 AM, Kevin <kevinlandverwoes...@gmail.com> wrote:
> > Hi Dan,
> > Thanks for your reply.
> > I understand your SDK does not support this. I'd like to know if it's > > possible anyway to develop and install "native" applications using C+ > > +.
Dossy, those are interesting projects. I can't see how Google could stop you from leveraging a project like that, since JVM bytecode is JVM bytecode from Android's point of view. As long as it passes the Davlik verifier, I can't imagine that there could be any issue. Putting the toolchain together would be a bit fiddly, but that's no big deal.
It's possible to compile C/C++ to JVM bytecodes, but there are several problems: (1) you pay a serious performance penalty, and (2) a lot of existing C/C++ code uses unportable, machine-dependent features, and (3) many of the APIs would be hard to support.
However, with a few additional bytecodes, C/C++ could be supported directly and efficiently. Since Android already uses its own virtual machine, adding those shouldn't be a problem. This is roughly the way "Managed C++" and unsafe pointer manipulation in C# are supported by the CLR.
Cheers, Tom.
On Nov 12, 7:52 pm, Dossy Shiobara <do...@panoptic.com> wrote:
> "Summary: It is very desirable to run programs on a variety of > platforms. The only programs today that can run on different > platforms are those written in Java. Although methods have been > developed to allow cross-language applications, these applications > are still mostly be hardware and/or operating system platform > dependent. In this paper, we describe a platform-neutral compiler > for a C++ like language that generates Java bytecode to run on any > platform where a Java runtime is available."
> "Axiomatic Multi-Platform C (AMPC) is a C compiler suite with an IDE > that generates Java bytecode (Java class files) to produce platform > independent applications. This is for Write Once Run Anywhere (WORA) > with C. AMPC supports a very large subset of ANSI C (1989). It can > be used to develop new applications using C as well as port existing > applications written in C to run on JVM enabled devices. A JNI (JVM > Native Interface) feature is available for calling native C or C > functions. Also, numerous Java methods can be called from AMPC. The > asm() directive can be used to embed Jasmin assembly code within C > source code."
> Apparently, a possible approach is to use GNU gcc to emit assembler > source, which you then post-process into a format that can be fed into > Jasmin <http://jasmin.sourceforge.net/>, an assembler for the JVM.
> Naturally, it'd be most convenient to be able to just specify "gcc > -mjasmin" and/or "-mjvm" ... which of course is entirely outside the > scope of the Android project itself, but something that might be useful > to implement.
> Or, we just punt altogether and say "it's 2007 already--who still > seriously tries to use Java?"
> -- Dossy
> -- > Dossy Shiobara | do...@panoptic.com |http://dossy.org/ > Panoptic Computer Network |http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70)
Personally I am interested in porting a codec I developed this summer to android. Its currently written in c with some ARM asm for performance reasons. I don't think rewriting it in Java is feasible. Having some sort of gcc based SDK would be extremely helpful for media applications.
On Nov 12, 1:26 pm, "Dan Morrill" <morri...@google.com> wrote:
> Well, it's literally true that we simply haven't focused on it. That > shouldn't be taken to mean that we like or dislike native programming, just > that to date we've focused on the developer experience for apps written in > the Java language.
> It seems that you perceive some limitations with that approach. Can you > describe what it is that you feel you can't achieve with the current model?
> - Dan
> On Nov 12, 2007 9:32 AM, Kevin <kevinlandverwoes...@gmail.com> wrote:
> > Hi Dan,
> > Thanks for your reply.
> > I understand your SDK does not support this. I'd like to know if it's > > possible anyway to develop and install "native" applications using C+ > > +.
> As a developer of native mobile games and applications for Smartphone > I'm quite disapointed by the fact that the Android platform seem to be > only Java oriented so far.
It looks like Google's main competitor is RIM & BlackBerry services, not Apple. There's no native SDK for BB devices, and so did google.
> We'll be very glad to work on the Android Platform and quickly port > this library if it's possible to run native applications, gcc and > access to the classic Linux API (devices like the framebuffer, audio, > input) is just what we are waiting for.
+1
> Android is not an "open" platform if it does not support native > applications.
why do you think it should be "open" for us. developers? Google means "open" to hardware vendors & etc...
> Not every developers are eager to write applications in Java or worse, > rewrite them when they are already done in C/C++.
> However, with a few additional bytecodes, C/C++ could be supported > directly and efficiently. Since Android already uses its own virtual > machine, adding those shouldn't be a problem.
Just to be clear: this would mean having a compiler that takes normal C/C++ source code and outputs .dex files (with special C-related "unsafe" opcodes). This would permit existing C/C++ libraries to be used unchanged from inside Android and even across different CPUs. It would also allow C and Java code to call each other. However, the speed would still be limited by the virtual machine (which may or may not be slower than native code).
