2010-04-09 9 views

Respuesta

23

El equipo de Dalvik desea crear una biblioteca de generación de código de tiempo de ejecución de primera clase. Estamos rastreando la solicitud de función como Android bug 6322. Desafortunadamente, tenemos una lista muy larga de problemas de rendimiento y corrección, por lo que no podemos darte un cronograma para cuándo dedicaremos tiempo a este tema.

hay algunas alternativas, pero todos ellos tomará algo de trabajo:

  • ejecutar su aplicación en una JVM estándar y ejercer toda la generación de código de tiempo de ejecución de allí. Vuelque los archivos .class de la memoria a los archivos, y luego ejecute dx en esos archivos. Si eres bastante sofisticado, puedes integrar todo este trabajo en tu construcción.

  • Incluya la herramienta de código abierto dx como biblioteca de proyectos y ejecútela programáticamente desde su aplicación, posiblemente en el cargador de clases de la aplicación. Esto hinchará el binario de tu aplicación.

+1

Gracias por su respuesta. ¿Hay algo que me impida escribir mi propio generador de código en este momento? He escrito uno para .Net-> Flash y .Net ->. Net, y Dex es como un cruce entre los archivos Java .Class y Flash .ABC. Además, gracias por el enlace. Lo destaqué y agregué un comentario (solicitando que su API sea similar al DLR de .Net). –

+3

Definitivamente podría escribir su propio generador de código en este momento. ¡Si le das una licencia de Apache, aún mejor! –

+3

Actualización: eche un vistazo a dexmaker, que lo hace fácil: http://code.google.com/p/dexmaker/ –

5

¿hay alguna manera de cargar los archivos DEX /códigos de bytes en una aplicación en tiempo de ejecución ?

Mire DexFile y DexClassLoader.

+1

Anteriormente sobre este tema: http://stackoverflow.com/questions/1001944/android-remote-code-loading/2450049#2450049 – fadden

1

Si dentro de cualquier programa de C o C++, que desea cargar y poner en las clases de DEX, se puede ver cómo se inicia la máquina virtual Dalvik, dentro del Android Runtime - por ejemplo, marcos/base/CMDS/app_process/app_main.cpp:

status_t app_init(const char* className, int argc, const char* const argv[]) 
{ 
    LOGV("Entered app_init()!\n"); 

    AndroidRuntime* jr = AndroidRuntime::getRuntime(); 
    jr->callMain(className, argc, argv); 

    LOGV("Exiting app_init()!\n"); 
    return NO_ERROR; 
} 

como "JR" Android Runtime ya se ha iniciado, callMain() se llamará:

status_t AndroidRuntime::callMain(
    const char* className, int argc, const char* const argv[]) 
{ 
    JNIEnv* env; 
    jclass clazz; 
    jmethodID methodId; 

    LOGD("Calling main entry %s", className); 

    env = getJNIEnv(); 
    if (env == NULL) 
     return UNKNOWN_ERROR; 

    clazz = findClass(env, className); 
    if (clazz == NULL) { 
     LOGE("ERROR: could not find class '%s'\n", className); 
     return UNKNOWN_ERROR; 
    } 

    methodId = env->GetStaticMethodID(clazz, "main", "([Ljava/lang/String;)V"); 
    if (methodId == NULL) { 
     LOGE("ERROR: could not find method %s.main(String[])\n", className); 
     return UNKNOWN_ERROR; 
    } 
<...> 
    env->CallStaticVoidMethod(clazz, methodId, strArray); 
    return NO_ERROR; 
} 

De lo anterior, podemos ver cómo se cargan los códigos de las clases de DEX y CallStaticVoidMe thod() comenzará a interpretar los códigos DEX.

2

He usado ASM y BCEL para generar clases de Java y luego las he convertido a archivos Dex. Finalmente, he creado archivos jar para cargar dinámicamente en el dispositivo.

Se puede extraer de mi código :)

https://github.com/sciruela/android

Cuestiones relacionadas