When is the NDK going to be on par with the Java SDK ?

[Skyrape]

Hi,

*So, When is the NDK going to be on par with the Java SDK ? Is there any on
going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*

*Why do I ask this :*

I'm an Android developer for half a year now and a game developer for quite
a number of years and while at first I liked Android because of the price
accesability, I now prefer iOS for serious development. After months of
Java development although being a C++ developer at the core I can say that
it would've been cool if the NDK was on par with the Java SDK. I personally
have no idea why Java was the preferred language/subsytem and I found
nothing on the internet that actually tells me why google chose this
language.

*How did I find java to be bad :*

So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.

So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.

One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this

synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}

That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).

*So what do I want :*

An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

[Irwin Billing]

It is indeed quit frustrating to work with..road blocks everywhere. It is
improving though. The NDK isn't for the faint of heart.

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

[Andrew Hsieh]

Is NDK plugin http://tools.android.com/recent/usingthendkplugin close to
you what you have in mind?

Post by Irwin Billing
It is indeed quit frustrating to work with..road blocks everywhere. It is
improving though. The NDK isn't for the faint of heart.

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you
don't find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().**isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/6miETd4oy84J.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Zoran Angelov]

Hi,
I think that reason why NDK is not on par as Java SDK, is because they are
still lurking in the platform design and can not standardize the native
code in android and can not maintain backward compatibility at native level.

I agree with you that Java is not a good choice for mobile platforms, that
is why android need a hardware like a consumer desktop computer from not so
far ago in order to run it just smooth.

My opinion is that objective-c is the best choice for mobile platforms.
With its great dynamic features it offers easy implementation hiding while
still being native and able to mix it with c/c++.

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/Bt8QbW-MntAJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Tim Mensch]

Post by Zoran Angelov
My opinion is that objective-c is the best choice for mobile
platforms. With its great dynamic features it offers easy
implementation hiding while still being native and able to mix it with
c/c++.

Oh, the pain I've been suffering dealing with Objective C on
iOS...please no... It falls into the same category as Java for me:
Verbose, ugly, and yet not as fast as C++. In the case of Objective C
add an extra helping of ugly. The syntax is really awful. While named
parameters is nice, it's too hard to see [[[what brackets]
associate:[with what:functions for:[anything remotely:complicated]]]
ifYouSeeWhatIMean]. And @synthesize means that you can't use a prefix on
your member variables (m_foo), or more to the point, people DON'T, so
when I'm looking at unfamiliar code I have to search for every variable
to see if it's a member variable, parameter, global variable, or a local
that I just didn't notice. Or maybe a keyword that I don't know yet. Blech.

I put up with the verbosity and the ugliness of C++ to get at the raw
speed. If a language isn't ultra-fast, I want it to be a dynamic
language where I can be much more productive. My dynamic language of
choice is Lua (especially LuaJIT, which is FAST -- some benchmarks beat
C, and several beat Java), but that's probably because I work in games
and most everyone in games uses Lua. Oh, and it's TINY compared to
Python or Ruby, so it's easy to embed.

The only decent alternative to C/C++ that I've seen for a systems-design
language is Go. A Google-backed language, I feel I should note. But
they'd be better off making the system APIs C-based. EVERYTHING can talk
to C libraries. That way you can have people write their code in C++,
Objective-C, Go, or even Lua, and it's easy to interface. Though I'd be
happy with a Go-based API, as long as it doesn't turn out to be too hard
to write a Lua-Go bridge. ;)

Tim

[Latimerius]

But they'd
be better off making the system APIs C-based. EVERYTHING can talk to C
libraries. That way you can have people write their code in C++,
Objective-C, Go, or even Lua, and it's easy to interface.

Yes, exactly. One would think that by now, every programming novice
is familiar with the "right tool for the job" mantra. Yet we get Java
rammed down our throat, and most of the other tools are blocked out.

I'm not saying Java is useless, I imagine it has its place as a good
tool for a certain classes of jobs. However if you try to write
high-performance software with it (read "games" ;-) you'll quickly
discover that some things simply can't be done. For instance, if you
care about memory usage and GC induced freezes you end up spending as
much time thinking about memory management as in C++ (if not more
actually), but *without* the tools C++ gives you to deal with the
problem.

[Glenn Kasten]

See Q&A starting at 41:49 minutes into Google I/O 2012 - Android Fireside
Chat

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

[Nalin Savara]

@Glenn Kasten:
haha very cool video; thx for sharing.

@Sky[xxxx] :
buddy-- if you say NDK is bad... compared to what ???

Compared to Symbian ? to ios ? to Blackberry OS ? to Blackberry 10 that
uses c++ ? OR Windows Phone-7 ? OR what?

you cant compare NDK to JDK-- because they are 2 different things--
targetted at different audiences and different hardware requirements and
use-cases.

among mobile platforms; NDK is actually pretty good-- in terms of code of
it's toolchain etc being openly available and not just NDK-- but also dev
tools built on top of it being portable and available on various OSes make
it quite cool.

-Nalin
ps: hope I dont sound like a fanboi preaching to the choir... bt just sayin
my mind...

Post by Glenn Kasten
See Q&A starting at 41:49 minutes into Google I/O 2012 - Android Fireside
Chat
http://youtu.be/UGJbPPjANKA

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you
don't find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().**isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/OC2rsKq2UasJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Latimerius]

Is this about portability of the framework itself, or the apps?

If the former, I don't think writing C/C++ portable enough to cover
broad range of hardware is something unheard of (witness the very
Linux kernel on top of which Android runs).

If it's about the apps, well, why don't you just leave portability to
developers?

With the amount of changes (and breakages) successive Android versions
bring about you can't hope to keep apps forever compatible without the
original developer's assistance anyway.

Post by Glenn Kasten
See Q&A starting at 41:49 minutes into Google I/O 2012 - Android Fireside
Chat
http://youtu.be/UGJbPPjANKA

Post by Skyrape
Hi,
So, When is the NDK going to be on par with the Java SDK ? Is there any on
going progress on the matter ? Is Google working on it ? Is there an
announced release date ?
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files right,
but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/OC2rsKq2UasJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[RichardC]

"The NDK is a toolset that allows you to implement parts of your app using
native-code languages such as C and C++. For certain types of apps, this
can be helpful so that you may reuse existing code libraries written in
these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you don't
find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

[Skyrape]

Yeah, it's a half-done job which is why they recommend to not use it to
write your entire app.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app using
native-code languages such as C and C++. For certain types of apps, this
can be helpful so that you may reuse existing code libraries written in
these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*
*Why do I ask this :*
I'm an Android developer for half a year now and a game developer for
quite a number of years and while at first I liked Android because of the
price accesability, I now prefer iOS for serious development. After months
of Java development although being a C++ developer at the core I can say
that it would've been cool if the NDK was on par with the Java SDK. I
personally have no idea why Java was the preferred language/subsytem and I
found nothing on the internet that actually tells me why google chose this
language.
*How did I find java to be bad :*
So back to the main point, who wants to develop in Java anyway ? You get
only 32MB of RAM unless you use "large heap", an undocumented flag that
supposedly gives me 64MB of RAM, but soon even that will be too little.
Given that I may have a device with 1 GB of RAM I may have at one point a
console-like game requiring 512 MB of RAM. Without going the NDK way, I'm
unable to make my application.
So I'm developing using the NDK and using undocumented functions you
don't find on the main site. At first I thought I didn't read the ndk files
right, but yeah, all those "docs" do not describe any NDK function like say
AAssetManager_open . Next up is random behavior. I develop on NDK and have
to rely on the standard Java SDK for certain features, like say png
decompression ( or at least I tried), so when I do that, if my phone's
screen is off, the android function calls called from my java code fail.
When having a standard java app that doesn't happen. So I dunno what voodoo
magic is going on, but I had to get libpng in my project. I would've
expected they give me the NDK lib for libpng since it's already included in
the Android OS, like they do for libz, but no, the NDK is like a stripped
down version of the original SDK.
One more random behavior that is really annoying is java classes that are
actually C++ constructs behind your back, like the Bitmap class. At any
point in time, since my app is about 5MB (and in a virtual machine it can
occupy far more than that) one of my 20 used bitmaps decides to get
"recycled", so what does that mean ? Well, at the first use my app crashes.
Can I control recycling ? Absolutely not. what happens if I check for
recycling, reload bitmap and then use it ? Well, it may happen that between
reloading and drawing it, it gets recycled again ! WHAT ??? The only fix to
this problem is to go ahead and for every instance in the code where my
bitmap gets called do something like this
synchronized (Drawable.getBitmap())
{
if (Drawable.getBitmap().isRecycled())
{
//Do Reloading
}
Drawable.draw( canvas );
}
That's just annoying. I gave up on that and switched to GL even for a 2D
app. I don't even wanna discuss separate thread canvas drawing and how 2
stacked activities are ok, but at the third one, something really weird
happens (screen goes completely black, but if you power-off screen and
power-on it again, chances are, it's back to normal).
*So what do I want :*
An SDK that installs just like ADT into eclipse or visual studio ( I
actually use vsandroid for NDK development ) and that has all the java SDK
features ( debugging, breakpoints, all java classes) as well so that I can
do whatever I can do now in java, in C++.

[Tim Mensch]

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of
apps, this can be helpful so that you may reuse existing code
libraries written in these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html

It's the arrogance of that that annoys me.

"You SHOULD use Java! It's plenty good enough to get things done! Come
to the altar and pray! It will be good for you! Ignore the man behind
the curtain! Reusing code is the exception, not the rule!"

Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it,
meaning that every line of Java you write is Android-only.

Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to
do this in Java, making matters worse (since any cross-platform code now
has to talk to the GUI code through an annoying bridge, and you have to
go through two build sequences that each use a different build system to
actually create an app).

But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means
wasted time when you want to port an app from one platform to another.
It means trying to create a closed ecosystem, even if it's "open" on the
surface.

And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and
skip Android. If they're making enough money on iOS, after all, why
bother porting to Android?

If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus
points if the APIs let you skin your app so that iOS apps can look like
iOS apps. But there's no way I'd want to stick an entire Java stack in
an iOS app just to try to share code, so Java is a mistake no matter how
you slice it.

So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.

Tim

[Doug Linder]

Quite so. I'm glad I'm not the only one who was annoyed by the comments in
that video.

Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"

A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's portable.
Yeah, use render script. That's totally not portable."

Seriously though, imagine the terribly horrible situation in which you have
to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.

I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.

~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app using
native-code languages such as C and C++. For certain types of apps, this
can be helpful so that you may reuse existing code libraries written in
these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come to
the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new platform.
I would even claim that it's a violation of Google's "Don't be evil."
Creating an API that locks you in is evil, period. It means wasted time
when you want to port an app from one platform to another. It means trying
to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and skip
Android. If they're making enough money on iOS, after all, why bother
porting to Android?
If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus points
if the APIs let you skin your app so that iOS apps can look like iOS apps.
But there's no way I'd want to stick an entire Java stack in an iOS app
just to try to share code, so Java is a mistake no matter how you slice it.
So instead we have to rely on third parties to create cross-platform code
that's actually usable. Looking at MoSync these days, for example.
Tim

[Ian Ni-Lewis]

I want to make it clear that I don't agree with or endorse all of the
arguments made in this thread, but I share the frustration. I don't like
being told what language I can or can't use, especially when I've spent
years learning how to successfully write cross-platform code. I'm also not
particularly fond of Java, but that's more of a personal problem than a
technical one. :-)

I do think our limited manpower needs to be carefully allocated and support
for compiled languages needs to be carefully balanced against other
features.

At the same time, I do hope that Android isn't pursuing Java as a platform
lock-in. That sounds evil to me.
Ian

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the comments in
that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's portable.
Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/**tools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come to
the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and skip
Android. If they're making enough money on iOS, after all, why bother
porting to Android?
If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus points
if the APIs let you skin your app so that iOS apps can look like iOS apps.
But there's no way I'd want to stick an entire Java stack in an iOS app
just to try to share code, so Java is a mistake no matter how you slice it.
So instead we have to rely on third parties to create cross-platform code
that's actually usable. Looking at MoSync these days, for example.
Tim
--

You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/9P0159O4qIQJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

--
Ian Ni-Lewis
Developer Advocate
Android Developer Relations

[Michael Salmon]

The reality is android customers do not get the best games because most
developers build first for iOS then port, but NDK is nearly unsupported and
hence many developers I know skip caring. Yes the ratio of paid/free
downloads between iOS & Android is roughly 15:1 to 100:1. But the tools
influence the apps, and the apps influences usage.

Not to mention how annoying this is that it makes integrating with other
native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the comments in
that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's portable.
Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come to
the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and skip
Android. If they're making enough money on iOS, after all, why bother
porting to Android?
If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus points
if the APIs let you skin your app so that iOS apps can look like iOS apps.
But there's no way I'd want to stick an entire Java stack in an iOS app
just to try to share code, so Java is a mistake no matter how you slice it.
So instead we have to rely on third parties to create cross-platform code
that's actually usable. Looking at MoSync these days, for example.
Tim

[Skyrape]

Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE being
like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.

As for first building for iOS I have to say I started the other way around
but now, because the tools are like they are, I can't even consider Android
being the first platform I develop on. I don't love Apple either but come
on, C++ out of the box, including debugging ? No cross-platform developer
can say no to that.

Still though, I wish we could do more than just talk about it. Can't we
contact Google directly saying "Hey, your business could go up 300% if you
would just polish this feature" ? Or somehow tell Google to not invest time
in a dozen new APIs that just <10% of the developers will use in <1% of the
apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because most
developers build first for iOS then port, but NDK is nearly unsupported and
hence many developers I know skip caring. Yes the ratio of paid/free
downloads between iOS & Android is roughly 15:1 to 100:1. But the tools
influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with other
native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the comments
in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's portable.
Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/tools/sdk/ndk/index.html
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come
to the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and skip
Android. If they're making enough money on iOS, after all, why bother
porting to Android?
If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus points
if the APIs let you skin your app so that iOS apps can look like iOS apps.
But there's no way I'd want to stick an entire Java stack in an iOS app
just to try to share code, so Java is a mistake no matter how you slice it.
So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.
Tim

[Zoran Angelov]

I hardly believe that google would come up with any solution to this with
current state of android because of following reasons:

1. Allmost all native code in android is tightly coupled with java/dalvik,
i do not think it would be possible to provide native only sdk with all of
functionalities currently found in android, excluding java/dalvik
dependency in that native sdk;

2. google will not giveup from java/dalvik, and provide native sdk written
from scratch in parallel with java/dalvik, because with that google
confirms that java/dalvik is not suitable for serious games, signal
processing, image processing, computer vision, augmented reality
application development;

So i think that we will be stuck for a long time with current state of NDK.

Post by Skyrape
Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE being
like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.
As for first building for iOS I have to say I started the other way around
but now, because the tools are like they are, I can't even consider Android
being the first platform I develop on. I don't love Apple either but come
on, C++ out of the box, including debugging ? No cross-platform developer
can say no to that.
Still though, I wish we could do more than just talk about it. Can't we
contact Google directly saying "Hey, your business could go up 300% if you
would just polish this feature" ? Or somehow tell Google to not invest time
in a dozen new APIs that just <10% of the developers will use in <1% of the
apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because most
developers build first for iOS then port, but NDK is nearly unsupported and
hence many developers I know skip caring. Yes the ratio of paid/free
downloads between iOS & Android is roughly 15:1 to 100:1. But the tools
influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with other
native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the comments
in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's portable.
Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/**tools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come
to the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android being
much bigger, it means that a lot of developers just develop on iOS and skip
Android. If they're making enough money on iOS, after all, why bother
porting to Android?
If instead the Android APIs were written in cross-platform code (based,
say, on OpenGL, which is available everywhere relevant), then you could
build for Android AND iOS using predominantly the same code. Bonus points
if the APIs let you skin your app so that iOS apps can look like iOS apps.
But there's no way I'd want to stick an entire Java stack in an iOS app
just to try to share code, so Java is a mistake no matter how you slice it.
So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.
Tim
--

You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/itpYghleAbIJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Michael]

I'm not sure whether providing C++ counterparts for all the Java classes
would really increase productivity or make any big difference at all.
There's no way around rewriting parts of an application for a specific
platform anyway, in order to follow the platform's paradigms and to provide
the necessary glue. I doubt that a complete "C++-based SDK" would really
fix the underlying problem. And development using the SDK is in general a
pleasant experience.
A solution to the problem boils down to developing all the
platform-specific parts in Java and to properly factor out the
platform-agnostic code to C++. It's just a little tricky to make a correct
decision on which level to place the JNI interface (i.e. to determine its
granularity). And having to write the JNI layer is annoying, admittedly.

That is not to say the state of the NDK is good at all. It's clear that
many developers have a need for writing (potentially cross-platform) native
code, be it for games, image processing, augmented reality purposes, etc.
As pointed out before, Java/Dalvik just can't cut it. And, as also pointed
out before, it would be highly advantageous for the platform as a whole if
Google catered to these developers somewhat more.

For a start, it would be really nice if Google could expose some more
native APIs. There are quite a few libraries already present on an
Android-based system that developers could make use of, without having to
recompile and statically integrate them again. libjpeg and libpng are the
first ones that come to my mind, but how about video decoding/media playing
libraries? Why not provide some native interface for these, so that proper
hardware support can be leveraged?

Also, we were stuck with an ancient GCC 4.4-based toolchain for what seemed
an eternity. There was no way to use most C++11 features using the official
NDK, and the compiler had some bad NEON-related bugs, too.
Now that we have a GCC 4.6-based toolchain (- thanks to the NDK dev team at
this point! -), I hope that an update to GCC 4.7 isn't far off. Also, an
LLVM-based toolchain (LLVM/Clang/libc++) would be immensely useful. In
fact, this is what I wish for most for the next update.
As far as I remember, there have even been offers on this group to help
with providing these things. If Google could step up and provide more
modern toolchains on a timely basis, that would already be a big win.

IDE integration of the NDK leaves something to be desired, too, at the very
least. The debugging experience using plain GDB is indeed like a thing from
the past. I admit to not having tried out the integration in combination
with Eclipse Juno/SDK r20 yet (mainly because of some annoying CDT indexer
issues), but I'd imagine it's still somewhat clunky.

So, yes, I really wish Google would give the NDK and native development
some more attention (i.e. resources?).

In case anyone from Google is reading this - is there any way to be more
transparent about the NDK? Regarding integration of features, or a future
roadmap? Development in the open, as promised a long time ago?

Post by Zoran Angelov
I hardly believe that google would come up with any solution to this with
1. Allmost all native code in android is tightly coupled with java/dalvik,
i do not think it would be possible to provide native only sdk with all of
functionalities currently found in android, excluding java/dalvik
dependency in that native sdk;
2. google will not giveup from java/dalvik, and provide native sdk written
from scratch in parallel with java/dalvik, because with that google
confirms that java/dalvik is not suitable for serious games, signal
processing, image processing, computer vision, augmented reality
application development;
So i think that we will be stuck for a long time with current state of NDK.

Post by Skyrape
Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE being
like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.
As for first building for iOS I have to say I started the other way
around but now, because the tools are like they are, I can't even consider
Android being the first platform I develop on. I don't love Apple either
but come on, C++ out of the box, including debugging ? No cross-platform
developer can say no to that.
Still though, I wish we could do more than just talk about it. Can't we
contact Google directly saying "Hey, your business could go up 300% if you
would just polish this feature" ? Or somehow tell Google to not invest time
in a dozen new APIs that just <10% of the developers will use in <1% of the
apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because most
developers build first for iOS then port, but NDK is nearly unsupported and
hence many developers I know skip caring. Yes the ratio of paid/free
downloads between iOS & Android is roughly 15:1 to 100:1. But the tools
influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with other
native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the comments
in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's
portable. Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited man
power, and right now that's working on other things. This also accelerates
our platform specific lock-in and long term goals in a way that portable
cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/**tools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done! Come
to the altar and pray! It will be good for you! Ignore the man behind the
curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android
being much bigger, it means that a lot of developers just develop on iOS
and skip Android. If they're making enough money on iOS, after all, why
bother porting to Android?
If instead the Android APIs were written in cross-platform code
(based, say, on OpenGL, which is available everywhere relevant), then you
could build for Android AND iOS using predominantly the same code. Bonus
points if the APIs let you skin your app so that iOS apps can look like iOS
apps. But there's no way I'd want to stick an entire Java stack in an iOS
app just to try to share code, so Java is a mistake no matter how you slice
it.
So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.
Tim
--

You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/itpYghleAbIJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Doug Linder]

Tangibly speaking I honestly think the NDK is pretty good; There's a lot
that could be improved, but hey, it works. :)

The thing I take issue with is this:
" Before downloading the NDK, you should understand that *the NDK will not
benefit most apps*. As a developer, you need to balance its benefits
against its drawbacks. Notably, using native code on Android generally does
not result in a noticable performance improvement, but it always increases
your app complexity. In general, you should only use the NDK if it is
essential to your app—*never because you simply prefer to program in C/C++.*
* *"
(http://developer.android.com/tools/sdk/ndk/index.html)

I simply prefer programming in C/C++, because I can take my code and run it
on, say, my PC, iphone and mac.

..and yes, that _is_ a perfectly good reason to not program using the java
SDK and write a native application instead, and no I do not care to be told
that I'd write a better app if I didn't, and no your java code is not
portable to all of those devices.

I get it. Apps hard crash in C++. Guess what, "Blah has stopped
unexpectedly", they do in java too. I'm a grown up; and I can make that
choice thoughtfully.

It's the attitude I take issue with, not the technical details of the NDK,
which, while I wish they were better, I can appreciate that improving
things takes time and resources, of which there are never enough.

~
Doug.

Post by Michael
I'm not sure whether providing C++ counterparts for all the Java classes
would really increase productivity or make any big difference at all.
There's no way around rewriting parts of an application for a specific
platform anyway, in order to follow the platform's paradigms and to provide
the necessary glue. I doubt that a complete "C++-based SDK" would really
fix the underlying problem. And development using the SDK is in general a
pleasant experience.
A solution to the problem boils down to developing all the
platform-specific parts in Java and to properly factor out the
platform-agnostic code to C++. It's just a little tricky to make a correct
decision on which level to place the JNI interface (i.e. to determine its
granularity). And having to write the JNI layer is annoying, admittedly.
That is not to say the state of the NDK is good at all. It's clear that
many developers have a need for writing (potentially cross-platform) native
code, be it for games, image processing, augmented reality purposes, etc.
As pointed out before, Java/Dalvik just can't cut it. And, as also pointed
out before, it would be highly advantageous for the platform as a whole if
Google catered to these developers somewhat more.
For a start, it would be really nice if Google could expose some more
native APIs. There are quite a few libraries already present on an
Android-based system that developers could make use of, without having to
recompile and statically integrate them again. libjpeg and libpng are the
first ones that come to my mind, but how about video decoding/media playing
libraries? Why not provide some native interface for these, so that proper
hardware support can be leveraged?
Also, we were stuck with an ancient GCC 4.4-based toolchain for what
seemed an eternity. There was no way to use most C++11 features using the
official NDK, and the compiler had some bad NEON-related bugs, too.
Now that we have a GCC 4.6-based toolchain (- thanks to the NDK dev team
at this point! -), I hope that an update to GCC 4.7 isn't far off. Also, an
LLVM-based toolchain (LLVM/Clang/libc++) would be immensely useful. In
fact, this is what I wish for most for the next update.
As far as I remember, there have even been offers on this group to help
with providing these things. If Google could step up and provide more
modern toolchains on a timely basis, that would already be a big win.
IDE integration of the NDK leaves something to be desired, too, at the
very least. The debugging experience using plain GDB is indeed like a thing
from the past. I admit to not having tried out the integration in
combination with Eclipse Juno/SDK r20 yet (mainly because of some annoying
CDT indexer issues), but I'd imagine it's still somewhat clunky.
So, yes, I really wish Google would give the NDK and native development
some more attention (i.e. resources?).
In case anyone from Google is reading this - is there any way to be more
transparent about the NDK? Regarding integration of features, or a future
roadmap? Development in the open, as promised a long time ago?

Post by Zoran Angelov
I hardly believe that google would come up with any solution to this with
1. Allmost all native code in android is tightly coupled with
java/dalvik, i do not think it would be possible to provide native only sdk
with all of functionalities currently found in android, excluding
java/dalvik dependency in that native sdk;
2. google will not giveup from java/dalvik, and provide native sdk
written from scratch in parallel with java/dalvik, because with that google
confirms that java/dalvik is not suitable for serious games, signal
processing, image processing, computer vision, augmented reality
application development;
So i think that we will be stuck for a long time with current state of NDK.

Post by Skyrape
Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE
being like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.
As for first building for iOS I have to say I started the other way
around but now, because the tools are like they are, I can't even consider
Android being the first platform I develop on. I don't love Apple either
but come on, C++ out of the box, including debugging ? No cross-platform
developer can say no to that.
Still though, I wish we could do more than just talk about it. Can't we
contact Google directly saying "Hey, your business could go up 300% if you
would just polish this feature" ? Or somehow tell Google to not invest time
in a dozen new APIs that just <10% of the developers will use in <1% of the
apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because most
developers build first for iOS then port, but NDK is nearly unsupported and
hence many developers I know skip caring. Yes the ratio of paid/free
downloads between iOS & Android is roughly 15:1 to 100:1. But the tools
influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with
other native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the
comments in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's
portable. Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which you
have to compile multiple instances of your application to run on different
platforms. That's the world. That's what chrome, firefox, etc. all do. It's
no big deal.
I suspect the real answer to this question is: We only have limited
man power, and right now that's working on other things. This also
accelerates our platform specific lock-in and long term goals in a way that
portable cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/**tools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done!
Come to the altar and pray! It will be good for you! Ignore the man behind
the curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is to
reinvent the wheel and create their own custom GUI API. Android chose to do
this in Java, making matters worse (since any cross-platform code now has
to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android
being much bigger, it means that a lot of developers just develop on iOS
and skip Android. If they're making enough money on iOS, after all, why
bother porting to Android?
If instead the Android APIs were written in cross-platform code
(based, say, on OpenGL, which is available everywhere relevant), then you
could build for Android AND iOS using predominantly the same code. Bonus
points if the APIs let you skin your app so that iOS apps can look like iOS
apps. But there's no way I'd want to stick an entire Java stack in an iOS
app just to try to share code, so Java is a mistake no matter how you slice
it.
So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.
Tim
--

You received this message because you are subscribed to the Google
Groups "android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/itpYghleAbIJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Zoran Angelov]

I'm not saying that NDK is not good at all.
Actually it is pretty good for what it is intended for: "The NDK is a
toolset that allows you to implement parts of your app using native-code
languages such as C and C++" and nothing else.

And do not expect that NDK will include LLVM, because apple is already
there.

Actually solution would be writing a complete C/C++ SDK, without knowing
about java/dalvik, and after that wrap it with java/dalvik (less
performance loss then oposite case).
That way you will have complete SDK in C/C++, complete Java SDK, no
performance issues with latencies or garbage collector, having happy java
and native developers and not talking about it today about this.

I do not agree that java is more portable than C/C++. Take for example
boost, it can run on almost every platform.
Try running java code on GPU. CUDA for example allows you to run c/c++ on
GPU.

I'm disappointed that i need to use NVIDIA packaged SDK to develop and
debug native application on android, and not having such thing from google.

Post by Doug Linder
Tangibly speaking I honestly think the NDK is pretty good; There's a lot
that could be improved, but hey, it works. :)
" Before downloading the NDK, you should understand that *the NDK will
not benefit most apps*. As a developer, you need to balance its benefits
against its drawbacks. Notably, using native code on Android generally does
not result in a noticable performance improvement, but it always increases
your app complexity. In general, you should only use the NDK if it is
essential to your app—*never because you simply prefer to program in
C/C++.** *"
(http://developer.android.com/tools/sdk/ndk/index.html)
I simply prefer programming in C/C++, because I can take my code and run
it on, say, my PC, iphone and mac.
..and yes, that _is_ a perfectly good reason to not program using the java
SDK and write a native application instead, and no I do not care to be told
that I'd write a better app if I didn't, and no your java code is not
portable to all of those devices.
I get it. Apps hard crash in C++. Guess what, "Blah has stopped
unexpectedly", they do in java too. I'm a grown up; and I can make that
choice thoughtfully.
It's the attitude I take issue with, not the technical details of the NDK,
which, while I wish they were better, I can appreciate that improving
things takes time and resources, of which there are never enough.
~
Doug.

Post by Michael
I'm not sure whether providing C++ counterparts for all the Java classes
would really increase productivity or make any big difference at all.
There's no way around rewriting parts of an application for a specific
platform anyway, in order to follow the platform's paradigms and to provide
the necessary glue. I doubt that a complete "C++-based SDK" would really
fix the underlying problem. And development using the SDK is in general a
pleasant experience.
A solution to the problem boils down to developing all the
platform-specific parts in Java and to properly factor out the
platform-agnostic code to C++. It's just a little tricky to make a correct
decision on which level to place the JNI interface (i.e. to determine its
granularity). And having to write the JNI layer is annoying, admittedly.
That is not to say the state of the NDK is good at all. It's clear that
many developers have a need for writing (potentially cross-platform) native
code, be it for games, image processing, augmented reality purposes, etc.
As pointed out before, Java/Dalvik just can't cut it. And, as also pointed
out before, it would be highly advantageous for the platform as a whole if
Google catered to these developers somewhat more.
For a start, it would be really nice if Google could expose some more
native APIs. There are quite a few libraries already present on an
Android-based system that developers could make use of, without having to
recompile and statically integrate them again. libjpeg and libpng are the
first ones that come to my mind, but how about video decoding/media playing
libraries? Why not provide some native interface for these, so that proper
hardware support can be leveraged?
Also, we were stuck with an ancient GCC 4.4-based toolchain for what
seemed an eternity. There was no way to use most C++11 features using the
official NDK, and the compiler had some bad NEON-related bugs, too.
Now that we have a GCC 4.6-based toolchain (- thanks to the NDK dev team
at this point! -), I hope that an update to GCC 4.7 isn't far off. Also, an
LLVM-based toolchain (LLVM/Clang/libc++) would be immensely useful. In
fact, this is what I wish for most for the next update.
As far as I remember, there have even been offers on this group to help
with providing these things. If Google could step up and provide more
modern toolchains on a timely basis, that would already be a big win.
IDE integration of the NDK leaves something to be desired, too, at the
very least. The debugging experience using plain GDB is indeed like a thing
from the past. I admit to not having tried out the integration in
combination with Eclipse Juno/SDK r20 yet (mainly because of some annoying
CDT indexer issues), but I'd imagine it's still somewhat clunky.
So, yes, I really wish Google would give the NDK and native development
some more attention (i.e. resources?).
In case anyone from Google is reading this - is there any way to be more
transparent about the NDK? Regarding integration of features, or a future
roadmap? Development in the open, as promised a long time ago?

Post by Zoran Angelov
I hardly believe that google would come up with any solution to this
1. Allmost all native code in android is tightly coupled with
java/dalvik, i do not think it would be possible to provide native only sdk
with all of functionalities currently found in android, excluding
java/dalvik dependency in that native sdk;
2. google will not giveup from java/dalvik, and provide native sdk
written from scratch in parallel with java/dalvik, because with that google
confirms that java/dalvik is not suitable for serious games, signal
processing, image processing, computer vision, augmented reality
application development;
So i think that we will be stuck for a long time with current state of NDK.

Post by Skyrape
Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE
being like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.
As for first building for iOS I have to say I started the other way
around but now, because the tools are like they are, I can't even consider
Android being the first platform I develop on. I don't love Apple either
but come on, C++ out of the box, including debugging ? No cross-platform
developer can say no to that.
Still though, I wish we could do more than just talk about it. Can't we
contact Google directly saying "Hey, your business could go up 300% if you
would just polish this feature" ? Or somehow tell Google to not invest time
in a dozen new APIs that just <10% of the developers will use in <1% of the
apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because
most developers build first for iOS then port, but NDK is nearly
unsupported and hence many developers I know skip caring. Yes the ratio of
paid/free downloads between iOS & Android is roughly 15:1 to 100:1. But the
tools influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with
other native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the
comments in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's
portable. Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which
you have to compile multiple instances of your application to run on
different platforms. That's the world. That's what chrome, firefox, etc.
all do. It's no big deal.
I suspect the real answer to this question is: We only have limited
man power, and right now that's working on other things. This also
accelerates our platform specific lock-in and long term goals in a way that
portable cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your app
using native-code languages such as C and C++. For certain types of apps,
this can be helpful so that you may reuse existing code libraries written
in these languages and possibly increased performance. "
http://developer.android.com/**t**ools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done!
Come to the altar and pray! It will be good for you! Ignore the man behind
the curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that, I
submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is
to reinvent the wheel and create their own custom GUI API. Android chose to
do this in Java, making matters worse (since any cross-platform code now
has to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android
being much bigger, it means that a lot of developers just develop on iOS
and skip Android. If they're making enough money on iOS, after all, why
bother porting to Android?
If instead the Android APIs were written in cross-platform code
(based, say, on OpenGL, which is available everywhere relevant), then you
could build for Android AND iOS using predominantly the same code. Bonus
points if the APIs let you skin your app so that iOS apps can look like iOS
apps. But there's no way I'd want to stick an entire Java stack in an iOS
app just to try to share code, so Java is a mistake no matter how you slice
it.
So instead we have to rely on third parties to create cross-platform
code that's actually usable. Looking at MoSync these days, for example.
Tim
--

You received this message because you are subscribed to the Google
Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/**
msg/android-ndk/-/itpYghleAbIJ<https://groups.google.com/d/msg/android-ndk/-/itpYghleAbIJ>
**.
For more options, visit this group at http://groups.google.com/**
group/android-ndk?hl=en<http://groups.google.com/group/android-ndk?hl=en>
.

--

You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/qIywjmqCOQcJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Michael]

Post by Zoran Angelov
And do not expect that NDK will include LLVM, because apple is already

there.

Why not? It's an open-source compiler toolchain/library. And Google seems
to be very interested in providing this:
https://groups.google.com/forum/?fromgroups#!searchin/android-ndk/llvm/android-ndk/cuIVuVIzUPc/ShlHqqmYulQJ
I'm looking forward to seeing the first release with LLVM/Clang support!

Post by Zoran Angelov
I'm not saying that NDK is not good at all.
Actually it is pretty good for what it is intended for: "The NDK is a
toolset that allows you to implement parts of your app using native-code
languages such as C and C++" and nothing else.
And do not expect that NDK will include LLVM, because apple is already
there.
Actually solution would be writing a complete C/C++ SDK, without knowing
about java/dalvik, and after that wrap it with java/dalvik (less
performance loss then oposite case).
That way you will have complete SDK in C/C++, complete Java SDK, no
performance issues with latencies or garbage collector, having happy java
and native developers and not talking about it today about this.
I do not agree that java is more portable than C/C++. Take for example
boost, it can run on almost every platform.
Try running java code on GPU. CUDA for example allows you to run c/c++ on
GPU.
I'm disappointed that i need to use NVIDIA packaged SDK to develop and
debug native application on android, and not having such thing from google.

Post by Doug Linder
Tangibly speaking I honestly think the NDK is pretty good; There's a lot
that could be improved, but hey, it works. :)
" Before downloading the NDK, you should understand that *the NDK will
not benefit most apps*. As a developer, you need to balance its benefits
against its drawbacks. Notably, using native code on Android generally does
not result in a noticable performance improvement, but it always increases
your app complexity. In general, you should only use the NDK if it is
essential to your app—*never because you simply prefer to program in
C/C++.** *"
(http://developer.android.com/tools/sdk/ndk/index.html)
I simply prefer programming in C/C++, because I can take my code and run
it on, say, my PC, iphone and mac.
..and yes, that _is_ a perfectly good reason to not program using the
java SDK and write a native application instead, and no I do not care to be
told that I'd write a better app if I didn't, and no your java code is not
portable to all of those devices.
I get it. Apps hard crash in C++. Guess what, "Blah has stopped
unexpectedly", they do in java too. I'm a grown up; and I can make that
choice thoughtfully.
It's the attitude I take issue with, not the technical details of the
NDK, which, while I wish they were better, I can appreciate that improving
things takes time and resources, of which there are never enough.
~
Doug.

Post by Michael
I'm not sure whether providing C++ counterparts for all the Java classes
would really increase productivity or make any big difference at all.
There's no way around rewriting parts of an application for a specific
platform anyway, in order to follow the platform's paradigms and to provide
the necessary glue. I doubt that a complete "C++-based SDK" would really
fix the underlying problem. And development using the SDK is in general a
pleasant experience.
A solution to the problem boils down to developing all the
platform-specific parts in Java and to properly factor out the
platform-agnostic code to C++. It's just a little tricky to make a correct
decision on which level to place the JNI interface (i.e. to determine its
granularity). And having to write the JNI layer is annoying, admittedly.
That is not to say the state of the NDK is good at all. It's clear that
many developers have a need for writing (potentially cross-platform) native
code, be it for games, image processing, augmented reality purposes, etc.
As pointed out before, Java/Dalvik just can't cut it. And, as also pointed
out before, it would be highly advantageous for the platform as a whole if
Google catered to these developers somewhat more.
For a start, it would be really nice if Google could expose some more
native APIs. There are quite a few libraries already present on an
Android-based system that developers could make use of, without having to
recompile and statically integrate them again. libjpeg and libpng are the
first ones that come to my mind, but how about video decoding/media playing
libraries? Why not provide some native interface for these, so that proper
hardware support can be leveraged?
Also, we were stuck with an ancient GCC 4.4-based toolchain for what
seemed an eternity. There was no way to use most C++11 features using the
official NDK, and the compiler had some bad NEON-related bugs, too.
Now that we have a GCC 4.6-based toolchain (- thanks to the NDK dev team
at this point! -), I hope that an update to GCC 4.7 isn't far off. Also, an
LLVM-based toolchain (LLVM/Clang/libc++) would be immensely useful. In
fact, this is what I wish for most for the next update.
As far as I remember, there have even been offers on this group to help
with providing these things. If Google could step up and provide more
modern toolchains on a timely basis, that would already be a big win.
IDE integration of the NDK leaves something to be desired, too, at the
very least. The debugging experience using plain GDB is indeed like a thing
from the past. I admit to not having tried out the integration in
combination with Eclipse Juno/SDK r20 yet (mainly because of some annoying
CDT indexer issues), but I'd imagine it's still somewhat clunky.
So, yes, I really wish Google would give the NDK and native development
some more attention (i.e. resources?).
In case anyone from Google is reading this - is there any way to be more
transparent about the NDK? Regarding integration of features, or a future
roadmap? Development in the open, as promised a long time ago?

Post by Zoran Angelov
I hardly believe that google would come up with any solution to this
1. Allmost all native code in android is tightly coupled with
java/dalvik, i do not think it would be possible to provide native only sdk
with all of functionalities currently found in android, excluding
java/dalvik dependency in that native sdk;
2. google will not giveup from java/dalvik, and provide native sdk
written from scratch in parallel with java/dalvik, because with that google
confirms that java/dalvik is not suitable for serious games, signal
processing, image processing, computer vision, augmented reality
application development;
So i think that we will be stuck for a long time with current state of NDK.

Post by Skyrape
Finally, someone from Google answered, Congrats to Ian Ni-Lewis for
answering. Knowing that you guys have actually read this post makes us feel
that somehow you care :). Michael Salmon was talking about the IDE
being like from '98 but I can't even debug native code at all. As far as I
remember I could debug code back in '98.
As for first building for iOS I have to say I started the other way
around but now, because the tools are like they are, I can't even consider
Android being the first platform I develop on. I don't love Apple either
but come on, C++ out of the box, including debugging ? No cross-platform
developer can say no to that.
Still though, I wish we could do more than just talk about it. Can't
we contact Google directly saying "Hey, your business could go up 300% if
you would just polish this feature" ? Or somehow tell Google to not invest
time in a dozen new APIs that just <10% of the developers will use in <1%
of the apps ?

Post by Michael Salmon
The reality is android customers do not get the best games because
most developers build first for iOS then port, but NDK is nearly
unsupported and hence many developers I know skip caring. Yes the ratio of
paid/free downloads between iOS & Android is roughly 15:1 to 100:1. But the
tools influence the apps, and the apps influences usage.
Not to mention how annoying this is that it makes integrating with
other native code-bases (e.g. openframeworks) a huge hassle. Or IDE-based
debugging on par with microsoft tools from 1998, lolz.

Post by Doug Linder
Quite so. I'm glad I'm not the only one who was annoyed by the
comments in that video.
Q: "Why no NDK love? It's hard to beat native for speed and cross
platform compatibility"
A: ^_^!!! *Bullet TIME! doooooodgggeee!* "We prefer java. It's
portable. Yeah, use render script. That's totally not portable."
Seriously though, imagine the terribly horrible situation in which
you have to compile multiple instances of your application to run on
different platforms. That's the world. That's what chrome, firefox, etc.
all do. It's no big deal.
I suspect the real answer to this question is: We only have limited
man power, and right now that's working on other things. This also
accelerates our platform specific lock-in and long term goals in a way that
portable cross platform code does not.
~
Doug.

Post by RichardC
"The NDK is a toolset that allows you to implement parts of your
app using native-code languages such as C and C++. For certain types of
apps, this can be helpful so that you may reuse existing code libraries
written in these languages and possibly increased performance. "
http://developer.android.com/**t**ools/sdk/ndk/index.html<http://developer.android.com/tools/sdk/ndk/index.html>
It's the arrogance of that that annoys me.
"You SHOULD use Java! It's plenty good enough to get things done!
Come to the altar and pray! It will be good for you! Ignore the man behind
the curtain! Reusing code is the exception, not the rule!"
Java is a terrible tool for most things I do, but worse than that,
I submit that it's the wrong tool for ANYONE writing smart-phone apps, for
the simple reason that Android is the ONLY platform that uses it, meaning
that every line of Java you write is Android-only.
Every single hardware vendor seems to think that the Right Idea is
to reinvent the wheel and create their own custom GUI API. Android chose to
do this in Java, making matters worse (since any cross-platform code now
has to talk to the GUI code through an annoying bridge, and you have to go
through two build sequences that each use a different build system to
actually create an app).
But it's not a good idea to create Yet Another API for every new
platform. I would even claim that it's a violation of Google's "Don't be
evil." Creating an API that locks you in is evil, period. It means wasted
time when you want to port an app from one platform to another. It means
trying to create a closed ecosystem, even if it's "open" on the surface.
And because you can STILL make more money on iOS, despite Android
being much bigger, it means that a lot of developers just develop on iOS
and skip Android. If they're making enough money on iOS, after all, why
bother porting to Android?
If instead the Android APIs were written in cross-platform code
(based, say, on OpenGL, which is available everywhere relevant), then you
could build for Android AND iOS using predominantly the same code. Bonus
points if the APIs let you skin your app so that iOS apps can look like iOS
apps. But there's no way I'd want to stick an entire Java stack in an iOS
app just to try to share code, so Java is a mistake no matter how you slice
it.
So instead we have to rely on third parties to create
cross-platform code that's actually usable. Looking at MoSync these days,
for example.
Tim
--

You received this message because you are subscribed to the Google
Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/*
*msg/android-ndk/-/itpYghleAbIJ<https://groups.google.com/d/msg/android-ndk/-/itpYghleAbIJ>
**.
For more options, visit this group at http://groups.google.com/**
group/android-ndk?hl=en<http://groups.google.com/group/android-ndk?hl=en>
.

--

You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/android-ndk/-/qIywjmqCOQcJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.

[Nalin Savara]

Post by Skyrape
Hi,
*So, When is the NDK going to be on par with the Java SDK ? Is there any
on going progress on the matter ? Is Google working on it ? Is there an
announced release date ?*

Buddy-- another OS-- called Meego exactly answers your question/problem-->
that c++ on Meego can do exactly c++ on a desktop linux box can do.

Also, you can install OpenJDK there-- which is JDK.

And in that sense, it's better than Android- but yes; I try not to think
too much abt that-- because it makes me sad to remember it's story...

Regards,

Nalin