androidapp怎么调用Java接口_[Android] 解析android framework下利用app_process来调用java写的命令及示例...

在android SDK的framework/base/cmds目录下了，有不少目录，这些目的最终都是build出一个bin文件，再存放到/system/bin目 录下，对于C/CPP写的命令，我们还是比较好理解的，都有一个main函数作为入口，但是在cmds目录下还有一些原生代码是java的，比如 input、settings，那么这种类型的命令是怎么实现的呢?

笔者研习了原生的命令实现，写了一个demo，抛砖引玉吧!暂时叫strong吧!我们都知道java写的文件最后都是编译成了class文

件，java类里面也有很多接口，在android平台上cmds目录下的各模块的java文件都实现了一个共同的方法，还是叫main()，真是情有独

钟啊!当然从技术角度看叫其他名字也是可以的。那我们就简单实现以下这个class吧!如下：

java代码

public final classstrongcmd {static final String TAG = "strong";staticString[] mArgs;intmNextArg;public static voidmain(String[] args) {

printUsage();

System.err.println("Wellcom strong test function!!");try{newstrongcmd().run();

}catch(Exception e) {

System.err.println("Unable to run settings command");

}

}public voidrun() {try{

System.err.println("Now strong run() again");

}catch(Exception e) {

System.err.println("Now strong run() Exception");

}

}private static voidprintUsage() {

System.err.println("usage: strong -a -b -h");

System.err.println("'a' is for add");

System.err.println("-h for help");

}

}

写好Android.mk，编译好这个文件，会生成strong.jar包，包含这个class。那么，又怎么跟命令挂钩呢?先看看Android.mk，如下：

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_SRC_FILES := $(call all-subdir-java-files)

LOCAL_MODULE :=strong

LOCAL_MODULE_TAGS :=optional

include $(BUILD_JAVA_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE :=strong

LOCAL_SRC_FILES :=pre_strong

LOCAL_MODULE_CLASS :=EXECUTABLES

LOCAL_MODULE_TAGS :=optional

include $(BUILD_PREBUILT)

上一部分是BUILD_JAVA_LIBRARY，关键在下面，利用的是BUILD_PREBUILT，添加一个预编译好的应用程序，我们叫pre_strong，它有可执行的权限，看看它的具体实现吧!

base=/system

export CLASSPATH=$base/framework/strong.jar

exec app_process $base/bin com.android.commands.strong.strongcmd "$@"

首先还是设置好这个java lib的路径，如何再调用app_process来执行，主要是把这个类名要给对，app_process其实也是个命令。在app_process里 面，还是一样利用JNI技术，在java ENV里面查找传给app_process的class，找到这个class后再去找main函数接口的field，然后再call这个main接口，这 样就call到java里面去了。

下面简要看看app_process的关键代码吧!

virtual void onVmCreated(JNIEnv*env) {if (mClassName ==NULL) {return; //Zygote. Nothing to do here.

}/** This is a little awkward because the JNI FindClass call uses the

* class loader associated with the native method we're executing in.

* If called in onStarted (from RuntimeInit.finishInit because we're

* launching "am", for example), FindClass would see that we're calling

* from a boot class' native method, and so wouldn't look for the class

* we're trying to look up in CLASSPATH. Unfortunately it needs to,

* because the "am" classes are not boot classes.

*

* The easiest fix is to call FindClass here, early on before we start

* executing boot class Java code and thereby deny ourselves access to

* non-boot classes.*/

char*slashClassName =toSlashClassName(mClassName);

mClass= env ->FindClass(slashClassName);if (mClass ==NULL) {

ALOGE("ERROR: could not find class '%s'\n", mClassName);

}

free(slashClassName);

mClass= reinterpret_cast(env ->NewGlobalRef(mClass));

}

virtualvoidonStarted() {

sp proc=ProcessState::self ();

ALOGV("App process: starting thread pool.\n");

proc->startThreadPool();

AndroidRuntime* ar =AndroidRuntime::getRuntime ();

ar->callMain(mClassName, mClass, mArgC, mArgV);

IPCThreadState::self ()->stopProcess();

}

className) {//Remainder of args get passed to startup class main()

runtime.mClassName =className;

runtime.mArgC= argc -i;

runtime.mArgV= argv +i;

runtime.start("com.android.internal.os.RuntimeInit",

application? "application" : "tool");

}

Android平台提供的app_process，还是相当不错的，比较实用，利用好app_process还是可以写成很多供我们自己开发、测试、定制一些特殊的程序，给开发带来了很大的便利。