Hot answers tagged ndk
I don't have examples readily available, but obfuscating your code will not really provide any significant advantage in preventing piracy of your application. Piracy is typically accomplished through hacks that bypass copy protection or DRM checks, which can be done at the machine code or VM opcode level. No amount of obfuscation of the higher level code ...
If your assets don't change frequently, then upload the the assets to some folder on sdcard. Then read your assets from there. And if you assets change, you can easily make small script/batch file that uploads only modified files. Then run this script each time before running your app.
You need to read the error message more carefully: In file included from jni/src/GLIncludes.h:41:0, from jni/androidLauncher.cpp:4: jni/src/glm/glm.hpp:86:18: fatal error: limits: No such file or directory As you can see, the glm.hpp header is found. It's limits that is not found, because by default the NDK uses a stripped-down C++ ...
If you are still interested the Android SDK provides a native offuscation tool : ProGuard. And during Google IO 12 they have announced a new “application encryption” feature (DRM) but detail are still unknown.
to add onto the other answers, the way to get people to pay for your game (not pirate it) is one, use ads, two, make people want to buy it: make it good and give them a free trial so they can see if they like it. That could even mean giving it out for free and letting them 'donate'. You could also use things like in app purchases (they could be circumvented, ...
When I worked with the NDK a year ago, I build the .so file with the NDK make. Then I copied the .so from the NDK to the /lib folder of my project. It worked without a problem. Do the method names in your NDK-Project match the fully qualified class-/methodnames of the classes where you want to call the JNI functions? If you have a class: package ...
Found the problem. It was hidden in some legacy NDK code ported from the iOS version. Previously I was loading and unloading textures in the native code. In the destructor in question there was a glDeleteTextures call that was removing the texture. I'm not sure why it didn't cause a problem on the first reload, but it now works
I do quite a bit of the opposite -- I leverage the Android facilities for loading images from disk and into OpenGL, and then return the texture ID back over JNI. So basically, I have native code, a JNI bridge, and then a series of utility functions in Java that do the actual work, and my call sequence looks something like: [native code] -> [JNI code] -> ...
Ant build property "asset.dir" is responsible for providing name of assets directory. It's "assets" by default, but you can change it to something like "../assets". This changes path of entire directory, but if you have Android-specific resources, you can still use "res" directory.
Yes, you can absolutely use files in other directories. Place the assets you have in to the assets directory (sibling to the res directory), and use the AssetManager to access them. To load bitmaps, you'll want the BitmapFactory, and you'll have to do some extra work if you intend to load resolution dependent images. Be careful about loading Bitmaps more ...
Only top voted, non community-wiki answers of a minimum length are eligible