API per Android 3.1

Livello API: 12

Per gli sviluppatori, la piattaforma Android 3.1 (HONEYCOMB_MR1) è disponibile come componente scaricabile per l'SDK Android. La piattaforma scaricabile include una libreria Android e un'immagine di sistema, oltre a un set di skin per emulatori e altro ancora. La piattaforma scaricabile non include librerie esterne.

Per gli sviluppatori, la piattaforma Android 3.1 è disponibile come componente scaricabile per l'SDK Android. La piattaforma scaricabile include una libreria Android e un'immagine di sistema, oltre a un set di skin per emulatori e altro ancora. Per iniziare a sviluppare o testare la versione di Android 3.1, utilizza Android SDK Manager per scaricare la piattaforma nel tuo SDK.

Panoramica dell'API

Le sezioni seguenti forniscono una panoramica tecnica delle novità per gli sviluppatori di Android 3.1, incluse le nuove funzionalità e le modifiche dell'API Framework rispetto alla versione precedente.

API USB

Android 3.1 introduce nuove e potenti API per integrare le periferiche connesse con le applicazioni in esecuzione sulla piattaforma. Le API si basano su uno stack USB (Universal Serial Bus) e sui servizi integrati nella piattaforma, compreso il supporto sia per le interazioni di host e dispositivo USB. Utilizzando le API, gli sviluppatori possono creare applicazioni in grado di scoprire, comunicare con e gestire una varietà di tipi di dispositivi connessi tramite USB.

Lo stack e le API distinguono due tipi di hardware USB di base, a seconda che il dispositivo Android funzioni come host o che l'hardware esterno funzioni come host:

  • Un dispositivo USB è un componente hardware connesso che dipende dal dispositivo Android per fungere da host. Ad esempio, i dispositivi di input, i mouse e i joystick sono dispositivi USB, così come molte videocamere, hub e così via.
  • Un accessorio USB è un componente hardware collegato che dispone di un controller host USB, fornisce alimentazione ed è progettato per comunicare con i dispositivi Android tramite USB. È possibile collegare una serie di periferiche come accessori, dai controller robotici ad apparecchiature musicali, cyclette e altro ancora.

Per entrambi i tipi (dispositivi USB e accessori USB), le API USB della piattaforma supportano il rilevamento tramite trasmissione di intent quando collegati o scollegati, nonché interfacce standard, endpoint e modalità di trasferimento (controllo, collettivo e interrompe).

Le API USB sono disponibili nel pacchetto android.hardware.usb. La classe centrale è UsbManager, che fornisce metodi helper per l'identificazione e la comunicazione con dispositivi USB e accessori USB. Le applicazioni possono acquisire un'istanza di UsbManager e quindi eseguire una query per trovare l'elenco di dispositivi o accessori collegati per poi comunicare con questi o gestirli. UsbManager dichiara anche le azioni intent che il sistema trasmette per annunciare quando un dispositivo o un accessorio USB viene collegato o scollegato.

Altri corsi includono:

  • UsbDevice, una classe che rappresenta hardware esterno collegato come dispositivo USB (con il dispositivo Android che funge da host).
  • UsbAccessory, che rappresenta l'hardware esterno collegato come host USB (con il dispositivo Android che funge da dispositivo USB).
  • UsbInterface e UsbEndpoint, che forniscono l'accesso alle interfacce USB e agli endpoint standard di un dispositivo.
  • UsbDeviceConnection e UsbRequest, per l'invio e la ricezione di dati e il controllo dei messaggi da o verso un dispositivo USB, in modo sincrono e asincrono.
  • UsbConstants, che fornisce le costanti per dichiarare tipi di endpoint, classi di dispositivi e così via.

Tieni presente che, sebbene lo stack USB sia integrato nella piattaforma, il supporto effettivo per le modalità host USB e accessori aperti su dispositivi specifici dipende dai produttori. In particolare, la modalità host si basa sull'hardware del controller USB appropriato nel dispositivo Android.

Inoltre, gli sviluppatori possono richiedere filtri su Google Play, in modo che le loro applicazioni non siano disponibili per gli utenti i cui dispositivi non forniscono il supporto USB appropriato. Per richiedere l'applicazione di filtri, aggiungi uno o entrambi gli elementi di seguito al manifest dell'applicazione, a seconda dei casi:

  • Se l'applicazione deve essere visibile solo ai dispositivi che supportano la modalità host USB (connessione di dispositivi USB), dichiara questo elemento:

    <uses-feature android:name="android.hardware.usb.host" android:required="true">

  • Se l'applicazione deve essere visibile solo ai dispositivi che supportano accessori USB (connessione di host USB), dichiara questo elemento:

    <uses-feature android:name="android.hardware.usb.accessory" android:required="true">

Per informazioni complete su come sviluppare applicazioni che interagiscano con gli accessori USB, consulta la documentazione per gli sviluppatori.

Per esaminare le applicazioni di esempio che utilizzano l'API host USB, consulta ADB Test e Missile Launcher.

API MTP/PTP

Android 3.1 mostra una nuova API MTP che consente alle applicazioni di interagire direttamente con le fotocamere collegate e altri dispositivi PTP. La nuova API consente a un'applicazione di ricevere notifiche quando i dispositivi vengono collegati e rimossi, di gestire i file e l'archiviazione su tali dispositivi e di trasferire file e metadati da e verso questi dispositivi. L'API MTP implementa il sottoinsieme PTP (Picture Transfer Protocol) della specifica MTP (Media Transfer Protocol).

L'API MTP è disponibile nel pacchetto android.mtp e fornisce queste classi:

  • MtpDevice incapsula un dispositivo MTP collegato tramite il bus host USB. Un'applicazione può creare un'istanza di un oggetto di questo tipo e quindi utilizzare i suoi metodi per ottenere informazioni sul dispositivo e sugli oggetti archiviati al suo interno, nonché per aprire la connessione e trasferire i dati. Ecco alcuni dei metodi:
    • getObjectHandles() restituisce un elenco di handle per tutti gli oggetti sul dispositivo che corrispondono a un formato e a un elemento padre specificati. Per ottenere informazioni su un oggetto, un'applicazione può passare un handle a getObjectInfo().
    • importFile() consente a un'applicazione di copiare i dati per un oggetto in un file nello spazio di archiviazione esterno. Questa chiamata può bloccare per una quantità di tempo arbitraria a seconda delle dimensioni dei dati e della velocità dei dispositivi, quindi dovrebbe essere effettuata da un thread spearate.
    • open() consente a un'applicazione di aprire un dispositivo MTP/PTP collegato.
    • getThumbnail() restituisce la miniatura dell'oggetto sotto forma di array di byte.
  • MtpStorageInfo contiene informazioni su un'unità di archiviazione su un dispositivo MTP, corrispondenti al set di dati StorageInfo descritto nella sezione 5.2.2 della specifica MTP. I metodi nella classe consentono a un'applicazione di ottenere la stringa descrittiva di un'unità di archiviazione, lo spazio libero, la capacità massima di archiviazione, l'ID spazio di archiviazione e l'identificatore del volume.
  • MtpDeviceInfo contiene informazioni su un dispositivo MTP corrispondente al set di dati DeviceInfo descritto nella sezione 5.1.1 della specifica MTP. I metodi della classe consentono alle applicazioni di ottenere il produttore, il modello, il numero di serie e la versione.
  • MtpObjectInfo contiene informazioni su un oggetto archiviate su un dispositivo MTP, corrispondenti al set di dati ObjectInfo descritto nella sezione 5.3.1 della specifica MTP. I metodi nella classe consentono alle applicazioni di ottenere informazioni su dimensioni, formato dei dati, tipo di associazione, data di creazione e miniature di un oggetto.
  • MtpConstants fornisce le costanti per dichiarare i codici dei formati file MTP, il tipo di associazione e lo stato della protezione.

Supporto di nuovi dispositivi di input ed eventi di movimento

Android 3.1 estende il sottosistema di input per supportare nuovi dispositivi di input e nuovi tipi di eventi di movimento, in tutte le viste e le finestre. Gli sviluppatori possono sfruttare queste funzionalità per consentire agli utenti di interagire con le loro applicazioni utilizzando mouse, trackball, joystick, gamepad e altri dispositivi, oltre a tastiere e touchscreen.

Per gestire l'input del mouse, della rotellina di scorrimento e della trackball, la piattaforma supporta due nuove azioni relative agli eventi di movimento:

  • ACTION_SCROLL, che descrive la posizione del puntatore in cui è stato eseguito un movimento di scorrimento non touch, ad esempio tramite la rotellina del mouse. In MotionEvent, il valore degli assi AXIS_HSCROLL e AXIS_VSCROLL specifica il relativo movimento di scorrimento.
  • ACTION_HOVER_MOVE, segnala la posizione attuale del mouse quando non viene premuto alcun pulsante, nonché eventuali punti intermedi dall'ultimo evento HOVER_MOVE. Le notifiche di accesso e uscita tramite passaggio del mouse non sono ancora supportate.

Per supportare joystick e gamepad, la classe InputDevice include queste nuove origini dei dispositivi di input:

Per descrivere gli eventi di movimento da queste nuove origini, oltre a quelli provenienti da mouse e trackball, la piattaforma ora definisce i codici degli assi su MotionEvent, in modo simile a come definisce i codici chiave su KeyEvent. I nuovi codici di asse per joystick e controller di gioco includono AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE e molti altri. Gli assi MotionEvent esistenti sono rappresentati da AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR e AXIS_ORIENTATION.

Inoltre, MotionEvent definisce un numero di codici di assi generici che vengono utilizzati quando il framework non sa come mappare un determinato asse. Dispositivi specifici possono usare i codici generici degli assi per passare dati di movimento personalizzati alle applicazioni. Per un elenco completo degli assi e delle relative interpretazioni, consulta la documentazione della classe MotionEvent.

La piattaforma fornisce eventi di movimento alle applicazioni in batch, quindi un singolo evento può contenere una posizione attuale e più cosiddetti movimenti storici. Le applicazioni devono utilizzare getHistorySize() per ottenere il numero di campioni storici, quindi recuperare ed elaborare tutti i campioni storici in ordine utilizzando getHistoricalAxisValue(). Successivamente, le richieste dovrebbero elaborare l'esempio attuale utilizzando getAxisValue().

Alcuni assi possono essere recuperati utilizzando metodi di accesso speciali. Ad esempio, anziché chiamare getAxisValue(), le applicazioni possono chiamare getX(). Gli assi con funzioni di accesso integrate includono AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR e AXIS_ORIENTATION.

Ogni dispositivo di input ha un ID univoco assegnato dal sistema e può anche fornire più origini. Quando un dispositivo fornisce più origini, più di un'origine può fornire dati dell'asse utilizzando lo stesso asse. Ad esempio, un evento touch proveniente dall'origine del tocco utilizza l'asse X per i dati sulla posizione dello schermo, mentre un evento joystick proveniente dall'origine del joystick utilizzerà invece l'asse X per la posizione del joystick. Per questo motivo, è importante che le applicazioni interpretino i valori degli assi in base all'origine da cui hanno origine. Quando si gestisce un evento di movimento, le applicazioni devono utilizzare i metodi sulla classe InputDevice per determinare gli assi supportati da un dispositivo o un'origine. In particolare, le applicazioni possono utilizzare getMotionRanges() per eseguire query su tutti gli assi di un dispositivo o su tutti gli assi di una determinata origine del dispositivo. In entrambi i casi, le informazioni sull'intervallo per gli assi restituiti nell'oggetto InputDevice.MotionRange specificano l'origine di ogni valore dell'asse.

Infine, poiché gli eventi di movimento di joystick, gamepad, mouse e trackball non sono eventi di tocco, la piattaforma aggiunge un nuovo metodo di callback per trasferirli a un View come eventi di movimento "generici". Nello specifico, segnala gli eventi di movimento non touch ai View tramite una chiamata a onGenericMotionEvent(), anziché a onTouchEvent().

La piattaforma invia eventi di movimento generici in modo diverso, a seconda della classe di origine dell'evento. Gli eventi SOURCE_CLASS_POINTER vengono inseriti in View sotto il puntatore, in modo simile al funzionamento degli eventi touch. Tutti gli altri vanno al View attualmente attivo. Ad esempio, questo significa che un elemento View deve concentrarsi per ricevere eventi del joystick. Se necessario, le applicazioni possono gestire questi eventi a livello di attività o di dialogo implementando onGenericMotionEvent() lì.

Per esaminare un'applicazione di esempio che utilizza eventi di movimento joystick, vedi GameControllerInput e GameView.

API RTP

Android 3.1 espone un'API al suo stack RTP (Real-time Transport Protocol) integrato, che le applicazioni possono utilizzare per gestire i flussi di dati on demand o interattivi. In particolare, le app che offrono VoIP, push-to-talk, conferenze e streaming audio possono utilizzare l'API per avviare sessioni e trasmettere o ricevere stream di dati su qualsiasi rete disponibile.

L'API RTP è disponibile nel pacchetto android.net.rtp. I corsi includono:

  • RtpStream, la classe base dei flussi di dati che inviano e ricevono pacchetti di rete con payload multimediali tramite RTP.
  • AudioStream, una sottoclasse di RtpStream che trasporta i payload audio su RTP.
  • AudioGroup, un hub audio locale per la gestione e il missaggio dell'altoparlante, del microfono e del microfono del dispositivo AudioStream.
  • AudioCodec, che contiene una raccolta di codec da te definita per un AudioStream.

Per supportare l'audioconferenza e utilizzi simili, un'applicazione crea un'istanza di due classi come endpoint per lo stream:

  • AudioStream specifica un endpoint remoto ed è costituito dalla mappatura di rete e da un AudioCodec configurato.
  • AudioGroup rappresenta l'endpoint locale per uno o più AudioStream. L'AudioGroup mescola tutti i AudioStream e, facoltativamente, interagisce con l'altoparlante e il microfono del dispositivo contemporaneamente.

L'utilizzo più semplice prevede un singolo endpoint remoto e un endpoint locale. Per utilizzi più complessi, consulta le limitazioni descritte per AudioGroup.

Per utilizzare l'API RTP, le applicazioni devono richiedere l'autorizzazione all'utente dichiarando <uses-permission android:name="android.permission.INTERNET"> nei file manifest. Per acquisire il microfono del dispositivo, è richiesta anche l'autorizzazione <uses-permission android:name="android.permission.RECORD_AUDIO">.

Widget di app ridimensionabili

A partire da Android 3.1, gli sviluppatori possono ridimensionare i widget nella schermata Home: orizzontalmente, verticalmente o su entrambi gli assi. Gli utenti tengono premuto un widget per visualizzare i punti di manipolazione di ridimensionamento, quindi trascinano quelli orizzontali e/o verticali per modificare le dimensioni della griglia di layout.

Gli sviluppatori possono ridimensionare qualsiasi widget della schermata Home definendo un attributo resizeMode nei metadati AppWidgetProviderInfo del widget. I valori dell'attributo resizeMode includono "Horizontal", "vertical" e "none". Per dichiarare un widget come ridimensionabile orizzontalmente e verticalmente, fornisci il valore "Horizontal|vertical".

Ecco un esempio: 

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="294dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="86400000"
    android:previewImage="@drawable/preview"
    android:initialLayout="@layout/example_appwidget"
    android:configure="com.example.android.ExampleAppWidgetConfigure"
    android:resizeMode="horizontal|vertical" >
</appwidget-provider>

Per ulteriori informazioni sui widget della schermata Home, consultare la documentazione Widget app.

Framework dell'animazione

  • Nuova lezione ViewPropertyAnimator
    • Una nuova classe ViewPropertyAnimator offre agli sviluppatori un modo pratico per animare le proprietà selezionate negli oggetti View. La classe automatizza e ottimizza l'animazione delle proprietà e semplifica la gestione di più animazioni simultanee su un oggetto View.

      L'uso dell'ViewPropertyAnimator è semplice. Per animare le proprietà di un elemento View, chiama animate() per creare un oggetto ViewPropertyAnimator per View. Utilizza i metodi nella ViewPropertyAnimator per specificare quale proprietà animare e come farlo. Ad esempio, per applicare la dissolvenza di View a trasparente, richiama alpha(0);. L'oggetto ViewPropertyAnimator gestisce i dettagli della configurazione della classe Animator sottostante, dell'avvio e del rendering dell'animazione.

  • Colore di sfondo dell'animazione
    • I nuovi metodi getBackgroundColor() e setBackgroundColor(int) consentono di ottenere/impostare il colore di sfondo dietro le animazioni, solo per le animazioni delle finestre. Al momento lo sfondo deve essere nero, con qualsiasi livello alfa desiderato.
  • Recupero della frazione animata da ViewAnimator
    • Un nuovo metodo getAnimatedFraction() consente di ottenere la frazione attuale dell'animazione, ovvero la frazione trascorsa/interpolata utilizzata nell'aggiornamento di frame più recente, da un valore ValueAnimator.

Framework UI

  • Rendering forzato di un livello
    • Un nuovo metodo buildLayer() consente a un'applicazione forzare la creazione di un livello di una vista e il rendering della vista immediatamente. Ad esempio, un'applicazione può utilizzare questo metodo per eseguire il rendering di una vista nel suo livello prima di avviare un'animazione. Se la visualizzazione è complessa, il rendering nel livello prima di avviare l'animazione eviterà di saltare i fotogrammi.
  • Distanza fotocamera
    • Le applicazioni possono utilizzare un nuovo metodo setCameraDistance(float) per impostare la distanza dalla fotocamera a una vista. Ciò consente alle applicazioni di controllare meglio le trasformazioni 3D della vista, come le rotazioni.
  • Visualizzazione di una visualizzazione del calendario da un selettore di data
  • Ottenere i callback quando le viste vengono scollegate.
  • Listener di breadcrumb del frammento, nuova firma onInflate()
  • Mostra i risultati di ricerca in una nuova scheda
  • Cursore di testo disegnabile
    • Ora puoi specificare una risorsa da utilizzare come cursore di testo tramite il nuovo attributo delle risorse textCursorDrawable.
  • Impostazione mostrata come elemento secondario nelle viste remote
  • Tasti generici per gamepad e altri dispositivi di input
    • KeyEvent aggiunge una serie di codici chiave generici per supportare i pulsanti del gamepad. La classe aggiunge anche isGamepadButton(int) e diversi altri metodi helper per lavorare con i codici chiave.

Grafica

  • Aiutanti per la gestione delle bitmap
    • setHasAlpha(boolean) consente a un'app di indicare che tutti i pixel di una bitmap sono noti per essere opachi (false) o che alcuni pixel potrebbero contenere valori alfa non opachi (true). Tieni presente che per alcune configurazioni (come RGB_565) questa chiamata viene ignorata, poiché non supporta i valori alfa per pixel. Ciò è inteso come suggerimento di disegno, poiché in alcuni casi una bitmap che è nota per essere opaca può richiedere un disegno più veloce rispetto a una bitmap con valori alfa non opachi per pixel.
    • getByteCount() ottiene le dimensioni di una bitmap in byte.
    • getGenerationId() consente a un'applicazione di scoprire se una bitmap è stata modificata, ad esempio per la memorizzazione nella cache.
    • sameAs(android.graphics.Bitmap) determina se una determinata bitmap è diversa dalla bitmap attuale per dimensioni, configurazione o dati di pixel.
  • Impostazione della posizione e della rotazione della videocamera
    • Camera aggiunge i due nuovi metodi rotate() e setLocation() per il controllo della posizione della videocamera nelle trasformazioni 3D.

Rete

  • Blocco del Wi-Fi ad alte prestazioni
    • Un nuovo blocco Wi-Fi ad alte prestazioni consente alle applicazioni di mantenere connessioni Wi-Fi ad alte prestazioni anche quando lo schermo del dispositivo è spento. Le applicazioni che riproducono in streaming musica, video o voce per lunghi periodi di tempo possono acquisire il blocco del Wi-Fi ad alte prestazioni per garantire le prestazioni dello streaming anche quando lo schermo è spento. Poiché utilizza più energia, le applicazioni devono acquisire la connessione Wi-Fi ad alte prestazioni quando occorre una connessione attiva a lunga durata.

      Per creare un blocco ad alte prestazioni, passa WIFI_MODE_FULL_HIGH_PERF come modalità di blocco in una chiamata a createWifiLock().

  • Altre statistiche sul traffico
    • Le applicazioni ora possono accedere alle statistiche su più tipi di utilizzo della rete con nuovi metodi in TrafficStats. Le applicazioni possono utilizzare i metodi per ottenere statistiche UDP, conteggio pacchetti, byte e segmenti di payload per la trasmissione e la ricezione TCP per un determinato UID.
  • Nome utente autenticazione SIP

Gestione dei download

  • Gestione dei download completati
  • Mostra i download ordinati per dimensione

Framework IME

  • Ottenere una chiave valore aggiuntiva di un metodo di inserimento

Contenuti multimediali

  • Nuovi formati audio in streaming
    • Il framework multimediale aggiunge il supporto integrato per i contenuti ADTS AAC non elaborati, per un audio in streaming migliorato, nonché il supporto per l'audio FLAC, per contenuti audio compressi di massima qualità (senza perdita di dati). Per ulteriori informazioni, consulta il documento Formati multimediali supportati.

Avvia controlli sulle applicazioni interrotte

A partire da Android 3.1, il gestore di pacchetti del sistema tiene traccia delle applicazioni in stato di interruzione e fornisce un mezzo per controllarne l'avvio dai processi in background e da altre applicazioni.

Tieni presente che lo stato Arresto di un'applicazione non equivale allo stato Arresto di un'attività. Il sistema gestisce questi due stati di interruzione separatamente.

La piattaforma definisce due nuovi flag di intent che consentono a un mittente di specificare se l'intent deve essere autorizzato ad attivare componenti nell'applicazione interrotta.

Quando nessuno di questi flag o nessuno dei due viene definito in un intent, il comportamento predefinito prevede l'inclusione dei filtri delle applicazioni interrotte nell'elenco dei target potenziali.

Tieni presente che il sistema aggiunge FLAG_EXCLUDE_STOPPED_PACKAGES a tutti gli intent trasmessi. Ciò impedisce che gli annunci trasmessi dai servizi in background avvii inavvertitamente o inutilmente componenti delle applicazioni arrestate. Un'applicazione o un servizio in background possono eseguire l'override di questo comportamento aggiungendo il flag FLAG_INCLUDE_STOPPED_PACKAGES agli intent di trasmissione a cui è consentito attivare le applicazioni arrestate.

Le applicazioni si trovano in stato arrestato quando vengono installate per la prima volta ma non sono ancora state avviate e quando vengono arrestate manualmente dall'utente (in Gestisci applicazioni).

Notifica del primo avvio e dell'upgrade dell'applicazione

La piattaforma aggiunge una notifica migliorata del primo lancio dell'applicazione e degli upgrade tramite due nuove azioni per intent:

  • ACTION_PACKAGE_FIRST_LAUNCH: inviato al pacchetto di installazione di un'applicazione al primo avvio dell'applicazione (ovvero la prima volta che l'applicazione viene spostata dallo stato interrotto). I dati contengono il nome del pacchetto.
  • ACTION_MY_PACKAGE_REPLACED: segnala a un'applicazione che è stata aggiornata e che una nuova versione è stata installata su una versione esistente. Viene inviato soltanto all'applicazione che è stata sostituita. Non contiene dati aggiuntivi. Per riceverla, dichiara un filtro per intent per questa azione. Puoi utilizzare l'intent per attivare il codice che consente di ripristinare l'esecuzione corretta dell'applicazione dopo un upgrade.

    Questo intent viene inviato direttamente all'applicazione, ma solo se è stato eseguito l'upgrade dell'applicazione mentre era avviata (non in stato arrestata).

Utilità principali

  • Cache LRU
    • Una nuova classe LruCache consente alle applicazioni di trarre vantaggio da un'efficiente memorizzazione nella cache. Le applicazioni possono utilizzare la classe per ridurre il tempo dedicato all'elaborazione o al download dei dati dalla rete, mantenendo al contempo un'adeguata quantità di memoria per i dati memorizzati nella cache.LruCache è una cache che contiene forti riferimenti a un numero limitato di valori. Ogni volta che si accede a un valore, questo viene spostato in "head" in una coda. Quando un valore viene aggiunto a una cache completa, il valore alla fine della coda viene rimosso e potrebbe essere idoneo per la garbage collection.
  • Descrittore del file come int

WebKit

  • Cookie dello schema file
    • CookieManager ora supporta i cookie che utilizzano lo schema URI file:. Puoi utilizzare setAcceptFileSchemeCookies() per abilitare/disabilitare il supporto dei cookie dello schema file prima di creare un'istanza di WebView o CookieManager. In un'istanza CookieManager, puoi verificare se i cookie dello schema file sono abilitati chiamando allowFileSchemeCookies().
  • Notifica della richiesta di accesso
    • Per supportare le funzionalità di accesso automatico del browser introdotte in Android 3.0, il nuovo metodo onReceivedLoginRequest() comunica all'applicazione host che è stata elaborata una richiesta di accesso automatico per l'utente.
  • Classi e interfacce rimosse
    • Diverse classi e interfacce sono state rimosse dall'API pubblica, dopo che in precedenza era in stato deprecato. Per ulteriori informazioni, consulta il report Differenze API.

Browser

L'applicazione browser aggiunge le seguenti funzionalità per supportare le applicazioni web:

  • Supporto per la riproduzione in linea dei video incorporati nel tag <video> HTML5. La riproduzione avviene con accelerazione hardware, ove possibile.
  • Supporto del livello per gli elementi con posizione fissa per tutti i siti (dispositivi mobili e computer).

Nuove costanti delle funzionalità

La piattaforma aggiunge nuove costanti di funzionalità hardware che gli sviluppatori possono dichiarare nei manifest dell'applicazione per informare le entità esterne come Google Play del requisito dell'applicazione in merito alle nuove funzionalità hardware supportate in questa versione della piattaforma. Gli sviluppatori dichiarano queste e altre costanti di funzionalità negli elementi manifest di <uses-feature>.

Google Play filtra le applicazioni in base alle funzionalità dichiarate negli elementi del file manifest <uses-feature>. Per ulteriori informazioni su come dichiarare le funzionalità nel file manifest di un'applicazione, consulta la pagina relativa ai filtri di Google Play.

Report Differenze API

Per una visualizzazione dettagliata di tutte le modifiche all'API in Android 3.1 (Livello API 12), consulta il report Differenze API.

Livello API

La piattaforma Android 3.1 fornisce una versione aggiornata dell'API framework. All'API Android 3.1 viene assegnato un identificatore numero intero 12, memorizzato nel sistema stesso. Questo identificatore, chiamato "Livello API", consente al sistema di determinare correttamente se un'applicazione è compatibile con il sistema prima di installarla.

Per utilizzare nella tua applicazione le API introdotte in Android 3.1, devi compilare l'applicazione in base alla libreria Android fornita nella piattaforma SDK Android 3.1. A seconda delle esigenze, potrebbe anche essere necessario aggiungere un attributo android:minSdkVersion="12" all'elemento <uses-sdk> nel file manifest dell'applicazione.

Per ulteriori informazioni, consulta la sezione Che cos'è il livello API?