Developing using C++

2366 views
Skip to first unread message

Kevin

unread,
Nov 12, 2007, 12:02:09 PM11/12/07
to Android Developers
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?

Thanks a lot!

Tom Savage

unread,
Nov 12, 2007, 12:05:52 PM11/12/07
to Android Developers
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.

Tom Savage

unread,
Nov 12, 2007, 12:06:47 PM11/12/07
to Android Developers
Also the application framework is Java so I guess C++ development
isn't possible thought it may be.

Dan Morrill

unread,
Nov 12, 2007, 12:14:57 PM11/12/07
to android-d...@googlegroups.com
Hello, Tom!

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

Phlash

unread,
Nov 12, 2007, 12:15:45 PM11/12/07
to Android Developers
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.

Kurt

unread,
Nov 12, 2007, 12:16:48 PM11/12/07
to Android Developers
If there is no support for C / C++, this is a significant limitation.

Kurt

Kurt

unread,
Nov 12, 2007, 12:19:06 PM11/12/07
to Android Developers
Dan,

When will support for C be available?

Kurt


On Nov 12, 11:14 am, "Dan Morrill" <morri...@google.com> wrote:
> Hello, Tom!
>
> 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 -
>
> - Show quoted text -

Akeem A.

unread,
Nov 12, 2007, 12:21:24 PM11/12/07
to Android Developers
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.

Kevin

unread,
Nov 12, 2007, 12:32:39 PM11/12/07
to Android Developers
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+
+.

Hope you can shed some light :)

Kevin.

charlie m

unread,
Nov 12, 2007, 12:40:15 PM11/12/07
to Android Developers

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.

That's my initial thoughts anyway.

Charlie M

Rob Jellinghaus

unread,
Nov 12, 2007, 1:22:18 PM11/12/07
to Android Developers
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.

Cheers!
Rob

Dan Morrill

unread,
Nov 12, 2007, 1:26:39 PM11/12/07
to android-d...@googlegroups.com
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

Dossy Shiobara

unread,
Nov 12, 2007, 1:28:09 PM11/12/07
to android-d...@googlegroups.com
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)

Rob Jellinghaus

unread,
Nov 12, 2007, 1:31:50 PM11/12/07
to Android Developers
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?

Cheers,
Rob
http://robjsoftware.org

cleverthi...@gmail.com

unread,
Nov 12, 2007, 1:47:29 PM11/12/07
to Android Developers
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:

Dossy Shiobara

unread,
Nov 12, 2007, 1:52:03 PM11/12/07
to android-d...@googlegroups.com
On 2007.11.12, Rob Jellinghaus <rjelli...@gmail.com> wrote:
> Basically, that sounds very cool, but is it even possible given the
> definition of pointers in C?

There's nothing magical about pointers.

Compiling C++ programs to Java bytecode
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9806/30915/01434867.pdf&arnumber=1434867

"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."

...

Compile C into Java Classes
http://mblog.lib.umich.edu/lsloanswdev/archives/2006/05/compile_c_into.html

"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."

...

C to Java byte-code compiler
http://en.wikipedia.org/wiki/C_to_Java_byte-code_compiler

...

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?"

pal....@gmail.com

unread,
Nov 12, 2007, 2:16:37 PM11/12/07
to Android Developers
Hi!

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.

/Pal Szasz

StephC

unread,
Nov 12, 2007, 2:19:36 PM11/12/07
to Android Developers

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++.

--
Stephane Cocquereaumont


~mono

unread,
Nov 12, 2007, 2:33:49 PM11/12/07
to Android Developers
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!"

Tom

unread,
Nov 12, 2007, 2:36:56 PM11/12/07
to Android Developers
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
>

Rob Jellinghaus

unread,
Nov 12, 2007, 2:41:12 PM11/12/07
to Android Developers
On Nov 12, 11:16 am, "pal.sz...@gmail.com" <pal.sz...@gmail.com>
wrote:

> First of all, it's pretty clear that C/C++ is possible (unless Google
> ported Quake to JAVA... which I doubt).

No, they didn't, but someone else did :-)

http://bytonic.de/html/jake2.html

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.

Cheers!
Rob
http://robjsoftware.org

Tom

unread,
Nov 12, 2007, 2:41:32 PM11/12/07
to Android Developers
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:


> On 2007.11.12, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
>
> > Basically, that sounds very cool, but is it even possible given the
> > definition of pointers in C?
>
> There's nothing magical about pointers.
>
> Compiling C++ programs to Java bytecode

> http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9806/30915/0143...


>
> "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."
>
> ...
>
> Compile C into Java Classes

> http://mblog.lib.umich.edu/lsloanswdev/archives/2006/05/compile_c_int...

saratoga

unread,
Nov 12, 2007, 2:43:33 PM11/12/07
to Android Developers
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
>

~mono

unread,
Nov 12, 2007, 2:43:40 PM11/12/07
to Android Developers
> 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 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++.
>

+1

Tom

unread,
Nov 12, 2007, 2:52:27 PM11/12/07
to Android Developers

> 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).

Cheers,
Tom

APD

unread,
Nov 12, 2007, 2:55:12 PM11/12/07
to Android Developers
Java is certainly a non-starter for me. I dont want to get into native
vs non-native app, as C++ can't do everything, same limitation applies
to JAVA. It can't do everything. It may be worthwile to explore the C+
+ to JVM but fixing bugs of that might be demoralizing.

It seems like Google called for a party and forgot to order beer.

>> 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.

+2

> Not every developers are eager to write applications in Java or worse,
> rewrite them when they are already done in C/C++.

+2

Aaron Ardiri

unread,
Nov 12, 2007, 3:01:49 PM11/12/07
to Android Developers

my company supports almost 11 platforms using a single C/C++
code base, including the iphone (hacked). the android platform is
interesting, however the dependency on Java is a show stopper,
UNLESS there is:

- a mode to compile my C into java byte codes (and, have API's).
- is support for JNI to execute native code

dont get me wrong, i am a Java developer - however, Java on mobile
phones does not cut it when it comes to performance. CPU speeds
are not going to get faster, they, if anything will be the same or
even
slower, as the focus is on battery life and usage.

game developers will need native code. SDL is a must. it may suit
most if a bridge is built in Java, but then there are people like
myself, who write our own blitters. our code is proven and works.
why do we have to drop it?

i have been a Java developer for 12 years and a mobile developer
for just over 8. i have seen devices come and go. android will suit
the needs for some, but its not truely open as it should be. it is
really googles answer for RIM/blackberry.

there have been a lot of development with bytecode based systems
in mobile phones, i can simply refer to the mophun platform, which
has unfortunately dissapeared. it was java optimized for gaming.
but you wrote C code to generate byte codes.

surely something can be learnt from this and reused.

// Aaron Ardiri
Mobile Wizardry

Simon Kagstrom

unread,
Nov 12, 2007, 3:05:54 PM11/12/07
to Android Developers
On Nov 12, 7:52 pm, Dossy Shiobara <do...@panoptic.com> wrote:
> On 2007.11.12, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
>
> > Basically, that sounds very cool, but is it even possible given the
> > definition of pointers in C?
>
> There's nothing magical about pointers.
>
> Compiling C++ programs to Java bytecode
> http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9806/30915/0143...
> [...]

I'll add my pet-project Cibyl to this list: http://cibyl.googlecode.com.

Cibyl compiles C/C++ code into Java bytecode for J2ME devices and is
implemented as a binary translator that translates MIPS binaries into
Java bytecode. You basically produce a MIPS ELF file and translate
that with Cibyl. Me and other people have ported pretty large
applications to J2ME devices this way, and supporting Android should
*almost* work out of the box.

NestedVM does the same thing (although perhaps not for mobile phones)
so there are several working approaches to do this.

// Simon

~mono

unread,
Nov 12, 2007, 3:19:55 PM11/12/07
to Android Developers
On 12 нояб, 23:01, Aaron Ardiri <ard...@gmail.com> wrote:
> but its not truely open as it should be.

>From developers perspective, SymbianOS & WinMobile is much more
"open".

Tom

unread,
Nov 12, 2007, 3:45:15 PM11/12/07
to Android Developers
> dont get me wrong, i am a Java developer - however, Java on mobile
> phones does not cut it when it comes to performance.

I agree. The question is how to best make that happen. Natively
compiled code accessed via a native code interface may simply not be
feasible.

Hence, my suggestion for a possible alternative: consider using DEX as
an architecture neutral distribution format.

Tom

Aaron Ardiri

unread,
Nov 12, 2007, 3:56:55 PM11/12/07
to Android Developers
On Nov 12, 2007 9:45 PM, Tom <tmb...@gmail.com> wrote:
> > dont get me wrong, i am a Java developer - however, Java on mobile
> > phones does not cut it when it comes to performance.
>
> I agree. The question is how to best make that happen. Natively
> compiled code accessed via a native code interface may simply
> not be feasible.

even basic JNI would do the job for me. heck, i could create ARM,
MIPS,
or whatever variants are needed. i have a bunch of code, namely around
audio processing, image processing that just has to run native.

> Hence, my suggestion for a possible alternative: consider using DEX
> as an architecture neutral distribution format.

for me, DEX would work.

however, if its going to be bytecode being interpreted; the speed of
the CPU is just not going to be accessible - unless you use the
bindings
that google provides (not open there). it is great that they built on
top of
a number of open source products - but, its not open.

my multi-platform work has been very successful - single source code
base runs natively on many platforms. i used the years of experience
in Java and the mobile space to build this development kit.
unfortunately,
i have been too busy to update the website :P but it has come a long
way.

android would have been a perfect additional device.

oh well. i guess we will have to wait to see what happens. the demo
videos of the product are nice, however, if you look closely there is
a
lot of lag betwen the interaction and the display. is this java? or
slow device?
the iphone sdk will allow native applications, and even with the
unofficial
sdk, there are no lagging interactions.

i dont want to use the existing libraries, i want to use my own.

BTW:
we have also written a number of emulators that just wont cut it under
Java.

--


// Aaron Ardiri
Mobile Wizardry

www.mobilewizardry.com

Augusto

unread,
Nov 12, 2007, 3:58:16 PM11/12/07
to Android Developers
> - a mode to compile my C into java byte codes (and, have API's).

Why? If performance is your main concern, you'll still be running on
top of a VM using bytecodes. I don't see how compiling your C app to
bytecode addresses any performance concerns.

tgo

unread,
Nov 12, 2007, 4:35:44 PM11/12/07
to Android Developers
> 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.

This is a big disappointment (for me, thats not open, and boils down
to another
Java-only platform (J2ME, JavaFX Mobile, ..), though within a fully
integrated stack).

Also saying that the SDK does "not support native application
development _at this time_"
tries to imply that there is future perspective that it might do.
Well, if SDK means to
include the platform, then this seems very unlikely to me, since all
the application framework
on top of kernel/core libs is Java. Where is the layer in that stack
where integration
with native apps might be possible?

Tobias

StephC

unread,
Nov 12, 2007, 4:35:47 PM11/12/07
to Android Developers

I think its both simpler and better (more efficient) to directly
compile C/C++ to native code, it's even possible to compile only once
for all the ARM architectures in case the Android platform have to run
on more than one (I think most devices today are running on ARM v5 and
ARM v6)

Having extended instructions set available in the x86 world (MMX, SSE,
3DNow, Multiple core, etc) never prevented developers to write
applications compatible with all the CPU, the same mechanisms can
easily be used on mobile devices, I do it already with my own
framework..

On Nov 12, 8:52 pm, Tom <tmb...@gmail.com> wrote:

Peter da Silva

unread,
Nov 12, 2007, 4:50:57 PM11/12/07
to Android Developers
I'm at a bit of a loss to understand something here.

If the entire Android stack is open source, then all the underlying
SDKs are published and available, and many of them, including any
specific kernel changes required by individual phones, are GPL and
available to all developers.

This means that all these APIs are available as well, so while the
official Android API may not expose them, they will still be supported
by the open source community, and usabel in applications. What am I
missing?

Peter da Silva

unread,
Nov 12, 2007, 5:09:09 PM11/12/07
to Android Developers
> 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.

I come from the UNIX world, and I do my development on 32- and 64-bit
FreeBSD and PPC and Intel OS X. I've written code to run on everything
from 1802 and 6502 theough PDP-11s and 68000s and VAXes and Sparcs up
to Alpha and Itanium, with side trips to 36-bit and 1s-complement
mainframes. The idea of cross-compiling apps to a variety of CPUs is
just business as usual.

Instead of maintaining multiple SKUs just borrow a page from Apple.
You don't actually *need* fat binaries... just ship one version with
all the code launched from a script like

#!/bin/sh
exec /bin/env "$0_`uname -p`"

Then have /usr/local/bin/appname_arm7 point to something/arm7/bin/
appname and make it look in something/arm7/lib for its libraries...

Peter da Silva

unread,
Nov 12, 2007, 5:09:25 PM11/12/07
to Android Developers
> 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.

I come from the UNIX world, and I do my development on 32- and 64-bit

blee

unread,
Nov 12, 2007, 5:27:22 PM11/12/07
to Android Developers
Could it be a hook from Java to C/C++ API?
Even native code would only expose API anyway (or it should).
Java at least have some control over memory.
While C/C++ can do so much damage and average joe(programmer) can
shoot themselves on the foot and wont know where to start to fix it.
A simple index error so array out of bound, and trespass user data
which used by another 100 calls later can be such a nightmare.
It can take an expert a week to figure something like that out.
Not to limit ourselves, just saying C/C++ is more dangerous to a lot
of folks, hence it should not be the focus point.

Olaf Geibig

unread,
Nov 12, 2007, 5:39:58 PM11/12/07
to Android Developers
I acknowledge that certain high performance apps would benefit from
native development. But IMHO in the case of android it's not about
maximum performance but maximum portability. Android enables hardware
engineers to use other processors than arm what means more freedom for
innovation. I honestly hope that google won't open the SDK for native
development as this would discourage hardware engineers to walk off
the beaten tracks.

All this whining about Java being slow... I can't hear it anymore.
We're living in 2007. A modern JVM is much faster than it used to be
10 years ago. The point is to use virtualization and not to use Java.
If you don't like Java, fine. Choose another language which compiles
to JVM bytecode.and can make use of a Java API.

blee

unread,
Nov 12, 2007, 5:40:10 PM11/12/07
to Android Developers
The underlying x86 shares a more or less common base.
Cell phone vendors may have bigger differences between them.
I can't imagine conditional code execution in between x86 and 68k.
It pretty much render a big if from the beginning anyway.

blee

unread,
Nov 12, 2007, 5:43:27 PM11/12/07
to Android Developers
Oh, oh, can we port Python on it then? ;)

StephC

unread,
Nov 12, 2007, 6:10:43 PM11/12/07
to Android Developers

On Nov 12, 11:39 pm, Olaf Geibig <olaf.gei...@googlemail.com> wrote:
> I acknowledge that certain high performance apps would benefit from
> native development. But IMHO in the case of android it's not about
> maximum performance but maximum portability. Android enables hardware
> engineers to use other processors than arm what means more freedom for
> innovation. I honestly hope that google won't open the SDK for native
> development as this would discourage hardware engineers to walk off
> the beaten tracks.

I don't know one single mobile device sold without an ARM core inside,
the ARM architecture is just as hegemonic on mobile devices as x86 is
on the desktop.

And that's why forcing developers to use Java is pointless.

> All this whining about Java being slow... I can't hear it anymore.
> We're living in 2007. A modern JVM is much faster than it used to be
> 10 years ago. The point is to use virtualization and not to use Java.
> If you don't like Java, fine. Choose another language which compiles
> to JVM bytecode.and can make use of a Java API.

We're talking about a ressources (memory, CPU, power) constrained
mobile device...

If given the choice most serious games developers will choose C/C++
over Java for performance and flexibity, not to mention code reuse.

In the Android case, if not given the choice, I expect to see many
developers choosing to not waste their time porting all their C/C++
codebase to Java...


serg271

unread,
Nov 12, 2007, 6:13:02 PM11/12/07
to Android Developers

On Nov 13, 12:39 am, Olaf Geibig <olaf.gei...@googlemail.com>


>
> All this whining about Java being slow...

The thing is Java *is* slow. It may be not noticeable with
applications which doing mostly UI, but it's at least twice (actually
more) more slow with number crunching. And image processing, voice
processing and game development(physics, AI) *is* a number crunching.
No C++ - no voice/image processing on the Android.

~mono

unread,
Nov 12, 2007, 6:44:31 PM11/12/07
to Android Developers

On 13 нояб, 02:10, StephC <StephC.in...@gmail.com> wrote:

>
> If given the choice most serious games developers will choose C/C++
> over Java for performance and flexibity, not to mention code reuse.

+1

>
> In the Android case, if not given the choice, I expect to see many
> developers choosing to not waste their time porting all their C/C++
> codebase to Java...

+100

For me, the weak part is Java language itself, not the VM. It could be
fun to port my codebase to Ruby, but not to this Java thing.

Jingtao Wang

unread,
Nov 12, 2007, 6:44:35 PM11/12/07
to Android Developers
Java IS slow on cellphones in 2007. The performance of mainstream cell
phones is similar to that of the desktop computers ten years ago. In
addition, as far as I know, most JVMs on mobile devices don't
implement the JIT (just-in-time) compiling feature, which makes the
java bytecode being interpreted on cell phones, which usually lead to
a 30 -100 times slowdown in performance . JVMs on desktop computers
are fast because they implement JIT features (e.g. Sun's Hotspot) and
the java byte codes are compiled and executed natively.

I double there is a JIT in the current Android Java VM.

-jingtao

Augusto

unread,
Nov 12, 2007, 7:00:12 PM11/12/07
to Android Developers
> +100
>
> For me, the weak part is Java language itself, not the VM. It could be
> fun to port my codebase to Ruby, but not to this Java thing.

You do know that Ruby and performance don't go together right (since
you voted for C++ based on performance on the previous point).

~mono

unread,
Nov 12, 2007, 7:26:07 PM11/12/07
to Android Developers
It is fun to code with Ruby, and jruby compiler + jit-enabled VM could
be a good tradeoff for me.
Silly java lang + interpreted java bytecode - oh no, thanks, I'll wait
for iPhone SDK.

Rea...@gmail.com

unread,
Nov 12, 2007, 7:41:50 PM11/12/07
to Android Developers
My company is in the same boat as yours Aaron.
I work for a small software company that supports WM, Symbian s60,
Symbian UIQ, Palm, and
BlackBerry. We have a cross platform framework for our code written
in C/C++ that makes supporting multiple C/C++ platforms easier for
us. Two years ago we decided to start up a new code base and support
BlackBerry. In hide sight we should NOT have done this. As a small
company we can't afford to support multiple code bases. Our software
on BlackBerry is no were near the level of functionality as it is on
WM and Palm. If Android is successful, then maybe there will be
enough users on Java based cell phones for us to adequately support a
second code base, but it will still come at a MUCH LARGER cost to our
company. Limiting Android to just Java development is great for
companies who want to enter the mobile arena and for large companies
that can afford multiple code bases. But what about the small to mid
size companies that currently make up a very large portion of the
third party application providers for the mobile devices? This is
just adding extra cost and work. We want our customers to feel
confident that they can move from mobile platform to mobile platform
and know that their investment in our software will be secure and move
with them (some customer's spend 100's of dollars with us). This has
just made our job more difficult :( Android, like BlackBerry, is
just
ignoring the EXISTING "heavy application" (ie not small java games
like tetris)
third party developer community.

That said I am personally very excited to see where this platform will
go.

SJ

Ahmet A. Akin

unread,
Nov 12, 2007, 8:01:18 PM11/12/07
to android-d...@googlegroups.com
Java language is verbose and it is like that for a reason. but you can
write code much quicker and cleaner than objective C or C++ especially
if you use any of the leading IDE's. I can even challenge ruby
developers with Intellij IDEA in cases. Of course i wll not even talk
about ruby's abysmal performance. From my quick observations, android
provides a pretty clean API, hiding some deficiencies of Java API.

proberts9999

unread,
Nov 12, 2007, 8:33:45 PM11/12/07
to Android Developers
> All this whining about Java being slow... I can't hear it anymore.

Let me whine about some other J2ME shortcomings for you then: no
control of scheduling, no control when garbage collection happens,
JVMs are a resource hog, input and output latency is unpredictable and
usually high, you have to try to support 30 slightly different
platforms with tools that pretend all JVMs all the same, no unsigned
types for dealing with raw data, no (useable) dynamic audio, your code
can't do any better than the guy who wrote the java class code.

There are things I like Java for, and it certainly has it's place,
but let's not pretend it can replace a native API. (Even Motorola's
attempt at a java-on-linux phone platform have most of the
applications written in C/C++.)

Augusto

unread,
Nov 12, 2007, 8:38:34 PM11/12/07
to Android Developers
On Nov 12, 8:33 pm, proberts9999 <proberts9...@gmail.com> wrote:
> > All this whining about Java being slow... I can't hear it anymore.
>
> Let me whine about some other J2ME shortcomings for you then:

Android != JavaME

> your code
> can't do any better than the guy who wrote the java class code.

???

~mono

unread,
Nov 12, 2007, 9:17:49 PM11/12/07
to Android Developers
> Java language is verbose and it is like that for a reason. but you can
> write code much quicker and cleaner than objective C or C++ especially
> if you use any of the leading IDE's. I can even challenge ruby
> developers with Intellij IDEA in cases.

will not flame on this topic. I like c/c++, I dislike java. I almost
like android's VM idea,
I still hope there will be more than one language to develop with.

> Of course i wll not even talk about ruby's abysmal performance.

jruby has a complete ruby to bytecode compiler, so the bottleneck
will be android's VM, not the language itself.


Augusto

unread,
Nov 12, 2007, 9:29:27 PM11/12/07
to Android Developers
JRuby still runs considerably slower on a Hotspot VM when compared to
an equivalent Java application.

You prefer C/C++ over Java, yet like Ruby (and don't mind the
performance costs). That's an interesting combination there ...

VA

unread,
Nov 12, 2007, 9:29:34 PM11/12/07
to Android Developers
I have been doing mobile development for java as well as C++ for quite
some time and I have always found java apps to be not useful except
for games etc. because of the battery drain that these cause on mobile
devices. Are there specific improvements in android provided VM that
solves some of these issues or these have not been looked at.

On Nov 12, 10:14 pm, "Dan Morrill" <morri...@google.com> wrote:
> Hello, Tom!


>
> 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 -
>
> - Show quoted text -

Peter Ashford

unread,
Nov 12, 2007, 9:45:10 PM11/12/07
to Android Developers

On Nov 13, 8:33 am, ~mono <dmitriy.se...@gmail.com> wrote:
> 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!"

How do you know it's not done in Java? There are Quake ports and
Quake-like games in Java right now.

Peter Ashford

unread,
Nov 12, 2007, 9:50:15 PM11/12/07
to Android Developers

On Nov 13, 7:28 am, Dossy Shiobara <do...@panoptic.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
>

So... basically, this is a language-bigotry issue?

~mono

unread,
Nov 12, 2007, 9:50:42 PM11/12/07
to Android Developers

On 13 нояб, 05:29, Augusto <augusto.sellh...@gmail.com> wrote:
> JRuby still runs considerably slower on a Hotspot VM when compared to
> an equivalent Java application.

I don't think it is a good idea to use java or ruby for computing
intense applications.
And as a glue between different system api calls ruby is much more
flexible.

>
> You prefer C/C++ over Java, yet like Ruby (and don't mind the
> performance costs). That's an interesting combination there ...

Nothing surprising here...
c/c++ for speed, ruby for fun. Java took the worse from C++ and still
is no as flexible as ruby is.

Peter Ashford

unread,
Nov 12, 2007, 9:55:53 PM11/12/07
to Android Developers
Python for java already exists.

Peter Ashford

unread,
Nov 12, 2007, 9:57:56 PM11/12/07
to Android Developers

So, again - this is a language bigotry issue. In what way is the Java
language "weak" compared to C++ and Ruby?

StephC

unread,
Nov 12, 2007, 10:11:02 PM11/12/07
to Android Developers

> So, again - this is a language bigotry issue. In what way is the Java

> language "weak" compared to C++ and Ruby?- Hide quoted text -

Well, the problem is not the Java langage itself, but the fact that
many developers and companies already have a codebase in C/C++ and it
would be cumbersome and costly to rewrite it in Java only for this
platform, when it's already working natively on Windows Mobile,
Symbian and the iPhone...

Of course there is also some performance issues with Java apps
compared to hand optimized assembly code that could be written when
native development is possible.

And no, it's not unusual for games developer to write very low level
code to maximize the performances of their games..

Ahmet A. Akin

unread,
Nov 12, 2007, 10:33:21 PM11/12/07
to android-d...@googlegroups.com
Well, for really weak devices, what you said maybe would make sense.
But scene is changing pretty rapidly. Devices are getting stronger.
Android vm is still interpreted (unlike hotspot), but it is probably
taking advantage of the hardware acceleration and there can be future
enhancements (i am speculating here). it may be true that some
algorithms will never be as fast as native code, but if %95 of the
applications will work fine, it is a success.
The answer to the question if those c-c++ shops will write Java code
will be apparent once there are android implementations around.
Business demand can make wonders. On the technical side, i am a firm
believer that today writing java code is far far more easier and
quicker then native code development. Just imagine the time you have
lost on those #ifdef 's and pesky memory management problems not to
mention weak support for internationalization, concurrency and
collections. you should have a look at a java developer coding in
Eclipse or IntelliJ Idea..

Augusto

unread,
Nov 12, 2007, 10:37:41 PM11/12/07
to Android Developers
Is it fair to include iPhone in that list? The SDK is coming out next
year, I would imagine there's not such a large number of 3rd party
companies with C/C++ code for the iPhone (and isn't their SDK in
Objective C)?

For games? Aren't a good chunk of the mobile games written in Java
anyways?

proberts9999

unread,
Nov 12, 2007, 10:40:41 PM11/12/07
to Android Developers

On Nov 12, 5:38 pm, Augusto <augusto.sellh...@gmail.com> wrote:
> > your code
> > can't do any better than the guy who wrote the java class code.
>
> ???

If the native code written for a platform to implement a java API is
broken, buggy, etc. you're usually stuck with it. You can re-code
some stuff yourself in Java, but that won't work in many situations,
like where you need speed or OS access.

Kevin P

unread,
Nov 12, 2007, 10:41:31 PM11/12/07
to Android Developers
I'd like to jump into the fray, and request JNI and native C++
support.

Our reasons are two-fold:
1) our project is a media project. We need direct access to camera
drivers, sound I/O drivers, OpenGL, sockets, threads.
2) our project is built around a highly portable C++ framework that
abstracts I/O and threading. We're already running on Symbian and Win
Mobile, and we need to leverage our framework onto Android. We're
simply not going to rewrite our entire application in Java.

Please note that I'm not asking for C++ access to the high-level User
Interface frameworks. For our project, I fully expect to implement a
new Android UI in Java. However, that GUI must be able to call our
portable C++ framework using JNI, and our C++ framework must be able
to create threads, manage sockets, talk to a/v drivers, and write to
OpenGL textures.

This model works well for our Win Mobile and Symbian versions. We use
Linux for some prototyping and unit-tests, and we even have a partial
iPhone implementation running on a jailbroken iPhone. It would be
great to get our project running on Android as well.

Last, let me say that I'm excited about Android! Like the iPhone,
it's disruptive technology. It's about time the wireless industry was
shaken up.

Go Android!

Benno

unread,
Nov 12, 2007, 10:41:43 PM11/12/07