Alessandro Del Rosso

Android: dopo l'SDK, l'NDK

Il nuovo Native Development Kit per Android permette agli sviluppatori di bypassare la macchina virtuale del sistema operativo e di scrivere i propri programmi in codice nativo, spremendo ogni goccia di potenza della CPU

Roma - Da oggi chi sviluppa applicazioni per Android ha la possibilità di uscire dalla "gabbia dorata" della macchina virtuale Dalvik, all'interno della quale girano tutte le odierne applicazioni scritte per il giovane OS di Google, e accedere direttamente al codice macchina sottostante (l'ARMv5TE). A renderlo possibile è l'Android 1.5 Native Development Kit (NDK), che si va ad affiancare all'SDK preesistente.

logoL'NDK permette agli sviluppatori di scrivere porzioni di un'applicazione utilizzando i linguaggi nativi di Android, C e C++, e le librerie libc (C library), libm (math library), libz (ZLib compression library) e liblog (utilizzata per inviare messaggi logcat al kernel).

Il principale vantaggio nell'utilizzare codice nativo è dato dalla possibilità di bypassare tutti i controlli e le mediazioni della virtual machine di Android, sfruttando più a fondo la potenza della CPU. Ciò serve soprattutto quando si ha necessità di scrivere applicazioni che facciano un uso intensivo della CPU ma un moderato uso della RAM, e magari si voglia riutilizzare codice C/C++ già esistente.
Come si spiega in questo post dell'Android Developers Blog, l'uso dell'NDK va ben ponderato: tagliare fuori la Dalvik virtual machine, si avvisa nell'articolo, significa "che le vostre applicazioni saranno più complicate, avranno una compatibilità ridotta, non potranno accedere alle API del framework e saranno più difficili da debuggare".

"Tenete a mente che non tutte le applicazioni Android possono trarre benefici dall'uso dell'NDK - si legge nel succitato post - Come sviluppatori, dovrete bilanciare vantaggi e svantaggi, e questi ultimi sono numerosi!". Tra le applicazioni che potrebbero meglio adattarsi all'uso dell'NDK il post cita quelle che eseguono complesse simulazioni fisiche e che elaborano i segnali.

L'Android 1.5 NDK Release 1 può essere scaricato da qui per Windows, Mac OS X e Linux. L'Android 1.5 SDK, necessario per l'installazione dell'NDK, è invece disponibile qui.

Alessandro Del Rosso
82 Commenti alla Notizia Android: dopo l'SDK, l'NDK
Ordina
  • campo libero ai virus su Android quindi, ottimo.
    non+autenticato
  • ps. strano che Google non ci abbia pensato, Chrome è davvero ben fatto dal punto di vista sicurezza.. sono io ad essere poco informato? Deluso
    non+autenticato
  • Linux normale lavora sugli eseguibili da sempre... eppure non soffre di virus come soffre windows (penso che i virus per linux si possano contare sulle dita di una mano, e probabilmente sono già stati resi tutti inoffensivi)

    Dato che android ha sotto un sistema linux, rimane quella sicurezza intrinseca (sempre che non abbiano fatto stupidate) di un sistema Linux per PC....

    Quandi che venga eseguito codice compilato invece che codice per macchina virtuale cambia veramente poco in termini di sicurezza...

    (ps: esistono i virus scritti in java.....)
    non+autenticato
  • Non vorrei sbagliarmi ma mi era sembrato di capire che le applicazioni Dalvik possano accedere a librerie di codice C/C++ compilato, tramite JNI.
    E' un pò diverso da come è raccontato nell'articolo..

    Dal sito...
    http://developer.android.com/sdk/ndk/1.5_r1/index....

    Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
    non+autenticato
  • sono piuttosto i componenti nativi a non avere una libreria per l'accesso all'api di sistema mentre tramite jni dalvik riesce a comunicare con i componenti nativi

    a ben guardare però mi sembra sensato, google vuole mantenere il software per android il più portabile possibile
  • - Scritto da: pabloski
    > sono piuttosto i componenti nativi a non avere
    > una libreria per l'accesso all'api di sistema
    > mentre tramite jni dalvik riesce a comunicare con
    > i componenti nativi
    >
    > a ben guardare però mi sembra sensato, google
    > vuole mantenere il software per android il più
    > portabile possibile

    Sì ma solo tra un device Android e l'altro.

    Non vogliono invece la portabilità tra Android e i sistemi Unix o Java suoi cugini, ragion per cui
    1) non hanno usato una JVM come tutte le altre e non supportano i vari JSR e
    2) benché il kernel sia Linux la libc di Android non è compatibile con quella Linux.

    La ragione ufficiale sono le performance ed il voler confinare la GPL nel kernel e nei driver ed usare altre licenze per le applicazioni. La sensazione però è che Google abbia paura che la gente si possa compilare su Android tutte le applicazioni Java o Linux che ci sono in giro.

    Che faccia male allo store? Occhiolino
    non+autenticato
  • Come da titolo, l'importante è che si possa fare, sta allo sviluppatore poi decidere COSA fare...

    Il bello dell'open è proprio questo: non ci sono catene Sorride
    non+autenticato
  • > Come da titolo, l'importante è che si possa fare,
    > sta allo sviluppatore poi decidere COSA
    > fare...
    >
    > Il bello dell'open è proprio questo: non ci sono
    > catene
    > Sorride
    ...E liberarsi dai pesi morti come giavaA bocca aperta
    non+autenticato
  • quoto in pieno; alla fine trovo giusto che si sia aperta questa strada. Per come la vedo io in buona parte del codice le prestazioni non sono un grosso problema, soprattutto nella parte che si occupa dell' interazione con l' utente che un' operazione impieghi 1ms o 100ms ad eseguire spesso non è percettibile per l' utente e dunque non fa differenza (andate a vedere lo storico della quota idle del vostro processore/i in una tipica sessione desktop se non ci credete).
    Esistono tuttavia piccole porzioni di codice in cui effettivamente ogni microsecondo è importante, ed è lì che l' NDK casca a fagiolo, permettendo di realizzare soluzioni perfettamente ottimizzate al caso specifico, senza overhead che in quel contesto sarebbero dannosi.
    E poi fintanto che parliamo di C/C++ siamo a posto, c'è l' unico inconveniente di dovere compilare per architetture diverse, ma non mi pare che questo sia mai stato un problema su linux/unix/bsd...
  • Bhe, se guardiamo proprio il millisecondo è un problema Sorride

    Linux e co se la cavano sempre compilando tutto in assembly "universale".... che ha il difetto di non sfruttare mai al 100% la potenza di ogni singola macchina (ognuna differente)

    Per questo il C si è imposto nel mondo open Sorride Hai il sorgente e puoi compilartelo da solo in assembly specifico per la tua macchina, ottenendo la massima ottimizzazione Sorride
    non+autenticato
  • > Bhe, se guardiamo proprio il millisecondo è un
    > problema
    > Sorride
    >
    > Linux e co se la cavano sempre compilando tutto
    > in assembly "universale".... che ha il difetto di
    > non sfruttare mai al 100% la potenza di ogni
    > singola macchina (ognuna
    > differente)

    Che beep stai farneticando?
    Quale parte di
    ./configure
    make
    make install
    non ti è chiara?

    > Per questo il C si è imposto nel mondo open Sorride
    > Hai il sorgente e puoi compilartelo da solo in
    > assembly specifico per la tua macchina, ottenendo
    > la massima ottimizzazione
    > Sorride
    Questa è buona la primaOcchiolino
    non+autenticato
  • Guarda che quando istalli un sistema Linux mica lo compili XD è già compilato con le CFLAGS universali XDXD

    Se vuoi puoi anke metterti le CFLAGS del tuo processore... a patto di compilarti tutto XD


    http://it.wikipedia.org/wiki/CFLAGS
    non+autenticato
  • > Guarda che quando istalli un sistema Linux mica
    > lo compili XD è già compilato con le CFLAGS
    > universali
    > XDXD
    >
    gentoo ti dice niente?
    non+autenticato
  • Sto parlando di sistemi linux "normali" non di quelli fatti per i nerd che ti compilano anche la tua vita XDXDXD

    Lo so che esistono quelli che lo fanno... ma è da pazzi usarli... ore per istallare ogni cosa.....
    non+autenticato
  • > Sto parlando di sistemi linux "normali" non di
    > quelli fatti per i nerd che ti compilano anche la
    > tua vita
    > XDXDXD
    >
    > Lo so che esistono quelli che lo fanno... ma è da
    > pazzi usarli... ore per istallare ogni
    > cosa.....
    Sbaglio o l'hai detto tu questo:
    "Il bello dell'open è proprio questo: non ci sono catene"Occhiolino
    non+autenticato
  • Lo so, ed è bello che ci sia la possibilità di farlo (non ho detto che devono toglierli) ma rimane il fatto che compilare ogni minima cosa è assurdo, poichè non ne vale la pena (è utile a mio dire solo epr certe cose)

    Detto questo, la mia opinione, per fortuna, non è abbastanza potente da bandire un sistema operativo XDXDXD
    non+autenticato
  • - Scritto da: Andreabont

    > Detto questo, la mia opinione, per fortuna, non è
    > abbastanza potente da bandire un sistema
    > operativo
    > XDXDXD

    mmm non capisco il senso del bandire....come ho detto questo problema i sistemi operativi closed ce l'hanno ancorpiù