Libavcodec.so: tiene relocalizaciones de texto

Hoy, recibí los mismos mensajes de error al probar mi aplicación con Android 6.0 en un Nexus 6 (Motorola). Solucioné mi problema comprobando la targetSDKVersion en el archivo de manifiesto. Usar "22" y no "23" como targetSDKVersion lo resolvió. (Vea abajo)

 <uses-sdk android:minSdkVersion="15" android:targetSdkVersion="22" /> 

También revisé los archivos build.gradle para la versión de compilación y targetSDKversion:

 compileSdkVersion 22 buildToolsVersion '22.0.1' defaultConfig { minSdkVersion 15 targetSdkVersion 22 } 

Espero que esto te ayudará. Sin embargo, esto es sólo una solución a corto plazo por ahora, espero que recibamos algunos comentarios de metaio sin embargo.

Saludos, christin

OK Tengo esto trabajando aquí incluso con set de targetSDK 23.

Para mí y mi rama los cinco archivos que requirieron parches fueron

 libavcodec\arm\fft_fixed_neon.S libavcodec\arm\fft_neon.S libavcodec\arm\fft_vfp.S libavcodec\arm\mlpdsp_armv5te.S libutil\arm\asm.S 

Tomé las últimas de https://github.com/FFmpeg/FFmpeg

También necesitará HAVE_SECTION_DATA_REL_RO declarado en algún lugar de su compilación para la macro en asm.S para usar la opción de reubicaciones dinámicas.

Las versiones anteriores de Android advierten si se le pide que cargue una biblioteca compartida con reubicaciones de texto:

"Libfoo.so tiene reubicaciones de texto, esto está desperdiciando memoria y previene el endurecimiento de seguridad.

A pesar de esto, el sistema operativo cargará la biblioteca de todos modos. Marshmallow rechaza la biblioteca si la versión de SDK de destino de la aplicación es> = 23. El sistema ya no registra esto porque asume que su aplicación registrará el dlopen (3) falla en sí, e incluirá el texto de dlerror (3) que explica el problema. Desafortunadamente, muchas aplicaciones parecen capturar y ocultar el UnsatisfiedLinkError throw by System.loadLibrary en este caso, a menudo no deja ninguna pista de que la biblioteca no pudo cargar hasta que intenta invocar uno de sus métodos nativos y el VM se queja de que no está presente.

Puede utilizar la herramienta de exploración de línea de comandos para comprobar si hay reubicaciones de texto. Puede encontrar consejos sobre el tema en Internet; Por ejemplo https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide es una guía útil.

Usted puede comprobar si su lbirary compartido tiene reubicaciones de texto haciendo esto:

 readelf -a path/to/yourlib.so | grep TEXTREL 

Si tiene reubicaciones de texto, se mostrará algo como esto:

 0x00000016 (TEXTREL) 0x0 

Si este es el caso, puede volver a compilar su biblioteca compartida con la última versión de NDK disponible:

 ndk-build -B -j 8 

Y si lo vuelves a comprobar, el comando grep no devolverá nada.

Después de mucho tiempo luchando y tratando de compilar FFmpeg de diferentes maneras, encontré la solución. Asegúrese de compilar FFmpeg con el indicador –disable-asm. Esto asegurará que FFmpeg no tendrá reubicaciones de texto y no se bloqueará al compilar contra Android M (SDK 23)

Para asegurarse de que funcionó, puede utilizar readelf como se mencionó anteriormente.

Aclamaciones

Recibí comentarios del equipo SDK de metaio. Dicen que este problema no puede ser resuelto fácilmente por metaio, ya que está relacionado con la biblioteca FFMpeg. Tendríamos que esperar que una actualización de FFMpeg solucionara el problema. Supongo que tenemos que esperar para una actualización y para intercambiar los archivos de la biblioteca en la aplicación.

Todavía no he buscado un foro de contacto para desarrolladores de FFMpeg para hacer consultas o para notificar un error. ¿Conoce uno por accidente?

Mejor regrads, christin