2012-07-11 14 views
6

ho trovato un esempio chiamato nativeactivity nella cartella esempio FMOD, ma purtroppo uso del codice Java:Caricamento FMOD puramente da codice nativo

package org.fmod.nativeactivity; 

public class Example extends android.app.NativeActivity 
{ 
    static 
    { 
     System.loadLibrary("fmodex"); 
     System.loadLibrary("main"); 
    }  
} 

Android.mk assomiglia a questo:

LOCAL_PATH := $(call my-dir) 

# 
# FMOD Ex Shared Library 
# 
include $(CLEAR_VARS) 

LOCAL_MODULE   := fmodex 
LOCAL_SRC_FILES   := libfmodex.so 
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/inc 

include $(PREBUILT_SHARED_LIBRARY) 

# 
# Example Library 
# 
include $(CLEAR_VARS) 

LOCAL_MODULE   := main 
LOCAL_SRC_FILES  := main.c 
LOCAL_LDLIBS   := -llog -landroid 
LOCAL_SHARED_LIBRARIES := fmodex 
LOCAL_STATIC_LIBRARIES := android_native_app_glue 

include $(BUILD_SHARED_LIBRARY) 

$(call import-module,android/native_app_glue) 

Is è possibile fare a meno della parte java? Se sì, cosa dovrei cambiare?

risposta

6

Non so perché si vuole sbarazzarsi di queste poche righe di Java. Per quanto ne so, questo non ha alcun effetto sul resto della tua applicazione.

Il motivo per cui è necessario Java è che il caricatore di sistema Android non è in grado di trovare libfmodex.so, che è essenziale per risolvere i riferimenti nel tuo libghost.so. Pertanto, il caricamento di libghost.so non riesce. Java ti permette di precaricare la dipendenza prima che la tua libreria sia caricata.

Sfortunatamente, NativeActivity può caricare solo una libreria. A aprile 2012 è stato pubblicato un request per migliorare la situazione in futuro.

Attualmente, è possibile passare tutto il codice che funziona con fmod a collegamento dinamico, o costruire una terza libreria condivisa che caricherà fmod e quindi caricare il fantasma biblioteca. In questa situazione, il caricatore sarà in grado di risolvere i riferimenti in ghost perché fmod sarà già caricato.