Started playing with Android Studio 1.4 last week end. The Java implementation looks pretty straight forward. My real goal is native C/C++ development to see if I can get my game engine to run on it. It's mostly to see if I can do it.

From what I can tell, there's two ways to write native C/C++ for Android.

1) Write a function in C/C++ and link it to a Java native function call.

2) Avoid Java all together and use the NDK's Native Activity to implement purely in native code.

Would this be correct?

Also, does NDK's compiler support C++ 11 features?

Thanks.

Would this be correct?

In essence correct.

The NDK's native activity will still likely need a small amount of Java code to reach a few features. You might need a little Java for some rare pieces of functionality.

Also, does NDK's compiler support C++ 11 features?

Yes, but possibly not turned on by default.

You need to ensure you have the flag -std=c++11 set in your build tools, and that your build chain is correctly configured. It may or may not be set up that way based on what tools you are using.

Since as frob says, you likely need some java anyway, I don't feel like the native activity is much help really.

It also has the disadvantage of being maintained by the underprioritised NDK team. (I'm sure they are great guys, but it is obvious they don't get the time and resources they need)

So I find it easier to avoid any "weird and wonderful" bugs introduced there, and just write my own "native activity" which include all the features I need, and where I can fix them if they don't work as expected, and debug all parts of it.

It's not really that much java code needed anyhow.

On NDK debugging... I spend a week failing to get it working with Android Studio in a good way.

Seems it mostly work if you use a Nexus device or something. But its not just debugging. The NDK support in AS is still in some kind of beta stage.

I'm back to the old system with eclipse and ant now.

Thanks for the info guys. One more question. One of my friends is giving me his unused Android phone (Sony XPria) to use for development. Not sure which XPria since I don't have the phone yet.

Question: Is each device engineered to only use one specific API or a range of API's? Can a given phone use different API's like 21, 22 or 23 or is it designed for only one API for example 19?

Once I get my friends phone (first time touching an Android phone), I'll need to figure out what API it is currently using and I assume it's the API I'll target for my tests.

For the java part, the device has a specific API version, tied to the installed android version.

But you can bundle your application with a "compatibility library", if you do, you can also use newer APIs on older devices.

I think it is included with the app templates now

For the NDK part, it has the same API version as the java, and it is a somewhat harder limit.

The NDK for a specific version is only guarnteed to work on that level and higher.

In practice, I think you can actually build for a newer up to 19 and run it on older devices, but at 21 you can't anymore.

So if you build for NDK r21, it will only run on devices with Android 5.0+

(You can still download the latest ndk, it includes all api versions, and you should, for the latest versions of the tools)

So I have been doing this. Porting my android game engine/framework, which was done in Java to pure C++ solution using the NDK
Its a work in progress, but I can successfully create pure native android application that supports a OpenGL ES 2.0 context.

Based on my current experience with this I can definitely say:

Beware though, debugging NDK could be a real a pain in the neck

This is 100% true. I have not been able to debug (step through, step over, set breakpoints, and etc) with the NDK at all. I spend a solid week trying to set up various tools like Visual Studio 2015, Android Studio, and command line version of GDB. But in the end I could never get it working. Right now the __android_log_print function is my best friend

I don't feel like the native activity is much help really.

....

So I find it easier to avoid any "weird and wonderful" bugs introduced there, and just write my own "native activity"

I'm not sure if you are talking about the android glue header/cpp they included in the NDK here, but that android glue header is kind of questionable. I ended up writing my own version. I felt like mainly the sections dealing with some of the activity callbacks and ALooper code to be spaghetti like/messy. At the very least I understand how all of it works


Tips:

Visual studio 2015
Install and download Visual Studio 2015 (community edition is fine) with the cross-platform tools for mobile. I say this only because of the Android emulator seems to be way faster / less laggy than the google one. Also you want, you need that phone from your friend! An emulator can never properly test the way real hardware will handle. Also visual studio comes with a out of box solution that uses an OpenGL context. It is a hugh resource to study from. Its all done in C++ and you can even build/run it on a device.

Now just as a fair warning, visual studio is not all lollipops and rainbows. I actually have never been able to successfully deploy that out of the box solution onto the emulator. I have been able to deploy and run it on my Android 4.2 (API 17) physical device. But when it comes to the emulator it runs into some issue about not being able to find the emulator or something. With that being said I have been able to use the ADB toll through the command line, connect to the emulator, deploy my own native app, and run it

Logcat and __android_log_print function
Best friends ever. All day. Everyday

Honest tip
The NDK can be quite overwhelming. When you run into problems it can be very very unforgiving. Especially because the debugging can be really really rough. Just take a break, step back, and come at it later. The main thing is you keep moving forward, eventually things start to click, and then you'll be really moving before you know it

I'm not sure if you are talking about the android glue header/cpp they included in the NDK here, but that android glue header is kind of questionable.

That's the one. I've just skimmed it, but didn't feel it worth the effort.

All I need is an activity that sets up a GL context, sets up my JNI stuff, and any java service I need, and kicks it all into gear.

And I'd like the source code for it to be part of my project.

On NDK debugging.. sorry to hear that. Even though gdb isn't ideal, it's better then log prints only. (there's a lot of those in my code too...)

I've got a few tips that might help.

1. use ndk-gdb-py instead of ndk-gdb to start it up (ndk-gdb is buggy)

2. also ndk-gdb-py is buggy on some versions of android which is pre-64 bit. It makes it fail to find the app_process. You can fix it by patching line 781 in ndk-gdb.py, so it just looks for app_process instead of app_process32 (or fix it properly, then give me a patch ;) )

3. If the above doesn't help, you might have a device with one of the run-as bugs.. Different fix depending on which it is, but it all involves rooting the device. Either set suid bit on run-as, or replace it with a working version in worst case

I now have my friends phone. You'd think I'd never used a cell phone before. Couldn't figure out how to turn it on or unlock the screen. He reset it to factory defaults before handing it over.

Hope this things not too old. Below are the stats.

Sony at&t XPERIA LT28at

Audroid version: 2.3.7

Kernel version: 2.6.35.11-307007+

Build Number: 6.0.C1.257

So from this info, would I be targeting API 10?

Android version: 2.3.7

..

So from this info, would I be targeting API 10?

Yes. From 2.3.3 to 2.3.7 are API 10.