For anyone else who encounters similar problems, these are the steps I took: In every case so far I’d gone the “ right-click -> Android Tools -> Add native support” route, so I decided to get back to basics and do things manually. No includes.Įventually, I decided that there must be some kind of problem with the Android tool chain provided by the ADT. I created a brand-new project with a basic JNI test as a sanity check. The include paths in the Eclipse C/C++ build properties were obviously correct, but still, no includes. Googling had turned up quite a few people with similar problems, but none of the proffered solutions worked for me. But I couldn’t actually deploy the app from within Eclipse because the IDE itself couldn’t see the includes, and so wouldn’t let me launch the app because it contained “errors”. Even during the Eclipse build, it was fine. The maddening thing in all this was that the ndk-build command was working fine, and building the JNI glue without any problems. Still, Eclipse couldn’t find the includes. I went away and watched TV for a while (“ A touch of cloth“, a new spoof detective show on Sky 1, by the way, is hilarious!). I checked it out from a terminal and fiddled with various things. ![]() I checked it out as a new C++ project, and manually added the appropriate nature and settings for an ADT project (Yes, I was getting desperate). I checked it out as a new (basic Android) project. I checked the project out, and Eclipse couldn’t resolve the platform includes. To cut a long story short, it didn’t work. The engine itself is (as mentioned above) cross-compiled separately, and there’s a simple Ant build that takes care of copying in the required shared libraries during the build. The android side of things has a bit of C that exposes the game engine to Java via JNI. The way this project is set up is fairly convoluted, but it works. “ Now to get going on the Android side of things, where I actually need to make changes”. This went without a hitch once I’d updated a few things in the Makefile to adjust for the local setup. The engine itself is a separate (non-Android) project, so I started by grabbing the source from subversion, and did the cross compile using the latest NDK (r8b). The background is that I had an existing Android project that had some cross-compiled code (actually, the Quake III engine) that required a bit of work. But Windows is what I have to hand at the moment, so it’s what I must work with. My position on Windows as a development platform are well known around these parts, and I don’t think there’s really any need to go into all that again. To borrow an unrelated phrase from elsewhere, it’s been emotional – I’m guessing the problems I’ve had are a combination of my lack of knowledge of Windows, and Windows lack of knowledge of, well, anything really. ![]() Whew! Just spent an “interesting” hour or two trying to get some native android code working under Eclipse on Windows… Although this isn’t the first time I’ve used the NDK, it’s the first time I’ve tried to get it working with Eclipse on the Windows (+Cygwin) platform.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |