API Android 4.0

Livello API: 14

Android 4.0 (ICE_CREAM_SANDWICH) è un'importante release della piattaforma che aggiunge una serie di nuove funzionalità per utenti e app sviluppatori. Oltre a tutte le nuove funzionalità e API discusse di seguito, Android 4.0 è una release della piattaforma importante perché offre l'ampio insieme di API e temi olografici di Android 3.x su schermi più piccoli. In qualità di sviluppatore di app, ora hai una singola piattaforma e un framework API unificato che ti consente di sviluppare e pubblicare la tua applicazione con un singolo APK che offre un'esperienza utente ottimizzata per smartphone, tablet e altro ancora, quando esegui la stessa versione di Android: Android 4.0 (livello API 14) o versioni successive.

Per gli sviluppatori, la piattaforma Android 4.0 è disponibile come componente scaricabile per l'SDK Android. La piattaforma scaricabile include una libreria Android e un'immagine di sistema, nonché una serie di skin di emulazione altro ancora. Per iniziare a sviluppare o eseguire test su Android 4.0, utilizza Android SDK Manager per scaricare la piattaforma nel tuo SDK.

Panoramica dell'API

Le sezioni seguenti forniscono una panoramica tecnica delle nuove API in Android 4.0.

API di social nel provider di contatti

Le API di contatto definite dal provider ContactsContract sono state è stata estesa per supportare nuove funzionalità orientate ai social quali un profilo personale per il proprietario del dispositivo e la possibilità per gli utenti di invitare singoli contatti ai social network installati dispositivo.

Profilo utente

Android ora include un profilo personale che rappresenta il proprietario del dispositivo, come definito Tabella ContactsContract.Profile. App social che mantengono un'identità utente può contribuire ai dati del profilo dell'utente creando una nuova voce ContactsContract.RawContacts all'interno di ContactsContract.Profile. In altre parole, i contatti non elaborati che rappresentano l'utente del dispositivo non appartengono alla tabella tradizionale dei contatti non elaborati definita dall'URI ContactsContract.RawContacts; devi aggiungere un contatto non elaborato del profilo la tabella alle ore CONTENT_RAW_CONTACTS_URI. Grezzo i contatti di questa tabella vengono quindi aggregati in un singolo profilo visibile all'utente con l'etichetta "Io".

L'aggiunta di un nuovo contatto non elaborato per il profilo richiede Autorizzazione android.Manifest.permission#WRITE_PROFILE. Allo stesso modo, per leggere dal profilo devi richiedere l'autorizzazione android.Manifest.permission#READ_PROFILE. Tuttavia, la maggior parte delle app non dovrebbe dover leggere il profilo utente, anche quando fornisce dati al profilo. La lettura del profilo dell'utente è un'autorizzazione sensibile e dovrebbe essere visualizzata dagli utenti scettico nei confronti delle app che lo richiedono.

Intenzione di invito

L'azione intent INVITE_CONTACT consente a un'app di invocare un'azione che indica che l'utente vuole aggiungere un contatto a un social network. L'app riceve l'app e lo usa per invitare il contatto specificato social network. La maggior parte delle app sarà la destinataria di questa operazione. Ad esempio, L'app Persone integrata richiama l'intent di invito quando l'utente seleziona "Aggiungi connessione" per uno specifico app social elencata nei dati di contatto di una persona.

Per rendere visibile la tua app nell'elenco "Aggiungi collegamento", l'app deve fornire un'opzione di sincronizzazione per sincronizzare i dati di contatto dal tuo social network. Devi quindi indicare al sistema che i tuoi risponde all'intent INVITE_CONTACT aggiungendo l'attributo inviteContactActivity al file di configurazione della sincronizzazione dell'app, con un nome completo dell'attività che il sistema deve avviare quando invia l'intent di invito. L'attività che inizia può quindi recuperare l'URI del contatto in questione dalla ed eseguire le operazioni necessarie per invitare quel contatto alla rete o aggiungerlo alla le connessioni dell'utente.

Foto grandi

Android ora supporta le foto ad alta risoluzione per i contatti. Ora, quando invii una foto in un contatto, il sistema lo elabora sia in una miniatura 96x96 (come in precedenza) che in un "Foto del display" 256 x 256 in un nuovo archivio di foto basato su file (le dimensioni esatte scelte dal sistema possono variare in futuro). Puoi aggiungere una foto di grandi dimensioni a un contatto inserendola nella consueta colonna PHOTO di una riga di dati, che il sistema elaborerà poi nella miniatura appropriata e mostrerà i record delle foto.

Feedback sull'utilizzo dei contatti

Le nuove API di ContactsContract.DataUsageFeedback ti consentono di monitorare La frequenza con cui l'utente utilizza metodi particolari per contattare le persone, ad esempio la frequenza con cui l'utente usa ogni numero di telefono o indirizzo email. Queste informazioni contribuiscono a migliorare il ranking di ogni metodo di contatto associato a ogni persona e a fornire suggerimenti migliori per contattare ogni persona.

Provider calendario

Le nuove API Calendar vi consentono di leggere, aggiungere, modificare ed eliminare calendari, eventi, promemoria e avvisi memorizzati nel provider del calendario.

Una serie di app e widget può utilizzare queste API per leggere e modificare gli eventi di calendario. Tuttavia, alcuni dei casi d'uso più interessanti sono gli adattatori di sincronizzazione che sincronizzano il calendario dell'utente da altri servizi di calendario con il fornitore di calendario, in modo da offrire una posizione unificata per tutti gli eventi dell'utente. Gli eventi di Google Calendar, ad esempio, vengono sincronizzati con il Provider di calendario tramite l'adattatore Google Calendar Sync, che permette di visualizzare questi eventi con il software Android App Calendario.

Il modello dei dati per i calendari e le informazioni relative agli eventi nel provider di calendario è definito da CalendarContract. Tutti i dati del calendario dell'utente vengono archiviati in un numero di tabelle definite da varie sottoclassi di CalendarContract:

  • La tabella CalendarContract.Calendars contiene i dati specifici del calendario informazioni. Ogni riga di questa tabella contiene i dettagli di un singolo calendario, ad esempio il nome, il colore, le informazioni di sincronizzazione e così via.
  • La tabella CalendarContract.Events contiene informazioni specifiche per ogni evento. Ogni riga di questa tabella contiene le informazioni relative a un singolo evento, come titolo dell'evento, luogo, ora di inizio, ora di fine e così via. L'evento può verificarsi una volta o ricorrente più volte. Partecipanti, promemoria e proprietà estese sono archiviati in tabelle separate e usa l'attributo _ID dell'evento per collegarlo all'evento.
  • La tabella CalendarContract.Instances contiene l'ora di inizio e di fine per le occorrenze di un evento. Ogni riga di questa tabella rappresenta una singola occorrenza. Per eventi singoli c'è una mappatura one-to-one delle istanze agli eventi. Per gli eventi ricorrenti, vengono generate automaticamente più righe corrispondenti alle varie occorrenze dell'evento.
  • La tabella CalendarContract.Attendees contiene il partecipante o l'invitato all'evento informazioni. Ogni riga rappresenta un singolo invitato di un evento. Specifica il tipo di ospite e la sua risposta per l'evento.
  • La tabella CalendarContract.Reminders contiene i dati degli avvisi e delle notifiche. Ogni riga rappresenta un singolo avviso per un evento. Un evento può avere più promemoria. Il numero di lembri per evento è specificato in MAX_REMINDERS, che viene impostato dall'adattatore di sincronizzazione proprietario del calendario in questione. I promemoria vengono specificati in minuti prima della data dell'evento programmato e specificare un metodo di allarme, ad esempio utilizzare un avviso, un'email o un SMS per ricordarlo per l'utente.
  • La tabella CalendarContract.ExtendedProperties contiene campi di dati opachi usato dall'adattatore di sincronizzazione. Il fornitore non esegue alcuna azione sugli elementi di questa tabella, tranne eliminarli quando vengono eliminati gli eventi correlati.

Per accedere ai dati del calendario di un utente con il provider del calendario, la tua applicazione deve richiedere l'autorizzazione READ_CALENDAR (per l'accesso in lettura) e WRITE_CALENDAR (per accesso in scrittura).

Intento evento

Se vuoi solo aggiungere un evento al calendario dell'utente, puoi utilizzare un intent ACTION_INSERT con i dati definiti da Events.CONTENT_URI per avviare un l'attività nell'app Calendar che crea nuovi eventi. L'utilizzo dell'intent non richiede alcuna autorizzazione e puoi specificare i dettagli dell'evento con i seguenti extra:

Fornitore di servizi vocali

Il nuovo fornitore di messaggi vocali consente alle applicazioni di aggiungere messaggi vocali al dispositivo, in modo da presentare tutti i messaggi vocali dell'utente in un'unica presentazione visiva. Ad esempio, è possibile che un utente abbia più origini di messaggi vocali, ad esempio una del fornitore di servizi dello smartphone e altre di VoIP o altri servizi vocali alternativi. Queste app possono utilizzare le API Voicemail Provider per aggiungere le proprie segreterie al dispositivo. L'applicazione Telefono integrata presenta quindi all'utente tutte le voci registrate in una presentazione unificata. Sebbene l'applicazione Telefono del sistema sia l'unica che può leggere tutti i messaggi vocali, ogni applicazione che fornisce messaggi vocali può leggere quelli che ha aggiunto al sistema (ma non può leggere i messaggi vocali di altri servizi).

Attualmente le API non consentono ad app di terze parti di leggere tutti i messaggi vocali dal le uniche app di terze parti che dovrebbero usare le API della segreteria sono quelle che dispongono di da consegnare all'utente.

La classe VoicemailContract definisce il fornitore di contenuti per il fornitore di voicemail. Le sottoclassi VoicemailContract.Voicemails e VoicemailContract.Status forniscono tabelle in cui le app possono inserire i dati della posta vocale per l'archiviazione sul dispositivo. Per un esempio di app di un fornitore di servizi di segreteria, consulta la demo del fornitore di servizi di segreteria.

Multimediale

Android 4.0 aggiunge diverse nuove API per le applicazioni che interagiscono con contenuti multimediali come foto, video e musica.

Effetti multimediali

Un nuovo framework per gli effetti multimediali ti consente di applicare una serie di effetti visivi a immagini e video. Ad esempio, gli effetti delle immagini ti consentono di correggere facilmente l'effetto occhi rossi, convertire un'immagine in scala di grigi, regolare la luminosità, regolare la saturazione, ruotare un'immagine, applicare un effetto fisheye e molto altro ancora. La di sistema esegue tutti l'elaborazione degli effetti sulla GPU per ottenere le prestazioni massime.

Per ottenere prestazioni ottimali, gli effetti vengono applicati direttamente alle texture OpenGL, deve disporre di un contesto OpenGL valido prima di poter usare le API degli effetti. Le texture a cui applichi gli effetti possono provenire da bitmap, video o persino dalla fotocamera. Esistono, però, alcune restrizioni le texture devono soddisfare i seguenti requisiti:

  1. Devono essere associati a un'GL_TEXTURE_2D immagine di texture
  2. Devono contenere almeno un livello mipmap

Un oggetto Effect definisce un singolo effetto multimediale che puoi applicare a un inquadratura dell'immagine. Il flusso di lavoro di base per creare un Effect è il seguente:

  1. Chiama EffectContext.createWithCurrentGlContext() dal contesto OpenGL ES 2.0.
  2. Utilizza il valore EffectContext restituito per chiamare EffectContext.getFactory(), che restituisce un'istanza di EffectFactory.
  3. Chiama createEffect(), passando un nome dell'effetto da @link android.media.effect.EffectFactory}, ad esempio EFFECT_FISHEYE o EFFECT_VIGNETTE.

Puoi regolare i parametri di un effetto chiamando setParameter() e trasmettendo il nome e il valore del parametro. Ogni tipo di effetto accetta parametri diversi, che sono documentati con il nome dell'effetto. Ad esempio, EFFECT_FISHEYE ha un parametro per scale del un'immagine o una distorsione di testo.

Per applicare un effetto a una texture, chiama apply() su Effect e passa la texture di input, la sua larghezza e altezza e la texture di output. La texture di input deve essere associata a un'immagine della texture GL_TEXTURE_2D (in genere chiamando la funzione glTexImage2D()). Puoi fornire più livelli mipmap. Se la texture di output non è stata associata a un immagine texture, l'effetto verrà associato automaticamente a GL_TEXTURE_2D e a un livello mipmap (0), che avrà lo stesso dimensione come input.

È garantito il supporto di tutti gli effetti elencati in EffectFactory. Tuttavia, alcuni effetti aggiuntivi disponibili dalle librerie esterne non sono supportati da tutti i dispositivi. pertanto devi prima verificare se l'effetto desiderato dalla libreria esterna è supportato richiamando isEffectSupported().

Client di controllo remoto

La nuova versione di RemoteControlClient consente ai lettori multimediali di attivare la riproduzione da client di controllo remoto, come la schermata di blocco del dispositivo. I lettori multimediali possono inoltre esporre informazioni sui contenuti multimediali attualmente in riproduzione per la visualizzazione sul telecomando, come la traccia informazioni e copertine degli album.

Per attivare i client di controllo remoto per il tuo media player, esegui l'inizializzazione di un RemoteControlClient con il relativo costruttore, passandogli un PendingIntent che trasmette ACTION_MEDIA_BUTTON. L'intent deve anche dichiarare il componente BroadcastReceiver esplicito nell'app che gestisce l'evento ACTION_MEDIA_BUTTON.

Per dichiarare gli input del controllo multimediale che il player è in grado di gestire, devi chiamare setTransportControlFlags() sul tuo RemoteControlClient, passando un set di flag FLAG_KEY_MEDIA_*, ad esempio FLAG_KEY_MEDIA_PREVIOUS e FLAG_KEY_MEDIA_NEXT.

Devi quindi registrare il tuo RemoteControlClient passandolo a MediaManager.registerRemoteControlClient(). Una volta registrato, il broadcast receiver dichiarato quando hai creato l'istanza di RemoteControlClient riceverà eventi ACTION_MEDIA_BUTTON quando viene premuto un pulsante da un telecomando. L'intent che ricevi include il KeyEvent per il tasto multimediale premuto, che puoi recuperare dall'intent con getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Per visualizzare sul telecomando le informazioni relative ai contenuti multimediali in riproduzione, chiama editMetaData() e aggiungi metadati al file restituito RemoteControlClient.MetadataEditor. Puoi fornire una bitmap per gli artwork multimediali, informazioni numeriche come il tempo trascorso e informazioni di testo come il titolo della traccia. Per informazioni sulle chiavi disponibili, vedi i flag METADATA_KEY_* in MediaMetadataRetriever.

Per un'implementazione di esempio, consulta il player di musica casuale, che fornisce una logica di compatibilità tale da consentire al client di controllo remoto su Android 4.0 dispositivi pur continuando a supportare i dispositivi con Android 2.1.

Lettori multimediali

  • Per lo streaming di contenuti multimediali online da MediaPlayer ora è necessaria l'autorizzazione INTERNET. Se usi MediaPlayer per riprodurre contenuti da internet, assicurati di aggiungere l'elemento INTERNET autorizzazione al file manifest, altrimenti la riproduzione di contenuti multimediali non funzionerà a partire da Android 4,0.
  • setSurface() ti consente di definire un Surface da utilizzare come destinazione video.
  • setDataSource() ti consente di invia intestazioni HTTP aggiuntive con la tua richiesta, che possono essere utili per il live streaming HTTP(S)
  • Il live streaming HTTP(S) ora rispetta i cookie HTTP nelle richieste

Tipi di elementi multimediali

Android 4.0 aggiunge il supporto per:

  • Protocollo HTTP/HTTPS per il live streaming versione 3
  • Codifica audio AAC raw ADTS
  • Immagini WEBP
  • Video Matroska

Per maggiori informazioni, consulta la sezione Contenuti multimediali supportati Formati.

Fotocamera

La classe Camera ora include API per il rilevamento dei volti e il controllo delle aree di messa a fuoco e misurazione.

Riconoscimento facciale

Ora le app Fotocamera possono migliorare le loro capacità grazie alle API di rilevamento facciale di Android, che non rilevare solo il volto di un soggetto, ma anche caratteristiche facciali specifiche, come gli occhi e la bocca.

Per rilevare i volti nell'applicazione della videocamera, devi registrare un Camera.FaceDetectionListener chiamando setFaceDetectionListener(). Puoi quindi iniziare la superficie della videocamera e inizia a rilevare i volti chiamando il numero startFaceDetection().

Quando il sistema rileva uno o più volti nella scena della videocamera, chiama il callback onFaceDetection() nell'implementazione di Camera.FaceDetectionListener, incluso un array di oggetti Camera.Face.

Un'istanza della classe Camera.Face fornisce varie informazioni su volto rilevato, ad esempio:

  • Un Rect che specifica i limiti del volto rispetto al campo visivo corrente della fotocamera
  • Un numero intero compreso tra 1 e 100 che indica il grado di sicurezza del sistema che l'oggetto sia un volto umano
  • Un ID univoco che ti consente di monitorare più volti
  • Diversi oggetti Point che indicano la posizione degli occhi e della bocca

Nota: il rilevamento dei volti potrebbe non essere supportato su alcuni dispositivi, quindi devi verificare chiamando getMaxNumDetectedFaces() e assicurarti che il valore restituito sia maggiore di zero. Inoltre, alcuni dispositivi potrebbero non supportare l'identificazione di occhi e bocca, In questo caso, quei campi nell'oggetto Camera.Face saranno nulli.

Aree di messa a fuoco e misurazione

Ora le app della fotocamera possono controllare le aree utilizzate dalla fotocamera per la messa a fuoco e la misurazione del bilanciamento del bianco e dell'esposizione automatica. Entrambe le funzionalità utilizzano la nuova classe Camera.Area per specificare l'area della visualizzazione corrente della videocamera che deve essere messa a fuoco o a consumo. Un'istanza della classe Camera.Area definisce i confini dell'area con un Rect e la ponderazione dell'area, che rappresenta il livello di importanza di questa rispetto alle altre aree in considerazione, con un numero intero.

Prima di impostare un'area di messa a fuoco o un'area di misurazione, devi chiamare rispettivamente getMaxNumFocusAreas() o getMaxNumMeteringAreas(). Se restituiscono zero, allora il dispositivo non supporta la funzionalità corrispondente.

Per specificare le aree di messa a fuoco o di misurazione da utilizzare, chiama semplicemente setFocusAreas() o setMeteringAreas(). Ognuno dei due utilizza un List di Camera.Area oggetti che indicano le aree da considerare per la messa a fuoco o la misurazione. Ad esempio, potresti implementare una funzionalità che consenta all'utente di impostare l'area di messa a fuoco toccando un'area dell'anteprima, che poi traduci in un oggetto Camera.Area e richiedi alla fotocamera di mettere a fuoco quell'area della scena. La messa a fuoco o l'esposizione in quell'area cambiano continuamente in base ai cambiamenti della scena nell'area.

Messa a fuoco automatica continua per le foto

Ora puoi attivare la messa a fuoco automatica continua (CAF) quando scatti foto. Per attivare il CAF nel tuo app fotocamera, tessera FOCUS_MODE_CONTINUOUS_PICTURE a setFocusMode(). Quando è tutto pronto per l'acquisizione una foto, chiama autoFocus(). Il tuo Camera.AutoFocusCallback riceve immediatamente una richiamata per indicarti se l'attenzione. Per riprendere il CAF dopo aver ricevuto il callback, devi chiamare cancelAutoFocus().

Nota:la messa a fuoco automatica continua è supportata anche durante l'acquisizione. utilizzando FOCUS_MODE_CONTINUOUS_VIDEO, che è stato aggiunta al livello API 9.

Altre funzionalità della fotocamera

  • Ora, durante la registrazione video, puoi chiamare takePicture() per salvare una foto senza interrompere la sessione video. Prima di farlo, chiama isVideoSnapshotSupported() per assicurarti che l'hardware lo supporti.
  • Ora puoi bloccare l'esposizione automatica e il bilanciamento del bianco con setAutoExposureLock() e setAutoWhiteBalanceLock() per evitare che queste proprietà non vengano modificate.
  • Ora puoi chiamare setDisplayOrientation() mentre è in esecuzione l'anteprima della videocamera. In precedenza, potevi eseguire questa operazione solo prima di iniziare l'anteprima, ma ora puoi modificare l'orientamento in qualsiasi momento.

Intenzioni di trasmissione della videocamera

  • Camera.ACTION_NEW_PICTURE: Questo indica che l'utente ha acquisito una nuova foto. L'app Fotocamera integrata richiama questa dopo l'acquisizione di una foto e anche le app fotocamera di terze parti dovrebbero trasmettere questo intento dopo aver scattato una foto.
  • Camera.ACTION_NEW_VIDEO: Questo indica che l'utente ha acquisito un nuovo video. L'app Fotocamera integrata richiama questa trasmissione dopo la registrazione di un video e anche le app di fotocamere di terze parti dovrebbero trasmettere questo intento dopo aver acquisito un video.

Android Beam (NDEF Push con NFC)

Android Beam è una nuova funzionalità NFC che consente di inviare messaggi NDEF da un dispositivo a un altro (un processo noto anche come "NDEF Push"). Il trasferimento dei dati ha inizio I dispositivi basati su Android che supportano Android Beam si trovano nelle vicinanze (circa 4 cm), solitamente con si toccano le spalle. I dati all'interno del messaggio NDEF possono contenere qualsiasi dato che desideri condividere tra i dispositivi. Ad esempio, l'app Persone condivide i contatti, YouTube condivide i video e il browser condivide URL utilizzando Android Beam.

Per trasmettere i dati tra dispositivi utilizzando Android Beam, devi creare un NdefMessage che contenga le informazioni che vuoi condividere mentre è attiva la tua attività in primo piano. Devi quindi passare il NdefMessage al sistema in uno dei due modi seguenti:

Nel caso in cui tu voglia eseguire codice specifico dopo che il sistema ha distribuito correttamente il file NDEF all'altro dispositivo, puoi implementare NfcAdapter.OnNdefPushCompleteCallback e impostarlo con setNdefPushCompleteCallback(). Il sistema quindi chiama onNdefPushComplete() quando il messaggio viene recapitato.

Sul dispositivo di destinazione, il sistema invia messaggi push NDEF in modo simile ai normali tag NFC. Il sistema richiama un intent con l'ACTION_NDEF_DISCOVERED per avviare un'attività con un URL o un tipo MIME impostato in base al primo NdefRecord in NdefMessage. Per l'attività a cui vuoi rispondere, puoi dichiarare filtri per intent per gli URL o i tipi MIME che interessano alla tua app. Per ulteriori informazioni su Tag Dispatch, consulta la guida per gli sviluppatori NFC.

Se vuoi che NdefMessage contenga un URI, puoi usare la comodità createUri per creare un nuovo NdefRecord basato su una stringa o su un oggetto Uri. Se l'URI è un formato speciale che vuoi che la tua applicazione riceva anche durante un evento Android Beam, devi creare un filtro per intent per la tua attività utilizzando lo stesso schema URI per ricevere messaggio NDEF in arrivo.

Dovresti anche passare un "record di app Android" con NdefMessage in per garantire che l'applicazione gestisca il messaggio NDEF in arrivo, anche se le applicazioni filtrano in base alla stessa azione intent. Puoi creare un record di app Android chiamata createApplicationRecord(), passarla il nome del pacchetto dell'applicazione. Quando l'altro dispositivo riceve il messaggio NDEF con il record dell'applicazione e più applicazioni contengono attività che gestiscono l'intent specificato, il sistema invia sempre il messaggio all'attività nella tua applicazione (in base al record dell'applicazione corrispondente). Se al momento l'applicazione non è installata sul dispositivo di destinazione, verrà utilizza il record dell'applicazione Android per avviare Google Play e indirizzare l'utente l'applicazione per installarla.

Se la tua applicazione non utilizza API NFC per eseguire messaggi push NDEF, Android fornisce una comportamento predefinito: quando la tua applicazione è in primo piano su un dispositivo e Android Beam è richiamato con un altro dispositivo Android, l'altro dispositivo riceve un messaggio NDEF con un Record dell'app Android che identifica la tua applicazione. Se sul dispositivo di destinazione è installata l'applicazione, il sistema la avvia; se non è installata, si apre Google Play e l'utente viene indirizzato alla tua applicazione per installarla.

Per ulteriori informazioni su Android Beam e su altre funzioni NFC, consulta la guida per gli sviluppatori Nozioni di base su NFC. Per alcuni esempi di codice utilizzando Android Beam, consulta la sezione Android Demo Beam.

P2P Wi-Fi

Android ora supporta le connessioni Wi-Fi peer-to-peer (P2P) tra dispositivi Android e altri tipi di dispositivi (in conformità con Wi-Fi DirectTM di Wi-Fi Alliance di certificazione) senza hotspot o connessione a internet. Il framework Android fornisce un insieme di API Wi-Fi P2P che ti consentono di rilevare e connetterti ad altri dispositivi quando ognuno supporta il Wi-Fi P2P, per poi comunicare tramite una connessione veloce su distanze molto più lunghe rispetto a una connessione Bluetooth.

Un nuovo pacchetto, android.net.wifi.p2p, contiene tutte le API per eseguire connessioni peer-to-peer con il Wi-Fi. Il corso principale con cui devi lavorare è WifiP2pManager, che puoi acquisire chiamando getSystemService(WIFI_P2P_SERVICE). WifiP2pManager include API che ti consentono di:

  • Inizializza la tua applicazione per le connessioni P2P chiamando initialize()
  • Individuare i dispositivi nelle vicinanze chiamando discoverPeers()
  • Avvia una connessione P2P chiamando connect()
  • E altro ancora

Sono necessarie anche molte altre interfacce e classi, ad esempio:

  • L'interfaccia WifiP2pManager.ActionListener ti consente di ricevere callback quando un'operazione come la ricerca di peer o la connessione a questi ultimi va a buon fine o non va a buon fine.
  • L'interfaccia WifiP2pManager.PeerListListener consente di ricevere informazioni sui peer rilevati. Il callback fornisce un WifiP2pDeviceList, da cui puoi recuperare un oggetto WifiP2pDevice per ogni dispositivo nel raggio d'azione e ottenere informazioni come il nome, l'indirizzo, il tipo di dispositivo, le configurazioni WPS supportate dal dispositivo e altro ancora.
  • L'interfaccia di WifiP2pManager.GroupInfoListener ti consente di: ricevere informazioni su un gruppo P2P. Il callback fornisce un oggetto WifiP2pGroup, che fornisce informazioni sul gruppo come il proprietario, il il nome della rete e la passphrase.
  • L'interfaccia WifiP2pManager.ConnectionInfoListener ti consente di ricevere informazioni sulla connessione corrente. Il callback fornisce un oggetto WifiP2pInfo, che contiene informazioni come l'eventuale presenza di un gruppo e chi ne è il proprietario.

Per utilizzare le API Wi-Fi P2P, la tua app deve richiedere le seguenti autorizzazioni utente:

Il sistema Android trasmette anche diverse azioni durante determinati eventi Wi-Fi P2P:

Per ulteriori informazioni, consulta la documentazione di WifiP2pManager. Inoltre guarda il Demo P2P Wi-Fi dell'applicazione di esempio.

Dispositivi Bluetooth per la salute

Android ora supporta i dispositivi con profilo Bluetooth per la salute, quindi puoi creare applicazioni che utilizzano il Bluetooth per comunicare con dispositivi per la salute che supportano il Bluetooth, come cardiofrequenzimetri, misuratori della pressione sanguigna, termometri e bilance.

Come per le cuffie standard e i dispositivi con profilo A2DP, devi chiamare getProfileProxy() con un tipo di profilo BluetoothProfile.ServiceListener e HEALTH per stabilire una connessione con il profilo un oggetto proxy.

Una volta acquisito il proxy del profilo sanitario (l'BluetoothHealth ), la connessione e la comunicazione con i dispositivi sanitari accoppiati riguarda le seguenti nuove Classi Bluetooth:

  • BluetoothHealthCallback: devi estendere questo metodo e implementare i metodi di callback per ricevere aggiornamenti sulle modifiche dello stato di registrazione dell'applicazione e dello stato del canale Bluetooth.
  • BluetoothHealthAppConfiguration: durante i callback a BluetoothHealthCallback, riceverai un'istanza di questo oggetto, che fornisce informazioni di configurazione sul dispositivo per la salute Bluetooth disponibile, che devi utilizzare per eseguire varie operazioni, come avviare e terminare le connessioni con le API BluetoothHealth.

Per ulteriori informazioni sull'uso del profilo Salute Bluetooth, consulta la documentazione di BluetoothHealth.

Accessibilità

Android 4.0 migliora l'accessibilità per gli utenti con problemi di vista con la nuova modalità di esplorazione tramite tocco e API estese che ti consentono di fornire maggiori informazioni sulla visualizzazione dei contenuti o sviluppare servizi di accessibilità avanzati.

Modalità Esplora al tocco

Gli utenti affetti da ipovedenti ora possono esplorare lo schermo toccando e trascinando un dito sul schermo per ascoltare le descrizioni vocali dei contenuti. La modalità Esplora al tocco funziona come un cursore virtuale, consente agli screen reader di identificare il testo descrittivo nello stesso modo in cui i lettori possono quando l'utente naviga con un D-pad o una trackball, leggendo le informazioni fornite di android:contentDescription e setContentDescription() al passaggio del mouse simulato . Quindi, Tieni presente che questo è un promemoria per ricordarti di fornire un testo descrittivo per le visualizzazioni in soprattutto per ImageButton, EditText, ImageView e altri widget che potrebbero non contenere naturalmente testo.

Accessibilità per le visualizzazioni

Per migliorare le informazioni disponibili per i servizi di accessibilità come gli screen reader, puoi: implementare nuovi metodi di callback per gli eventi di accessibilità nei componenti View personalizzati.

Innanzitutto, è importante notare che il comportamento del metodo sendAccessibilityEvent() è cambiato in Android 4,0. Come nella versione precedente di Android, quando l'utente attiva i servizi di accessibilità sul dispositivo e si verifica un evento di input come un clic o il passaggio del mouse, la rispettiva visualizzazione viene notificata con una chiamata a sendAccessibilityEvent(). In precedenza, l'implementazione di sendAccessibilityEvent() inizializzava un AccessibilityEvent e lo inviava a AccessibilityManager. Il nuovo comportamento prevede alcuni metodi di callback aggiuntivi che consentono alla visualizzazione e ai relativi elementi principali di aggiungere ulteriori informazioni contestuali all'evento:

  1. Quando vengono richiamati, i metodi sendAccessibilityEvent() e sendAccessibilityEventUnchecked() riassegnano il controllo a onInitializeAccessibilityEvent().

    Le implementazioni personalizzate di View potrebbero voler implementare onInitializeAccessibilityEvent() per collegare ulteriori informazioni sull'accessibilità a AccessibilityEvent, ma anche chiamare la super-implementazione per forniscono informazioni predefinite come la descrizione standard dei contenuti, l'indice degli articoli e altro ancora. Tuttavia, non devi aggiungere altri contenuti testuali in questo callback, poiché succede a questo punto.

  2. Una volta inizializzato, se l'evento è uno dei diversi tipi che devono essere compilati con informazioni di testo, la visualizzazione riceve una chiamata a dispatchPopulateAccessibilityEvent(), che rimanda al callback onPopulateAccessibilityEvent().

    In genere, le implementazioni personalizzate di View devono implementare onPopulateAccessibilityEvent() per aggiungerne altre contenuti testuali in AccessibilityEvent se il testo android:contentDescription non è presente o insufficiente. Per aggiungere ulteriore descrizione testuale alla AccessibilityEvent, chiama getText().add().

  3. A questo punto, View passa l'evento nella gerarchia delle visualizzazioni chiamando requestSendAccessibilityEvent() nella visualizzazione principale. Ogni vista genitore ha poi la possibilità di aumentare le informazioni sull'accessibilità aggiungendo un elemento AccessibilityRecord, finché raggiunge la vista principale, che invia l'evento a AccessibilityManager con sendAccessibilityEvent().

Oltre ai nuovi metodi sopra riportati, che sono utili per estendere la classe View, puoi anche intercettare questi callback di evento su qualsiasi View estendendo AccessibilityDelegate e impostandolo sulla visualizzazione con setAccessibilityDelegate(). In questo caso, ogni metodo di accessibilità nella visualizzazione rimanda la chiamata al metodo corrispondente nel delegato. Ad esempio, quando la vista riceve una chiamata a onPopulateAccessibilityEvent(), la passa alla lo stesso metodo in View.AccessibilityDelegate. Tutti i metodi non gestiti dal delegato vengono restituiti direttamente alla visualizzazione per il comportamento predefinito. Questo ti permette di eseguire solo l'override i metodi necessari per una determinata vista senza estendere la classe View.

Se vuoi mantenere la compatibilità con le versioni di Android precedenti alla 4.0, supportando al contempo le nuove API di accessibilità, puoi farlo con l'ultima versione del supporto v4 libreria (in Compatibility Package, r4) utilizzando un insieme di classi di utilità che forniscono le nuove API di accessibilità in un ambiente la progettazione.

Servizi di accessibilità

Se stai sviluppando un servizio di accessibilità, le informazioni sui vari eventi di accessibilità è stata notevolmente ampliata per offrire agli utenti feedback sull'accessibilità più avanzati. Nella specifici, gli eventi vengono generati in base alla composizione delle visualizzazioni, fornendo informazioni di contesto migliori e consentendo ai servizi di accessibilità di attraversare le gerarchie di oggetti View per ottenere ulteriori informazioni e di affrontare casi speciali.

Se stai sviluppando un servizio di accessibilità (ad esempio uno screen reader), puoi accedere ulteriori informazioni sui contenuti e attraversare le gerarchie di visualizzazioni con la seguente procedura:

  1. Dopo aver ricevuto AccessibilityEvent da un'applicazione, richiama AccessibilityEvent.getRecord() per recuperare uno specifico AccessibilityRecord (potrebbero esserci diversi record allegati ).
  2. Da AccessibilityEvent o da un singolo AccessibilityRecord, puoi chiamare getSource() per recuperare un oggetto AccessibilityNodeInfo.

    Un AccessibilityNodeInfo rappresenta un singolo nodo del contenuto della finestra in un formato che consente di eseguire query sulle informazioni sull'accessibilità relative al nodo. L'oggetto AccessibilityNodeInfo restituito da AccessibilityEvent descrive l'origine evento, mentre l'origine di un AccessibilityRecord descrive il predecessore dell'origine evento.

  3. Con AccessibilityNodeInfo, puoi eseguire query sulle informazioni al suo interno, chiamare getParent() o getChild() per attraversare la gerarchia delle visualizzazioni e persino aggiungere visualizzazioni secondarie al nodo.

Affinché l'applicazione possa autopubblicarsi nel sistema come servizio di accessibilità, deve dichiarare un file di configurazione XML che corrisponda a AccessibilityServiceInfo. Per ulteriori informazioni sulla creazione di un servizio di accessibilità, consulta i AccessibilityService e SERVICE_META_DATA per informazioni sulla configurazione XML.

Altre API di accessibilità

Se ti interessa lo stato di accessibilità del dispositivo, AccessibilityManager ha alcune nuove API, tra cui:

Servizi di controllo ortografico

Un nuovo framework per i correttori ortografici consente alle app di creare correttori ortografici in modo simile al metodo di inserimento (per gli IME). Per creare un nuovo controllo ortografico, devi implementare un servizio che si estende SpellCheckerService ed estendi la classe SpellCheckerService.Session per fornire suggerimenti ortografici basati sul testo fornito dai metodi di callback dell'interfaccia. Nei metodi di callback SpellCheckerService.Session, devi restituire i suggerimenti ortografici come oggetti SuggestionsInfo.

Le applicazioni con un servizio di controllo ortografico devono dichiarare l'autorizzazione BIND_TEXT_SERVICE come richiesto dal servizio. Il servizio deve anche dichiarare un filtro per intent con <action android:name="android.service.textservice.SpellCheckerService" /> come azione dell'intent e deve includi un elemento <meta-data> che dichiara le informazioni di configurazione per l'incantesimo strumento di controllo.

Per il codice di esempio, consulta l'app di esempio Spell Checker Service e l'app di esempio Spell Checker Client.

Motori di sintesi vocale

Le API di sintesi vocale di Android sono state significativamente estese per consentire alle applicazioni di implementare più facilmente i motori di sintesi vocale personalizzati, mentre le applicazioni che vogliono utilizzare un motore di sintesi vocale hanno coppia nuove API per la selezione di un motore.

Utilizzo di motori di sintesi vocale

Nelle versioni precedenti di Android, potevi utilizzare la classe TextToSpeech eseguire operazioni di sintesi vocale (TTS) utilizzando il motore TTS fornito dal sistema o impostare motore personalizzato utilizzando setEngineByPackageName(). In Android 4.0, il metodo setEngineByPackageName() è stato ritirato e ora puoi specificare il motore da utilizzare con un nuovo costruttore TextToSpeech che accetta il nome del pacchetto di un motore TTS.

Puoi anche eseguire query sui motori di sintesi vocale disponibili con getEngines(). Questo metodo restituisce un elenco di oggetti TextToSpeech.EngineInfo, che includono metadati come l'oggetto icona, etichetta e nome del pacchetto.

Creazione di motori di sintesi vocale

In precedenza, gli engine personalizzati richiedevano che l'engine fosse creato utilizzando un file di intestazione nativo non documentato. In Android 4.0 è disponibile un set completo di API framework per la creazione di motori di sintesi vocale.

La configurazione di base richiede l'implementazione di TextToSpeechService che risponde all'intent INTENT_ACTION_TTS_SERVICE. La il lavoro principale per un motore di sintesi vocale viene eseguito durante il callback onSynthesizeText() in un servizio che estende TextToSpeechService. Il sistema fornisce a questo metodo due oggetti:

  • SynthesisRequest: contiene vari dati, tra cui il testo da sintetizza, le impostazioni internazionali, la velocità della voce e il tono della voce.
  • SynthesisCallback: questa è l'interfaccia tramite la quale il motore TTS fornisce i dati vocali risultanti come audio in streaming. Innanzitutto, il motore deve chiamare start() per indicare che è pronto per la pubblicazione l'audio, quindi chiama audioAvailable(), passando i dati audio in un buffer di byte. Una volta che il motore ha passato tutto l'audio attraverso buffer, chiama done().

Ora che il framework supporta una vera API per la creazione di motori di sintesi vocale, il supporto del codice nativo è stata rimossa. Cerca un post del blog su un livello di compatibilità che puoi usare per convertire i vecchi motori di sintesi vocale nel nuovo framework.

Per un motore di sintesi vocale di esempio che utilizza le nuove API, vedi l'app di esempio Motore di sintesi vocale.

Utilizzo della rete

Android 4.0 offre agli utenti una visibilità precisa della quantità di dati di rete utilizzati dalle loro applicazioni. L'app Impostazioni fornisce controlli che consentono agli utenti di gestire i limiti impostati per l'utilizzo dei dati di rete e persino di disattivare l'utilizzo dei dati in background per le singole app. Per evitare che gli utenti disattivino l'accesso dell'app ai dati in background, dovresti sviluppare strategie per utilizzare i dati la connessione in modo efficiente e regolare l'utilizzo in base al tipo di connessione disponibile.

Se la tua applicazione esegue molte transazioni di rete, devi fornire le impostazioni utente che Consentire agli utenti di controllare le abitudini della tua app in relazione ai dati, ad esempio la frequenza con cui l'app sincronizza i dati, se eseguire caricamenti/download solo in Wi-Fi, se utilizzare i dati in roaming e così via. Con questi controlli a loro disposizione, è molto meno probabile che gli utenti disattivino l'accesso della tua app ai dati quando si avvicinano ai propri limiti, perché possono invece controllare con precisione la quantità di dati utilizzata dalla tua app. Se fornisci un'attività di preferenza con queste impostazioni, devi includere nella dichiarazione manifest un filtro per intent per l'azione ACTION_MANAGE_NETWORK_USAGE. Ad esempio:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Questo filtro intent indica al sistema che si tratta dell'attività che controlla l'utilizzo dei dati della tua applicazione. Pertanto, quando l'utente controlla la quantità di dati utilizzata dalla tua app dall'app Impostazioni, è disponibile un pulsante "Visualizza impostazioni dell'applicazione" che avvia l'attività di preferenza in modo che l'utente possa perfezionare la quantità di dati utilizzata dalla tua app.

Tieni inoltre presente che getBackgroundDataSetting() è ora ritirato e restituisce sempre true. Utilizza getActiveNetworkInfo(). Prima di tentare qualsiasi rete transazioni, devi sempre chiamare getActiveNetworkInfo() per ottenere il NetworkInfo che rappresenta la rete attuale ed eseguire una query isConnected() per verificare se il dispositivo ha un connessione. Puoi quindi controllare altre proprietà della connessione, ad esempio se il dispositivo è in roaming o connesso alla rete Wi-Fi.

Aziende

Android 4.0 amplia le funzionalità per le applicazioni aziendali con le seguenti funzionalità.

Servizi VPN

Il nuovo VpnService consente alle applicazioni di creare la propria VPN (Virtual Private Network), in esecuzione come Service. Un servizio VPN crea un'interfaccia per rete virtuale con il proprio indirizzo e le proprie regole di routing ed esegue tutte le operazioni di lettura e scrittura con come descrittore del file.

Per creare un servizio VPN, usa VpnService.Builder, che ti consente di specificare indirizzo di rete, server DNS, route di rete e altro ancora. Al termine, puoi stabilire l'interfaccia chiamando establish(), che restituisce un ParcelFileDescriptor.

Dal momento che un servizio VPN può intercettare i pacchetti, ci sono implicazioni per la sicurezza. Pertanto, se implementi VpnService, il tuo servizio deve richiedere BIND_VPN_SERVICE per assicurarsi che solo il sistema possa associarsi (solo al sistema viene concessa questa autorizzazione, le app non possono richiederla). Per poter utilizzare il servizio VPN, gli utenti devono attivarlo manualmente nelle impostazioni di sistema.

Criteri relativi ai dispositivi

Le applicazioni che gestiscono le limitazioni dei dispositivi ora possono disattivare la videocamera tramite setCameraDisabled() e la proprietà USES_POLICY_DISABLE_CAMERA (applicata con un elemento <disable-camera /> nel file di configurazione dei criteri).

Gestione dei certificati

La nuova classe KeyChain fornisce API che ti consentono di eseguire l'importazione e accedere nell'archivio chiavi di sistema. I certificati semplificano l'installazione dei due client (per convalidare l'identità dell'utente) e i certificati dell'autorità di certificazione (per verificare l'identità del server). Applicazioni come browser web o client di posta possono accedere ai file installati per autenticare gli utenti nei server. Per ulteriori informazioni, consulta la KeyChain documentazione.

Sensori dei dispositivi

In Android 4.0 sono stati aggiunti due nuovi tipi di sensori:

  • TYPE_AMBIENT_TEMPERATURE: un sensore di temperatura che fornisce la temperatura ambiente (stanza) in gradi Celsius.
  • TYPE_RELATIVE_HUMIDITY: un sensore di umidità che fornisce la umidità relativa dell'ambiente (stanza) in percentuale.

Se un dispositivo ha entrambi i sensori TYPE_AMBIENT_TEMPERATURE e TYPE_RELATIVE_HUMIDITY, puoi utilizzarli per calcolare il punto di rugiada e umidità assoluta.

Il sensore di temperatura precedente, TYPE_TEMPERATURE, è stato ritirato. Dovresti usare il sensore TYPE_AMBIENT_TEMPERATURE .

Inoltre, i tre sensori sintetici di Android sono stati notevolmente migliorati, ora hanno una latenza inferiore e un output più fluido. Questi sensori includono il sensore di gravità (TYPE_GRAVITY), il sensore del vettore di rotazione (TYPE_ROTATION_VECTOR) e il sensore di accelerazione lineare (TYPE_LINEAR_ACCELERATION). I sensori migliorati si affidano al giroscopio sensore per migliorare la resa, in modo che i sensori appaiano solo sui dispositivi dotati di giroscopio.

Barra delle azioni

ActionBar è stato aggiornato per supportare diversi nuovi comportamenti. Più alta importante, il sistema gestisce agevolmente le dimensioni e la configurazione della barra delle azioni quando viene eseguita su schermi più piccoli, in modo da offrire un'esperienza utente ottimale su schermi di tutte le dimensioni. Ad esempio: quando lo schermo è stretto (ad esempio quando lo smartphone è in orientamento verticale), l'icona della barra delle azioni le schede di navigazione appaiono in una "barra in pila" direttamente sotto la barra delle azioni principale. Puoi attivare anche una "barra delle azioni divisa", che posiziona tutte le attività in una barra separata in basso dello schermo quando è stretto.

Barra delle azioni divisa

Se la barra delle azioni include diverse attività, non tutte potranno essere visualizzate nella barra delle azioni. uno schermo stretto, in modo che il sistema ne inserisca di più nel menu extra. Tuttavia, Android 4.0 ti consente di attivare la "barra delle azioni divisa" in modo che più attività possano essere visualizzate sullo schermo in barra separata nella parte inferiore dello schermo. Per attivare la barra delle azioni suddivise, aggiungi android:uiOptions con "splitActionBarWhenNarrow" a uno dei tuoi <application>: o singoli tag <activity> nel file manifest. Quando questa opzione è attiva, il sistema aggiunge un'ulteriore barra in fondo alla schermata per tutte le attività quando lo schermo è stretto (nessuna attività verrà visualizzata nella barra delle azioni).

Se vuoi usare le schede di navigazione fornite dalle API di ActionBar.Tab, ma non hai bisogno della barra principale delle azioni in alto (vuoi che vengano visualizzate solo le schede in alto), quindi attiva la barra delle azioni di suddivisione come descritto sopra e richiama anche setDisplayShowHomeEnabled(false) per disattivare sull'icona dell'applicazione nella barra delle azioni. Poiché non è presente alcun elemento nella barra delle azioni principale, questa scompare. Rimangono solo le schede di navigazione in alto e le attività in basso sullo schermo.

Stili della barra delle azioni

Se vuoi applicare stili personalizzati alla barra delle azioni, puoi utilizzare le nuove proprietà di stile backgroundStacked e backgroundSplit per applicare uno sfondo disegna o colorare rispettivamente la barra in pila e la barra divisa. Puoi anche impostare questi stili in fase di esecuzione con setStackedBackgroundDrawable() e setSplitBackgroundDrawable().

Fornitore di azioni

La nuova classe ActionProvider consente di creare un gestore specializzato per gli elementi di azione. Un provider di azioni può definire una visualizzazione dell'azione, un comportamento predefinito per le azioni e un sottomenu per ogni elemento dell'azione a cui è associato. Quando vuoi creare un'attività che abbia comportamenti dinamici (ad esempio una visualizzazione delle azioni variabili, un'azione predefinita o un sottomenu), l'estensione di ActionProvider è una buona soluzione per creare un componente riutilizzabile, anziché per gestire le varie trasformazioni delle attività nel frammento o nell'attività.

Ad esempio, ShareActionProvider è un'estensione di ActionProvider che semplifica un'azione "Condividi" dalla barra delle azioni. Invece di utilizzare tradizionale che richiama l'intent ACTION_SEND, puoi utilizza questo provider di azioni per presentare una vista azioni con un elenco a discesa di applicazioni che gestiscono l'intent ACTION_SEND. Quando l'utente seleziona un'applicazione da utilizzare. per l'azione, ShareActionProvider ricorda la selezione e la fornisce nella visualizzazione Azioni per accedere più rapidamente alla condivisione con l'app.

Per dichiarare un provider di azioni per un elemento di azione, includi l'attributo android:actionProviderClass nell'elemento <item> per il menu delle opzioni dell'attività, con il nome della classe del provider di azioni come valore. Ad esempio:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

Nei onCreateOptionsMenu() delle tue attività di callback, recupera un'istanza del provider di azioni dalla voce di menu e imposta intent:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

Per un esempio di utilizzo di ShareActionProvider, vedi ActionBarShareActionProviderActivity in ApiDemos.

Visualizzazioni delle azioni comprimibili

Le attività che forniscono una visualizzazione azione ora possono passare dallo stato di tale visualizzazione a quello tradizionale stato dell'attività. In precedenza, supportavano solo SearchView quando viene utilizzata come visualizzazione delle azioni, ma ora puoi aggiungerne una per qualsiasi attività passa dallo stato espanso (la visualizzazione dell'azione è visibile) a quello compresso (l'elemento dell'azione è visibile).

Per dichiarare che un'attività contenente una visualizzazione delle azioni può essere comprimibile, includi il flag “collapseActionView" nell'attributo android:showAsAction per l'elemento <item> nel file XML del menu.

Per ricevere i callback quando una visualizzazione dell'azione passa da espansa a compressa e viceversa, registra un'istanza di MenuItem.OnActionExpandListener con il rispettivo MenuItem chiamando setOnActionExpandListener(). In genere, devi farlo durante il callback onCreateOptionsMenu().

Per controllare una visualizzazione dell'azione comprimibile, puoi chiamare collapseActionView() e expandActionView() su il rispettivo MenuItem.

Quando crei una visualizzazione di azioni personalizzata, puoi anche implementare la nuova interfaccia CollapsibleActionView per ricevere i callback quando la visualizzazione viene espansa e chiusa.

Altre API per la barra delle azioni

  • setHomeButtonEnabled() ti consente di specificare se l'icona/il logo si comporta come un pulsante per tornare alla home page o "su" (passa "true" per farlo funzionare come un pulsante).
  • setIcon() e setLogo() ti consentono di definire l'icona o il logo della barra delle azioni in fase di esecuzione.
  • Fragment.setMenuVisibility() ti consente di attivare o disabilitare la visibilità delle voci di menu opzioni dichiarate dal frammento. Questo è utile se frammento è stato aggiunto all'attività, ma non è visibile, quindi le voci di menu dovrebbero essere nascosto.
  • FragmentManager.invalidateOptionsMenu() ti consente di invalidare il menu delle opzioni di attività durante vari stati del ciclo di vita del frammento in cui l'utilizzo del metodo equivalente di Activity potrebbe non essere disponibile.

Interfaccia utente e visualizzazioni

Android 4.0 introduce una serie di nuove visualizzazioni e altri componenti dell'interfaccia utente.

Layout griglia

GridLayout è un nuovo gruppo di visualizzazioni che inserisce le visualizzazioni secondarie in una tabella rettangolare. A differenza di TableLayout, GridLayout si basa su un piano gerarchia e non utilizza viste intermedie come le righe delle tabelle per fornire la struttura. Al contrario, gli elementi secondari specificano quali righe e colonne devono occupare (le celle possono estendersi righe e/o colonne) e, per impostazione predefinita, sono disposte in sequenza nelle righe e nelle colonne della griglia. L'orientamento GridLayout determina se gli elementi secondari sequenziali sono per per impostazione predefinita, in orizzontale o in verticale. Lo spazio tra i publisher secondari può essere specificato utilizzando delle istanze della nuova vista Space o impostando i parametri di margine pertinenti sui bambini.

Vedi ApiDemos per i campioni che utilizzano GridLayout.

TextureView

TextureView è una nuova visualizzazione che ti consente di visualizzare uno stream di contenuti, ad esempio come video o come scena OpenGL. Sebbene simile a SurfaceView, TextureView è unico in quanto si comporta come una visualizzazione normale, invece di creare una in una finestra separata, in modo da poterlo trattare come qualsiasi altro oggetto View. Ad esempio, puoi applicare trasformazioni, animarlo utilizzando ViewPropertyAnimator o regolare l'opacità con setAlpha().

Tieni presente che TextureView funziona solo in una finestra con accelerazione hardware.

Per saperne di più, consulta la documentazione di TextureView.

Cambia widget

Il nuovo widget Switch è un pulsante di attivazione/disattivazione a due stati che gli utenti possono trascinare su uno o l'altro (o semplicemente toccarlo) per alternare un'opzione tra due stati.

Puoi utilizzare gli attributi android:textOn e android:textOff per specificare il testo da visualizzare sul pulsante quando è impostato su On e Off. Anche l'attributo android:text consente di posizionare un'etichetta accanto all'opzione.

Per un esempio sull'utilizzo dei sensori, consulta il file di layout switches.xml e i rispettivi interruttori .

Android 3.0 ha introdotto PopupMenu per creare brevi menu contestuali che vengono visualizzati in un punto di ancoraggio specificato (di solito nel punto dell'elemento selezionato). Android 4.0 estende PopupMenu con un paio di funzionalità utili:

Preferenze

Una nuova classe astratta TwoStatePreference funge da base per le preferenze che forniscono un'opzione di selezione a due stati. La nuova SwitchPreference è un'estensione di TwoStatePreference che fornisce un widget Switch nella per consentire agli utenti di attivare o disattivare un'impostazione senza dover aprire un'altra schermata o finestra di dialogo delle preferenze. Ad esempio, l'applicazione Impostazioni utilizza un SwitchPreference per le impostazioni Wi-Fi e Bluetooth.

Temi di sistema

Il tema predefinito per tutte le applicazioni che hanno come target Android 4.0 (impostando targetSdkVersion o minSdkVersion su “14" o versioni successive) ora è il tema "predefinito del dispositivo": Theme.DeviceDefault. Potrebbe essere tema scuro Holo o un tema scuro diverso definito dal dispositivo specifico.

È garantito che la famiglia di temi Theme.Holo non cambi da un dispositivo all'altro con la stessa versione di Android. Se in modo esplicito applicare uno qualsiasi dei Theme.Holo temi alle tue attività, puoi ti garantisco che questi temi non cambieranno carattere su dispositivi diversi all'interno dello stesso completamente gestita.

Se vuoi che la tua app si confonda con il tema generale del dispositivo (ad esempio quando i diversi OEM) fornire temi predefiniti diversi per il sistema), devi applicare esplicitamente temi della famiglia Theme.DeviceDefault.

Pulsante del menu Opzioni

A partire da Android 4.0, noterai che i telefoni non richiedono più un pulsante hardware Menu. Tuttavia, non dovrai preoccuparti se la tua applicazione esistente fornisce un menu opzioni e si aspetta che ci sia una Pulsante Menu. Per garantire che le app esistenti continuino a funzionare come previsto, il sistema fornisce una il pulsante Menu sullo schermo per le app progettate per versioni precedenti di Android.

Per un'esperienza utente ottimale, le app nuove e aggiornate devono invece utilizzare ActionBar per fornire l'accesso ai menu e impostare targetSdkVersion su "14" per sfruttare i comportamenti predefiniti più recenti del framework.

Controlli per la visibilità dell'interfaccia utente di sistema

Sin dagli albori di Android, il sistema ha gestito un componente UI noto come stato , che si trova nella parte superiore dei dispositivi degli smartphone per fornire informazioni quali l'operatore segnale, ora, notifiche e così via. Android 3.0 ha aggiunto la barra di sistema per i dispositivi con display da 10 pollici, che si trova nella parte inferiore dello schermo per fornire i controlli di navigazione di sistema (Home, Indietro e così via) e un'interfaccia per gli elementi tradizionalmente forniti dalla barra di stato. In Android 4.0, il sistema fornisce un nuovo tipo di interfaccia utente di sistema chiamata barra di navigazione. Tu potrebbe considerare la barra di navigazione una versione ottimizzata di quella di sistema, smartphone: fornisce i controlli di navigazione. per i dispositivi che non dispongono di controparti hardware per la navigazione nel sistema, ma tralascia l'interfaccia utente di notifica e i controlli di impostazione della barra di sistema. Di conseguenza, un dispositivo che fornisce la barra di navigazione ha anche la barra di stato in alto.

Fino ad oggi, puoi nascondere la barra di stato sui telefoni usando il flag FLAG_FULLSCREEN. In Android 4.0, le API che controllano la visibilità della barra di sistema sono state aggiornate per riflettere meglio il comportamento sia della barra di sistema sia della barra di navigazione:

  • Il flag SYSTEM_UI_FLAG_LOW_PROFILE sostituisce il flag STATUS_BAR_HIDDEN. Se impostato, questo flag abilita "low profile" per la barra di sistema barra di navigazione. I pulsanti di navigazione vengono attenuati e altri elementi nella barra di sistema vengono nascosti. Abilitazione in corso... Ciò è utile per creare giochi più coinvolgenti senza distrazioni per la navigazione del sistema. pulsanti.
  • Il flag SYSTEM_UI_FLAG_VISIBLE sostituisce il flag STATUS_BAR_VISIBLE per richiedere la visibilità della barra di sistema o della barra di navigazione.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION è un nuovo flag che richiede di nascondere completamente la barra di navigazione. Tieni presente che questa opzione funziona solo per la barra di navigazione utilizzati da alcuni telefoni (non nasconde la barra di sistema sui tablet). La barra di navigazione viene visualizzata di nuovo non appena il sistema riceve l'input dell'utente. Di conseguenza, questa modalità è utile principalmente per la riproduzione di video o altri casi in cui è necessario l'intero schermo, ma non è richiesto l'input dell'utente.

Puoi impostare ciascuno di questi flag per la barra di sistema e la barra di navigazione chiamando setSystemUiVisibility() in qualsiasi visualizzazione della tua attività. La gestore di finestre combina (OR insieme) tutti i flag di tutte le visualizzazioni della finestra e e applicarle all'interfaccia utente di sistema purché la finestra abbia lo stato attivo per l'input. Quando la finestra perde il focus di immissione (l'utente esce dalla tua app o viene visualizzata una finestra di dialogo), gli indicatori non hanno più effetto. Analogamente, se rimuovi queste visualizzazioni dalla gerarchia delle visualizzazioni, i relativi indicatori non vengono più applicati.

Per sincronizzare altri eventi della tua attività con le modifiche di visibilità nell'interfaccia utente di sistema (ad ad esempio, nascondi la barra delle azioni o altri controlli dell'interfaccia utente quando l'UI di sistema si nasconde), devi registrare un View.OnSystemUiVisibilityChangeListener per ricevere una notifica quando la visibilità delle modifiche alla barra di sistema o alla barra di navigazione.

Consulta la classe OverscanActivity per una dimostrazione delle diverse opzioni dell'interfaccia utente di sistema.

Framework di input

Android 4.0 aggiunge il supporto per gli eventi di passaggio del cursore e per gli eventi relativi al pulsante del mouse e allo stilo.

Eventi di passaggio del mouse

Il corso View ora supporta il passaggio del mouse per rendere possibili interazioni più avanzate mediante l'uso di dispositivi di puntamento (come un mouse o altri dispositivi che attivano una schermata del cursore).

Per ricevere eventi di passaggio del mouse in una visualizzazione, implementa View.OnHoverListener e registralo con setOnHoverListener(). Quando un utente passa il mouse si verifica nella vista, il listener riceve una chiamata a onHover(), fornendo il valore View che ha ricevuto l'evento e un MotionEvent che descrive il tipo di evento di passaggio del mouse che si è verificato. L'evento di passaggio del mouse può essere uno dei seguenti:

View.OnHoverListener deve restituire true da onHover() se gestisce l'evento di passaggio del mouse. Se le tue listener restituisce false, l'evento di passaggio del mouse verrà inviato alla vista principale come di consueto.

Se la tua applicazione utilizza pulsanti o altri widget che cambiano aspetto in base allo stato corrente, ora puoi utilizzare l'attributo android:state_hovered in un drawable elenco stato per fornire un drawable di sfondo diverso quando un cursore passa sopra la visualizzazione.

Per una dimostrazione dei nuovi eventi di passaggio del mouse, consulta la classe Hover in ApiDemos.

Eventi relativi allo stilo e al pulsante del mouse

Android ora fornisce API per ricevere input da un dispositivo di input con stilo, ad esempio un digitalizzatore una periferica per tablet o un touchscreen compatibile con lo stilo.

L'input dello stilo funziona in modo simile all'input del tocco o del mouse. Quando lo stilo è a contatto con il digitizer, le applicazioni ricevono gli eventi tocco come se venissero utilizzati un dito per toccare il display. Quando lo stilo si trova sopra il digitalizzatore, le applicazioni ricevono il passaggio del mouse eventi proprio come avveniva quando il puntatore del mouse veniva spostato sul display quando non ci sono pulsanti sono stati premute.

La tua applicazione può distinguere tra input di dita, mouse, stilo e gomma eseguendo una query sul "tipo di strumento" associata a ogni puntatore in un MotionEvent utilizzando getToolType(). I tipi di strumenti attualmente definiti sono: TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS e TOOL_TYPE_ERASER. Eseguendo una query sul tipo di strumento, l'applicazione puoi scegliere di gestire l'input con lo stilo in modi diversi rispetto all'input con il dito o con il mouse.

L'applicazione può anche eseguire query sui pulsanti del mouse o dello stilo premuti interrogando lo "stato pulsante" di un MotionEvent utilizzando getButtonState(). Gli stati dei pulsanti attualmente definiti sono: BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK e BUTTON_FORWARD. Per praticità, i pulsanti Avanti e Indietro del mouse mappata automaticamente alle chiavi KEYCODE_BACK e KEYCODE_FORWARD. La tua applicazione può gestire queste chiavi per supportare la navigazione avanti e indietro basata sui pulsanti del mouse.

Oltre a misurare con precisione la posizione e la pressione di un contatto, alcuni input stilo indicano anche la distanza tra la punta dello stilo e il digitalizzatore, l'angolo di inclinazione dello stilo e l'angolo di orientamento dello stilo. La tua applicazione può eseguire query su queste informazioni utilizzando getAxisValue() con i codici asse AXIS_DISTANCE, AXIS_TILT e AXIS_ORIENTATION.

Per una dimostrazione dei tipi di strumenti, degli stati dei pulsanti e dei nuovi codici degli assi, consulta la sezione TouchPaint in ApiDemos.

Proprietà

La nuova classe Property fornisce un modo rapido, efficiente e semplice per specificare una proprietà su qualsiasi oggetto che consenta ai chiamanti di impostare/ottenere genericamente valori sugli oggetti di destinazione. Inoltre, permette di trasmettere i riferimenti a campo/metodo e al codice di impostare/ottenere valori della proprietà senza conoscere i dettagli di quali sono i campi/metodi.

Ad esempio, se vuoi impostare il valore del campo bar sull'oggetto foo, devi in precedenza:

Kotlin

foo.bar = value

Java

foo.bar = value;

Se vuoi chiamare il set per un campo privato sottostante bar, in precedenza dovevasti eseguire i seguenti passaggi:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Tuttavia, se vuoi passare l'istanza foo e fare in modo che sia impostato un altro codice bar, non c'è modo di farlo prima di Android 4.0.

Utilizzando la classe Property, puoi dichiarare un oggetto PropertyBAR nella classe Foo in modo da poter impostare il campo sull'istanza foo della classe Foo come segue:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

La classe View ora sfrutta la classe Property per consentirti di impostare vari campi, ad esempio le proprietà di trasformazione aggiunte in Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X e così via).

Il corso ObjectAnimator utilizza anche Property , quindi puoi creare un ObjectAnimator con un Property, che è più veloce, efficiente e sicuro per i tipi di caratteri l'importanza di un approccio umile.

Accelerazione hardware

A partire da Android 4.0, l'accelerazione hardware per tutte le finestre è attiva per impostazione predefinita se la tua applicazione ha impostato targetSdkVersion o minSdkVersion su “14" o versioni successive. L'accelerazione hardware in genere comporta animazioni più fluide, scorrimento più scorrevole e prestazioni e risposta complessive migliori all'interazione dell'utente.

Se necessario, puoi disattivare manualmente l'accelerazione hardware con il hardwareAccelerated per i singoli elementi <activity> o l'attributo <application> . In alternativa, puoi disattivare l'accelerazione hardware per singole visualizzazioni chiamando il numero setLayerType(LAYER_TYPE_SOFTWARE).

Per ulteriori informazioni sull'accelerazione hardware, incluso un elenco di disegni non supportati operazioni, consulta la sezione Hardware Documento di accelerazione.

Modifiche JNI

Nelle versioni precedenti di Android, i riferimenti locali JNI non erano handle indiretti; Android utilizzava i puntatori diretti. Questo non era un problema purché il garbage collection non spostasse oggetti, funzionava perché permetteva di scrivere codice con bug. In Android 4.0, il sistema ora utilizza riferimenti indiretti per rilevare questi bug.

I dettagli dei riferimenti locali di JNI sono descritti in "Riferimenti locali e globali" nei suggerimenti di JNI. In Android 4.0, CheckJNI è stato migliorato per rilevare questi errori. Sul Blog per sviluppatori Android verrà pubblicato un post imminente sugli errori comuni relativi ai riferimenti JNI e su come risolverli.

Questa modifica nell'implementazione di JNI interessa solo le app destinate ad Android 4.0 impostando targetSdkVersion o minSdkVersion a “14" o versioni successive. Se hai impostato questi attributi su un valore inferiore, i riferimenti locali JNI si comportano come nelle versioni precedenti.

WebKit

  • WebKit aggiornato alla versione 534.30
  • Supporto dei caratteri indoari (devanagari, bengali e tamil, incluso il supporto dei caratteri complessi necessari per la combinazione dei glifi) in WebView e nel browser integrato
  • Supporto dei caratteri etiopi, georgiani e armeno in WebView e nel browser integrato
  • Il supporto di WebDriver ti consente di è più facile testare le app che utilizzano WebView

Browser Android

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

Autorizzazioni

Di seguito sono riportate le nuove autorizzazioni:

Funzionalità del dispositivo

Di seguito sono riportate le nuove funzionalità del dispositivo:

  • FEATURE_WIFI_DIRECT: dichiara che l'applicazione utilizza Wi-Fi per le comunicazioni peer-to-peer.

Per una visualizzazione dettagliata di tutte le modifiche all'API in Android 4.0 (livello API 14), consulta il report Differenze API.

API precedenti

Oltre a quanto sopra, Android 4.0 supporta naturalmente tutte le API delle versioni precedenti. Poiché la piattaforma Android 3.x è disponibile solo per i dispositivi con schermi grandi, se hai , principalmente per gli smartphone, potresti non essere a conoscenza di tutte le API aggiunte ad Android in queste versioni recenti.

Qui puoi trovare alcune delle API più importanti che potrebbero esserti sfuggite e che ora sono disponibili anche sui telefoni:

Android 3.0
  • Fragment: un componente di framework che consente di separare elementi di un'attività in moduli autonomi che definiscono la propria interfaccia utente e il proprio ciclo di vita. Consulta le Guida per gli sviluppatori relativa ai frammenti.
  • ActionBar: sostituisce la barra del titolo tradizionale nella parte superiore della finestra dell'attività. Include il logo dell'applicazione nell'angolo a sinistra e fornisce una nuova a riga di comando per le voci di menu. Consulta la guida per gli sviluppatori relativa alla barra di azioni.
  • Loader: un componente del framework che facilita il caricamento asincrono dei dati in combinazione con i componenti dell'interfaccia utente per caricare i dati in modo dinamico senza bloccare il thread principale. Consulta le Guida per gli sviluppatori relativa ai caricatori.
  • Appunti di sistema: le applicazioni possono copiare e incollare dati (oltre il semplice testo) da e verso a livello di sistema. I dati troncati possono essere testo normale, URI o intent. Consulta le Guida per gli sviluppatori Copia e incolla.
  • Trascinamento: un insieme di API integrate nel framework di visualizzazione che facilita il trascinamento operazioni aziendali. Consulta le Guida per gli sviluppatori relativa al trascinamento.
  • Un nuovissimo framework di animazione flessibile consente di animare proprietà arbitrarie di qualsiasi (View, Drawable, Fragment, Object o qualsiasi altra cosa) e definisci aspetti dell'animazione come come durata, interpolazione, ripetizione e così via. Il nuovo framework rende le animazioni in Android più semplice che mai. Consulta la guida per gli sviluppatori relativa all'animazione delle proprietà.
  • Motore di calcolo e grafica RenderScript: RenderScript offre un'API di calcolo e rendering grafico 3D ad alte prestazioni a livello nativo, che puoi scrivere in C (standard C99), fornendo il tipo di prestazioni che ti aspetti da un ambiente nativo pur rimanendo portabile su varie CPU e GPU. Consulta la guida per gli sviluppatori di RenderScript.
  • Grafica 2D con accelerazione hardware: ora puoi attivare il renderer OpenGL per la tua applicazione impostando {android:hardwareAccelerated="true"} nell'elemento <application> dell'elemento manifest o per singoli elementi <activity>. Ciò si traduce in animazioni e scorrimento più fluidi, nonché in un miglioramento complessivo del rendimento e della risposta all'interazione con l'utente.

    Nota:se imposti minSdkVersion o targetSdkVersion della tua applicazione su "14" o superiore, l'accelerazione hardware è abilitata per impostazione predefinita.

  • E molto altro ancora. Consulta la piattaforma Android 3.0 note per ulteriori informazioni.
Android 3.1
  • API USB: nuove potenti API per l'integrazione di periferiche connesse con App per Android Le API si basano su uno stack USB e su servizi integrato nella piattaforma, con supporto per le interazioni sia su host USB che su dispositivo. Consulta la guida per gli sviluppatori relativa ad host e accessori USB.
  • API MTP/PTP: le applicazioni possono interagire direttamente con le fotocamere collegate e altri dispositivi PTP per ricevere notifiche quando i dispositivi vengono collegati e rimossi, gestire file e spazio di archiviazione su questi dispositivi e trasferire file e metadati verso e da questi dispositivi. L'API MTP implementa la PTP (Picture Transfer Protocol) della specifica MTP (Media Transfer Protocol). Consulta la documentazione di android.mtp.
  • API RTP: Android espone un'API al proprio stack RTP (Real-time Transport Protocol). quali applicazioni possono utilizzare per gestire i flussi di dati on demand o interattivi. In particolare, le app che forniscono VOIP, push-to-talk, conferenze e streaming audio possono utilizzare l'API per avviare sessioni e trasmettono o ricevono stream di dati su qualsiasi rete disponibile. Consulta la documentazione di android.net.rtp.
  • Supporto per joystick e altri input generici di movimento.
  • Consulta la piattaforma Android 3.1 note per molte altre nuove API.
Android 3.2
  • Le nuove schermate supportano API che ti consentono di avere un maggiore controllo sulla modalità di visualizzazione delle tue applicazioni su schermi di dimensioni diverse. L'API estende il modello di supporto per lo schermo esistente con la capacità di scegliere come target con precisione intervalli specifici di dimensioni dello schermo in base alle dimensioni, misurate in unità di pixel indipendenti dalla densità (ad esempio 600 dp o 720 dp di larghezza), piuttosto che dalla loro generalizzazione dimensioni dello schermo (ad esempio, grande o xlarge). Ad esempio, questo è importante per distinguere tra 5" e un dispositivo da 7" device, che tradizionalmente vengono raggruppati in bucket "grandi" schermate. Vedi il post del blog Nuovi strumenti per la gestione delle dimensioni dello schermo.
  • Nuove costanti per <uses-feature> a dichiarare i requisiti di orientamento orizzontale o verticale.
  • Le "dimensioni dello schermo" del dispositivo la configurazione cambia ora durante l'orientamento dello schermo modifica. Se la tua app ha come target il livello API 13 o versioni successive, devi gestire la modifica di configurazione "screenSize" se vuoi gestire anche la modifica di configurazione "orientation". Consulta: android:configChanges per ulteriori informazioni.
  • Consulta la piattaforma Android 3.2 per altre nuove API.

Livello API

All'API Android 4.0 viene assegnato un numero intero 14, archiviato nel sistema stesso. Questo identificatore, chiamato "livello API", consente al sistema di determinare correttamente se un sia compatibile con il sistema prima di installarla.

Per utilizzare le API introdotte in Android 4.0 nella tua applicazione, devi compilarla per una piattaforma Android che supporti il livello API 14 o superiore. In base alle tue esigenze, potrebbe essere necessario aggiungere anche android:minSdkVersion="14" al <uses-sdk> .

Per saperne di più, consulta Che cos'è il livello API?