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.
Related
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.
Our Android software uses a virtual file system (VFS) for SQLite, which has been working correctly. Once we began using it with Android 6 (Marshmallow) all sorts of weird errors started to occur with large negative offsets being passed to ftruncate(), stack overflows, data corruptions, etc. Using readelf (among other tools), we eventually traced the problem to a change in the imports used by libsqlite.so: Lollipop and earlier import ftruncate and mmap, the newest libraries import ftruncate64 and mmap64. We "solved" the problem by changing which functions we use depending on the API version (Marshmallow is version 23):
/*
* Empirical testing of Tab S2 running Marshmallow revealed the SQLite
* unix_syscall table uses "ftruncate" and "mmap" as connection points,
* but the actual functions linked against are the *64 versions. This
* leads to stack corruption and all sorts of nasty errors as a result.
*/
if (getApiVersion() >= 23) // for Marshmallow
{ setUnixSystemCall(NULL, "ftruncate", our_ftruncate64);
setUnixSystemCall(NULL, "mmap", our_mmap64);
}
else // for Lollipop & older
{ setUnixSystemCall(NULL, "ftruncate", our_ftruncate);
setUnixSystemCall(NULL, "mmap", our_mmap);
}
Looking at the source code both from http://www.sqlite.org/2015/sqlite-amalgamation-3081002.zip and https://github.com/android/platform_external_sqlite/blob/master/dist/sqlite3.c all that the C source calls is ftruncate and mmap which makes our methodology "questionable" at best.
How does libsqlite.so import and use ftruncate64 and mmap64 where the source code only calls ftruncate and mmap? Are we not looking at the correct source code repository? Is there something going on at a link step? Did Marshmallow remove support for the non-64 bit versions of these functions?
It turns out the headers in the NDK don't exactly match the corresponding headers that the OS is ​built with!
Bionic: https://android.googlesource.com/platform/bionic.git/+/marshmallow-release/libc/include
Here's the way to BUILD the NDK: https://android.googlesource.com/platform/ndk/+/marshmallow-release
In particular,
https://android.googlesource.com/platform/bionic.git/+/marshmallow-release/libc/include/unistd.h
#if defined(__USE_FILE_OFFSET64)
extern int truncate(const char *, off_t) __RENAME(truncate64);
extern off_t lseek(int, off_t, int) __RENAME(lseek64);
extern ssize_t pread(int, void *, size_t, off_t) __RENAME(pread64);
extern ssize_t pwrite(int, const void *, size_t, off_t) __RENAME(pwrite64);
extern int ftruncate(int, off_t) __RENAME(ftruncate64);
https://android.googlesource.com/platform/bionic.git/+/marshmallow-release/libc/include/sys/mman.h has similar macros for mmap - the __RENAME() in the system headers means that any code built using the system headers (e.g., libc.so) will only export ftruncate64, not ftruncate, and when an app that calls ftruncate is linked against libc.so, it instead imports ftruncate64 rather than the call the source code was written with.
We didn't dive into the __RENAME() macro to investigate how this magic happens - the reality of trying to get a product out the door prohibits how deep we can go down the rabbit hole. If anybody wants to investigate this further, however, this is where you start.
I am trying to load a libsvm model on an android phone. The model is about 3MB, but it takes about 20s to load this model file which is not acceptable for a small App. I am using the libsvm official Java API to load it from my internal storage.
PS: I am trying to use libsvm c++ API to load this model via JNI too. but I meet the following problem:
JNIEXPORT void JNICALL Java_ca_uwo_csd_Threads_FoodRecgNativeLib_loadsvm
(JNIEnv *env, jclass cls, jstring path)
{
const char* path_char = env->GetStringUTFChars(path,0);//path is correct!
LOGI(TAG,"Loading start");
svm_model* model = svm_load_model(path_char); // fatal signal 11 here!!!
LOGI(TAG,"Loading OK");
}
If I comment the load model line, everything goes well. Can anyone help?
I solved it myself. Calling C++ loading function svm_load_model() via JNI is much faster than Java version(444ms in my case). The fatal signal 11 error happens at
char *old_locale = strdup(setlocale(LC_ALL, NULL));
setlocale(LC_ALL, "C");
and any other places that call the parameter and function in svm.cpp file (like free the points to it). So comment these and loading file will work.
Can anyone explain why this happens?
I try to use the pocketsphinx package for my app and need to rename the demo package name to something usefull (eg com.myname.foo)
I spent hours on figuring out, but I simply can't get it to work.
The problem is, that the project runs fine if I leave the package name and works without any problems (apart from random crashes), but when I rename it, i get the error
FATAL EXCEPTION: main
java.lang.UnsatisfiedLinkError: new_Config__SWIG_0
I already tried modifying the Swig command, but it didn't work either.
Any ideas?
I only changed the Manifest's package name declariation and the package folder of the normal Activity.
You need to change on the c/c++ side there are two posible ways depending on how your JNI is implemented.
A. The function name contains the full classpath
JNIEXPORT jlong JNICALL Java_"package with underscore instead of .""class""method"(JNIEnv *env, jclass class,...
e.g.
JNIEXPORT jlong JNICALL Java_com_android_mms_transaction_NativeSms_send(JNIEnv *env, jclass class,...
match method send in class NativeSms in package com.android.mms.transaction
B. There is a string supplied back to dalvik/javaVM with the classpath. Look for someting like this:
static int registerMethods(JNIEnv* env) {
static const char* const kClassName =
"com/example/android/platform_library/PlatformLibrary";
jclass clazz;
/* look up the class */
clazz = env->FindClass(kClassName);
if (clazz == NULL) {
LOGE("Can't find class %s\n", kClassName);
return -1;
}
/* register all the methods */
if (env->RegisterNatives(clazz, gMethods,
sizeof(gMethods) / sizeof(gMethods[0])) != JNI_OK)
{
LOGE("Failed registering methods for %s\n", kClassName);
return -1;
}
...
Edit 2011-12-07 Clarified first example
Sooo, I found the problem; I spend 20 ****ing hours just to find out, that I actually forgot to add
static {
System.loadLibrary("pocketsphinx_jni");
}
to the Activity class. I can't believe I didn't see that, but thanks for all the answers! +1 for everyone helping me :]
If you have link command issue it's most likely you forgot to change the SWIG launch properties. The file is
.externalToolBuilders/SWIG.launch
Those properties have several places to mention edu.cmu.sphinx package.
If you changed something it's recommended to describe the changes more precisely. Most likely you just forgot some small thing. For example you can pack whole changed code into archive and upload it somewhere.
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