Sign in to follow this  
howie_007

New to Andriod development - two questions

Recommended Posts

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.

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by Olof Hedman

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Edited by Olof Hedman

Share this post


Link to post
Share on other sites
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 Edited by noodleBowl

Share this post


Link to post
Share on other sites

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

Edited by Olof Hedman

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

I just did something and I don't know why it worked.

 

I tried building an SDL2 OpenGL ES2 test app targeting API 10 since the phone is API 10 and I would get the error "No resource identifier found for attribute 'hardwareAccelerated' in package 'android'". It builds fine if I target API 15. It wouldn't install on the phone because it's API 15. So I changed the AndroidManifest.xml to a minimum of 10 but a target of 15. It compiled, installed on the phone and ran. It's just a spinning cube but it shows that OpenGL ES2 works.

 

The question is, why does this work? Why is the phone allowing API 15 on it?

Share this post


Link to post
Share on other sites

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


unfortunately I have done all these things already. It blew my mind that all of this never worked. But in the end I think I'm stuck with a device that does not work. I could never hit my break points for whatever reason. I could get the app to show up and launch, but I had to use the no wai option otherwise I wold get stuck at trying to find the debugger. Even then the breakpoints would not trigger. I might try using the visual studio emulator and running it that way, but log statements have gotten me pretty far so far
 

The question is, why does this work? Why is the phone allowing API 15 on it?

Somebody correct me if I'm wrong but

The phone does not have API level 15 on it. It still has API level 10
What you are doing by setting the target API to level 15 and the min API level to 10 is basically you are saying: Hey android application you have been tested and are meant for android devices at API level 15, but those guys out there that have at least API level 10 allow them to run you too. If an android device comes across that does not meet that min API level then sorry they can't run you

As for the weird error, it sounds like SDL was/is trying to set something that is mean for higher APIs. But since your device only has API level 10 that feature or features are not available Edited by noodleBowl

Share this post


Link to post
Share on other sites

As for the weird error, it sounds like SDL was/is trying to set something that is mean for higher APIs. But since your device only has API level 10 that feature or features are not available

 

That error ("No resource identifier found for attribute 'hardwareAccelerated' in package 'android'") is from compiling the java part with ant (ant debug).

 

Why is it some code will be ignored when you try to compile it as a static library?

Share this post


Link to post
Share on other sites

Why is it some code will be ignored when you try to compile it as a static library?


Not sure why that error is being thrown,. I honestly didn't even know SDL has support for android.
To me it just sounds like SDL is saying that that feature is enabled when it really does not exist
 

http://stackoverflow.com/questions/12619974/no-resource-identifier-found-for-attribute-hardwareaccelerated-when-building-w

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this