reference to : http://bbs.9ria.com/thread-253058-1-1.html
在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 class strongcmd { static final String TAG = "strong"; static String[] mArgs; int mNextArg; public static void main(String[] args) { printUsage(); System.err.println("Wellcom strong test function!!"); try { new strongcmd().run(); } catch (Exception e) { System.err.println("Unable to run settings command"); } } public void run() { try { System.err.println("Now strong run() again"); } catch (Exception e) { System.err.println("Now strong run() Exception"); } } private static void printUsage() { 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)); } virtual void onStarted() { 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還是可以寫成很多供我們自己開發、測試、定制一些特殊的程序,給開發帶來了很大的便利。
