Tengo una pregunta sobre las limitaciones de lo que puede hacer en código nativo en la plataforma Android.
Básicamente, he desarrollado una biblioteca en código C nativo que usa conectores UDP para SIP/RTP y usa OpenAL para grabación/reproducción de audio, básicamente toda la aplicación. La idea es tener tanto como sea posible en código C nativo en lugar de código Java. Quiero hacer esto porque también lo voy a usar en otras plataformas.
Entonces, mi pregunta es simple: ¿es posible usar Java para la GUI y luego todo el procesamiento en código nativo? ¿Qué sucederá cuando mi código nativo intente crear un socket, vincularlo, grabar audio, reproducirlo, etc.? Dado que está en código nativo, ¿necesito configurar permisos para él (como el acceso de la aplicación al micrófono y demás) o lo haré? ¿simplemente omite estas cosas desde su código nativo? ¿Puede el código nativo hacer casi todo lo que quiera en Android como en las PC?
Lo siento si no está claro; solo dilo y tratare de mejorarlo
Gracias
EboMike
Puede hacer prácticamente cualquier cosa que desee en código nativo, pero lo único realmente compatible a nivel de sistema operativo es OpenGL, OpenSL y algunas bibliotecas de procesamiento de números (compresión, matemática, etc.).
Sin embargo, en cualquier momento puede usar el JNI para llamar a un método Java, por lo que podría usar la API estándar de Android para redes (clases como Socket
, etc). Obviamente, dado que la llamada se realiza a través de la API de Java, se aplican todos los permisos normales de Android (como android.permission.INTERNET
).
EDITAR: como se explica en los comentarios, las bibliotecas estándar que forman parte del NDK tienen soporte para sockets.
-
¿Podría dar más detalles sobre lo que quiere decir con ‘apoyado’? Por ejemplo, no puedo encontrar sockets en la lista de bibliotecas NDK. ¿Todavía puedo usarlos? ¿Qué archivos de encabezado y otras cosas usa? ¿No hay sys/sockets?
– KaiserJohaan
12 de julio de 2011 a las 1:01
-
No te gustará esto, pero… tendrás que pasar por Java, es decir, usas FindClass en
Socket
luego obtenga el método para el constructor, el método pararead
el método parawrite
almacenas el socket como unjobject
en tu código, y usasCallVoidEnvMethod
o algo similar. Suena absolutamente horrible, pero puede escribir una capa delgada que se traduce entre C y Java y terminar con solo un puñado de esas funciones de traducción.– EboMike
12 de julio de 2011 a las 1:05
-
Por cierto, como señaló Kazuki, PUEDE haber soporte completo para la API de socket, pero personalmente siempre he usado esta indirección a través de Java.
– EboMike
12 de julio de 2011 a las 1:06
-
@EboMike está equivocado en el reclamo de enchufes que requieren jni. Junto con la mayoría de los unixismos estándar, se pueden hacer desde código nativo. Es principalmente UI y otras cosas de servicio de Android donde se requiere jni.
– Chris Stratton
12 de julio de 2011 a las 3:42
-
Uso las librerías curl c en un daemon que escribí (código nativo puro) para Android, sin problema. Cuando incorporé el código en una aplicación Java para Android, usando llamadas JNI, continuó funcionando bien, sin embargo, necesita el permiso de INTERNET en AndroidManifest.xml o la llamada fallará, independientemente de si la aplicación está en /data/app o / sistema/aplicación.
– Colín
5 abr 2015 a las 23:47
jglouie
Todavía necesita que su aplicación tenga permisos. Por ejemplo, sus sockets nativos no funcionarán sin android.permission.INTERNET
en el manifiesto.
<manifest xlmns:android...>
...
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
</manifest>
Otra opción es crear el socket en la capa de Java y pasarlo. Aquí hay un ejemplo de interacción con el enchufe en tierra nativa, vea el método org_..._OpenSSLSocketImpl_connect()
:
La API nativa de Android es un buen artículo para NDK.
¿Es posible usar Java para la GUI y luego todo el procesamiento en código nativo?
Sí. Y debe establecer los permisos apropiados para su AndroidManifest.
grabar audio, reproducirlo,
Debe usar la API de OpenSL ES para grabar y reproducir audio en el lado nativo. Significa que su aplicación debe ser para Android 2.3 o posterior.
O bien, NVIDIA proporciona un marco que nos permite desarrollar usando C ++ para eventos, sensores, audio, etc. de Android, incluso para Android 2.2 o anterior.
Recursos de Tegra: documentación y aplicaciones de muestra de Android SDK y NDK
-
¿OpenAL no es compatible con Android? Creo que leí en alguna parte al respecto, o que simplemente puede incluir la biblioteca compartida OpenAL en el apk.
– KaiserJohaan
12 de julio de 2011 a las 1:34
-
Implementación del software OpenAL para Android. Es una implementación de software, por lo que OpenSL ES es más eficiente que esta implementación de OpenAL.
– Kazuki Sakamoto
12 de julio de 2011 a las 1:43