You know guys that doing this will prevent your application in being an Android application, yes? If you tie up your app to a certain CPU, it mean that XYZ manufacturer producing an Android device with a MIPS CPU (or whatever other CPU) will not be able to run your app. If you want to be really Android (and not Android/ARM) compatible, you better stick with Java and let the JIT to do its own job.
On Nov 14, 10:40 am, "Aaron P. D'Souza" <adso...@gmail.com> wrote:
I find it kind of amusing that there are people fascinated with building console based C apps for a phone platform, talk about a waste of time! :-)
You have a whole new application platform with all the right abstractions, a nice looking UI toolkit and access to 3D apps via OpenGL and you're going to play with building a command line console app? LOL!
On Nov 14, 1:50 pm, gaz <billy00the00...@yahoo.com> wrote:
> You know guys that doing this will prevent your application in being > an Android application, yes? > If you tie up your app to a certain CPU, it mean that XYZ manufacturer > producing an Android device with a MIPS CPU (or whatever other CPU) > will not be able to run your app. > If you want to be really Android (and not Android/ARM) compatible, you > better stick with Java and let the JIT to do its own job.
> On Nov 14, 10:40 am, "Aaron P. D'Souza" <adso...@gmail.com> wrote:
> > ANDROID OS TIPS
> > * to start emulator > > ./emulator -console
> > * to xfer a file to emulator; this is stored in emulator's > > userdata.img file > > adb push <file> <dst file>
> > * to copy a file or a directory recursively to emulator > > adb push <source> <destination>
> > * to copy a file or a directory recursively from emulator > > adb pull <source> <destination>
> > * emulator can run native ARM Linux code. > > build your apps using GNU/ARM Linux toolchain and then run in > > emulator.
> > * to get a shell on the emulator > > adb shell
> > * to run a console app on Android emulator > > adb shell <Linux command>
> > * to connect to emulator console for specific commands > > telnet localhost 5554/6/8
> > BUILDING AND RUNNING A NATIVE C APP ON ANDROID EMULATOR
Writing native apps may be even cool, but defies the role of the Android platform, sicne it moves portability down to the CPU layer. At that point it becomes an HW platform instead of a SW one.
On Nov 14, 11:02 am, Augusto <augusto.sellh...@gmail.com> wrote:
> I find it kind of amusing that there are people fascinated with > building console based C apps for a phone platform, talk about a waste > of time! :-)
> You have a whole new application platform with all the right > abstractions, a nice looking UI toolkit and access to 3D apps via > OpenGL and you're going to play with building a command line console > app? LOL!
> On Nov 14, 1:50 pm, gaz <billy00the00...@yahoo.com> wrote:
> > You know guys that doing this will prevent your application in being > > an Android application, yes? > > If you tie up your app to a certain CPU, it mean that XYZ manufacturer > > producing an Android device with a MIPS CPU (or whatever other CPU) > > will not be able to run your app. > > If you want to be really Android (and not Android/ARM) compatible, you > > better stick with Java and let the JIT to do its own job.
> > On Nov 14, 10:40 am, "Aaron P. D'Souza" <adso...@gmail.com> wrote:
Console applications are the first step. OpenGL is just a C library, calling into that should be easy once you get your console apps working.
Remember that not everybody wants to write their programs in Java. Some people want to write in other languages (not just C and C++) and many languages have VMs/runtimes implemented in C.
You should not be so rude to people such as Aaron P. D'Souza who are doing useful research here. Having a robust native toolchain for Android will benefit everybody, and it certainly is not a "waste of time".
> I find it kind of amusing that there are people fascinated with > building console based C apps for a phone platform, talk about a waste > of time! :-)
> You have a whole new application platform with all the right > abstractions, a nice looking UI toolkit and access to 3D apps via > OpenGL and you're going to play with building a command line console > app? LOL!
> Writing native apps may be even cool, but defies the role of the > Android platform, sicne it moves portability down to the CPU layer. > At that point it becomes an HW platform instead of a SW one.
Even if both Android/ARM and Android/PPC devices take off in the marketplace (that's a big if; Android itself may flop) people who wish to ship native applications can certainly just compile binaries for both architectures.
You are correct. It came out wrong, didn't mean to insult anybody. Experimentation is great, I guess I was just having a reflex reaction to the countless "why did Google not provide a native SDK" posts. Sorry about that, Aaron, I apologize if I insulted you.
Hey I'm getting a kick just playing around in the shell, so I can see some of the value to this. Hopefully people won't forget thought that the main point of something like this is dealing with the higher level constructs and application platform though.
On Nov 14, 2:14 pm, Slava Pestov <sl...@jedit.org> wrote:
> Console applications are the first step. OpenGL is just a C library, > calling into that should be easy once you get your console apps working.
> Remember that not everybody wants to write their programs in Java. > Some people want to write in other languages (not just C and C++) and > many languages have VMs/runtimes implemented in C.
> You should not be so rude to people such as Aaron P. D'Souza who are > doing useful research here. Having a robust native toolchain for > Android will benefit everybody, and it certainly is not a "waste of > time".
> Slava
> On 14-Nov-07, at 2:02 PM, Augusto wrote:
> > Exactly.
> > I find it kind of amusing that there are people fascinated with > > building console based C apps for a phone platform, talk about a waste > > of time! :-)
> > You have a whole new application platform with all the right > > abstractions, a nice looking UI toolkit and access to 3D apps via > > OpenGL and you're going to play with building a command line console > > app? LOL!
You seems to forget the fact that Android does *not* define any ABI whatsoever from a CPU POV. And rightly so. There is no lower layer Androind standard, besides the one exposed to device manufacturers, that states that in order for them to be Android- compatible, they have to be able to run Linux of their HW platform. Going towards native apps defies the unification intent of Android. Java with a half decent JITC, can be really performing. And this comes from a core C developer, developing JITC solutions.
On Nov 14, 11:16 am, Slava Pestov <sl...@jedit.org> wrote:
> > Writing native apps may be even cool, but defies the role of the > > Android platform, sicne it moves portability down to the CPU layer. > > At that point it becomes an HW platform instead of a SW one.
> Even if both Android/ARM and Android/PPC devices take off in the > marketplace (that's a big if; Android itself may flop) people who > wish to ship native applications can certainly just compile binaries > for both architectures.
Right. I don't think anybody is looking to deliver end-user console applications for mobile phones. That would be really silly. The point is that having a native SDK really opens up a number of opportunities in terms of what you can do your device.
Personally I'm interested in porting my Factor language to Android, and using Factor to develop mobile applications. Factor already has an ARM compiler backend and runs on Windows Mobile. So "porting" in this case means first getting it working with Android's toolchain as a Linux/ARM as a console application, and then writing bindings to Android's C and Java libraries (we have a JNI bridge) and actually properly integrating with the platform.
> Hey I'm getting a kick just playing around in the shell, so I can see > some of the value to this. Hopefully people won't forget thought that > the main point of something like this is dealing with the higher level > constructs and application platform though.
> You seems to forget the fact that Android does *not* define any ABI > whatsoever from a CPU POV. And rightly so. > There is no lower layer Androind standard, besides the one exposed to > device manufacturers, that states that in order for them to be > Android- > compatible, they have to be able to run Linux of their HW platform. > Going towards native apps defies the unification intent of Android.
Are you speaking on behalf of Google or is this just conjecture?
> Java with a half decent JITC, can be really performing. And this comes > from a core C developer, developing JITC solutions.
Some people have expressed concerns about performance, but not me. Personally my main objection to having a Java-only stack is the Java language itself. Java is not very expressive, and the JVM is quite limited in many ways which make it a poor choice for hosting higher- level languages.
If Android is indeed a Java-only platform, and the "Linux-based mobile OS" is just a marketing line, then I guess Windows Mobile is a far superior choice and I will continue to focus my energies there.
However, Windows Mobile is not open, and a mainstream Linux-based mobile OS is really an exciting possibility, which is why I'm hoping Google does eventually officially acknowledge native development and ship a robust native toolchain as part of the SDK.
On Nov 14, 11:33 am, Slava Pestov <sl...@jedit.org> wrote:
> On 14-Nov-07, at 2:27 PM, gaz wrote:
> > You seems to forget the fact that Android does *not* define any ABI > > whatsoever from a CPU POV. And rightly so. > > There is no lower layer Androind standard, besides the one exposed to > > device manufacturers, that states that in order for them to be > > Android- > > compatible, they have to be able to run Linux of their HW platform. > > Going towards native apps defies the unification intent of Android.
> Are you speaking on behalf of Google or is this just conjecture?
I'm simply basing it on the information available around. It'd make little sense to come out with a Java based environment now, to later uncover a lower compatibility layer. Unless they're trying to buy some time. But unless they define the lower layer in the OHA standard, you're in your own with native apps. That is basically the current status. There are a few linux devices around, many of them using an ARM CPU. But then, when you move up of Linux kernel, you find the more widespread set of libraries.
On Nov 14, 8:27 pm, gaz <billy00the00...@yahoo.com> wrote:
> You seems to forget the fact that Android does *not* define any ABI
> whatsoever from a CPU POV. And rightly so.
> There is no lower layer Androind standard, besides the one exposed to
> device manufacturers, that states that in order for them to be Android-
> compatible, they have to be able to run Linux of their HW platform.
> Going towards native apps defies the unification intent of Android.
> Java with a half decent JITC, can be really performing. And this comes
> from a core C developer, developing JITC solutions.
Your statement is in fact pure speculation.
Saying that in the future the Andoid platform *may* not run on the
current ABI (ie the ARM EABI) is exactly like saying that PC computers
may not be compatible with IA32 in the future, that may happen, but
it's not a sufficient reason to prevent native development today.
> On Nov 14, 8:27 pm, gaz <billy00the00...@yahoo.com> wrote:
> > You seems to forget the fact that Android does *not* define any ABI
> > whatsoever from a CPU POV. And rightly so.
> > There is no lower layer Androind standard, besides the one exposed to
> > device manufacturers, that states that in order for them to be Android-
> > compatible, they have to be able to run Linux of their HW platform.
> > Going towards native apps defies the unification intent of Android.
> > Java with a half decent JITC, can be really performing. And this comes
> > from a core C developer, developing JITC solutions.
> Your statement is in fact pure speculation.
> Saying that in the future the Andoid platform *may* not run on the
> current ABI (ie the ARM EABI) is exactly like saying that PC computers
> may not be compatible with IA32 in the future, that may happen, but
> it's not a sufficient reason to prevent native development today.
Is it? Does Android states anywhere that its reference ABI is ARM
EABI? It seems to me, that they defined to upper layer (Java based at
the moment), and the lower layer (Linux kernel) for manufacturers
willing to produce Android-aware devices.
When the OHA will define that a certain ABI is the standard for
Android, then it'll make sense talking about native applications.
And it's not only a matter of simple CPU ABI, you'll need a standard
about libc implementation (unless you want to carry it your own with -
static), about the windowing system used (unless you want to bundle
your own), and so on.
Since device HW is pretty limited, those things are better be
standardized, because the end user sure will not like each installed
app to carry its own version of the libraries.
I'd really welcome that kind of standardization, even if it seems a
little strange the path Google is taking (defining a Java-based access
in primis).
> You'll see that on a quite simple benchmark the Dalvik VM is 28x (yes,
> that's quite an order of magnitude) slower that optimized native C
> code.
First, I said an "half decent" JITC. Second, that's a recursive micro-
benchmark.
I can throw at you linux kernel code micro-optimizations that with
specially crafted micro-benchmarks shows 50% or more performance gain,
but that in reality means little or nothing for a normal userspace
application.
An microbench can really over-estimate differences when it comes to
native/JITC comparisons.
> Is it? Does Android states anywhere that its reference ABI is ARM
> EABI? It seems to me, that they defined to upper layer (Java based at
> the moment), and the lower layer (Linux kernel) for manufacturers
> willing to produce Android-aware devices.
The actual devices manufacturers present in the alliance always have
produced ARM based handset, and will continue to do so in the
foreseeable future.
Symbian and Windows Mobile developers are already accustomed to deal
with the evolution of chipsets, libraries and OS API, I don't see why
this new "open" platform should be more restrictive than its
competitors..
And I bet it wont be.
> When the OHA will define that a certain ABI is the standard for
> Android, then it'll make sense talking about native applications.
> And it's not only a matter of simple CPU ABI, you'll need a standard
> about libc implementation (unless you want to carry it your own with -
> static), about the windowing system used (unless you want to bundle
> your own), and so on.
> Since device HW is pretty limited, those things are better be
> standardized, because the end user sure will not like each installed
> app to carry its own version of the libraries.
> I'd really welcome that kind of standardization, even if it seems a
> little strange the path Google is taking (defining a Java-based access
> in primis).
That's not a Google choice in my opinion, that's a choice of the
Android team, the company that have been bought by Google, the fact
that no native SDK has been released yet is because they did not
focused on it, not because they don't want to see native apps.
> > You'll see that on a quite simple benchmark the Dalvik VM is 28x (yes,
> > that's quite an order of magnitude) slower that optimized native C
> > code.
> First, I said an "half decent" JITC. Second, that's a recursive micro-
> benchmark.
> I can throw at you linux kernel code micro-optimizations that with
> specially crafted micro-benchmarks shows 50% or more performance gain,
> but that in reality means little or nothing for a normal userspace
> application.
> An microbench can really over-estimate differences when it comes to
> native/JITC comparisons.- Hide quoted text -
For now the announced JVM is Dalvik, and AFAIK it's not a JITC and
will not be converted to a JITC in the foreseeable future.
What we know is that Java is integral to the application framework and
architecture of Android. Nobody has said Google won't allow for native
apps *at all*, but they've admitted they are not focusing on it right
now (in this very list).
Hopefully people will get over the fact that the main API for
developing Android apps is Java ... *sigh*
On Nov 14, 9:18 pm, StephC <StephC.in...@gmail.com> wrote:
> > Is it? Does Android states anywhere that its reference ABI is ARM
> > EABI? It seems to me, that they defined to upper layer (Java based at
> > the moment), and the lower layer (Linux kernel) for manufacturers
> > willing to produce Android-aware devices.
> The actual devices manufacturers present in the alliance always have
> produced ARM based handset, and will continue to do so in the
> foreseeable future.
> Symbian and Windows Mobile developers are already accustomed to deal
> with the evolution of chipsets, libraries and OS API, I don't see why
> th
is new "open" platform should be more restrictive than its
> > When the OHA will define that a certain ABI is the standard for
> > Android, then it'll make sense talking about native applications.
> > And it's not only a matter of simple CPU ABI, you'll need a standard
> > about libc implementation (unless you want to carry it your own with -
> > static), about the windowing system used (unless you want to bundle
> > your own), and so on.
> > Since device HW is pretty limited, those things are better be
> > standardized, because the end user sure will not like each installed
> > app to carry its own version of the libraries.
> > I'd really welcome that kind of standardization, even if it seems a
> > little strange the path Google is taking (defining a Java-based access
> > in primis).
> That's not a Google choice in my opinion, that's a choice of the
> Android team, the company that have been bought by Google, the fact
> that no native SDK has been released yet is because they did not
> focused on it, not because they don't want to see native apps.
> > > Please have a look at the end of this post :
> > > You'll see that on a quite simple benchmark the Dalvik VM is 28x (yes,
> > > that's quite an order of magnitude) slower that optimized native C
> > > code.
> > First, I said an "half decent" JITC. Second, that's a recursive micro-
> > benchmark.
> > I can throw at you linux kernel code micro-optimizations that with
> > specially crafted micro-benchmarks shows 50% or more performance gain,
> > but that in reality means little or nothing for a normal userspace
> > application.
> > An microbench can really over-estimate differences when it comes to
> > native/JITC comparisons.- Hide quoted text -
> For now the announced JVM is Dalvik, and AFAIK it's not a JITC and
> will not be converted to a JITC in the foreseeable future.
On Nov 14, 6:18 pm, StephC <StephC.in...@gmail.com> wrote:
> > Is it? Does Android states anywhere that its reference ABI is ARM
> > EABI? It seems to me, that they defined to upper layer (Java based at
> > the moment), and the lower layer (Linux kernel) for manufacturers
> > willing to produce Android-aware devices.
> The actual devices manufacturers present in the alliance always have
> produced ARM based handset, and will continue to do so in the
> foreseeable future.
What you perceive as foreseeable means little or nothing
unfortunately. So far OHA did not mandate the usage of ARM-Linux to
the manufacturers, but simply of Linux. That means that manufacturer
XYZ, using a MIPS CPU, can expect full Android compatibility if it
supports Linux. Actually, the definition of "Linux support" is pretty
lose too, since you need to define the devices the userspace layer is
expecting to find underneath.
But as I said a few times already, native application support is not
only a matter of defining a CPU. You need to define the userspace
interfaces too, if you don't want every native application to carry
along its required full set of libraries.
And this still did not happen. It might happen, but at the moment it
is not.
> Symbian and Windows Mobile developers are already accustomed to deal
> with the evolution of chipsets, libraries and OS API, I don't see why
> this new "open" platform should be more restrictive than its
> competitors..
You're citing to very opposite ways to face compatibility. On one
side, you have Symbian, that breaks userspace ABIs (and even worse,
APIs) every other release. This is so clearly an example we don't want
to follow.
On the other side you have Microsoft, that you can say everything
about them, besides that they fail the compatibility test in their
releases. You can take a win32 binary built in 1995 and it'll still be
running fine on todays OSs.
This came at some cost for them though, since compatibility across
releases means carrying over potentially dead code that the new
implementation would not use anymore. OTOH this allowed them to grab
and mantain (as in not pissing off) a quite large user base.
> > When the OHA will define that a certain ABI is the standard for
> > Android, then it'll make sense talking about native applications.
> > And it's not only a matter of simple CPU ABI, you'll need a standard
> > about libc implementation (unless you want to carry it your own with -
> > static), about the windowing system used (unless you want to bundle
> > your own), and so on.
> > Since device HW is pretty limited, those things are better be
> > standardized, because the end user sure will not like each installed
> > app to carry its own version of the libraries.
> > I'd really welcome that kind of standardization, even if it seems a
> > little strange the path Google is taking (defining a Java-based access
> > in primis).
> That's not a Google choice in my opinion, that's a choice of the
> Android team, the company that have been bought by Google, the fact
> that no native SDK has been released yet is because they did not
> focused on it, not because they don't want to see native apps.
I've never said, neither I think, that they don't want to see native
apps. I'm simply looking at the status-quo, where the two statements
OHA made are 1) Java support for userspace 2) Linux support for
manufacturers.
> What you perceive as foreseeable means little or nothing
> unfortunately. So far OHA did not mandate the usage of ARM-Linux to
> the manufacturers, but simply of Linux. That means that manufacturer
> XYZ, using a MIPS CPU, can expect full Android compatibility if it
> supports Linux.
My point is there is no manufacturer XYZ using a MIPS CPU.
The only other ABI that may appear someday in the mobile phone
ecosystem is x86 / IA32, but not until 2012 I think.
