El NDK es básicamente una implementación del Java Native Interface para Android. Te da GCC 4.2.1 (el conjunto completo de herramientas por lo que puedo ver) con el objetivo arm-eabi. Si el código resultante se ejecutará en un iPhone u otros dispositivos, no sé; Nunca he codificado para el iPhone. Esto es lo que file tiene que decir acerca de algo que construí con el NDK así que quizás se puede comparar:
libpuzzles.so: ELF 32-bits LSB objeto compartido, ARM, versión 1 (SYSV), vinculado dinámicamente, no se despojado
(. strip está incluido; yo no he corrido aquí) aquí es gcc -v o g++ -v (son idénticos):
El uso de especificaciones técnicas incorporadas.
Target: brazo-EABI
Configurado con: /opt/digit/android/git/android-ndk/out/arm-eabi-4.2.1/toolchain/src/gcc-4.2.1/configure --prefix =/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 --target = brazo-eabi --host = x86 _ 64-unknown-linux -gnu --build = x86 _ 64-unknown-linux-gnu --enable-languages = c, C++ --disable-libssp --enable-threads --disable-nls --disable-libmudflap --disable-libgomp - -disable-libstdc __- v3 --disable-sjlj-exceptions --disable-shared --with-float = soft --with-fpu = vfp --with-arch = armv5te --enable-target-optspace --with- abi = aapcs --disable-nls --prefix =/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 --with-sysroot =/opt/digit/android/git/android-ndk/bu ild/plataformas/magdalena/arch-brazo --program-transformar-name = s, ^, brazo-eabi-,
modelo de rosca: sola
versión gcc 4.2.1
Suponiendo el código se ejecutará, administrar esto en el nivel de la API es un problema separado e interesante. Android solo te permitirá llamar al código nativo a través de la API de JNI. No estoy familiarizado con el enfoque de iPhone, pero sé que no es Java, así que supongo que es más parecido a la vinculación dinámica estándar o dlopen()? Lo que quiero decir es que tendrías que hacer que tus funciones JNI (p. Ej., Java_com_example_Foo_YourMethod(JNI_Env*, jobject, ...)) reciban un llamado de algo que no es una JVM (¿el código de tu iPhone falsifica un JNI_Env por ejemplo?) O, mucho menos horriblemente, comenzar proporcionando una API nativa adecuada para iPhone y luego incluye un contenedor JNI, que las plataformas que no son JNI pueden ignorar de forma segura, lo que supongo que es un enfoque común para este tipo de cosas. Espero que ayude.
Para aclarar, no me preocupa el lado del iPhone de la ecuación. Sé que tendré que compilarlo por separado para el iPhone (usa bibliotecas estáticas, no dinámicas). Me preocupa que si creo un .so para Android, solo será compatible con ese subconjunto de teléfonos Android que son compatibles con el brazo-eabi. Tal vez estoy mostrando mi ignorancia de hardware aquí, pero si todos los teléfonos Android tienen que cumplir con ese estándar, entonces no hay problema. – john146
> Tenemos una aplicación con algunos códigos pesados de cómputo que nos gustaría compartir entre Android y iPhone. iPhone (a partir de iOS 4.2) no admite objetos compartidos creados por el usuario –