Bytecode dalvik e architetture

[mm7]

Ehi bella gente

Quando per esempio nella app google now (http://forum.xda-developers.com/show....php?t=1747224) o flash player si fa la distinzione tra armv6 e armv7 perchè la si fa ? Cioè mi spiego, le app dovrebbero essere "compilate" nel cosidetto bytecode che poi viene eseguito dalla dalvik (che se non sbaglio è il file .dex all'interno dell' .apk ), ma non è un compilato codice macchina (quello prodotto da linguaggi come C per capirci, che deve essere compilato per un architettura) quindi non dovrebbe essere influenzato dalle architetture !!
Di conseguenza anche mettendo un app di un armv7 (io ho l'ace che ha una cpu armv6) dovrebbe girare ma non è cosi... perchè ??????

Qualcuno può chiarirmi le idee ?

[IlSocio]

Probabilmente perchè per alcune parti di codice è stato utilizzato il c++
Infatti, mentre il codice java viene compilato in bytecode, il codice c++ viene compilato in assembly... o addirittura, è anche possibile includere direttamente codice assembly.

[mm7]

Probabilmente perchè per alcune parti di codice è stato utilizzato il c++
Infatti, mentre il codice java viene compilato in bytecode, il codice c++ viene compilato in assembly... o addirittura, è anche possibile includere direttamente codice assembly.

Ok grazie mille, però questo vale anche per le app ordinarie o solo per alcune app (come quelle che ho citato sopra) ?

[IlSocio]

Vale per tutto... non c'è distinzione.
Se è stato utilizzato il c++ o l'assembly, allora l'app contiene codice che è già stato compilato per una determinata architettura.
(e nota che, generalmente, compilando per armv5, l'app potrà girare anche su armv7... non vale il reciproco)

[mm7]

Ok il discorso dell'assembly lo conosco volevo pero sapere nell'apk dove c'è il pezzo di script assembly e dove quello bytecode.. perchè dentro l'apk c'è solo il classes.dex (che è il bytecode !!)

[IlSocio]

Se è quello l'unico file che contiene, sarà embedded dentro al classes.dex ovvero, ad un certo punto, nel .dex ci sarà un blob contenente il codice binario, ed il compilatore jit, prenderà semplicemente quel codice binario e lo integrerà, cosi' com'è, con il resto del codice che ha appena compilato.

Come puoi notare dall'uso del condizionale, la mia è una supposizione... ed è l'unica plausibile che mi viene in mente al momento.

[mm7]

Ok, ma quando decompilo il .dex in smali (quindi mi decompila il bytecode e l'assebly in codice leggibile [Ma sempre con funzioni macchina o dalvik]), poi dopo durante la ricompilazione non dovrebbe chiedermi il target dei pezzi di codice c++ (oppure lo deduce da solo vedendo cha ha solo funzioni per una architettura?) ?

[IlSocio]

non ho mai decompilato nulla su android... ma considera che il codice c++ non esiste piu', quindi, quei pezzi di codice c++ in realtà sono pezzi di codice assembly... in smali non ho idea di come ti si presenti, ma in ogni caso, essendo codice assembly, non necessita di essere compilato... viene preso cosi' com'è.

Soprattutto, proprio in questi giorni, ho letto altrove che il codice c++ viene compilato e messo in \libs\ quindi non si trova dentro il file .dex pertanto, la mia supposizione iniziale, (che il .dex possa contenere codice assembly) non so se è corretta... perchè forse il dex non contiene mai codice assembly.

[mm7]

Allora ho sbagliato io a dire.. tutti lo chiamano decompilare-compilare da smali ("decompilato") a .dex ("compilato") invece (come dici tu anche) si tratta tradurre le routine assembly in un qualcosa che l'umano può leggere cioè non piu in zeri-uni ma con cose leggibili ... insomma hai capito XD In libs non dovrebbero esserci le librerie ?

[IlSocio]

si in \libs\ si sono le librerie, e da quanto ho letto, il codice c++ compilato da come risultato una shared-library che viene piazzata dentro \libs\ e verrà poi caricata da java a runtime, tramite la chiamata alla loadlibrary()