Develop Reference

JNI called with jstring parameters, but one of them becomes NULL

I'm calling native function from Java:
String pathTemp = Environment.getExternalStorageDirectory().getAbsolutePath()+Const.PATH_TEMP
String pathFiles = Environment.getExternalStorageDirectory().getAbsolutePath()+Const.PATH_FILES
engine.init(someInt, pathTemp, pathFiles);
And I have the native function:
extern "C" JNIEXPORT void Java_com_engine_init(JNIEnv *env, jobject __unused obj, jint someInt, jstring pathTemp, jstring pathFiles) {
const char *pathTemp_ = env->GetStringUTFChars(pathTemp, JNI_FALSE);
const char *pathFiles_ = env->GetStringUTFChars(pathFiles, JNI_FALSE); // <-- CRASH
// More init code
env->ReleaseStringUTFChars(pathTemp, pathTemp_);
env->ReleaseStringUTFChars(pathRecording, pathRecording_);
}
The problem: pathTemp is arriving good, but pathFiles==NULL in native function.
Rechecked, and confirmed - both strings are non NULL in java.
One more strange thing - The problem is on LG-G3 (android 6.0).
On Meizu PRO 5 (android 7.0) - everything works good - both strings are intact.
What is this JNI magic? Any clue?

I had the same problem as this and while I can't guarantee this is the same, I found a better solution than re-ordering the parameters.
tldr; Ensure the code works for 32bit and 64bit platforms as pointers have different sizes. I was running 32bit native code and passed nullptr as a parameter and java expected a long which resulted in all parameters after the nullptr to be invalid.
(JJLjava/lang/String;Z)V -> (final long pCallback, final long pUserPointer, final String id, final boolean b)
pCallback was always set to a valid value (pointer casted to jlong in c++) and pUserPointer was always nullptr. I found this answer and tried switching the order around and it 'just worked' but I knew that fix was never going to be approved.
After looking at the JNI documentation on the Android website again (https://developer.android.com/training/articles/perf-jni) I took note of the "64-bit considerations" section and took a stab at my assumption of the data size. This feature was developed with a 64bit device (Pixel 3) but issues had been reported on a 32bit device (Amazon Fire Phone) so nullptr would be 32bit but the java function still expected a long (64bit).
In my situation the offending parameter was always unused so I could safely remove it and everything "just worked" (including some other parameters which were broken).
An alternative would be to have a define/function/macro for JniLongNullptr which is just 0 casted to jlong.

Not an answer, but workaround. Moved the strings (in parameters) to be before int parameter. Now it's working. I have no idea why is this.

How to get device model as appears in 'Google Play Developer Console'?

I am a developer and trying to block a specific model of the Samsung Galaxy Note4 in Google Play Developer Console, problem is I can't find a correlation between the device model to what they write in the console.
For example, I want to know what SM-N910C translates to from the below list I took from the console:
Any ideas how to do that? Manually or programmatically...
I don't think it's part of the http://developer.android.com/reference/android/os/Build.html

So this is undoubtedly too late for you, but I have recently had the same question, so I decided to look into it, and I've developed a working theory.
I believe that the two strings that appear in the Google Play Developer Console are Android system properties. The more user-friendly one is "ro.product.model" and the other is "ro.product.device". This mapping appears to work, at least with the devices I have available right now. If anyone finds that these two values do not match what Google provides, please comment to that effect!
Programmatically reading Android system properties requires a JNI call into native code, like so:
package com.example;
class Native {
// pass a String[2]
public static native void readModelAndDevice(String[] _results);
}
-
#include <jni.h>
#include <sys/system_properties.h>
char model[256], device[256];
extern "C" JNIEXPORT void JNICALL com_example_Native_readModelAndDevice
(
JNIEnv * _java, jclass _class, jobjectArray _array
)
{
__system_property_get("ro.product.model", model);
__system_property_get("ro.product.device", device);
jstring jmodel = _java->NewStringUTF(model);
jstring jdevice = _java->NewStringUTF(device);
_java->SetObjectArrayElement(_array, 0, jmodel);
_java->SetObjectArrayElement(_array, 1, jdevice);
return;
}
Anyone who has never done JNI in Android Studio before should complete a JNI tutorial before trying this example.

SDL2, JNI and UnsatisfiedLinkError

I have the following setup - a MainActivity with button which starts SDLActivity (SDL2). On the C++ side of my SDL project I have a main.cpp with declared native function:
extern "C" void Java_org_libdsl_app_SDLActivity_nativeSetAcc (JNIEnv* env, jclass clazz, jint Acc);
void Java_org_libdsl_app_SDLActivity_nativeSetAcc (JNIEnv* env, jclass clazz, jint Acc)
{
SDL_Log ("set acc");
// does something with the Acc value
}
I've put the following in the SDLActivity.java:
public static native void nativeSetAcc (int Acc);
but I'm getting unsatisified link error (java.lang.UnsatisfiedLinkError: Native method not found: org.libsdl.app.SDLActivity.nativeSetAcc:(I)V)
The C/SDL side compiles OK ("jni.h" is included as well). The android part runs fine until I want to use nativeSetAcc;
The strange part is that other JNI functions from SDL library do indeed work (nativeQuit, nativeResume, etc). And I'm sure that I do LoadLibrary ("main") - the code inside main's main() is working (looping SDL events, etc).
Looking at the hexdump of libmain.so I do see the Java_org_libdsl_app_SDLActivity_nativeSetAcc string.
Please help! Surely I'm missing something small, but I can't see.

OK Guys, I'm stupid. Instead of libsdl I was using libdsl in the code. A little sleep at sunday is very recommended

Obtaining the name of an Android APK using C++ and the NativeActivity class

I'm writing an Android app using the NDK and NativeActivity. My app depends on a few bits of third party code that are shipped as assets. Currently I'm working on trying to extract those assets while keeping the folder structure intact.
I've tried using the AssetManager, but to keep the folder structure intact it seemed like there would a huge amount of code involved, for a simple task such as what I've mentioned. I've since switched focus to try to implement treating the APK as a ZIP file and extract its contents that way. But that requires I find the exact path to the APK.
In a normal Android app one would use getPackageCodePath, but this is an abstract method attached to the Context class. My question is how do I obtain the exact path to the APK when not using a normal Activity?
Also I tried calling getPackageCodePath via JNI, but that crashed the app on account of not being able to find the method.
EDIT:
Is this even possible?

I was actually able to call getPackageCodePath via JNI and get it to work. The following code put at the top of android_main in the native-activity sample in NDK r7 logs the correct path and doesn't crash:
void android_main(struct android_app* state) {
struct engine engine;
ANativeActivity* activity = state->activity;
JNIEnv* env = activity->env;
jclass clazz = (*env)->GetObjectClass(env, activity->clazz);
jmethodID methodID = (*env)->GetMethodID(env, clazz, "getPackageCodePath", "()Ljava/lang/String;");
jobject result = (*env)->CallObjectMethod(env, activity->clazz, methodID);
const char* str;
jboolean isCopy;
str = (*env)->GetStringUTFChars(env, (jstring)result, &isCopy);
LOGI("Looked up package code path: %s", str);
...
}
I feel like this might not be a great solution, though. There are two things that worry me:
Thread safety - there's an ugly warning about only using the env member of ANativeActivity in the main Java thread, and if I understand things correctly, this code is going to get run in the native activity's thread.
ANativeActivity's clazz member appears to be misnamed and is actually the instance of the Java NativeActivity instead of the class object. Otherwise this code wouldn't work. I really hate relying on something that is obviously misnamed like this.
Aside from that, it works, and I'm actually about to use it myself to try to extract the assets out of the .apk using libzip and into the data directory.

Since I just had to search for exactly how to do the attach/detach calls I'll paste the updated version here.
The following seems to get the right location without crashing (after minimal testing)
ANativeActivity* activity = state->activity;
JNIEnv* env=0;
(*activity->vm)->AttachCurrentThread(activity->vm, &env, 0);
jclass clazz = (*env)->GetObjectClass(env, activity->clazz);
jmethodID methodID = (*env)->GetMethodID(env, clazz, "getPackageCodePath", "()Ljava/lang/String;");
jobject result = (*env)->CallObjectMethod(env, activity->clazz, methodID);
const char* str;
jboolean isCopy;
str = (*env)->GetStringUTFChars(env, (jstring)result, &isCopy);
LOGI("Looked up package code path: %s", str);
(*activity->vm)->DetachCurrentThread(activity->vm);

Had to modify it to this in the year 2014.
ANativeActivity* activity = state->activity;
JNIEnv* env=0;
activity->vm->AttachCurrentThread(&env, NULL);
jclass clazz = env->GetObjectClass(activity->clazz);
jmethodID methodID = env->GetMethodID(clazz, "getPackageCodePath", "()Ljava/lang/String;");
jobject result = env->CallObjectMethod(activity->clazz, methodID);
jboolean isCopy;
std::string res = env->GetStringUTFChars((jstring)result, &isCopy);
LOG_DEBUG("Looked up package code path: %s", res.c_str());
activity->vm->DetachCurrentThread();

Did you try to read /proc/self/cmdline from your application?
You should be able to open it as a normal (as far as proc files are normal :-) so you can read from the file until EOF, but not seek) c FILE and read from it.
As an example for the phone app, I can see from ps in android that the name of the applications is the expected app name:
# ps | grep phone
radio 1588 839 1467420 103740 SyS_epoll_ 7f7de374ac S com.android.phone
And checking the cmdline for that pid returns a good app name:
# cat /proc/1588/cmdline
com.android.phone

Call getPackageCodePath() in Java and pass jstring to your C++ app via native method

Using OpenCV Android porting

I want to use the OpenCV Android porting, that you can find HERE, to make some image transformations for an Augmented Reality application. I've found no problem configuring and building the library, I receive no error and I succed put it within my Android application throght JNI process: the library libopencv.so is in the correct directory "\libs\armeabi\" under my project's directory.
And now the problems:
1) First I want to understand what version of the original openCV library this porting derive from. Is important for me know if it derive from version 1.5, 2.0 or 2.1 because same functions are very different and others are absent.
2) Before starting with real time video manipulation, I'd try make some simple operations on a single image or saved video:
JNIEXPORT
jstring
JNICALL
Java_org_examples_testOpenCV_OpenCV_LoadImage(JNIEnv* env, jobject thiz)
{
IplImage* imgIn = cvLoadImage("/sdcard/testimage.jpg", -1);
if (!imgIn) return env->NewStringUTF("Error");
cvReleaseImage( &imgIn );
return env->NewStringUTF("Ok");
}
JNIEXPORT
jstring
JNICALL
Java_balmas_examples_testOpenCV_OpenCV_manageVideo(JNIEnv* env, jobject thiz)
{
CvCapture* capture = cvCaptureFromFile("/sdcard/video_galaxyspica_352x288_15fps.3gp");
if (!capture) return env->NewStringUTF("Error");
return env->NewStringUTF("Ok");
}
In both cases I receive "Error". There are no problems with files on the sdcard becouse I try to make this:
FILE* file = fopen("/sdcard/video_galaxyspica_352x288_15fps.3gp","w+");
//FILE* file = fopen("/sdcard/testimage.jpg","w+");
if (!file) return env->NewStringUTF("Error");
else {
fflush(file);
fclose(file);
return env->NewStringUTF("OK");
}
and I receive "OK".
I realize that there is some problem within highgui library but I don't understand what and wath I should make to avoid the problem.
Some suggestions!!!
Thank you everyone

guys- you may want to try this link, it ports the C++ 'modern' interface to opencv. The IplImage stuff is deprecated, but new versions leave wrappers if you need to support legacy code.
http://code.google.com/p/android-opencv/
There's a sample camera-calibration app, you click snap a few times and it will solve for the K matrix.
Note: you'll need the crystax ndk for STL classes, http://www.crystax.net/android/ndk-r4.php