Continue my previous question, I succeeded to execute a process from an Android application. Now I can see two process like I wanted, they both up and running. Now I need to execute an Android application from the native C code.
Found similar questions (1, 2), but the following solutions did NOT work for me.
1. execl("/system/bin/sh", "sh", "-c", "am start -a android.intent.action.MAIN -n com.android.browser/.BrowserActivity", (char *)NULL);
2. execl("/system/bin/am", "start", "-a", "android.intent.action.MAIN",
"-n", "com.android.settings/.Settings", (char *)NULL);
None of the lines above didn't executed anything.
Even executing execl command with fork as follows did NOT help.
if (!fork()) {
execl...
}
Can you please give me some kind of a clue?
Thanks.
UPDATE: I've manage to print the stdout to the Android log, I'm getting errno
"Exec format error"
message from the execl method. Anybody have an idea how I can resolve this?
Maybe you can write this from the Android/ Java / VM scope and call it from native code using NDK & JNI (Java Native Interface) ?
Example :
From your app:
class MyActivity extends Activity {
public native int nativeMethodName();
public void launchSomeAppMethod() {
// launch some app
Intent LaunchIntent = getPackageManager().getLaunchIntentForPackage("com.package.someapp");
startActivity(LaunchIntent);
}
}
Native :
jint Java_com_yourpackage_appname_MyActivity_nativeMethodName(JNIEnv* env, jobject thiz) {
//....
// do your native work here
// ...
// call your obj instance that can launch another app
jclass cls = (*env)->GetObjectClass(env, thiz);
jmethodID method = (*env)->GetMethodID(env, cls, "launchSomeAppMethod", "()V");
(*env)->CallVoidMethod(env, thiz, method);
}
Hope it helps dude.
The error printed smells like permission problem.
Are you trying to run the application from an SD card? SD Cards by default are mounted without execute permission, you need to remount it.
Related
I am trying to use Androids NDKMediaExtractor in C++ code like this:
const char *storageFile = "/storage/emulated/0/mytestfile.mp3";
AMediaExtractor *extractor = AMediaExtractor_new();
media_status_t amresult = AMediaExtractor_setDataSource(extractor, storageFile);
This fails with the error message E/NdkMediaExtractor: setDataSource(path) must be called from Java thread.
Searching online did not bring me any hints how I can solve this, what I did find though was the source code, the responsible part looks like this:
EXPORT
media_status_t AMediaExtractor_setDataSource(AMediaExtractor *mData, const char *location) {
ALOGV("setDataSource(%s)", location);
// TODO: add header support
JNIEnv *env = AndroidRuntime::getJNIEnv();
jobject service = NULL;
if (env == NULL) {
ALOGE("setDataSource(path) must be called from Java thread");
env->ExceptionClear();
return AMEDIA_ERROR_UNSUPPORTED;
}
// rest of method omitted for brevity
}
I hand in a JNIEnv when I call my native methods from Java/Kotlin, but NDKMediaExtractordoes not seem to know about it. How can I solve this?
you cant just pass JNIenv* between threads you should get it(every time in a native thread) by calling AttachCurrentThread(before calling any jni methods)in the current native thread so that it can be managed as java Thread.Once you do this it should be working.
i.e
JNIEnv* env;
virtualMachine->AttachCurrentThread(&env,NULL);
you should obtain env by calling AttachCurrentThread and now your native thread is managed as Java thread after attaching.So should resolve ur error.
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
I'm working in Android, writing some JNI code, and I'm looking for a way to query the Mobile Equipment Identifier (MEID) from the device.
http://en.wikipedia.org/wiki/Mobile_equipment_identifier
I'm trying to write C or C++ code that can run by itself on an Android device, so I don't think I can use Java (i.e., get MEID from TelephonyManager).
A search of StackOverflow finds: Is there an android shell or adb command that I could use to get a device's IMEI/MEID?
Okay great, dumpsys iphonesubinfo can get the info I need. And it works!
I couldn't find the source for dumpsys except as part of the source for Android. So I downloaded that... my hard disk filled up before the download finished, but I did get the source code to dumpsys. It is a surprisingly short C++ file. All it does is query Android's IBinder interface.
So, my questions:
0) Is there any way I can write a query against IBinder using just the stuff in the NDK? The include files used by dumpsys.cpp are not in the NDK, and grep in the NDK directory didn't find IBinder in any include files or code samples, so my guess is "no" (but I would like to be wrong).
1) Is there any other good way to get the MEID?
I'm seriously thinking I should just use system("dumpsys iphonesubinfo > /tmp/myprogname_dumpsys.tmp" and then open the resulting file and parse it. That should work, but I would hardly call it elegant... and I'm not sure if dumpsys is available on every Android device or not.
EDIT: The idea of using system() to run dumpsys will not work, because dumpsys needs android.permission.DUMP and Android no longer allows non-system apps to have that permission.
Dumpsys permission denial in java
I believe Dalvik implements all the same JNI interfaces that the JVM does, so while it's a bit fiddly, it's perfectly possible to make calls from native code through JNI to arbitrary Java classes and methods.
/* assuming you already have */
JNIEnv *env;
jobject context;
/* then call (with error-checking) */
jclass cls = (*env)->FindClass(env, "android/context/Context");
jmethodId mid = (*env)->GetMethodID(env, context_cls, "getSystemService",
"(Ljava/lang/String;)Ljava/lang/Object;");
jfieldID fid = (*env)->GetStaticFieldID(env, cls, "TELEPHONY_SERVICE",
"Ljava/lang/String;");
jstring str = (*env)->GetStaticObjectField(env, cls, fid);
jobject telephony = (*env)->CallObjectMethod(env, context, mid, str);
cls = (*env)->FindClass(env, "android/telephony/TelephonyManager");
mid =(*env)->GetMethodID(env, cls, "getDeviceId", "()Ljava/lang/String;");
str = (*env)->CallObjectMethod(env, telephony, mid);
jsize len = (*env)->GetStringUTFLength(env, str);
char* deviceId = calloc(len + 1, 1);
(*env)->GetStringUTFRegion(env, str, 0, len, deviceId);
(*env)->DeleteLocalRef(env, str);
/* to get a string in deviceId */
Retrieve the MEID on the Java side, then pass into your JNI function as a jstring parameter. It'll be cleaner than calling back to Java from C.
As to how to retrieve that, see Abhilasha's answer.
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'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