Sviluppare con LibVLC per Android su Windows

Question

Ho faticato persino a ottenere un demo application in esecuzione con Android-LibVLC.

Posso trovare solo documentation per linux e non riesco a far funzionare l'applicazione sul mio dispositivo (sebbene compili).

Quando lancio l'applicazione si registra:

12-16 15:58:19.572 9121-9121/? E/VLC/LibVLC﹕ Can't load vlcjni library: java.lang.UnsatisfiedLinkError: Couldn't load vlcjni from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.compdigitec.libvlcandroidsample-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.compdigitec.libvlcandroidsample-1, /vendor/lib, /system/lib]]]: findLibrary returned null 
12-16 15:58:19.667 9135-9135/com.compdigitec.libvlcandroidsample E/VLC/LibVLC﹕ Can't load vlcjni library: java.lang.UnsatisfiedLinkError: Couldn't load vlcjni from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.compdigitec.libvlcandroidsample-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.compdigitec.libvlcandroidsample-1, /vendor/lib, /system/lib]]]: findLibrary returned null 

ho compilato l'APK progetto con le classi di directory org.videolan.libvlc come parte della radice di origine e con la directory JNI nello stesso modulo e fallito, ho anche incluso l'intero modulo VLC come modulo libreria separato e ne ho fatto una dipendenza, anche questo è fallito.

Qualcuno ha un metodo collaudato per configurare/creare un progetto Android con LibVLC, da Windows? O un link alle istruzioni/documentazione? (Non sono stato in grado di trovare nulla).

L'obiettivo è di sostituire le mie classi dipendenti di Android MediaPlayer in una libreria/implementazione che supporti più tipi di file/codec.

Answer 1

Durante la costruzione in Windows verrà visualizzato il messaggio di avviso ""Android.mk:iomx-hc: non-system libraries in linker flags: -lgcc -lstagefright - lmedia -lbinder"" per più file. E avvisa anche "Android NDK:This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES" Quindi, anche se si ottiene l'output di build, non avrà i file richiesti. E quindi stai ricevendo l'errore durante l'esecuzione dell'applicazione.

Ora se guardi su Android.mk troverete

include $(CLEAR_VARS) 

LOCAL_MODULE  := libiomx-gingerbread 
LOCAL_SRC_FILES := ../$(VLC_SRC_DIR)/modules/codec/omxil/iomx.cpp 
LOCAL_C_INCLUDES := $(VLC_SRC_DIR)/modules/codec/omxil $(ANDROID_SYS_HEADERS_GINGERBREAD)/frameworks/base/include $(ANDROID_SYS_HEADERS_GINGERBREAD)/system/core/include 
LOCAL_CFLAGS  := -Wno-psabi 
LOCAL_LDLIBS  := -L$(ANDROID_LIBS) -lgcc -lstagefright -lmedia -lutils -lbinder 

include $(BUILD_SHARED_LIBRARY) 

ho scaricato la fonte di VLC da here e dopo l'estrazione della fonte sono riuscito a trovare "extracted_path" \ vlc-2.1.4 \ moduli \ codec \ omxil \ iomx.cpp. Quindi, se è possibile modificare il percorso di inclusione per VLC_SRC_DIR nella directory in cui è stata estratta l'origine di vlc sulla macchina WINDOWS, penso che dovresti essere in grado di compilarlo. Se non si utilizza una macchina virtuale che esegue linux per compilare il progetto. Richiede anche le librerie di archivio (.a) che non si troveranno nell'origine di vlc. Quindi dovrai prima creare la sorgente di vlc e quindi includere tutte le cose nel progetto. Penso che Linux nella macchina virtuale sia la soluzione migliore.

Answer 2

Progetto interessante lì. L'errore di collegamento non soddisfatto di solito significa che la libreria nativa (probabilmente un oggetto condiviso o qualcosa) non è stata trovata nella libreria . Hai eseguito "ndk-build" da Android NDK all'interno della cartella "jni" del progetto?

Hai anche detto che hai aggiunto le sorgenti Java dal Progetto libreria a Java fonti. Questo probabilmente non è il modo giusto per farlo. Considera questo:

1. Sotto queste classi Java c'è il codice JNI, che è scritto in C/C++. Quello che vuoi ottenere è che questo cosiddetto codice nativo è compilato in un oggetto libreria che può essere caricato/eseguito su Android. A tal fine, in genere uno scrive un file Android.mk, che si trova nella cartella "JNI" ed esegue "ndk-build" su creando tali sorgenti.
2. Ci deve essere un po 'di codice wrapper/binding in Java, che chiama quelle funzioni native C/C++. L'associazione delle chiamate Java alle funzioni C viene eseguita dai nomi di pacchetti e classi. Pertanto, se si sposta in codice, è probabile che si possano distruggere tali associazioni. A meno che tu non sia a conoscenza di ciò che stai facendo, ti consiglio di lasciare come un progetto di libreria Android così com'è e di includere semplicemente il progetto nel tuo progetto di applicazione tramite Proprietà -> Android da Eclipse.

Inoltre, è possibile controllare questo progetto. https://github.com/fscz/FFmpeg-Android