NDK all from within Eclipse

[Robert Green]

I was going to post this to the group but figured I'd write up a how-
to on my website instead. Basically, here's how you configure Eclipse
to do nice C editing and automatically build your native code for you
on-save. It also automatically refreshes your lib directory and
consequently ADT puts it straight into your APK.

http://www.rbgrn.net/content/348-get-your-eclipse-integrated-ndk-on

I started doing a lot more native dev lately and it cut the time in
half. Let me know if you have problems/questions with it.

[Mathieu]

Thx for the tip!

Very usefull!

> --
>
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>

[guich]

AWESOME!!!!!!

This topic should really go into a sticky....

[tylik]

Robert,

thank you for these very helpful instructions, but somehow it does not
completely work for me and the following happens when I try to run the
application after changing the C part of it:
- the .so file is rebuilt
- Java code is compiled
- application is launched somehow picking up the previous version
of .so
file. It looks like the project is not properly refreshed after the
Native
builder completes

Tried the following to fix the problem with no success:
- Properties->Builders - moved the Native Builder to the top of the
list
- Properties->Builders->Native Builder->Edit->Refresh - checked "The
folder
containing the selected resource"

Can you please tell me the version of Eclipse you are using ? I am on
20090920-1017
--
Best regards,
Dmitry

[Robert Green]

I'm not sure what to tell you. I'm running
Eclipse Version: 3.5.1
Build id: M20090917-0800

so one version before yours. They haven't changed the builder stuff
in ages, so I can't imagine that it's a bug with it. Do you have
other builders configured? I've had deployment weirdness with various
resources in ADT before. Sometimes a good old fashioned clean will
take care of the problem, other times I just reboot or rename some
files. It definitely still has its quirks, but the instructions I
gave work 100% for me.

Sorry I can't offer more help!

[KK]

This is really nice.. Thanks Robert!!!

[Kevin Duffey]

Good info..bookmarked your site. I am curious tho.. when building native code.. is it for a specific phone? I ask because I thought various phones have different hardware under them. I have a moto droid. What about when the Snapdragon's come out? I fear having to build native for each platform and try to some how ship this in one .apk for the market? Or are we lucky enough that linux is the underlying OS and is the same on all of them so we don't have to worry about special compiling for different phones?

[Robert Green]

This is where a Google employee should step in and help out :)

As far as I know, everything is and will be ARM for a while. I've
wondered the same thing, though. What happens when someone wants to
build an x86 Android device? Will they be able to compile all of
Android to x86? NDK apps will be screwed then, though, as they are
all built for ARM.

I'm not sure that any of that has anything to do with what I was
bringing to the table but it's good discussion none the less :)

On Dec 20, 11:33 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> Good info..bookmarked your site. I am curious tho.. when building native
> code.. is it for a specific phone? I ask because I thought various phones
> have different hardware under them. I have a moto droid. What about when the
> Snapdragon's come out? I fear having to build native for each platform and
> try to some how ship this in one .apk for the market? Or are we lucky enough
> that linux is the underlying OS and is the same on all of them so we don't
> have to worry about special compiling for different phones?
>

> On Fri, Dec 18, 2009 at 7:32 PM, KK <krishnakumar.ramachand...@gmail.com>wrote:
>
> > This is really nice.. Thanks Robert!!!
>
> > On Dec 16, 4:03 am, Robert Green <rbgrn....@gmail.com> wrote:
> > > I was going to post this to the group but figured I'd write up a how-
> > > to on my website instead.  Basically, here's how you configureEclipse
> > > to do nice C editing and automatically build your native code for you
> > > on-save.  It also automatically refreshes your lib directory and
> > > consequently ADT puts it straight into your APK.
>
> > >http://www.rbgrn.net/content/348-get-your-eclipse-integrated-ndk-on
>
> > > I started doing a lot more native dev lately and it cut the time in
> > > half.  Let me know if you have problems/questions with it.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Kevin Duffey]

This is my primary concern... I want to work on a music app. The latency issues with pure Java are too great. Unless Android brings us ASIO like capabilities for music apps, Android devices will never have anything close to what iPhone has in regards to music apps. The same probably could be said for real-time video games. The best shot we have right now seems to be using NDK. If we start writing games and music apps with NDK and a few new devices come out and our stuff won't work with it.. we're screwed. My hope is that the underlying OS is linux on all these devices and that hopefully the compiled C code runs on linux and not the specific hardware. I haven't used it yet, but does NDK provide the ARM compiler? The only C compiler I know for Eclipse is GCC. So does it compile to ARM instructions?

I suppose worse case is our apps become like cross-platform C apps, and we'll have to do some cpu specific code for Arm, Snapdragon, etc. But then the .apk files we upload are going to get larger I would imagine. Maybe I am worried over nothing and it will be answered soon when different cpu devices come out for Android.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[guich]

Hi Robert,

Do you know how to make the Java project recognize the includes for
the .c? It keeps giving me warnings when i edit the files in Eclipse.

cheers

guich

[Robert Green]

guich - you'd have to have CDT compile for you to fix that and that
get much trickier to set up. My method has those limitations.

Kevin,

Let me clear a few things up:

1) ARM is an instruction set, just like x86 is. Snapdragon is an ARM
CPU. Every Android phone has an ARM CPU.
2) Android does and will run Linux as the underlying OS. I don't
think you have to worry about that changing.
3) In the event that Android supports more architectures, we'll
probably have some time to update our NDK and build to the new
targets.

I'd just go ahead and develop your apps. Worst case scenario is that
you'll have to do a little extra support work in the future, but my
guess is that you won't have to change your code, just your project
configuration. You mentioned building an app like cross-platform c.
I don't think it will be like that at all. This is and probably will
always be single-platform but multi-CPU-architecture, which is a
totally different thing. It just means that in NDK in the future,
when you run make app=myapp, it'll compile more than one SO - one for
each architecture. Same code on your end. At least that's the
logical way to have it work.

Wow this is off-topic!

[Kevin Duffey]

Thanks Rboert, and I don't think it's that off topic. You opened up with how to set up the NDK, this is NDK related. :) I hope you are correct and I agree that Google should make the NDK add (either optionally or automatically) .so files for each platform it supports, and the .apk can bundle them all, and the loadLibrary call should hopefully figure out based on architecture which SO to load. Worse case, I can live with checking the arch and loading the right .so, although it would be nice if something like I18N was done, where we put soname_arm.so, soname_othercpu.so  and it can figure it out and load it for us.

[Dianne Hackborn]

On Mon, Dec 21, 2009 at 12:39 AM, Robert Green <rbgrn.net@gmail.com> wrote:

As far as I know, everything is and will be ARM for a while.  I've
wondered the same thing, though.  What happens when someone wants to
build an x86 Android device?  Will they be able to compile all of
Android to x86?  NDK apps will be screwed then, though, as they are
all built for ARM.

I think David has already answered this, but --

There is currently no x86 NDK, so anyone making an x86 device will not be able to run applications with native code (and no applications currently on Market with native code will show up on such a device).  I am sure at some point in the future there will be x86 devices with an x86 NDK, in which case yes you will need to have x86 code as well as ARM code to run on all devices.  (And of course there are also people working with MIPS etc.)

This is one of the disadvantages of using the NDK.  For the people who are going whole-hog and writing their entire app in native code...  well, I think that's just going to be the world they end up living in.  I would like for people who are just using it to accelerate certain functions that we have a way for them to say the native code is not requires, so they can be installed on any device and switch to native implementations where available.

As far as what tools there might be to support this, it isn't really known.  First thing is to just have a non-ARM NDK. :)

Also you can get yourself into this same position on ARM CPUs as well.  Whenever there is an NDK for ARM11 CPUs then you will be able to build your code for that, which means it won't run on any devices with an ARM9 or whatever (of course current ARM9 native code will be fine on the newer processors).  Note that this isn't device-specific, but just using features of newer ARM architectures like the FPU or NEON instructions.

When you bundle your code into the .apk, it is put into a directory corresponding to the CPU architecture, so Market can know which devices it will work with and the system can pick the right code to use at install time.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Doug Schaefer]

On Tue, Dec 22, 2009 at 1:52 PM, Dianne Hackborn <hac...@android.com> wrote:

On Mon, Dec 21, 2009 at 12:39 AM, Robert Green <rbgrn.net@gmail.com> wrote:

As far as I know, everything is and will be ARM for a while.  I've
wondered the same thing, though.  What happens when someone wants to
build an x86 Android device?  Will they be able to compile all of
Android to x86?  NDK apps will be screwed then, though, as they are
all built for ARM.

I think David has already answered this, but --

There is currently no x86 NDK, so anyone making an x86 device will not be able to run applications with native code (and no applications currently on Market with native code will show up on such a device).  I am sure at some point in the future there will be x86 devices with an x86 NDK, in which case yes you will need to have x86 code as well as ARM code to run on all devices.  (And of course there are also people working with MIPS etc.)

The android-x86.org gang have an NDK in the works. I'm not sure how they're specifying the replacement for 'armeabi'. But it's an open source group if you're interested in trying it or helping them out.

[blindfold]

> I would like for people who are just using it to accelerate certain functions
> that we have a way for them to say the native code is not requires, so they can
> be installed on any device and switch to native implementations where available.

Perhaps something like <uses-feature android:name="android.native" />
in the future? My app uses native code but it also runs fine without,
so people who want to run it on an x86 netbook currently have to
install the APK from my own website since the Market will not list the
app for them (the Market currently cannot know if my app will work
without the native code).

Thanks

On Dec 22, 7:52 pm, Dianne Hackborn <hack...@android.com> wrote:

> hack...@android.com