Qualche esperienza con Android NDK?

Question

Sono particolarmente interessato a quanto è portatile tra vari telefoni. Abbiamo un'applicazione con un codice pesante di calcolo che vorremmo condividere tra Android e iPhone. Se potessimo scriverlo in C, avremmo un unico code-base, ma se l'NDK supporta solo un sottoinsieme dei processori che i produttori di telefoni stanno creando, o se dobbiamo ricompilare per ogni processore, non è una soluzione praticabile .

Grazie per qualsiasi esperienza con esso.

Answer 1

A proposito di se tutti gli Android (versione 1.5+) telefoni supporteranno l'uscita della corrente NDK:

Tutto quello che posso dire è non c'è niente nella documentazione di suggerire altrimenti (se non forse se si legge un implicazione in "questa release supporta il set di istruzioni ARMv5TE"), e seguo le notizie di Android abbastanza da vicino e non ho sentito parlare di telefoni Android rilasciati usando un'architettura non ARM (anche se some people hacked together a build for EeePC). Guardando lo Android source, ci sono tracce solo di un'altra piattaforma, x86. Per quanto riguarda i piani futuri di Google e il OHA? Dovresti chiederlo a loro. Recentemente hanno annunciato alcuni developer days, ma probabilmente tutti gli spot sono spariti ora (il primo è oggi). Mi sono registrato abbastanza presto per il giorno di Londra (17 °), quindi se entrerò cercherò di ottenere una risposta (sono curioso di sapere anche in modo definitivo).

Answer 2

Io non sono molto familiare con lo sviluppo di Iphone, ma se guardi lo android ndk page, nella sezione degli strumenti di sviluppo, elenca le intestazioni garantite disponibili nella piattaforma, quindi se l'iphone supporta queste funzioni, oppure puoi creare interfacce tra il tuo codice e le librerie native su entrambe le piattaforme di quante non capisco perché non funzionerebbe.

Answer 3

L'NDK è fondamentalmente un'implementazione di Java Native Interface per Android. Ti dà GCC 4.2.1 (il set completo di strumenti per quanto posso dire) con l'obiettivo arm-eabi. Se il codice risultante sarebbe eseguito su un iPhone o altri dispositivi che non conosco; Non ho mai programmato per l'iPhone. Ecco cosa file ha da dire su qualcosa che ho costruito con l'NDK in modo forse si può confrontare:

libpuzzles.so: ELF a 32 bit LSB oggetto condiviso, ARM, versione 1 (SYSV), collegato dinamicamente, non spogliato

(. strip è incluso; io non ho eseguito qui) Ecco gcc -v o g++ -v (sono identiche):

Utilizzando specifiche incorporate.

cliente: il braccio eabi

Configurato 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 = arm-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/piattaforme/bigné/arch-braccio --program-transform-name = s, ^, braccio-eabi-,

modello Discussione: single

gcc version 4.2.1

Assumendo il codice verrà eseguito, gestendo questo a livello di API è un problema separato e interessante. Android ti consente di chiamare il codice nativo solo tramite l'API JNI. Non ho familiarità con l'approccio dell'iPhone, ma so che non è Java, quindi suppongo che sia più simile al collegamento dinamico standard o allo dlopen()? Quello che voglio dire è che dovresti o fare le tue funzioni JNI (ad esempio, Java_com_example_Foo_YourMethod(JNI_Env*, jobject, ...) far fronte all'essere chiamato da qualcosa che non è una JVM (avere il tuo codice iPhone falso un JNI_Env per esempio?) O, molto meno orribilmente, iniziare fornendo un'API nativa adatta per iPhone e quindi include un wrapper JNI, che le piattaforme non-JNI possono tranquillamente ignorare, che raccolgo è un approccio comune per questo genere di cose .Spero che aiuti.

Answer 4

Ho avuto una buona esperienza di scrittura di applicazioni JNI/C cross-bread con elaborazione framebuffer in NDK e rendering in JAVA.

Pitty, è una soluzione solo Android