Definizione di compatibilità con Android 4.4

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Revisione 1
Ultimo aggiornamento: 27 novembre 2013

Copyright © 2013, Google Inc. Tutti i diritti riservati.
compatibility@android.com

Indice

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché i dispositivi siano compatibili con Android 4.4.

L'uso di "deve", "non deve", "obbligatorio", "deve", "non deve", "deve", "non deve", "consigliato", "può" e "facoltativo" è conforme allo standard IETF definito in RFC2119 [Risorse, 1].

Come utilizzato in questo documento, un "implementatore di dispositivi" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 4.4. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 4.4, le implementazioni dei dispositivi devono soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.

Se questa definizione o i test software descritti nella Sezione 10 non sono chiari, ambigui o incompleti, è compito dell'implementatore del dispositivo garantire la compatibilità con le implementazioni esistenti.

Per questo motivo, Android Open Source Project [Risorse, 3] è sia l'implementazione di riferimento sia quella preferita di Android. Gli implementatori di dispositivi sono vivamente incoraggiati a basare le proprie implementazioni, nella misura del possibile, sul codice sorgente "upstream" disponibile nell'Android Open Source Project. Sebbene alcuni componenti possano essere ipotetticamente sostituiti con implementazioni alternative, questa pratica è fortemente sconsigliata, in quanto superare i test software diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità di comportamento con l'implementazione standard di Android, inclusa e oltre la Compatibility Test Suite. Infine, tieni presente che alcune sostituzione e modifiche dei componenti sono esplicitamente vietate da questo documento.

2. Risorse

1. Livelli di requisiti RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Panoramica del Programma di compatibilità Android: http://source.android.com/docs/compatibility/index.html
3. Android Open Source Project: http://source.android.com/
4. Definizioni e documentazione dell'API: http://developer.android.com/reference/packages.html
5. Documentazione di riferimento per le autorizzazioni Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Riferimento android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Stringhe di versione consentite per Android 4.4: http://source.android.com/docs/compatibility/4.4/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Accelerazione hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Funzionalità offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/
16. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17. Specifiche della macchina virtuale Dalvik: disponibili nel codice sorgente di Android, in dalvik/docs
18. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Risorse per le applicazioni: http://code.google.com/android/reference/available-resources.html
21. Style guide per le icone della barra di stato: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Gestione ricerche: http://developer.android.com/reference/android/app/SearchManager.html
23. Messaggi popup: http://developer.android.com/reference/android/widget/Toast.html
24. Temi: http://developer.android.com/guide/topics/ui/themes.html
25. Classe R.style: http://developer.android.com/reference/android/R.style.html
26. Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Amministrazione dispositivo Android: http://developer.android.com/guide/topics/admin/device-admin.html
28. Documentazione di riferimento di DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. API Android Accessibility: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Progetto Eyes Free: http://code.google.com/p/eyes-free
32. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. Documentazione di riferimento degli strumenti (per adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html
34. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
35. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Strumento di test Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Classe android.content.pm.PackageManager di Android e elenco delle funzionalità hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. Protocollo NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. API di orientamento della fotocamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.html
52. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html
53. API host USB: http://developer.android.com/guide/topics/usb/host.html
54. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/permissions.html
55. App per Android: http://code.google.com/p/apps-for-android
56. DownloadManager di Android: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Formati multimediali Android: http://developer.android.com/guide/appendix/media-formats.html
59. Protocollo HTTP Live Streaming in versione preliminare: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. Trasferimento NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover
61. Accoppiamento Bluetooth semplice e sicuro tramite NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. API multicast Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. Specifiche di ricarica USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. Impostazioni di condivisione NFC di Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Widget della schermata iniziale e di blocco: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
70. Riferimento a UserManager: http://developer.android.com/reference/android/os/UserManager.html
71. Riferimento allo spazio di archiviazione esterno: /docs/core/storage
72. API di archiviazione esterna: http://developer.android.com/reference/android/os/Environment.html
73. Short code SMS: http://it.wikipedia.org/wiki/Short_code
74. Media Remote Control Client: http://developer.android.com/reference/android/media/RemoteControlClient.html
75. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
76. Sogni: http://developer.android.com/reference/android/service/dreams/DreamService.html
77. Impostazioni relative allo sviluppo di app per Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
78. Fotocamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
79. Estensione EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
80. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
81. Configurazione dell'input tocco: http://source.android.com/docs/core/interaction/input/touch-devices.html
82. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
83. Compatibilità di WebView: http://www.chromium.org/
84. App Android Device Owner: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
85. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html
86. Requisiti di codifica hardware RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
87. LOCATION_MODE di Settings.Secure: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
88. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html
89. SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html
90. Emulazione di carte basata su host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
91. Fornitore di servizi di telefonia: http://developer.android.com/reference/android/provider/Telephony.html

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android e saranno funzionalmente identiche alle informazioni riportate nella documentazione dell'SDK. In tutti i casi in cui questa definizione di compatibilità o la Compatibility Test Suite non è in accordo con la documentazione dell'SDK, la documentazione dell'SDK è considerata autorevole. Eventuali dettagli tecnici forniti nei riferimenti inclusi sopra sono considerati parte di questa Definizione di compatibilità.

3. Software

3.1. Compatibilità con le API gestite

L'ambiente di esecuzione gestito (basato su Dalvik) è il veicolo principale per le applicazioni Android. L'API Android è l'insieme di interfacce della piattaforma Android esposte alle applicazioni in esecuzione nell'ambiente VM gestito. Le implementazioni dei dispositivi DEVONO fornire implementazioni complete, inclusi tutti i comportamenti documentati, di qualsiasi API documentata esposta dall'SDK Android [Risorse, 4].

Le implementazioni dei dispositivi NON DEVONO omettere API gestite, alterare le interfacce o le firme delle API, discostarsi dal comportamento documentato o includere no-op, tranne dove specificamente consentito da questa definizione di compatibilità.

Questa definizione di compatibilità consente di omettere alcune implementazioni di dispositivi per alcuni tipi di hardware per i quali Android include API. In questi casi, le API DEVONO essere ancora presenti e comportarsi in modo ragionevole. Consulta la sezione 7 per i requisiti specifici di questo scenario.

3.2. Compatibilità API soft

Oltre alle API gestite della sezione 3.1, Android include anche un'API "soft" significativa solo in fase di runtime, sotto forma di elementi quali Intent, autorizzazioni e aspetti simili delle applicazioni Android che non possono essere applicati al momento della compilazione dell'applicazione.

3.2.1. Autorizzazioni

Gli implementatori di dispositivi DEVONO supportare e applicare tutte le costanti di autorizzazione come documentato nella pagina di riferimento delle autorizzazioni [Risorse, 5]. Tieni presente che la Sezione 9 elenca requisiti aggiuntivi relativi al modello di sicurezza di Android.

3.2.2. Parametri di compilazione

Le API Android includono una serie di costanti nella classe android.os.Build [Resources, 6] destinate a descrivere il dispositivo corrente. Per fornire valori coerenti e significativi per tutte le implementazioni dei dispositivi, la tabella seguente include ulteriori limitazioni relative ai formati di questi valori a cui le implementazioni dei dispositivi DEVONO essere conformi.

Parametro	Commenti
VERSION.RELEASE	La versione del sistema Android attualmente in esecuzione, in formato leggibile. Questo campo DEVE avere uno dei valori di stringa definiti in [Risorse, 7].
VERSION.SDK	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 4.4, questo campo DEVE avere il valore intero 19.
VERSION.SDK_INT	La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 4.4, questo campo DEVE avere il valore intero 19.
VERSION.INCREMENTAL	Un valore scelto dall'implementatore del dispositivo che designa la build specifica del sistema Android attualmente in esecuzione, in formato leggibile. Questo valore NON DEVE essere riutilizzato per build diverse rese disponibili agli utenti finali. Un utilizzo tipico di questo campo è indicare il numero di build o l'identificatore della modifica del controllo del codice sorgente utilizzato per generare la build. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
DA TAVOLO	Un valore scelto dall'implementatore del dispositivo che identifica l'hardware interno specifico utilizzato dal dispositivo, in formato leggibile. Un possibile utilizzo di questo campo è indicare la revisione specifica della scheda che alimenta il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare"^[a-zA-Z0-9.,_-]+$".
BRAND	Un valore che riflette il nome del brand associato al dispositivo come conosciuto dagli utenti finali. DEVE essere in un formato leggibile e DEVE rappresentare il produttore del dispositivo o il brand dell'azienda sotto cui viene commercializzato il dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
CPU_ABI	Il nome dell'insieme di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: Compatibilità con le API native.
CPU_ABI2	Il nome del secondo set di istruzioni (tipo di CPU + convenzione ABI) del codice nativo. Consulta la sezione 3.3: Compatibilità con le API native.
DISPOSITIVO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice che identifica la configurazione delle funzionalità hardware e il design industriale del dispositivo. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
FINGERPRINT	Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Ad esempio: acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys L'impronta NON DEVE includere caratteri di spazio. Se altri campi inclusi nel templato riportato sopra contengono spazi vuoti, DEVONO essere sostituiti nel fingerprinting della build con un altro carattere, ad esempio il trattino basso ("_"). Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit.
HARDWARE	Il nome dell'hardware (dalla riga di comando del kernel o da /proc). DOVREBBE essere ragionevolmente leggibile da una persona. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e deve corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
ORGANIZZATORE	Una stringa che identifica in modo univoco l'host su cui è stata eseguita la compilazione, in formato leggibile da persone. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
ID	Un identificatore scelto dall'implementatore del dispositivo per fare riferimento a una release specifica, in un formato leggibile da una persona. Questo campo può essere uguale a android.os.Build.VERSION.INCREMENTAL, ma DEVE essere un valore sufficientemente significativo per consentire agli utenti finali di distinguere le build software. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare"^[a-zA-Z0-9.,_-]+$".
PRODUTTORE	La ragione sociale del produttore di apparecchiature originali (OEM) del prodotto. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
MODELLO	Un valore scelto dall'implementatore del dispositivo contenente il nome del dispositivo come noto all'utente finale. DOVREBBE essere lo stesso nome con cui il dispositivo viene commercializzato e venduto agli utenti finali. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").
PRODOTTO	Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del prodotto specifico (SKU) che DEVE essere univoco all'interno dello stesso marchio. DEVE essere leggibile, ma non necessariamente destinato alla visualizzazione da parte degli utenti finali. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare "^[a-zA-Z0-9.,_-]+$".
SERIALE	Un numero di serie hardware, che DEVE essere disponibile. Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare"^([a-zA-Z0-9]{6,20})$".
TAG	Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che distingue ulteriormente la build. Ad esempio, "unsigned,debug". Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare"^[a-zA-Z0-9.,_-]+$".
DURATA	Un valore che rappresenta il timestamp della compilazione.
MACCHINA	Un valore scelto dall'implementatore del dispositivo che specifica la configurazione di runtime della build. Questo campo DEVE avere uno dei valori corrispondente alle tre configurazioni di runtime Android standard: "user", "userdebug" o "eng". Il valore di questo campo DEVE essere codificabile come ASCII a 7 bit e corrispondere all'espressione regolare"^[a-zA-Z0-9.,_-]+$".
UTENTE	Un nome o un ID utente dell'utente (o dell'utente automatico) che ha generato la compilazione. Non sono previsti requisiti per il formato specifico di questo campo, tranne che NON DEVE essere nullo o la stringa vuota ("").

3.2.3. Compatibilità con gli intent

Le implementazioni dei dispositivi DEVONO rispettare il sistema di intent a disaccoppiamento flessibile di Android, come descritto nelle sezioni seguenti. Per "rispettato" si intende che l'implementatore del dispositivo DEVE fornire un'attività o un servizio Android che specifichi un filtro per intent corrispondente e che si leghi e implementi il comportamento corretto per ogni pattern di intent specificato.

3.2.3.1. Intent di applicazione principali

Il progetto upstream di Android definisce una serie di applicazioni di base, come i contatti, il calendario, la galleria fotografica, il music player e così via. Gli implementatori dei dispositivi POSSONO sostituire queste applicazioni con versioni alternative.

Tuttavia, queste versioni alternative DEVONO rispettare gli stessi pattern di intenti forniti dal progetto a monte. Ad esempio, se un dispositivo contiene un lettore musicale alternativo, deve comunque rispettare il pattern Intent emesso da app di terze parti per scegliere un brano.

Le seguenti applicazioni sono considerate applicazioni di sistema Android di base:

• Orologio da scrivania
• Browser
• Calendar
• Contatti
• Galleria
• GlobalSearch
• Avvio app
• Musica
• Impostazioni

Le applicazioni di sistema Android di base includono vari componenti Activity o Service considerati "pubblici". In altre parole, l'attributo "android:exported" può essere assente o avere il valore "true".

Per ogni attività o servizio definito in una delle app di sistema Android di base che non è contrassegnata come non pubblica tramite un attributo android:exported con il valore "false", le implementazioni del dispositivo DEVONO includere un componente dello stesso tipo che implementa gli stessi pattern di filtro per intent dell'app di sistema Android di base.

In altre parole, un'implementazione del dispositivo PUÒ sostituire le app di sistema Android di base. Tuttavia, in questo caso, l'implementazione del dispositivo DEVE supportare tutti i pattern Intent definiti da ogni app di sistema Android di base sostituita.

3.2.3.2. Sostituzioni di intent

Poiché Android è una piattaforma estensibile, le implementazioni dei dispositivi DEVONO consentire a ogni pattern di intent a cui si fa riferimento nella Sezione 3.2.3.1 di essere sostituito da applicazioni di terze parti. L'implementazione open source di Android upstream lo consente per impostazione predefinita. Gli implementatori dei dispositivi NON DEVONO associare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi a questi pattern e assumerne il controllo. Questo divieto include, in modo specifico, ma non esaustivo, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

Tuttavia, le implementazioni dei dispositivi POSSONO fornire attività predefinite per pattern URI specifici (ad es. http://play.google.com) se l'attività predefinita fornisce un filtro più specifico per l'URI dati. Ad esempio, un filtro per intent che specifica l'URI dati "http://www.android.com" è più specifico del filtro del browser per "http://". Le implementazioni dei dispositivi DEVONO fornire un'interfaccia utente per consentire agli utenti di modificare l'attività predefinita per gli intent.

3.2.3.3. Spazi dei nomi degli intent

Le implementazioni dei dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando una stringa ACTION, CATEGORY o di altro tipo nello spazio dei nomi android.* o com.android.*. Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione che utilizzano ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO alterare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1. Le implementazioni dei dispositivi POSSONO includere pattern di intent che utilizzano spazi dei nomi chiaramente e inequivocabilmente associati alla propria organizzazione.

Questo divieto è analogo a quello specificato per le classi di lingua Java nella Sezione 3.6.

3.2.3.4. Intent di trasmissione

Le applicazioni di terze parti si basano sulla piattaforma per trasmettere determinati intent per informarle delle modifiche nell'ambiente hardware o software. I dispositivi compatibili con Android DEVONO trasmettere gli intent di trasmissione pubblica in risposta a eventi di sistema appropriati. Gli intent di trasmissione sono descritti nella documentazione dell'SDK.

3.2.3.5. Impostazioni app predefinite

Android 4.4 aggiunge impostazioni che consentono agli utenti di selezionare le applicazioni Home e SMS predefinite. Le implementazioni dei dispositivi DEVONO fornire un menu di impostazioni utente simile per ciascuno, compatibile con il pattern del filtro Intent e i metodi API descritti nella documentazione dell'SDK [Risorse, 91].

3.3. Compatibilità con le API native

3.3.1 Interfacce a livello di codice dell'applicazione

Il codice gestito in esecuzione in Dalvik può chiamare il codice nativo fornito nel file .apk dell'applicazione come file .so ELF compilato per l'architettura hardware del dispositivo appropriata. Poiché il codice nativo è altamente dipendente dalla tecnologia del processore di base, Android definisce una serie di interfacce ABI (Application Binary Interface) nell'NDK di Android, nel filedocs/CPU-ARCH-ABIS.html. Se un'implementazione del dispositivo è compatibile con uno o più ABI definiti, DEVE implementare la compatibilità con Android NDK, come indicato di seguito.

Se un'implementazione del dispositivo include il supporto di un'ABI Android:

• DEVE includere il supporto per il codice in esecuzione nell'ambiente gestito per chiamare il codice nativo utilizzando la semantica standard dell'interfaccia nativa Java (JNI)
• DEVE essere compatibile con il codice sorgente (ovvero con le intestazioni) e con i file binari (per l'ABI) di ogni libreria richiesta nell'elenco di seguito
• DEVE segnalare con precisione l'interfaccia a oggetti di base dell'applicazione (ABI) nativa supportata dal dispositivo tramite i parametri android.os.Build.CPU_ABI API e android.os.Build.CPU_ABI2.
• DEVE segnalare, tramite android.os.Build.CPU_ABI2, solo gli ABI documentati nella versione più recente dell'Android NDK, nel file docs/CPU-ARCH-ABIS.html
• DEVE segnalare, tramite android.os.Build.CPU_ABI, solo una delle ABI elencate di seguito
• armeabi-v7a
• x86
• MIPS
• DEVE essere compilato utilizzando il codice sorgente e i file di intestazione disponibili nell'upstream Android Open Source Project

Le seguenti API di codice nativo DEVONO essere disponibili per le app che includono codice nativo:

• libc (libreria C)
• libm (libreria matematica)
• Supporto minimo per C++
• Interfaccia JNI
• liblog (logging Android)
• libz (compressione Zlib)
• libdl (linker dinamico)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.0)
• libEGL.so (gestione delle superfici OpenGL native)
• libjnigraphics.so
• libOpenSLES.so (supporto audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (supporto di OpenMAX AL 1.0.1)
• libandroid.so (supporto delle attività native di Android)
• Supporto di OpenGL, come descritto di seguito

Tieni presente che le release future dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntive. Se un'implementazione del dispositivo non è compatibile con un ABI predefinito esistente, NON DEVE segnalare il supporto per alcun ABI.

Tieni presente che le implementazioni del dispositivo DEVONO includere libGLESv3.so e DEVONO avere un link simbolico (simbolico) a libGLESv2.so. Nelle implementazioni del dispositivo che dichiarano il supporto di OpenGL ES 3.0, libGLESv2.so DEVE esportare i simboli delle funzioni OpenGL ES 3.0 oltre ai simboli delle funzioni OpenGL ES 2.0.

La compatibilità con il codice nativo è complessa. Per questo motivo, è necessario ripetere che gli implementatori di dispositivi sono MOLTO vivamente incoraggiati a utilizzare le implementazioni a monte delle librerie sopra elencate per contribuire a garantire la compatibilità.

3.4. Compatibilità web

3.4.1. Compatibilità con WebView

L'implementazione di Android Open Source utilizza il codice del progetto Chromium per implementare android.webkit.WebView [Resources, 10] . Poiché non è possibile sviluppare una suite di test completa per un sistema di rendering web, gli implementatori dei dispositivi DEVONO utilizzare la build upstream specifica di Chromium nell'implementazione di WebView. Nello specifico:

• Le implementazioni del dispositivo android.webkit.WebView DEVONO essere basate sulla build di Chromium del progetto open source Android upstream per Android 4.4. Questa build include un insieme specifico di correzioni di funzionalità e sicurezza per WebView. [Risorse, 83]
• La stringa dello user agent segnalata da WebView DEVE essere nel seguente formato:
  Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
  • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE.
  • Il valore della stringa $(LOCALE) è facoltativo, DEVE seguire le convenzioni ISO per il codice paese e la lingua e DEVE fare riferimento alle impostazioni internazionali attualmente configurate del dispositivo. Se omesso, deve essere rimossa anche la virgola semicircolare finale.
  • Il valore della stringa $(MODEL) DEVE essere uguale al valore di android.os.Build.MODEL.
  • Il valore della stringa $(BUILD) DEVE essere uguale al valore di android.os.Build.ID.
  • Il valore della stringa $(CHROMIUM_VER) DEVE essere la versione di Chromium nel progetto open source Android di origine.
  • Le implementazioni dei dispositivi POSSONO omettere Mobile nella stringa dell'agente utente.

Il componente WebView DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 [Risorse, 11].

3.4.2. Compatibilità del browser

Le implementazioni dei dispositivi DEVONO includere un'applicazione browser autonoma per la navigazione web degli utenti in generale. Il browser autonomo PUÒ essere basato su una tecnologia di browser diversa da WebKit. Tuttavia, anche se viene utilizzata un'applicazione browser alternativa, il componente android.webkit.WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come descritto nella sezione 3.4.1.

Le implementazioni POSSONO includere una stringa user agent personalizzata nell'applicazione browser autonoma.

L'applicazione Browser autonoma (in base all'applicazione Browser WebKit a monte o a una sostituzione di terze parti) DEVE includere il supporto per il maggior numero possibile di funzionalità HTML5 [Risorse, 11]. Come minimo, le implementazioni dei dispositivi DEVONO supportare ciascuna di queste API associate a HTML5:

• cache dell'applicazione/operazione offline [Resources, 12]
• il tag <video> [Risorse, 13]
• geolocalizzazione [Risorse, 14]

Inoltre, le implementazioni dei dispositivi DEVONO supportare l'API webstorage HTML5/W3C [Risorse, 15] e DOVREBBERO supportare l'API IndexedDB HTML5/W3C [Risorse, 16]. Tieni conto che, poiché gli enti normativi per lo sviluppo web stanno adottando IndexedDB al posto di webstorage, IndexedDB dovrebbe diventare un componente obbligatorio in una versione futura di Android.

3.5. Compatibilità comportamentale dell'API

Il comportamento di ciascuno dei tipi di API (gestite, soft, native e web) deve essere coerente con l'implementazione preferita del progetto open source Android upstream [Risorse, 3]. Alcune aree specifiche di compatibilità sono:

• I dispositivi NON DEVONO modificare il comportamento o la semantica di uno scopo standard
• I dispositivi NON DEVONO alterare il ciclo di vita o la semantica del ciclo di vita di un determinato tipo di componente di sistema (ad esempio Service, Activity, ContentProvider e così via).
• I dispositivi NON DEVONO modificare la semantica di un'autorizzazione standard

L'elenco riportato sopra non è esaustivo. La Compatibility Test Suite (CTS) esamina parti significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità di comportamento con il progetto open source Android. Per questo motivo, gli implementatori di dispositivi DEVONO utilizzare il codice sorgente disponibile tramite l'Android Open Source Project, ove possibile, anziché implementare nuovamente parti significative del sistema.

3.6. Spazi dei nomi API

Android segue le convenzioni relative allo spazio dei nomi dei pacchetti e delle classi definite dal linguaggio di programmazione Java. Per garantire la compatibilità con le applicazioni di terze parti, gli implementatori dei dispositivi NON DEVONO apportare modifiche vietate (vedi di seguito) a questi spazi dei nomi del pacchetto:

• java.*
• javax.*
• sole.*
• android.*
• com.android.*

Le modifiche vietate includono:

• Le implementazioni dei dispositivi NON DEVONO modificare le API esposte pubblicamente sulla piattaforma Android modificando le firme di metodi o classi o rimuovendo classi o campi di classe.
• Gli implementatori dei dispositivi POSSONO modificare l'implementazione sottostante delle API, ma queste modifiche NON DEVONO influire sul comportamento dichiarato e sulla firma in linguaggio Java di qualsiasi API esposta pubblicamente.
• Gli implementatori dei dispositivi NON DEVONO aggiungere elementi esposti pubblicamente (ad esempio classi o interfacce oppure campi o metodi a classi o interfacce esistenti) alle API sopra indicate.

Un "elemento esposto pubblicamente" è qualsiasi costrutto non decorato con il marcatore "@hide" come utilizzato nel codice sorgente di Android upstream. In altre parole, gli implementatori dei dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti nei spazi dei nomi sopra indicati. Gli implementatori dei dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o comunque esposte agli sviluppatori.

Gli implementatori dei dispositivi POSSONO aggiungere API personalizzate, ma queste API NON DEVONO trovarsi in un ambito di nomi di proprietà di un'altra organizzazione o che fanno riferimento a un'altra organizzazione. Ad esempio, gli implementatori di dispositivi NON DEVONO aggiungere API al namespace com.google.* o a un namespace simile; solo Google può farlo. Analogamente, Google NON DEVE aggiungere API ai namespace di altre aziende. Inoltre, se un'implementazione del dispositivo include API personalizzate al di fuori del namespace Android standard, queste API DEVONO essere pacchettizzate in una libreria condivisa di Android in modo che solo le app che le utilizzano esplicitamente (tramite il meccanismo <uses-library>) siano interessate dall'aumento dell'utilizzo della memoria di queste API.

Se un implementatore di dispositivi propone di migliorare uno dei namespace del pacchetto elencati sopra (ad esempio aggiungendo nuove funzionalità utili a un'API esistente o aggiungendo una nuova API), l'implementatore DEVE visitare il sito source.android.com e avviare la procedura per contribuire con modifiche e codice, in base alle informazioni riportate su quel sito.

Tieni presente che le limitazioni riportate sopra corrispondono alle convenzioni standard per la denominazione delle API nel linguaggio di programmazione Java. Lo scopo di questa sezione è semplicemente rafforzare queste convenzioni e renderle vincolanti tramite l'inclusione in questa definizione di compatibilità.

3.7. Compatibilità con le macchine virtuali

Le implementazioni dei dispositivi DEVONO supportare la specifica completa del bytecode di Dalvik Executable (DEX) e la semantica della macchina virtuale Dalvik [Risorse, 17].

Le implementazioni dei dispositivi DEVONO configurare Dalvik per allocare la memoria in base alla piattaforma Android a monte e come specificato dalla tabella seguente. (consulta la Sezione 7.1.1 per le definizioni di dimensioni e densità dello schermo).

Tieni presente che i valori di memoria specificati di seguito sono considerati valori minimi e che le implementazioni dei dispositivi POSSONO allocare più memoria per applicazione.

Dimensioni schermo	Densità dello schermo	Memoria dell'applicazione
small / normal / large	ldpi / mdpi	16MB
small / normal / large	tvdpi / hdpi	32MB
small / normal / large	xhdpi	64MB
small / normal / large	400dpi	96MB
small / normal / large	xxhdpi	128MB
small / normal / large	xxxhdpi	256MB
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB
xlarge	400dpi	192MB
xlarge	xxhdpi	256MB
xlarge	xxxhdpi	512MB

3.8. Compatibilità dell'interfaccia utente

3.8.1. Avvio app (schermata Home)

Android include un'applicazione Avvio app (schermata Home) e il supporto di applicazioni di terze parti per sostituire l'Avvio app (schermata Home) del dispositivo. Le implementazioni dei dispositivi che consentono ad applicazioni di terze parti di sostituire la schermata Home del dispositivo devono dichiarare la funzionalità della piattaforma android.software.home_screen.

3.8.2. Widget

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre un "AppWidget" all'utente finale [Resources, 18]. Le implementazioni dei dispositivi che supportano l'inserimento di widget nella schermata Home DEVONO soddisfare i seguenti requisiti e dichiarare il supporto della funzionalità della piattaforma android.software.app_widgets.

• Gli Avvio app dei dispositivi DEVONO includere il supporto integrato per gli AppWidget ed esporre funzionalità dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente all'interno dell'Avvio app.
• Le implementazioni dei dispositivi DEVONO essere in grado di eseguire il rendering di widget con dimensioni 4 x 4 nella griglia standard. Per maggiori dettagli, consulta le linee guida per la progettazione di widget per app nella documentazione dell'SDK Android [Risorse, 18].
• Le implementazioni dei dispositivi che includono il supporto della schermata di blocco DEVONO supportare i widget delle applicazioni nella schermata di blocco.

3.8.3. Notifiche

Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 19] utilizzando le funzionalità hardware e software del dispositivo.

Alcune API consentono alle applicazioni di inviare notifiche o attirare l'attenzione utilizzando l'hardware, in particolare suono, vibrazione e luce. Le implementazioni dei dispositivi devono supportare le notifiche che utilizzano funzionalità hardware, come descritto nella documentazione dell'SDK e, nella misura del possibile, con l'hardware di implementazione del dispositivo. Ad esempio, se un'implementazione del dispositivo include un vibratore, deve implementare correttamente le API di vibrazione. Se l'implementazione di un dispositivo è priva di hardware, le API corrispondenti DEVONO essere implementate come no-op. Tieni presente che questo comportamento è descritto in modo più dettagliato nella sezione 7.

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file audio e così via) previste nelle API [Risorse, 20] o nella guida di stile delle icone della barra di stato/del sistema [Risorse, 21]. Gli implementatori dei dispositivi POSSONO fornire un'esperienza utente alternativa per le notifiche rispetto a quella fornita dall'implementazione di riferimento di Android Open Source. Tuttavia, questi sistemi di notifica alternativi DEVONO supportare le risorse di notifica esistenti, come sopra indicato.

Android include il supporto delle notifiche avanzate, ad esempio le visualizzazioni interattive per le notifiche in corso. Le implementazioni dei dispositivi DEVONO mostrare e eseguire correttamente le notifiche avanzate, come descritto nelle API Android.

3.8.4. Cerca

Android include API [Risorse, 22] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati delle applicazioni nella ricerca di sistema globale. In generale, questa funzionalità consiste in un'unica interfaccia utente a livello di sistema che consente agli utenti di inserire query, visualizzare suggerimenti man mano che digitano e visualizzare i risultati. Le API Android consentono agli sviluppatori di riutilizzare questa interfaccia per fornire la ricerca all'interno delle proprie app e di fornire risultati all'interfaccia utente della ricerca globale comune.

Le implementazioni dei dispositivi DEVONO includere un'unica interfaccia utente di ricerca condivisa a livello di sistema in grado di fornire suggerimenti in tempo reale in risposta all'input dell'utente. Le implementazioni dei dispositivi DEVONO implementare le API che consentono agli sviluppatori di riutilizzare questa interfaccia utente per fornire la ricerca all'interno delle proprie applicazioni. Le implementazioni dei dispositivi DEVONO implementare le API che consentono alle applicazioni di terze parti di aggiungere suggerimenti alla casella di ricerca quando viene eseguita in modalità di ricerca globale. Se non sono installate applicazioni di terze parti che utilizzano questa funzionalità, il comportamento predefinito DOVREBBE essere quello di mostrare i risultati e i suggerimenti del motore di ricerca web.

3.8.5. Auguri

Le applicazioni possono utilizzare l'API "Toast" (definita in [Risorse, 23]) per mostrare all'utente finale brevi stringhe non modali che scompaiono dopo un breve periodo di tempo. Le implementazioni dei dispositivi DEVONO mostrare le notifiche popup provenienti dalle applicazioni agli utenti finali in modo molto visibile.

3.8.6. Temi

Android fornisce i "temi" come meccanismo per consentire alle applicazioni di applicare stili a un'intera attività o applicazione.

Android include una famiglia di temi "Holo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono avere lo stesso aspetto e la stessa sensazione del tema Holo come definito dall'SDK Android [Risorse, 24]. Le implementazioni dei dispositivi NON DEVONO alterare nessuno degli attributi del tema Holo esposti alle applicazioni [Risorse, 25].

Android include anche una famiglia di temi "Predefinito del dispositivo" come insieme di stili definiti che gli sviluppatori di applicazioni possono utilizzare se vogliono abbinare l'aspetto del tema del dispositivo come definito dall'implementatore del dispositivo. Le implementazioni dei dispositivi POSSONO modificare gli attributi del tema DeviceDefault esposti alle applicazioni [Resources, 25].

A partire dalla versione 4.4, Android ora supporta un nuovo tema di variante con barre di sistema traslucide, consentendo agli sviluppatori di applicazioni di riempire l'area dietro la barra di stato e la barra di navigazione con i contenuti delle loro app. Per consentire un'esperienza coerente per gli sviluppatori in questa configurazione, è importante che lo stile delle icone della barra di stato venga mantenuto nelle diverse implementazioni dei dispositivi. Pertanto, le implementazioni dei dispositivi Android DEVONO utilizzare il bianco per le icone di stato del sistema (ad esempio l'intensità del segnale e il livello della batteria) e le notifiche emesse dal sistema, a meno che l'icona non indichi uno stato problematico [Risorse, 25].

3.8.7. Sfondi animati

Android definisce un tipo di componente e l'API e il ciclo di vita corrispondenti che consentono alle applicazioni di esporre uno o più "Sfondi animati" all'utente finale [Risorse, 26]. Gli sfondi animati sono animazioni, motivi o immagini simili con funzionalità di input limitate che vengono visualizzate come sfondo dietro altre applicazioni.

L'hardware è considerato in grado di eseguire in modo affidabile gli sfondi animati se può eseguire tutti gli sfondi animati, senza limitazioni alla funzionalità, a una frequenza frame ragionevole senza effetti negativi su altre applicazioni. Se le limitazioni dell'hardware causano arresti anomali di sfondi e/o applicazioni, malfunzionamenti, consumo eccessivo di CPU o batteria o funzionamento a frequenze fotogrammi inaccettabilmente basse, l'hardware è considerato incapace di eseguire lo sfondo animato. Ad esempio, alcuni sfondi animati potrebbero utilizzare un contesto Open GL 1.0 o 2.0 per eseguire il rendering dei contenuti. La funzionalità Sfondo animato non funziona in modo affidabile su hardware che non supporta più contesti OpenGL perché l'utilizzo di un contesto OpenGL da parte della funzionalità Sfondo animato potrebbe entrare in conflitto con altre applicazioni che utilizzano anche un contesto OpenGL.

Le implementazioni dei dispositivi in grado di eseguire in modo affidabile gli sfondi animati come descritto sopra DOVREBBERO implementare gli sfondi animati. Le implementazioni dei dispositivi che non eseguono gli sfondi animati in modo affidabile come descritto sopra NON DEVONO implementare gli sfondi animati.

3.8.8. Visualizzazione delle app recenti

Il codice sorgente di Android upstream include un'interfaccia utente per la visualizzazione delle applicazioni recenti utilizzando un'immagine in miniatura dello stato grafico dell'applicazione al momento dell'ultima uscita dell'utente dall'applicazione. Le implementazioni dei dispositivi POTREBBERO modificare o eliminare questa interfaccia utente. Tuttavia, è prevista una versione futura di Android che farà un uso più esteso di questa funzionalità. Le implementazioni dei dispositivi sono vivamente incoraggiate a utilizzare l'interfaccia utente Android upstream (o un'interfaccia basata su miniature simile) per le applicazioni recenti, altrimenti potrebbero non essere compatibili con una versione futura di Android.

3.8.9. Gestione dell'input

Android include il supporto per la gestione dell'input e per gli editor di metodi di immissione di terze parti. Le implementazioni dei dispositivi che consentono agli utenti di utilizzare metodi di inserimento di terze parti sul dispositivo DEVONO dichiarare la funzionalità della piattaformaandroid.software.input_methods e supportare le API IME come definito nella documentazione dell'SDK Android.

Le implementazioni dei dispositivi che dichiarano la funzionalità android.software.input_methods DEVONO fornire un meccanismo accessibile agli utenti per aggiungere e configurare metodi di immissione di terze parti. Le implementazioni dei dispositivi DEVONO mostrare l'interfaccia delle impostazioni in risposta all'intentandroid.settings.INPUT_METHOD_SETTINGS.

3.8.10. Telecomando per contenuti multimediali nella schermata di blocco

Android include il supporto dell'API Remote Control che consente alle applicazioni multimediali di integrarsi con i controlli di riproduzione visualizzati in una visualizzazione remota come la schermata di blocco del dispositivo [Risorse, 74]. Le implementazioni dei dispositivi che supportano la schermata di blocco nel dispositivo e consentono agli utenti di aggiungere widget nella schermata Home DEVONO includere il supporto per l'inserimento di telecomandi nella schermata di blocco del dispositivo [Risorse, 69].

3.8.11. Sogni

Android include il supporto per screensaver interattivi chiamati Sogni [Risorse, 76]. Dreams consente agli utenti di interagire con le applicazioni quando un dispositivo di ricarica è inattivo o agganciato alla base da tavolo. Le implementazioni dei dispositivi devono includere il supporto di Dreams e fornire un'opzione di impostazioni per consentire agli utenti di configurare Dreams.

3.8.12. Posizione

Le modalità di geolocalizzazione DEVONO essere visualizzate nel menu Posizione in Impostazioni [Risorse, 87]. I servizi di geolocalizzazione forniti tramite SettingInjectorService introdotti in Android 4.4 devono essere visualizzati nello stesso menu Posizione [Risorse, 89].

3.8.13. Unicode

Android 4.4 include il supporto dei caratteri emoji a colori. Le implementazioni dei dispositivi Android DEVONO fornire all'utente un metodo di inserimento per i caratteri emoji definiti in Unicode 6.1 [Risorse, 82] e DEVONO essere in grado di eseguire il rendering di questi caratteri emoji in un glifo a colori.

3.9. Amministrazione dispositivo

Android include funzionalità che consentono alle applicazioni sensibili alla sicurezza di eseguire funzioni di amministrazione del dispositivo a livello di sistema, ad esempio l'applicazione di criteri per le password o l'esecuzione di una cancellazione remota, tramite l'API Android Device Administration [Risorse, 27]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione della classe DevicePolicyManager [Risorse, 28]. Le implementazioni dei dispositivi che includono il supporto della schermata di blocco devono supportare l'intera gamma di criteri di amministrazione del dispositivo definiti nella documentazione dell'SDK Android [Risorse, 27].

Le implementazioni dei dispositivi POSSONO avere un'applicazione preinstallata che esegue funzioni di amministrazione del dispositivo, ma questa applicazione NON DEVE essere impostata come app Proprietario dispositivo predefinita [Risorse, 84].

3.10. Accessibilità

Android fornisce un livello di accessibilità che aiuta gli utenti con disabilità a navigare più facilmente sui loro dispositivi. Inoltre, Android fornisce API di piattaforma che consentono alle implementazioni dei servizi di accessibilità di ricevere callback per eventi utente e di sistema e di generare meccanismi di feedback alternativi, come la sintesi vocale, il feedback aptico e la navigazione con trackball/d-pad [Risorse, 29]. Le implementazioni dei dispositivi DEVONO fornire un'implementazione del framework di accessibilità di Android coerente con l'implementazione predefinita di Android. Nello specifico, le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti.

• Le implementazioni dei dispositivi DEVONO supportare le implementazioni di servizi di accessibilità di terze parti tramite le API android.accessibilityservice [Risorse, 30].
• Le implementazioni dei dispositivi DEVONO generare AccessibilityEvents e inviare questi eventi a tutte le implementazioni di AccessibilityService registrate in modo coerente con l'implementazione predefinita di Android.
• Le implementazioni dei dispositivi DEVONO fornire un meccanismo accessibile all'utente per attivare e disattivare i servizi di accessibilità e DEVONO mostrare questa interfaccia in risposta all'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Inoltre, le implementazioni dei dispositivi DEVONO fornire un'implementazione di un servizio di accessibilità sul dispositivo e DEVONO fornire un meccanismo per consentire agli utenti di attivare il servizio di accessibilità durante la configurazione del dispositivo. Un'implementazione open source di un servizio di accessibilità è disponibile nel progetto EyesFree [Risorse, 31].

3.11. Sintesi vocale

Android include API che consentono alle applicazioni di utilizzare i servizi di sintesi vocale (TTS) e ai fornitori di servizi di fornire implementazioni di questi servizi [Risorse, 32]. Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti relativi al framework Android TTS:

• Le implementazioni dei dispositivi DEVONO supportare le API del framework TTS di Android e DOVREBBERO includere un motore TTS che supporti le lingue disponibili sul dispositivo. Tieni presente che il software open source Android upstream include un'implementazione del motore TTS con funzionalità complete.
• Le implementazioni dei dispositivi DEVONO supportare l'installazione di motori TTS di terze parti.
• Le implementazioni dei dispositivi DEVONO fornire un'interfaccia accessibile agli utenti che consenta agli utenti di selezionare un motore TTS da utilizzare a livello di sistema.

4. Compatibilità con il pacchettizzazione delle applicazioni

Le implementazioni dei dispositivi DEVONO installare ed eseguire i file ".apk" di Android come generati dallo strumento "aapt" incluso nell'SDK Android ufficiale [Risorse, 33].

Le implementazioni dei dispositivi NON DEVONO estendere i file .apk [Risorse, 34], Android Manifest [Risorse, 35], bytecode Dalvik [Risorse, 17] o i formati bytecode di RenderScript in modo da impedire l'installazione e l'esecuzione corretta di questi file su altri dispositivi compatibili. Gli implementatori di dispositivi DEVONO utilizzare l'implementazione upstream di riferimento di Dalvik e il sistema di gestione dei pacchetti dell'implementazione di riferimento.

5. Compatibilità multimediale

Le implementazioni dei dispositivi DEVONO includere almeno una forma di uscita audio, ad esempio altoparlanti, jack per cuffie, connessione di altoparlanti esterni e così via.

5.1. Codec multimediali

Le implementazioni dei dispositivi DEVONO supportare i formati multimediali di base specificati nella documentazione dell'SDK Android [Risorse, 58], tranne ove consentito esplicitamente in questo documento. Nello specifico, le implementazioni dei dispositivi devono supportare i formati multimediali, gli encoder, i decodificatori, i tipi di file e i formati dei contenitori definiti nelle tabelle riportate di seguito. Tutti questi codec sono forniti come implementazioni software nell'implementazione Android preferita dell'Android Open Source Project.

Tieni presente che né Google né l'Open Handset Alliance dichiarano che questi codec sono esenti da brevetti di terze parti. Gli utenti che intendono utilizzare questo codice sorgente in prodotti hardware o software devono essere informati che le implementazioni di questo codice, incluso in software open source o shareware, potrebbero richiedere licenze di brevetto da parte dei relativi titolari.

Tieni presente che queste tabelle non elencano requisiti specifici per le larghezza di banda della maggior parte dei codec video perché l'hardware attuale dei dispositivi non supporta necessariamente larghezza di banda che corrispondono esattamente a quelle richieste specificate dagli standard pertinenti. Le implementazioni dei dispositivi DOVREBBERO supportare la massima velocità in bit possibile sull'hardware, fino ai limiti definiti dalle specifiche.

Digitazione	Formato / codec	Codificatore	Decoder	Dettagli	Tipi di file/formati contenitore
Audio	Profilo MPEG-4 AAC (AAC LC)	OBBLIGATORI per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC non compresso ADTS (.aac, decodifica in Android 3.1 e versioni successive, codifica in Android 4.0 e versioni successive, ADIF non supportato) MPEG-TS (.ts, non cercabile, Android 3.0 e versioni successive)
	Profilo MPEG-4 HE AAC (AAC+)	OBBLIGATORI per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone	OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 16 a 48 kHz.
	Profilo MPEG-4 HE AAC v2 (AAC+ migliorato)		OBBLIGATORIO	Supporto per contenuti mono/stereo/5.0/5.1* con frequenze di campionamento standard da 16 a 48 kHz.
	Tipo di oggetto audio MPEG-4 ER AAC ELD (Enhanced Low Delay AAC)	OBBLIGATORI per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone	OBBLIGATORIO	Supporto per contenuti mono/stereo con frequenze di campionamento standard da 16 a 48 kHz.
	AMR-NB	OBBLIGATORI per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	4,75-12,2 Kbps campionati a 8 kHz	3GPP (.3gp)
	AMR-WB	OBBLIGATORI per le implementazioni dei dispositivi che includono hardware per microfono e definiscono android.hardware.microphone.	OBBLIGATORIO	9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz	3GPP (.3gp)
	FLAC		OBBLIGATORI (Android 3.1 e versioni successive)	Mono/stereo (nessun multicanale). Frequenze di campionamento fino a 48 kHz (ma fino a 44,1 kHz è consigliata sui dispositivi con uscita a 44,1 kHz, poiché il campionatore giù da 48 a 44,1 kHz non include un filtro passa basso). Consigliati 16 bit; non viene applicato il dither per 24 bit.	Solo FLAC (.flac)
	MP3		OBBLIGATORIO	Mono/stereo 8-320 Kbps a velocità in bit costante (CBR) o variabile (VBR)	MP3 (.mp3)
	MIDI		OBBLIGATORIO	Tipo MIDI 0 e 1. Versioni 1 e 2 di DLS. XMF e Mobile XMF. Supporto per i formati delle sveglie RTTTL/RTX, OTA e iMelody	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		OBBLIGATORIO		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE	OBBLIGATORIO	OBBLIGATORIO	PCM lineare a 8 e 16 bit** (frequenze fino al limite dell'hardware).I dispositivi DEVONO supportare le frequenze di campionamento per la registrazione PCM non compressa a 8000,16000 e 44100 Hz	WAVE (.wav)
Immagine	JPEG	OBBLIGATORIO	OBBLIGATORIO	Base+progressiva	JPEG (.jpg)
	GIF		OBBLIGATORIO		GIF (.gif)
	PNG	OBBLIGATORIO	OBBLIGATORIO		PNG (.png)
	BMP		OBBLIGATORIO		BMP (.bmp)
	WebP	OBBLIGATORIO	OBBLIGATORIO		WebP (.webp)
Video	H.263	OBBLIGATORI per le implementazioni dei dispositivi che includono l'hardware della videocamera e definiscono android.hardware.camera o android.hardware.camera.front.	OBBLIGATORIO		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	OBBLIGATORI per le implementazioni dei dispositivi che includono l'hardware della videocamera e definiscono android.hardware.camera o android.hardware.camera.front.	OBBLIGATORIO	Profilo di riferimento (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, solo audio AAC, non cercabile, Android 3.0 e versioni successive)
	MPEG-4 SP		OBBLIGATORIO		3GPP (.3gp)
	VP8****	OBBLIGATORI (Android 4.3 e versioni successive)	OBBLIGATORI (Android 2.3.3 e versioni successive)		WebM (.webm) e Matroska (.mkv, Android 4.0 e versioni successive)***
	VP9		OBBLIGATORI (Android 4.4 e versioni successive)		WebM (.webm) e Matroska (.mkv, Android 4.0 e versioni successive)***

• *Nota: è richiesto solo il downmix dei contenuti 5.0/5.1; la registrazione o il rendering di più di 2 canali è facoltativo.
• **Nota: la registrazione PCM lineare a 16 bit è obbligatoria. La cattura PCM lineare a 8 bit non è obbligatoria.
• ***Nota: le implementazioni dei dispositivi DOVREBBERO supportare la scrittura di file Matroska WebM.
• ****Nota: per una qualità accettabile dei servizi di video streaming web e videoconferenza, le implementazioni dei dispositivi DEVONO utilizzare un codec VP8 hardware che soddisfi i requisiti riportati in [Risorse, 86].

5.2. Codifica video

Le implementazioni dei dispositivi Android che includono una fotocamera posteriore e dichiarano android.hardware.camera DEVONO supportare i seguenti profili di codifica video H.264.

	SD (bassa qualità)	SD (alta qualità)	HD (se supportato dall'hardware)
Risoluzione video	176 x 144 px	480 x 360 px	1280 x 720 px
Frequenza fotogrammi video	12 f/s	30 fps	30 fps
Velocità in bit video	56 Kbps	500 Kbps o superiore	2 Mbps o superiore
Codec audio	AAC-LC	AAC-LC	AAC-LC
Canali audio	1 (mono)	2 (stereo)	2 (stereo)
Velocità in bit audio	24 kbps	128 Kbps	192 kbps

Le implementazioni dei dispositivi Android che includono una fotocamera posteriore e dichiarano android.hardware.camera DEVONO supportare i seguenti profili di codifica video VP8

	SD (bassa qualità)	SD (alta qualità)	HD 720p (se supportato dall'hardware)	HD 1080p (se supportato dall'hardware)
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	800 kbps	2 Mbps	4 Mbps	10 Mbps

5.3. Decodifica video

Le implementazioni dei dispositivi Android DEVONO supportare i seguenti profili di decodifica video VP8, VP9 e H.264. Le implementazioni dei dispositivi DOVREBBERO supportare anche il passaggio dinamico della risoluzione video all'interno dello stesso stream per i codec VP8, VP9 e H.264.

	SD (bassa qualità)	SD (alta qualità)	HD 720p (se supportato dall'hardware)	HD 1080p (se supportato dall'hardware)
Risoluzione video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frequenza fotogrammi video	30 fps	30 fps	30 fps	30 fps
Velocità in bit video	800 kbps	2 Mbps	8 Mbps	20 Mbps

5.4. Registrazione audio

Quando un'applicazione ha utilizzato l'API android.media.AudioRecord per avviare la registrazione di uno stream audio, le implementazioni dei dispositivi che includono hardware per microfoni e dichiarano android.hardware.microphone DEVONO campionare e registrare l'audio con ciascuno di questi comportamenti:

• Il dispositivo DEVE presentare caratteristiche di ampiezza approssimativamente piatte rispetto alla frequenza; in particolare, ±3 dB, da 100 Hz a 4000 Hz
• La sensibilità di ingresso audio DEVE essere impostata in modo che una sorgente con un livello di potenza sonora (SPL) di 90 dB a 1000 Hz generi un valore RMS di 2500 per i campioni a 16 bit.
• I livelli di ampiezza PCM DEVONO seguire in modo lineare le variazioni di SPL in ingresso su almeno un intervallo di 30 dB da -18 dB a +12 dB rispetto a 90 dB SPL al microfono.
• La distorsione armonica totale DEVE essere inferiore all'1% per 1 KHz a un livello di ingresso di 90 dB SPL.

Oltre alle specifiche di registrazione riportate sopra, quando un'applicazione ha iniziato a registrare uno stream audio utilizzando l'origine audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• L'elaborazione di riduzione del rumore, se presente, DEVE essere disattivata.
• Il controllo automatico del guadagno, se presente, DEVE essere disattivato.

Da Android 4.4, la classe android.media.MediaRecorder.AudioSource ha una nuova fonte audio: REMOTE_SUBMIX. I dispositivi DEVONO implementare correttamente l'REMOTE_SUBMIX sorgente audio in modo che, quando un'applicazione utilizza l'API android.media.AudioRecord per registrare da questa sorgente audio, possa acquisire un mix di tutti gli stream audio, ad eccezione di quanto segue:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

Nota: anche se alcuni dei requisiti descritti sopra sono indicati come "DA FARE" da Android 4.3, è previsto di modificarli in "DA FARE OBBLIGATORIO" nella definizione di compatibilità per una versione futura. In altre parole, questi requisiti sono facoltativi in Android 4.4, ma saranno obbligatori in una versione futura. I dispositivi esistenti e nuovi che funzionano su Android sono vivamente invitati a soddisfare questi requisiti, altrimenti non potranno raggiungere la compatibilità con Android quando verrà eseguito l'upgrade alla versione futura.

Se la piattaforma supporta tecnologie di soppressione del rumore ottimizzate per il riconoscimento vocale, l'effetto DEVE essere controllabile dall'API android.media.audiofx.NoiseSuppressor. Inoltre, il campo "uuid" per il descrittore dell'effetto del riduttore del rumore DEVE identificare in modo univoco ogni implementazione della tecnologia di soppressione del rumore.

5.5. Latenza audio

La latenza audio è il ritardo temporale che si verifica quando un segnale audio passa attraverso un sistema. Molte classi di applicazioni si basano su latenze brevi per ottenere effetti sonori in tempo reale.

Ai fini di questa sezione:

• Per "latenza in uscita" si intende l'intervallo di tempo tra il momento in cui un'applicazione scrive un frame di dati codificati in PCM e il momento in cui l'audio corrispondente può essere ascoltato da un ascoltatore esterno o osservato da un trasduttore
• Per "latenza di output a freddo" si intende la latenza di output per il primo frame, quando il sistema di output audio è inattivo e spento prima della richiesta
• "latenza di output continua" è definita come la latenza di output per i frame successivi, dopo che il dispositivo sta già riproducendo l'audio
• "Latenza di input" è l'intervallo di tempo tra il momento in cui un suono esterno viene presentato al dispositivo e il momento in cui un'applicazione legge il frame corrispondente di dati codificati PCM
• Per "latenza di input a freddo" si intende la somma del tempo di input perso e della latenza di input per il primo frame, quando il sistema di input audio è inattivo e spento prima della richiesta
• "latenza di input continua" è definita come la latenza di input per i frame successivi, mentre il dispositivo sta già acquisendo l'audio
• "OpenSL ES PCM buffer queue API" è l'insieme di API OpenSL ES correlate al PCM all'interno di Android NDK; consulta NDK_root/docs/opensles/index.html

Ai sensi della Sezione 5, tutte le implementazioni di dispositivi compatibili DEVONO includere almeno una forma di uscita audio. Le implementazioni dei dispositivi DEVONO soddisfare o superare i seguenti requisiti di latenza di output:

• latenza di output a freddo di massimo 100 millisecondi
• latenza di uscita continua di massimo 45 millisecondi

Se l'implementazione di un dispositivo soddisfa i requisiti di questa sezione dopo la calibrazione iniziale quando si utilizza l'API OpenSL ES PCM buffer queue, per la latenza di uscita continua e la latenza di uscita a freddo su almeno un dispositivo di uscita audio supportato, PUÒ segnalare il supporto dell'audio a bassa latenza, registrando la funzionalità "android.hardware.audio.low-latency" tramite la classe android.content.pm.PackageManager. [Risorse, 37] Al contrario, se l'implementazione del dispositivo non soddisfa questi requisiti, NON DEVE segnalare il supporto dell'audio a bassa latenza.

Ai sensi della sezione 7.2.5, l'hardware del microfono può essere omesso dalle implementazioni del dispositivo.

Le implementazioni dei dispositivi che includono hardware per microfono e dichiarano android.hardware.microphone DEVONO soddisfare questi requisiti di latenza audio in ingresso:

• latenza di input a freddo di massimo 100 millisecondi
• latenza di input continua di massimo 50 millisecondi

5.6. Protocolli di rete

I dispositivi DEVONO supportare i protocolli della rete multimediale per la riproduzione di audio e video come specificato nella documentazione dell'SDK Android [Risorse, 58]. Nello specifico, i dispositivi DEVONO supportare i seguenti protocolli di rete multimediale:

• RTSP (RTP, SDP)
• Streaming progressivo HTTP(S)
• HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]

6. Compatibilità di Strumenti per sviluppatori e Opzioni sviluppatori

6.1. Strumenti per sviluppatori

Le implementazioni dei dispositivi DEVONO supportare gli Android Developer Tools forniti nell'SDK Android. Nello specifico, i dispositivi compatibili con Android DEVONO essere compatibili con:

• Android Debug Bridge (noto come adb) [Risorse, 33]
  Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android. Il daemon adb lato dispositivo DEVE essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
• Android include il supporto per adb sicuro. adb sicuro attiva adb su host autenticati noti. Le implementazioni dei dispositivi DEVONO supportare adb sicuro.
• Dalvik Debug Monitor Service (noto come ddms) [Risorse, 33]
  Le implementazioni dei dispositivi DEVONO supportare tutte le funzionalità ddms come descritte nell'SDK Android. Poiché ddms utilizza adb, il supporto di ddms DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere supportato ogni volta che l'utente ha attivato Android Debug Bridge, come sopra.
• Monkey [Risorse, 36]
  Le implementazioni del dispositivo DEVONO includere il framework Monkey e metterlo a disposizione delle applicazioni.
• SysTrace [Risorse, 33]
  Le implementazioni del dispositivo DEVONO supportare lo strumento systrace come documentato nell'SDK Android. Systrace deve essere inattivo per impostazione predefinita e DEVE essere presente un meccanismo accessibile all'utente per attivarlo.

La maggior parte dei sistemi basati su Linux e dei sistemi Apple Macintosh riconosce i dispositivi Android utilizzando gli strumenti SDK Android standard, senza ulteriore supporto. Tuttavia, i sistemi Microsoft Windows in genere richiedono un driver per i nuovi dispositivi Android. Ad esempio, i nuovi ID fornitore e a volte i nuovi ID dispositivo richiedono driver USB personalizzati per i sistemi Windows. Se un'implementazione del dispositivo non è riconosciuta dallo strumento adb fornito nell'SDK Android standard, gli implementatori del dispositivo DEVONO fornire i driver Windows che consentono agli sviluppatori di connettersi al dispositivo utilizzando il protocollo adb. Questi driver DEVONO essere forniti per Windows XP, Windows Vista, Windows 7 e Windows 8, sia nelle versioni a 32 bit sia in quelle a 64 bit.

6.2. Opzioni sviluppatore

Android include il supporto per la configurazione delle impostazioni relative allo sviluppo delle applicazioni. Le implementazioni dei dispositivi DEVONO rispettare l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS per mostrare le impostazioni relative allo sviluppo delle applicazioni [Risorse, 77]. L'implementazione di Android upstream nasconde il menu Opzioni sviluppatore per impostazione predefinita e consente agli utenti di avviare le Opzioni sviluppatore dopo aver premuto sette (7) volte la voce di menu Impostazioni > Informazioni sul dispositivo > Numero build. Le implementazioni dei dispositivi DEVONO fornire un'esperienza coerente per le Opzioni sviluppatore. Nello specifico, le implementazioni dei dispositivi DEVONO nascondere le Opzioni sviluppatore per impostazione predefinita e DEVONO fornire un meccanismo per attivarle che sia coerente con l'implementazione di Android a monte.

6.2.1. Sperimentale

Android 4.4 introduce ART, un runtime Android sperimentale, accessibile come anteprima nel menu Opzioni sviluppatore. Le implementazioni del dispositivo DEVONO includere ART (libart.so) e supportare il dual boot dalle Opzioni sviluppatore, ma DEVONO mantenere Dalvik (libdvm.so) come runtime predefinito.

7. Compatibilità hardware

Se un dispositivo include un determinato componente hardware con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non dispone di questo componente:

• le definizioni di classi complete (come documentato dall'SDK) per le API del componente DEVONO essere ancora presenti
• I comportamenti dell'API DEVONO essere implementati come no-op in modo ragionevole
• I metodi dell'API DEVONO restituire valori null se consentito dalla documentazione dell'SDK
• I metodi API DEVONO restituire implementazioni no-op delle classi in cui i valori null non sono consentiti dalla documentazione dell'SDK
• I metodi dell'API NON DEVONO generare eccezioni non documentate dalla documentazione dell'SDK.

Un esempio tipico di uno scenario in cui si applicano questi requisiti è l'API di telefonia: anche su dispositivi diversi dagli smartphone, queste API devono essere implementate come no-op ragionevoli.

Le implementazioni dei dispositivi DEVONO segnalare con precisione informazioni sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager. [Resources, 37]

7.1. Display e grafica

Android include funzionalità che regolano automaticamente gli asset e i layout dell'interfaccia utente dell'applicazione in base al dispositivo, per garantire il corretto funzionamento delle applicazioni di terze parti su una serie di configurazioni hardware [Risorse, 38]. I dispositivi DEVONO implementare correttamente queste API e questi comportamenti, come descritto in questa sezione.

Le unità a cui fanno riferimento i requisiti in questa sezione sono definite come segue:

• Per "dimensioni diagonali fisiche" si intende la distanza in pollici tra due angoli opposti della parte illuminata del display.
• "DPI" (che significa "punti per pollice") indica il numero di pixel inclusi in un intervallo lineare orizzontale o verticale di 1". Se sono elencati i valori dpi, sia il dpi orizzontale sia quello verticale devono rientrare nell'intervallo.
• "Proporzioni" indica il rapporto tra la dimensione più lunga dello schermo e la dimensione più corta. Ad esempio, un display di 480 x 854 pixel corrisponde a 854 / 480 = 1,779, ovvero circa "16:9".
• Un "pixel indipendente dalla densità" ("dp") è l'unità di pixel virtuale normalizzata a un schermo di 160 dpi, calcolata come: pixels = dps * (density / 160).

7.1.1. Configurazione schermo

Dimensioni schermo

Il framework UI di Android supporta una serie di dimensioni dello schermo diverse e consente alle applicazioni di eseguire query sulle dimensioni dello schermo del dispositivo (ovvero "layout dello schermo") tramite android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Le implementazioni dei dispositivi DEVONO segnalare le dimensioni dello schermo corrette come definite nella documentazione dell'SDK Android [Risorse, 38] e determinate dalla piattaforma Android a monte. Nello specifico, le implementazioni dei dispositivi devono segnalare le dimensioni dello schermo corrette in base alle seguenti dimensioni dello schermo in pixel indipendenti dalla densità (dp) logiche.

• I dispositivi DEVONO avere dimensioni dello schermo di almeno 426 dp x 320 dp ("piccolo")
• I dispositivi che segnalano dimensioni dello schermo "normali" DEVONO avere dimensioni dello schermo di almeno 480 dp x 320 dp
• I dispositivi che segnalano dimensioni dello schermo "grandi" DEVONO avere dimensioni dello schermo di almeno 640 dp x 480 dp
• I dispositivi che segnalano dimensioni dello schermo "Molto grande" DEVONO avere dimensioni dello schermo di almeno 960 dp x 720 dp

Inoltre, i dispositivi DEVONO avere dimensioni dello schermo di almeno 6,35 cm di diagonale fisica.

I dispositivi NON DEVONO modificare le dimensioni dello schermo registrate in nessun momento.

Le applicazioni possono indicare facoltativamente le dimensioni dello schermo supportate tramite l'attributo <supports-screens> nel file AndroidManifest.xml. Le implementazioni dei dispositivi DEVONO rispettare correttamente il supporto dichiarato dalle applicazioni per schermi piccoli, normali, grandi e molto grandi, come descritto nella documentazione dell'SDK Android.

Proporzioni dello schermo

Le proporzioni DEVONO essere un valore compreso tra 1,3333 (4:3) e 1,86 (circa 16:9)

Densità schermo

Il framework dell'interfaccia utente di Android definisce un insieme di densità logiche standard per aiutare gli sviluppatori di applicazioni a scegliere come target le risorse dell'applicazione. Le implementazioni dei dispositivi DEVONO segnalare una delle seguenti densità del framework Android logico tramite le API android.util.DisplayMetrics e DEVONO eseguire le applicazioni a questa densità standard.

• 120 dpi, noto come "ldpi"
• 160 dpi, noti come "mdpi"
• 213 dpi, noto come "tvdpi"
• 240 dpi, noto come "hdpi"
• 320 dpi, noto come "xhdpi"
• 400 dpi, noto come "400dpi"
• 480 dpi, noto come "xxhdpi"
• 640 dpi, noto come "xxxhdpi"

Le implementazioni dei dispositivi DEVONO definire la densità del framework Android standard più vicina numericamente alla densità fisica dello schermo, a meno che questa densità logica non riduca le dimensioni dello schermo registrate al di sotto del minimo supportato. Se la densità del framework Android standard più vicina numericamente alla densità fisica genera dimensioni dello schermo inferiori alle dimensioni dello schermo compatibili supportate più piccole (larghezza di 320 dp), le implementazioni del dispositivo DEVONO registrare la densità del framework Android standard successiva più bassa.

7.1.2. Metriche relative alla visualizzazione

Le implementazioni dei dispositivi DEVONO riportare valori corretti per tutte le metriche di visualizzazione definite in android.util.DisplayMetrics [Risorse, 39].

7.1.3. Orientamento schermo

I dispositivi DEVONO supportare l'orientamento dinamico delle applicazioni per l'orientamento dello schermo in verticale o in orizzontale. In altre parole, il dispositivo deve violare la richiesta dell'applicazione di un orientamento dello schermo specifico. Le implementazioni dei dispositivi POSSONO selezionare l'orientamento verticale o orizzontale come valore predefinito.

I dispositivi DEVONO riportare il valore corretto per l'orientamento corrente del dispositivo, ogni volta che viene eseguito una query tramite android.content.res.Configuration.orientation, android.view.Display.getOrientation() o altre API.

I dispositivi NON DEVONO modificare le dimensioni o la densità dello schermo registrate quando si cambia orientamento.

I dispositivi DEVONO indicare gli orientamenti dello schermo supportati (android.hardware.screen.portrait e/oandroid.hardware.screen.landscape) e DEVONO indicare almeno un orientamento supportato. Ad esempio, un dispositivo con uno schermo in orientamento orizzontale fisso, come una televisione o un laptop, DEVE segnalare solo android.hardware.screen.landscape.

7.1.4. Accelerazione grafica 2D e 3D

Le implementazioni dei dispositivi DEVONO supportare sia OpenGL ES 1.0 sia 2.0, come descritto e dettagliato nella documentazione dell'SDK Android. Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 3.0 sui dispositivi in grado di supportare OpenGL ES 3.0. Le implementazioni dei dispositivi DEVONO supportare anche Android Renderscript, come descritto nella documentazione dell'SDK Android [Risorse, 8].

Le implementazioni dei dispositivi DEVONO anche identificarsi correttamente come supportanti OpenGL ES 1.0, OpenGL ES 2.0 o OpenGL ES 3.0. ovvero:

• Le API gestite (ad esempio tramite il metodo GLES10.getString()) devono segnalare il supporto di OpenGL ES 1.0 e OpenGL ES 2.0
• Le API OpenGL native C/C++ (ovvero quelle disponibili per le app tramite libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEVONO segnalare il supporto per OpenGL ES 1.0 e OpenGL ES 2.0.
• Le implementazioni dei dispositivi che dichiarano il supporto di OpenGL ES 3.0 DEVONO supportare le API gestite OpenGL ES 3.0 e includere il supporto per le API C/C++ native. Nelle implementazioni sul dispositivo che dichiarano il supporto di OpenGL ES 3.0, libGLESv2.so DEVE esportare i simboli delle funzioni OpenGL ES 3.0 oltre ai simboli delle funzioni OpenGL ES 2.0.

Le implementazioni dei dispositivi POSSONO implementare le estensioni OpenGL ES desiderate. Tuttavia, le implementazioni dei dispositivi DEVONO segnalare tramite le API native e gestite OpenGL ES tutte le stringhe di estensione supportate e, al contrario, NON DEVONO segnalare le stringhe di estensione non supportate.

Tieni presente che Android include il supporto per le applicazioni che possono optionally specificare che richiedono formati di compressione delle texture OpenGL specifici. Questi formati sono in genere specifici del fornitore. Android non richiede l'implementazione di formati di compressione delle texture specifici per le implementazioni dei dispositivi. Tuttavia, devono segnalare con precisione tutti i formati di compressione delle texture supportati tramite il metodo getString() nell'API OpenGL.

Android include un meccanismo per consentire alle applicazioni di dichiarare di voler attivare l'accelerazione hardware per la grafica 2D a livello di applicazione, attività, finestra o visualizzazione tramite l'utilizzo di un tag manifestandroid:hardwareAccelerated o di chiamate API dirette [Risorse, 9].

In Android 4.4, le implementazioni dei dispositivi DEVONO attivare l'accelerazione hardware per impostazione predefinita e DEVONO disattivarla se lo richiede lo sviluppatore impostando android:hardwareAccelerated="false" o disattivando l'accelerazione hardware direttamente tramite le API Android View.

Inoltre, le implementazioni dei dispositivi DEVONO avere un comportamento coerente con la documentazione dell'SDK Android sull'accelerazione hardware [Risorse, 9].

Android include un oggetto TextureView che consente agli sviluppatori di integrare direttamente le texture OpenGL ES con accelerazione hardware come target di rendering in una gerarchia dell'interfaccia utente. Le implementazioni dei dispositivi DEVONO supportare l'API TextureView e DEVONO avere un comportamento coerente con l'implementazione di Android di upstream.

Android include il supporto di EGL_ANDROID_RECORDABLE, un attributo EGLConfig che indica se EGLConfig supporta il rendering in un'ANativeWindow che registra le immagini in un video. Le implementazioni dei dispositivi DEVONO supportare l'estensione EGL_ANDROID_RECORDABLE [Risorse, 79].

7.1.5. Modalità di compatibilità delle applicazioni precedenti

Android specifica una "modalità di compatibilità" in cui il framework opera in una modalità equivalente a dimensioni dello schermo "normali" (larghezza di 320 dp) a vantaggio delle applicazioni precedenti non sviluppate per le versioni precedenti di Android che risalgono a prima dell'indipendenza dalle dimensioni dello schermo. Le implementazioni dei dispositivi DEVONO includere il supporto della modalità di compatibilità delle applicazioni legacy come implementata dal codice open source Android upstream. In altre parole, le implementazioni dei dispositivi NON DEVONO modificare gli attivatori o le soglie a cui viene attivata la modalità di compatibilità e NON DEVONO modificare il comportamento della modalità di compatibilità stessa.

7.1.6. Tipi di schermo

Le schermate di implementazione del dispositivo sono classificate in due tipi:

• Implementazioni di display con pixel fissi: lo schermo è un singolo pannello che supporta solo una larghezza e un'altezza di un singolo pixel. In genere, lo schermo è integrato fisicamente con il dispositivo. Alcuni esempi sono cellulari, tablet e così via.
• Implementazioni di display con pixel variabili: l'implementazione del dispositivo non ha uno schermo integrato e include una porta di uscita video come VGA, HDMI o una porta wireless per il display oppure ha uno schermo integrato che può modificare le dimensioni dei pixel. Alcuni esempi sono televisioni, decoder e così via.

Implementazioni di dispositivi con pixel fissi

Le implementazioni di dispositivi con pixel fissi POSSONO utilizzare schermi di qualsiasi dimensione di pixel, a condizione che soddisfino i requisiti definiti in questa definizione di compatibilità.

Le implementazioni con pixel fissi POTREBBERO includere una porta di uscita video da utilizzare con un display esterno. Tuttavia, se il display viene utilizzato per eseguire app, il dispositivo DEVE soddisfare i seguenti requisiti:

• Il dispositivo DEVE riportare le stesse metriche di configurazione e visualizzazione dello schermo, come descritto nelle sezioni 7.1.1 e 7.1.2, del display a pixel fissi.
• Il dispositivo DEVE riportare la stessa densità logica del display a pixel fissi.
• Il dispositivo DEVE segnalare dimensioni dello schermo uguali o molto simili a quelle del display a pixel fissi.

Ad esempio, un tablet con una diagonale di 7" e una risoluzione di 1024 x 600 pixel è considerato un'implementazione di display mdpi di grandi dimensioni con pixel fissi. Se contiene una porta di output video che mostra a 720p o 1080p, l'implementazione del dispositivo DEVE scalare l'output in modo che le applicazioni vengano eseguite solo in una finestra mdpi di grandi dimensioni, indipendentemente dal fatto che sia in uso il display con pixel fissi o la porta di output video.

Implementazioni di dispositivi con pixel variabili

Le implementazioni dei dispositivi con pixel variabili DEVONO supportare almeno una delle risoluzioni 1280x720, 1920x1080 o 3840x2160 (ovvero 720p, 1080p o 4K). Le implementazioni dei dispositivi con display a pixel variabili NON DEVONO supportare altre configurazioni o modalità dello schermo. Le implementazioni dei dispositivi con schermi a pixel variabili POTREBBERO modificare la configurazione o la modalità dello schermo in fase di esecuzione o di avvio. Ad esempio, un utente di un set-top box potrebbe sostituire un display a 720p con uno a 1080p e l'implementazione del dispositivo potrebbe essere modificata di conseguenza.

Inoltre, le implementazioni dei dispositivi con pixel variabili DEVONO registrare i seguenti bucket di configurazione per queste dimensioni dei pixel:

• 1280 x 720 (noto anche come 720p): dimensioni dello schermo "grandi", densità "tvdpi" (213 dpi)
• 1920 x 1080 (noto anche come 1080p): dimensioni dello schermo "grandi", intensità "xhdpi" (320 dpi)
• 3840 x 2160 (noto anche come 4K): dimensioni dello schermo "grandi", densità "xxxhdpi" (640 dpi)

Per chiarezza, le implementazioni dei dispositivi con dimensioni dei pixel variabili sono limitate a 720p, 1080p o 4K in Android 4.4 e DEVONO essere configurate per segnalare i bucket di dimensioni e densità dello schermo come indicato sopra.

7.1.7. Tecnologia dello schermo

La piattaforma Android include API che consentono alle applicazioni di eseguire il rendering di grafica avanzata sul display. I dispositivi DEVONO supportare tutte queste API come definite dall'SDK Android, a meno che non sia specificamente consentito in questo documento. Nello specifico:

• I dispositivi DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 16 bit e DEVONO supportare display in grado di eseguire il rendering di grafica a colori a 24 bit.
• I dispositivi DEVONO supportare display in grado di eseguire il rendering delle animazioni.
• La tecnologia di visualizzazione utilizzata DEVE avere un rapporto di aspetto dei pixel (PAR) compreso tra 0,9 e 1,1. In altre parole, le proporzioni dei pixel DEVONO essere quasi quadrate (1,0) con una tolleranza del 10%.

7.1.8. Display esterni

Android include il supporto per il display secondario per abilitare le funzionalità di condivisione dei contenuti multimediali e le API per sviluppatori per accedere ai display esterni. Se un dispositivo supporta un display esterno tramite una connessione con cavo, wireless o un display aggiuntivo incorporato, l'implementazione del dispositivo DEVE implementare l'API Display Manager come descritto nella documentazione dell'SDK Android [Risorse, 75]. Le implementazioni dei dispositivi che supportano l'uscita video sicura e sono in grado di supportare le piattaforme sicure DEVONO dichiarare il supporto per Display.FLAG_SECURE. Nello specifico, le implementazioni dei dispositivi che dichiarano il supporto di Display.FLAG_SECURE devono supportare HDCP 2.x o versioni successive per i display wireless Miracast o HDCP 1.2 o versioni successive per i display con cavo. L'implementazione open source di Android upstream include il supporto per i display wireless (Miracast) e con cavo (HDMI) che soddisfano questo requisito.

7.2. Dispositivi di immissione

7.2.1. Tastiera

Implementazioni dei dispositivi:

• DEVE includere il supporto per il framework di gestione dell'input (che consente agli sviluppatori di terze parti di creare motori di gestione dell'input, ad esempio la tastiera virtuale) come descritto all'indirizzo http://developer.android.com
• DEVE fornire almeno un'implementazione di tastiera virtuale (indipendentemente dal fatto che sia presente o meno una tastiera fisica)
• POTREBBE includere implementazioni aggiuntive della tastiera su schermo
• POTREBBE includere una tastiera hardware
• NON DEVE includere una tastiera hardware che non corrisponde a uno dei formati specificati in android.content.res.Configuration.keyboard [Risorse, 40] (ovvero QWERTY o 12 tasti)

7.2.2. Navigazione non tocco

Implementazioni dei dispositivi:

• PUO' omettere un'opzione di navigazione non tocco (ad es. un trackball, un d-pad o un cursore)
• DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Resources, 40]
• DEVE fornire un meccanismo di interfaccia utente alternativo ragionevole per la selezione e la modifica del testo, compatibile con i motori di gestione dell'input. L'implementazione open source di Android upstream include un meccanismo di selezione adatto all'uso con i dispositivi che non dispongono di input di navigazione non touch.

7.2.3. Tasti di navigazione

Le funzioni Home, Recenti e Indietro sono essenziali per il paradigma di navigazione di Android. Le implementazioni dei dispositivi DEVONO rendere queste funzioni disponibili all'utente in qualsiasi momento durante l'esecuzione delle applicazioni. Queste funzioni POSSONO essere implementate tramite pulsanti fisici dedicati (ad esempio pulsanti touch meccanici o capacitivi) o POSSONO essere implementate utilizzando chiavi software dedicate in una parte distinta dello schermo, gesti, pannello touch e così via. Android supporta entrambe le implementazioni. Tutte queste funzioni DEVONO essere accessibili con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili.

Le funzioni Indietro e App recenti DEVONO avere un pulsante o un'icona visibili, a meno che non siano nascoste insieme ad altre funzioni di navigazione in modalità a schermo intero. La funzione Casa DEVE avere un pulsante o un'icona visibile, a meno che non sia nascosta insieme ad altre funzioni di navigazione in modalità a schermo intero.

La funzione Menu è stata ritirata a favore della barra delle app da Android 4.0. Le implementazioni del dispositivo NON DEVONO implementare un pulsante fisico dedicato per la funzione Menu. Se il pulsante Menu fisico è implementato e il dispositivo esegue applicazioni con targetSdkVersion > 10, l'implementazione del dispositivo:

• Per un dispositivo lanciato con Android 4.4, DEVE mostrare il pulsante del menu extra di azioni sulla barra delle azioni quando questa è visibile e il popup del menu extra di azioni risultante non è vuoto.
• Per un dispositivo esistente lanciato con una versione precedente, ma con upgrade ad Android 4.4, DOVREBBE essere visualizzato il pulsante del menu extra azioni nella barra delle azioni quando la barra delle azioni è visibile e il menu popup del menu extra azioni risultante non è vuoto.
• NON DEVE modificare la posizione del popup del menu extra delle azioni visualizzato selezionando il pulsante del menu extra nella barra delle azioni.
• POTREBBE visualizzare il popup di overflow delle azioni in una posizione modificata sullo schermo quando viene visualizzato selezionando il pulsante del menu fisico.

Per la compatibilità con le versioni precedenti, le implementazioni dei dispositivi DEVONO rendere disponibile la funzione Menu per le applicazioni quando targetSdkVersion <= 10, tramite un pulsante fisico, un tasto software o gesti. Questa funzione Menu deve essere presentata, a meno che non sia nascosta insieme ad altre funzioni di navigazione.

Android supporta l'azione Assist [Risorse, 63]. Le implementazioni dei dispositivi DEVONO rendere l'azione di assistenza disponibile all'utente in qualsiasi momento durante l'esecuzione delle applicazioni. L'azione di assistenza DEVE essere implementata come pulsante premuto a lungo sul pulsante Home o un gesto di scorrimento verso l'alto sul tasto Home software. Questa funzione PUÒ essere implementata tramite un altro pulsante fisico, un tasto software o gesti, ma DEVE essere accessibile con una singola azione (ad es. tocco, doppio clic o gesto) quando sono visibili altri tasti di navigazione.

Le implementazioni dei dispositivi POSSONO utilizzare una parte distinta dello schermo per visualizzare i tasti di navigazione, ma in questo caso DEVONO soddisfare i seguenti requisiti:

• I tasti di navigazione per l'implementazione del dispositivo DEVONO utilizzare una parte distinta dello schermo, non disponibile per le applicazioni, e NON DEVONO coprire o interferire in altro modo con la parte dello schermo disponibile per le applicazioni.
• Le implementazioni dei dispositivi DEVONO rendere disponibile una parte del display per le applicazioni che soddisfano i requisiti definiti nella sezione 7.1.1.
• Le implementazioni dei dispositivi DEVONO mostrare i tasti di navigazione quando le applicazioni non specificano una modalità dell'interfaccia utente di sistema o specificano SYSTEM_UI_FLAG_VISIBLE.
• Le implementazioni dei dispositivi DEVONO presentare i tasti di navigazione in una modalità "a basso profilo" (ad es. attenuata) non invadente quando le applicazioni specificano SYSTEM_UI_FLAG_LOW_PROFILE.
• Le implementazioni dei dispositivi DEVONO nascondere i tasti di navigazione quando le applicazioni specificano SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Input touchscreen

Le implementazioni dei dispositivi DEVONO avere un sistema di input del cursore di qualche tipo (simile a un mouse o tocco). Tuttavia, se l'implementazione di un dispositivo non supporta un sistema di input del cursore, NON DEVE segnalare la costante di funzionalità android.hardware.touchscreen o android.hardware.faketouch. Implementazioni di dispositivi che includono un sistema di input del cursore:

• DOVREBBE supportare cursori monitorati in modo completamente indipendente, se il sistema di input del dispositivo supporta più cursori
• DEVE riportare il valore di android.content.res.Configuration.touchscreen [Resources, 40] corrispondente al tipo di touchscreen specifico sul dispositivo

Android include il supporto di una serie di touch screen, touchpad e dispositivi di input touch falsi. Le implementazioni dei dispositivi basati su touchscreen sono associate a un display [Risorse, 81] in modo che l'utente abbia l'impressione di manipolare direttamente gli elementi sullo schermo. Poiché l'utente tocca direttamente lo schermo, il sistema non richiede funzionalità aggiuntive per indicare gli oggetti manipolati. Al contrario, un'interfaccia tocco falsa fornisce un sistema di input utente che approssima un sottoinsieme di funzionalità del touchscreen. Ad esempio, un mouse o un telecomando che gestisce un cursore sullo schermo si avvicina al tocco, ma richiede all'utente di prima selezionare o mettere a fuoco un elemento e poi fare clic. Numerosi dispositivi di input come mouse, trackpad, mouse aereo basato su giroscopio, cursore a giroscopio, joystick e trackpad multi-touch possono supportare interazioni touch false. Android 4.0 include la costante di funzionalità android.hardware.faketouch, che corrisponde a un dispositivo di input non touch (ovvero basato su cursore) ad alta fedeltà, come un mouse o un trackpad, che può emulare adeguatamente l'input basato su tocco (incluso il supporto di gesti di base) e indica che il dispositivo supporta un sottoinsieme emulato delle funzionalità del touchscreen. Le implementazioni dei dispositivi che dichiarano la funzionalità di tocco falso DEVONO soddisfare i requisiti di tocco falso descritti nella sezione 7.2.5.

Le implementazioni dei dispositivi DEVONO segnalare la funzionalità corretta corrispondente al tipo di input utilizzato. Le implementazioni dei dispositivi che includono un touchscreen (single-touch o superiore) DEVONO segnalare la costante della funzionalità della piattaforma android.hardware.touchscreen. Le implementazioni dei dispositivi che segnalano la costante della funzionalità della piattaforma android.hardware.touchscreen DEVONO segnalare anche la costante della funzionalità della piattaformaandroid.hardware.faketouch. Le implementazioni dei dispositivi che non includono un touchscreen (e si basano solo su un dispositivo di puntamento) NON DEVONO segnalare alcuna funzionalità del touchscreen e DEVONO segnalare solo android.hardware.faketouch se soddisfano i requisiti relativi ai tocchi falsi descritti nella Sezione 7.2.5.

7.2.5. Input tocco simulato

Implementazioni dei dispositivi che dichiarano il supporto di android.hardware.faketouch

• DEVE segnalare le posizioni X e Y assolute dello schermo della posizione del cursore e mostrare un cursore visivo sullo schermo [Risorse, 80]
• È OBBLIGATORIO registrare l'evento tocco con il codice azione [Risorse, 80] che specifica la modifica dello stato che si verifica quando il cursore diventa down o up sullo schermo [Risorse, 80]
• DEVE supportare i cursori down e up su un oggetto sullo schermo, il che consente agli utenti di emulare il tocco di un oggetto sullo schermo
• DEVE supportare il cursore down, il cursore up, il cursore down e poi il cursore up nello stesso punto su un oggetto sullo schermo entro una soglia di tempo, che consente agli utenti di emulare il doppio tocco su un oggetto sullo schermo [Risorse, 80]
• DEVE supportare il cursore down su un punto arbitrario dello schermo, il cursore si sposta in un altro punto arbitrario dello schermo, seguito da un cursore up, che consente agli utenti di emulare un trascinamento con tocco
• DEVE supportare il cursore down, quindi consentire agli utenti di spostare rapidamente l'oggetto in un'altra posizione sullo schermo e poi il cursore up sullo schermo, che consente agli utenti di lanciare un oggetto sullo schermo

I dispositivi che dichiarano il supporto di android.hardware.faketouch.multitouch.distinct DEVONO soddisfare i requisiti per il controllo simulato sopra indicati e DEVONO anche supportare il monitoraggio distinto di due o più input del cursore indipendenti.

7.2.6. Microfono

Le implementazioni dei dispositivi POSSONO omettere un microfono. Tuttavia, se l'implementazione di un dispositivo omette un microfono, NON DEVE segnalare la costante della funzionalità android.hardware.microphone e deve implementare l'API di registrazione audio come no-op, come indicato nella Sezione 7. Al contrario, le implementazioni dei dispositivi che dispongono di un microfono:

• DEVE segnalare la costante della funzionalità android.hardware.microphone
• DEVE soddisfare i requisiti di qualità audio descritti nella sezione 5.4
• DEVE soddisfare i requisiti di latenza audio descritti nella sezione 5.5

7.3. Sensori

Android include API per accedere a diversi tipi di sensori. Le implementazioni dei dispositivi in genere POSSONO omettere questi sensori, come previsto nelle seguenti sezioni. Se un dispositivo include un determinato tipo di sensore con un'API corrispondente per gli sviluppatori di terze parti, l'implementazione del dispositivo DEVE implementare l'API come descritto nella documentazione dell'SDK Android. Ad esempio, implementazioni dei dispositivi:

• DEVE segnalare con precisione la presenza o l'assenza di sensori in base alla classe android.content.pm.PackageManager. [Resources, 37]
• DEVE restituire un elenco accurato dei sensori supportati tramite metodiSensorManager.getSensorList() e simili
• DEVE comportarsi in modo ragionevole per tutte le altre API di sensori (ad esempio, deve restituire true o false a seconda dei casi quando le applicazioni tentano di registrare gli ascoltatori, non deve chiamare gli ascoltatori dei sensori quando i sensori corrispondenti non sono presenti e così via).
• DEVE segnalare tutte le misurazioni dei sensori utilizzando i valori pertinenti del Sistema internazionale di unità di misura (ovvero metrico) per ogni tipo di sensore come definito nella documentazione dell'SDK Android [Risorse, 41]

L'elenco riportato sopra non è esaustivo; il comportamento documentato dell'SDK Android deve essere considerato autorevole.

Alcuni tipi di sensori sono sintetici, il che significa che possono essere ricavati dai dati forniti da uno o più altri sensori. Alcuni esempi sono il sensore di orientamento e il sensore di accelerazione lineare. Le implementazioni dei dispositivi DEVONO implementare questi tipi di sensori, se includono i sensori fisici prerequisiti.

Android include il concetto di sensore "in streaming", ovvero un sensore che restituisce dati continuamente, anziché solo quando i dati cambiano. Le implementazioni dei dispositivi DEVONO fornire continuamente campioni di dati periodici per qualsiasi API indicata dalla documentazione dell'SDK Android come sensore in streaming. Tieni presente che le implementazioni del dispositivo DEVONO garantire che lo stream del sensore non impedisca alla CPU del dispositivo di entrare in uno stato di sospensione o di risvegliarsi da uno stato di sospensione.

7.3.1. Accelerometro

Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un accelerometro a 3 assi:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 120 Hz. Tieni presente che, sebbene la frequenza dell'accelerometro sopra indicata sia indicata come "DEVE" per Android 4.4, la definizione di compatibilità per una versione futura prevede di modificarla in "DEVE". In altre parole, questi standard sono facoltativi in Android, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi con Android sono vivamente invitati a soddisfare questi requisiti in Android per poter eseguire l'upgrade alle release future della piattaforma
• DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android (vedi [Risorse, 41])
• DEVE essere in grado di misurare dalla caduta libera fino al doppio della gravità (2 g) o più su qualsiasi vettore tridimensionale
• DEVE avere un'accuratezza di almeno 8 bit
• DEVE avere una deviazione standard non superiore a 0,05 m/s^2

7.3.2. Magnetometro

Le implementazioni dei dispositivi DEVONO includere un magnetometro a 3 assi (ad es. una bussola). Se un dispositivo include un magnetometro a 3 assi:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 10 Hz
• DEVE essere conforme al sistema di coordinate del sensore Android come descritto nelle API Android (vedi [Risorse, 41]).
• DEVE essere in grado di campionare un intervallo di intensitù di campo adeguato per coprire il campo geomagnetico
• DEVE avere un'accuratezza di almeno 8 bit
• DEVE avere una deviazione standard non superiore a 0,5 µT

7.3.3. GPS

Le implementazioni dei dispositivi DEVONO includere un ricevitore GPS. Se l'implementazione di un dispositivo include un ricevitore GPS, DEVE includere qualche forma di tecnica "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.

7.3.4. Giroscopio

Le implementazioni dei dispositivi DEVONO includere un giroscopio (ovvero un sensore di variazione angolare). I dispositivi NON DEVONO includere un sensore giroscopio, a meno che non sia incluso anche un accelerometro a 3 assi. Se l'implementazione di un dispositivo include un giroscopio:

• DEVE essere compensato in base alla temperatura.
• DEVE essere in grado di misurare le variazioni di orientamento fino a 5,5*Pi radianti/secondo (ovvero circa 1000 gradi al secondo).
• DEVE essere in grado di inviare eventi a una frequenza di almeno 200 Hz. Tieni presente che, sebbene la frequenza del giroscopio riportata sopra sia indicata come "DEVE" per Android 4.4, la definizione di compatibilità per una versione futura prevede di modificarla in "DEVE". In altre parole, questi standard sono facoltativi in Android, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi che utilizzano Android sono vivamente invitati a soddisfare questi requisiti per poter eseguire l'upgrade alle release future della piattaforma.
• DEVE avere una precisione di 12 bit o superiore
• DEVE avere una varianza non superiore a 1e-7 rad^2 / s^2 per Hz (varianza per Hz o rad^2 / s). La varianza può variare con la frequenza di campionamento, ma deve essere vincolata da questo valore. In altre parole, se misuri la varianza del giroscopio a una frequenza di campionamento di 1 Hz, non deve essere superiore a 1e-7 rad^2/s^2.
• DEVONO avere timestamp il più vicino possibile al momento in cui si è verificato l'evento hardware. La latenza costante deve essere rimossa.

7.3.5. Barometro

Le implementazioni dei dispositivi POSSONO includere un barometro (ovvero un sensore di pressione dell'aria ambiente). Se un'implementazione del dispositivo include un barometro:

• DEVE essere in grado di inviare eventi a una frequenza di almeno 5 Hz
• DEVE avere una precisione adeguata per consentire la stima dell'altitudine
• DEVE essere compensato in base alla temperatura

7.3.6. Termometro

Le implementazioni dei dispositivi POSSONO includere un termometro ambiente (ovvero un sensore di temperatura). Se presente, DEVE essere definito come SENSOR_TYPE_AMBIENT_TEMPERATURE e DEVE misurare la temperatura ambiente (della stanza) in gradi Celsius.

Le implementazioni dei dispositivi POSSONO, ma NON DEVONO, includere un sensore di temperatura della CPU. Se presente, DEVE essere definito come SENSOR_TYPE_TEMPERATURE, DEVE misurare la temperatura della CPU del dispositivo e NON DEVE misurare altre temperature. Tieni presente che il tipo di sensore SENSOR_TYPE_TEMPERATURE è stato ritirato in Android 4.0.

7.3.7. Fotometro

Le implementazioni dei dispositivi POSSONO includere un fotometro (ovvero un sensore di luce ambientale).

7.3.8. Sensore di prossimità

Le implementazioni del dispositivo POSSONO includere un sensore di prossimità. Se l'implementazione di un dispositivo include un sensore di prossimità, DEVE misurare la vicinanza di un oggetto nella stessa direzione dello schermo. In altre parole, il sensore di prossimità DEVE essere orientato in modo da rilevare gli oggetti vicini allo schermo, poiché lo scopo principale di questo tipo di sensore è rilevare uno smartphone in uso dall'utente. Se l'implementazione di un dispositivo include un sensore di prossimità con un altro orientamento, NON DEVE essere accessibile tramite questa API. Se un'implementazione del dispositivo ha un sensore di prossimità, DEVE avere una precisione di almeno 1 bit.

7.4. Connettività dei dati

7.4.1. Telefonia

"Telefonia", come utilizzato dalle API Android e in questo documento, fa riferimento specificamente all'hardware relativo all'invio di chiamate vocali e di messaggi SMS tramite una rete GSM o CDMA. Sebbene queste chiamate vocali possano o meno essere basate su protocollo di commutazione di pacchetti, ai fini di Android sono considerate indipendenti da qualsiasi connettività dati che possa essere implementata utilizzando la stessa rete. In altre parole, le API e la funzionalità "telefonia" di Android fanno riferimento specificamente alle chiamate vocali e agli SMS. Ad esempio, le implementazioni dei dispositivi che non possono effettuare chiamate o inviare/ricevere messaggi SMS NON DEVONO segnalare la funzionalità "android.hardware.telephony" o eventuali sottofunzionalità, indipendentemente dal fatto che utilizzino una rete cellulare per la connettività dati.

Android PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android è compatibile con dispositivi diversi dagli smartphone. Tuttavia, se l'implementazione di un dispositivo include la telefonia GSM o CDMA, deve implementare il supporto completo dell'API per quella tecnologia. Le implementazioni di dispositivi che non includono hardware di telefonia DEVONO implementare le API complete come no-op.

7.4.2. IEEE 802.11 (Wi-Fi)

Le implementazioni dei dispositivi Android DEVONO includere il supporto di una o più forme di 802.11 (b/g/a/n e così via). Se l'implementazione di un dispositivo include il supporto per 802.11, DEVE implementare l'API Android corrispondente.

Le implementazioni dei dispositivi DEVONO implementare l'API multicast come descritto nella documentazione dell'SDK [Risorse, 62]. Le implementazioni dei dispositivi che includono il supporto Wi-Fi DEVONO supportare il DNS multicast (mDNS). Le implementazioni dei dispositivi NON DEVONO filtrare i pacchetti mDNS (224.0.0.251) in nessun momento di funzionamento, anche quando lo schermo non è attivo.

7.4.2.1. Wi-Fi Direct

Le implementazioni dei dispositivi DEVONO includere il supporto del Wi-Fi Direct (Wi-Fi peer-to-peer). Se l'implementazione di un dispositivo include il supporto del Wi-Fi Direct, DEVE implementare l'API Android corrispondente come descritto nella documentazione dell'SDK [Risorse, 68]. Se l'implementazione di un dispositivo include il supporto di Wi-Fi Direct, il dispositivo:

• DEVE supportare il normale funzionamento del Wi-Fi
• DEVE supportare il funzionamento simultaneo del Wi-Fi e di Wi-Fi Direct

7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi

Le implementazioni dei dispositivi DEVONO includere il supporto della configurazione del link diretto in tunnel Wi-Fi (TDLS) come descritto nella documentazione dell'SDK Android [Risorse, 85]. Se l'implementazione di un dispositivo include il supporto di TDLS e TDLS è abilitato dall'API WiFiManager, il dispositivo:

• DEVI utilizzare TDLS solo quando è possibile E utile.
• DOVREBBE avere qualche euristica e NON utilizzare TDLS quando il suo rendimento potrebbe essere peggiore rispetto al passaggio tramite il punto di accesso Wi-Fi.

7.4.3. Bluetooth

Le implementazioni dei dispositivi DEVONO includere un trasmettitore Bluetooth. Le implementazioni dei dispositivi che includono un transceiver Bluetooth DEVONO attivare l'API Bluetooth basata su RFCOMM come descritto nella documentazione dell'SDK e dichiarare la funzionalità hardware android.hardware.bluetooth [Risorse, 42]. Le implementazioni dei dispositivi DOVREBBERO implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX e così via, come appropriato per il dispositivo.

Le implementazioni dei dispositivi che includono il supporto di Bluetooth GATT (Generic Attribute Profile) per abilitare la comunicazione con dispositivi Bluetooth Smart o Smart Ready DEVONO attivare l'API Bluetooth basata su GATT come descritto nella documentazione dell'SDK e dichiarare la funzionalità hardware android.hardware.bluetooth_le [Risorse, 42].

7.4.4. Near Field Communication

Le implementazioni dei dispositivi DEVONO includere un transceiver e hardware correlato per le comunicazioni NFC (Near Field Communication). Se l'implementazione di un dispositivo include hardware NFC, deve:

• DEVE segnalare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37]
• DEVE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC:
  • DEVE essere in grado di agire come lettore/scrittore NFC Forum (come definito dalla specifica tecnica del NFC Forum NFCForum-TS-DigitalProtocol-1.0) tramite i seguenti standard NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • Tipi di tag NFC Forum 1, 2, 3, 4 (definiti dal NFC Forum)
• DOVREBBE essere in grado di leggere e scrivere messaggi NDEF tramite i seguenti standard NFC. Tieni presente che, sebbene gli standard NFC riportati di seguito siano indicati come "DA", è previsto di sostituirli con "DEVE" nella definizione di compatibilità di una versione futura. In altre parole, questi standard sono facoltativi in questa versione, ma saranno obbligatori nelle versioni future. I dispositivi esistenti e nuovi che eseguono questa versione di Android sono vivamente invitati a soddisfare questi requisiti ora per poter eseguire l'upgrade alle future release della piattaforma.
  • NfcV (ISO 15693)
• DEVE essere in grado di trasmettere e ricevere dati tramite i seguenti standard e protocolli peer-to-peer:
  • ISO 18092
  • LLCP 1.0 (definito dal NFC Forum)
  • SDP 1.0 (definito dal NFC Forum)
  • Protocollo NDEF Push [Risorse, 43]
  • SNEP 1.0 (definito dal NFC Forum)
• DEVE includere il supporto di Android Beam [Risorse, 65]:
  • DEVE implementare il server SNEP predefinito. I messaggi NDEF validi ricevuti dal server SNEP predefinito DEVONO essere inviati alle applicazioni che utilizzano l'intent android.nfc.ACTION_NDEF_DISCOVERED. La disattivazione di Android Beam nelle impostazioni NON DEVE disattivare l'invio del messaggio NDEF in arrivo.
  • Le implementazioni dei dispositivi DEVONO rispettare l'intent android.settings.NFCSHARING_SETTINGS per mostrare le impostazioni di condivisione NFC [Risorse, 67].
  • DEVE implementare il server NPP. I messaggi ricevuti dal server NPP DEVONO essere elaborati allo stesso modo del server SNEP predefinito.
  • DEVE implementare un client SNEP e tentare di inviare NDEF P2P in uscita al server SNEP predefinito quando Android Beam è abilitato. Se non viene trovato alcun server SNEP predefinito, il client DEVE tentare di inviare a un server NPP.
  • DEVE consentire alle attività in primo piano di impostare il messaggio NDEF P2P in uscita utilizzando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
  • DOVREBBE utilizzare un gesto o una conferma sullo schermo, ad esempio "Tocca per trasmettere", prima di inviare messaggi NDEF P2P in uscita.
  • DOVREBBE attivare Android Beam per impostazione predefinita
  • DEVE supportare il trasferimento della connessione NFC al Bluetooth quando il dispositivo supporta il profilo Bluetooth Object Push. Le implementazioni dei dispositivi devono supportare il trasferimento della connessione al Bluetooth quando si utilizza android.nfc.NfcAdapter.setBeamPushUris, implementando le specifiche "Connection Handover version 1.2" [Risorse, 60] e "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Risorse, 61] del NFC Forum. Una simile implementazione DEVE implementare il servizio LLCP di trasferimento con il nome di servizio "urn:nfc:sn:handover" per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC e DEVE utilizzare il profilo Bluetooth Object Push per il trasferimento effettivo dei dati Bluetooth. Per motivi di compatibilità con i dispositivi Android 4.1, l'implementazione DOVREBBE comunque accettare le richieste GET SNEP per lo scambio della richiesta di trasferimento/seleziona i record tramite NFC. Tuttavia, un'implementazione stessa NON DEVE inviare richieste GET SNEP per eseguire il trasferimento della connessione.
• DEVE eseguire il polling per tutte le tecnologie supportate in modalità di rilevamento NFC.
• DOVREBBE essere in modalità di rilevamento NFC quando il dispositivo è attivo con lo schermo attivo e la schermata di blocco sbloccata.

Tieni presente che i link disponibili pubblicamente non sono disponibili per le specifiche JIS, ISO e NFC Forum citate sopra.

Android 4.4 introduce il supporto della modalità NFC Host Card Emulation (HCE). Se un'implementazione del dispositivo include un controller NFC in grado di gestire il routing HCE e AID (Application ID), deve:

• DEVE segnalare la costante della funzionalità android.hardware.nfc.hce
• DEVE supportare le API NFC HCE come definite nell'SDK Android [Risorse, 90]

Inoltre, le implementazioni dei dispositivi POSSONO includere il supporto di lettori/scrittori per le seguenti tecnologie MIFARE.

• MIFARE Classic (NXP MF1S503x [Risorse, 44], MF1S703x [Risorse, 45])
• MIFARE Ultralight (NXP MF0ICU1 [Risorse, 46], MF0ICU2 [Risorse, 47])
• NDEF su MIFARE Classic (NXP AN130511 [Risorse, 48], AN130411 [Risorse, 49])

Tieni presente che Android include le API per questi tipi di MIFARE. Se un'implementazione del dispositivo supporta MIFARE nel ruolo di lettore/scrittore:

• DEVE implementare le API Android corrispondenti come documentato dall'SDK Android
• DEVE segnalare la funzionalità com.nxp.mifare dal metodo android.content.pm.PackageManager.hasSystemFeature(). [Risorse, 37] Tieni presente che questa non è una funzionalità Android standard e, pertanto, non viene visualizzata come costante nella classe PackageManager.
• NON DEVE implementare le API Android corrispondenti né segnalare la funzionalità com.nxp.mifare, a meno che non implementi anche il supporto NFC generale come descritto in questa sezione

Se l'implementazione di un dispositivo non include hardware NFC, NON deve dichiarare la funzionalità android.hardware.nfc dal metodo android.content.pm.PackageManager.hasSystemFeature() [Resources, 37] e DEVE implementare l'API NFC di Android come no-op.

Poiché le classi android.nfc.NdefMessage e android.nfc.NdefRecord rappresentano un formato di rappresentazione dei dati indipendente dal protocollo, le implementazioni dei dispositivi DEVONO implementare queste API anche se non includono il supporto per NFC o dichiarano la funzionalità android.hardware.nfc.

7.4.5. Capacità di rete minima

Le implementazioni dei dispositivi DEVONO includere il supporto di una o più forme di reti di dati. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati in grado di supportare una velocità di 200 Kbit/s o superiore. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g, Ethernet e così via.

Le implementazioni dei dispositivi in cui uno standard di rete fisica (ad esempio Ethernet) è la connessione dati principale DEVONO includere anche il supporto di almeno uno standard di dati wireless comune, come 802.11 (Wi-Fi).

I dispositivi POSSONO implementare più di una forma di connettività dati.

7.4.6. Impostazioni sincronizzazione

Le implementazioni dei dispositivi DEVONO avere l'impostazione di sincronizzazione automatica principale attiva per impostazione predefinita in modo che il metodo getMasterSyncAutomatically() restituisca "true" [Resources, 88].

7.5. Fotocamere

Le implementazioni dei dispositivi DOVREBBERO includere una fotocamera posteriore e POTREBBERO includere una fotocamera anteriore. Una fotocamera posteriore è una fotocamera situata sul lato opposto al display del dispositivo, ovvero acquisisce le immagini sul lato opposto del dispositivo, come una fotocamera tradizionale. Una fotocamera anteriore è una fotocamera collocata sullo stesso lato del dispositivo del display, ovvero una fotocamera in genere utilizzata per acquisire immagini dell'utente, ad esempio per videoconferenze e applicazioni simili.

7.5.1. Fotocamera posteriore

Le implementazioni dei dispositivi DEVONO includere una fotocamera posteriore. Se l'implementazione di un dispositivo include una fotocamera posteriore, deve:

• DEVE avere una risoluzione di almeno 2 megapixel
• DEVE avere l'autofocus hardware o l'autofocus software implementato nel driver della fotocamera (trasparente al software dell'applicazione)
• POTREBBE avere hardware con messa a fuoco fissa o EDOF (profondità di campo estesa)
• PUO' includere un flash. Se la fotocamera include un flash, la spia del flash NON deve essere accesa mentre è stata registrata un'istanza di android.hardware.Camera.PreviewCallback su una superficie di anteprima della fotocamera, a meno che l'applicazione non abbia attivato esplicitamente il flash attivando gli attributi FLASH_MODE_AUTO o FLASH_MODE_ON di un oggetto Camera.Parameters. Tieni presente che questo vincolo non si applica all'applicazione della fotocamera di sistema integrata del dispositivo, ma solo alle applicazioni di terze parti che utilizzano Camera.PreviewCallback.

7.5.2. Fotocamera anteriore

Le implementazioni dei dispositivi POSSONO includere una fotocamera anteriore. Se l'implementazione di un dispositivo include una fotocamera anteriore:

• DEVE avere una risoluzione di almeno VGA (ovvero 640 x 480 pixel)
• NON DEVE utilizzare una fotocamera anteriore come predefinita per l'API Camera. In altre parole, l'API della fotocamera in Android ha un supporto specifico per le fotocamere anteriori e le implementazioni dei dispositivi NON DEVONO configurare l'API in modo da trattare una fotocamera anteriore come fotocamera posteriore predefinita, anche se è l'unica fotocamera sul dispositivo.
• PUO' includere funzionalità (come messa a fuoco automatica, flash e così via) disponibili per le fotocamere posteriori come descritto nella Sezione 7.5.1.
• DEVE riflettere orizzontalmente (ovvero rispecchiare) lo stream visualizzato da un'app in CameraPreview, come segue:
• Se l'implementazione del dispositivo può essere ruotata dall'utente (ad esempio automaticamente tramite un accelerometro o manualmente tramite l'input dell'utente), l'anteprima della fotocamera DEVE essere speculare orizzontalmente rispetto all'orientamento corrente del dispositivo.
• Se l'applicazione corrente ha richiesto esplicitamente la rotazione del display della fotocamera tramite una chiamata al metodo android.hardware.Camera.setDisplayOrientation() [Resources, 50], l'anteprima della fotocamera DEVE essere specchiata orizzontalmente rispetto all'orientamento specificato dall'applicazione.
• In caso contrario, l'anteprima DEVE essere speculare rispetto all'asse orizzontale predefinito del dispositivo.
• DEVE rispecchiare l'immagine visualizzata dalla visualizzazione post nello stesso modo dello stream di immagini dell'anteprima della fotocamera. Se l'implementazione del dispositivo non supporta la postview, questo requisito ovviamente non si applica.
• NON DEVE rispecchiare gli stream di video o immagini acquisiti finali restituiti ai callback dell'applicazione o sottoposti a commit nello spazio di archiviazione multimediale

7.5.3. Comportamento dell'API Camera

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alla fotocamera, sia per le fotocamere anteriori che posteriori:

1. Se un'applicazione non ha mai chiamato android.hardware.Camera.Parameters.setPreviewFormat(int), il dispositivo DEVE utilizzare android.hardware.PixelFormat.YCbCr_420_SP per i dati di anteprima forniti ai callback dell'applicazione.
2. Se un'applicazione registra un'istanza android.hardware.Camera.PreviewCallback e il sistema chiama il metodo onPreviewFrame() quando il formato di anteprima è YCbCr_420_SP, i dati in byte[] passati a onPreviewFrame() devono essere inoltre nel formato di codifica NV21. In altre parole, NV21 DEVE essere il valore predefinito.
3. Le implementazioni dei dispositivi DEVONO supportare il formato YV12 (come indicato dalla costante android.graphics.ImageFormat.YV12) per le anteprime della fotocamera sia per le fotocamere anteriori che posteriori. L'encoder video hardware e la fotocamera possono utilizzare qualsiasi formato pixel nativo, ma l'implementazione del dispositivo DEVE supportare la conversione in YV12.

Le implementazioni dei dispositivi DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android [Risorse, 51], indipendentemente dal fatto che il dispositivo includa l'autofocus hardware o altre funzionalità. Ad esempio, le videocamere prive di messa a fuoco automatica DEVONO comunque chiamare eventuali istanze android.hardware.Camera.AutoFocusCallback registrate (anche se questo non ha alcuna rilevanza per una videocamera senza messa a fuoco automatica). Tieni presente che questo vale anche per le fotocamere anteriori. Ad esempio, anche se la maggior parte delle fotocamere anteriori non supporta la messa a fuoco automatica, i callback dell'API devono comunque essere "falsi" come descritto.

Le implementazioni dei dispositivi DEVONO riconoscere e rispettare ogni nome di parametro definito come costante nella classe android.hardware.Camera.Parameters, se l'hardware di base supporta la funzionalità. Se l'hardware del dispositivo non supporta una funzionalità, l'API deve comportarsi come descritto nella documentazione. Al contrario, le implementazioni del dispositivo NON DEVONO rispettare o riconoscere le costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri della fotocamera standard se il hardware lo consente e NON DEVONO supportare i tipi di parametri della fotocamera personalizzati. Ad esempio, le implementazioni dei dispositivi che supportano l'acquisizione di immagini utilizzando tecniche di imaging HDR (High Dynamic Range) DEVONO supportare il parametro della videocamera Camera.SCENE_MODE_HDR [Risorse, 78]).

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_PICTURE ogni volta che la fotocamera scatta una nuova foto e la voce della foto è stata aggiunta al media store.

Le implementazioni dei dispositivi DEVONO trasmettere l'intent Camera.ACTION_NEW_VIDEO ogni volta che la videocamera registra un nuovo video e l'elemento della foto è stato aggiunto al media store.

7.5.4. Orientamento della fotocamera

Entrambe le fotocamere anteriori e posteriori, se presenti, DEVONO essere orientate in modo che la dimensione lunga della fotocamera sia allineata alla dimensione lunga dello schermo. ovvero, quando il dispositivo è tenuto in orizzontale, le fotocamere DEVONO acquisire le immagini in orizzontale. Questo vale indipendentemente dall'orientamento naturale del dispositivo, ovvero si applica ai dispositivi con orientamento principale orizzontale e verticale.

7.6. Memoria e spazio di archiviazione

7.6.1. Memoria e spazio di archiviazione minimi

Le implementazioni dei dispositivi DEVONO avere almeno 340 MB di memoria a disposizione per il kernel e lo spazio utente. I 340 MB DEVONO essere aggiuntivi rispetto alla memoria dedicata ai componenti hardware come radio, video e così via che non sono sotto il controllo del kernel.

Le implementazioni dei dispositivi con meno di 512 MB di memoria a disposizione del kernel e dello spazio utente DEVONO restituire il valore "true" per ActivityManager.isLowRamDevice().

Le implementazioni dei dispositivi DEVONO avere almeno 1 GB di spazio di archiviazione non volatile disponibile per i dati privati dell'applicazione. In altre parole, la partizione /data DEVE essere di almeno 1 GB. Le implementazioni dei dispositivi che eseguono Android sono vivamente incoraggiate a avere almeno 2 GB di spazio di archiviazione non volatile per i dati privati delle applicazioni in modo da poter eseguire l'upgrade alle release future della piattaforma.

Le API Android includono un gestore dei download che le applicazioni possono utilizzare per scaricare file di dati [Risorse, 56]. L'implementazione del gestore dei download sul dispositivo DEVE essere in grado di scaricare singoli file di dimensioni pari o superiori a 100 MB nella posizione predefinita "cache".

7.6.2. Spazio di archiviazione esterno condiviso

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni. Lo spazio di archiviazione condiviso fornito DEVE avere una dimensione di almeno 1 GB.

Le implementazioni dei dispositivi DEVONO essere configurate con lo spazio di archiviazione condiviso montato per impostazione predefinita, "out of the box". Se lo spazio di archiviazione condiviso non è montato sul percorso /sdcard di Linux, il dispositivo DEVE includere un link simbolico Linux da /sdcard al punto di montaggio effettivo.

Le implementazioni dei dispositivi DEVONO applicare l'autorizzazione android.permission.WRITE_EXTERNAL_STORAGE su questo spazio di archiviazione condiviso come descritto nella documentazione. In caso contrario, lo spazio di archiviazione condiviso DEVE essere scrivibile da qualsiasi applicazione che ottiene l'autorizzazione.

Le implementazioni dei dispositivi POSSONO avere hardware per lo spazio di archiviazione rimovibile accessibile all'utente, ad esempio una scheda Secure Digital. In alternativa, le implementazioni dei dispositivi possono allocare lo spazio di archiviazione interno (non rimovibile) come spazio di archiviazione condiviso per le app. Il progetto Android Open Source upstream include un'implementazione che utilizza lo spazio di archiviazione interno del dispositivo per le API di archiviazione esterna condivisa. Le implementazioni del dispositivo DEVONO utilizzare questa configurazione e implementazione software.

Indipendentemente dalla forma di archiviazione condivisa utilizzata, le implementazioni dei dispositivi DEVONO fornire un qualche meccanismo per accedere ai contenuti dell'archiviazione condivisa da un computer host, ad esempio archiviazione di massa USB (UMS) o Media Transfer Protocol (MTP). Le implementazioni dei dispositivi POSSONO utilizzare l'archiviazione di massa USB, ma DEVONO utilizzare il protocollo Media Transfer. Se l'implementazione del dispositivo supporta il Media Transfer Protocol:

• L'implementazione del dispositivo DEVE essere compatibile con l'host MTP Android di riferimento, Android File Transfer [Risorse, 57].
• L'implementazione del dispositivo DEVE segnalare una classe di dispositivo USB pari a 0x00.
• L'implementazione del dispositivo DEVE riportare un nome dell'interfaccia USB di "MTP".

Se l'implementazione del dispositivo non dispone di porte USB, DEVE fornire a un computer host l'accesso ai contenuti dello spazio di archiviazione condiviso con altri mezzi, ad esempio un file system di rete.

È utile considerare due esempi comuni. Se l'implementazione di un dispositivo include uno slot per schede SD per soddisfare il requisito di archiviazione condivisa, È OBBLIGATORIO includere una scheda SD formattata FAT di almeno 1 GB con il dispositivo venduto agli utenti e deve essere montata per impostazione predefinita. In alternativa, se l'implementazione di un dispositivo utilizza spazio di archiviazione interno fisso per soddisfare questo requisito, lo spazio di archiviazione DEVE avere una dimensione minima di 1 GB e essere montato su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è montato altrove).

Le implementazioni dei dispositivi che includono più percorsi di archiviazione condivisi (ad esempio un attacco per schede SD e uno spazio di archiviazione interno condiviso) NON DEVONO consentire alle applicazioni Android di scrivere nello spazio di archiviazione esterno secondario, ad eccezione delle directory specifiche del pacchetto nello spazio di archiviazione esterno secondario, ma DEVONO esporre i contenuti di entrambi i percorsi di archiviazione in modo trasparente tramite il servizio di scansione multimediale di Android e android.provider.MediaStore.

7.7. USB

Le implementazioni dei dispositivi DEVONO includere una porta client USB e DEVONO includere una porta host USB.

Se l'implementazione di un dispositivo include una porta client USB:

• La porta DEVE essere connettibile a un host USB con una porta USB-A standard
• la porta DEVE utilizzare il fattore di forma micro USB sul lato del dispositivo. I dispositivi esistenti e nuovi con Android sono vivamente invitati a soddisfare questi requisiti in Android per poter eseguire l'upgrade alle release future della piattaforma
• La porta DEVE essere centrata al centro di un bordo. Le implementazioni del dispositivo DEVONO collocare la porta nella parte inferiore del dispositivo (in base all'orientamento naturale) o attivare la rotazione dello schermo software per tutte le app (inclusa la schermata Home), in modo che il display venga visualizzato correttamente quando il dispositivo è orientato con la porta in basso. I dispositivi esistenti e nuovi che utilizzano Android sono molto fortemente invitati a soddisfare questi requisiti in Android per poter eseguire l'upgrade alle release future della piattaforma.
• se il dispositivo ha altre porte (ad esempio una porta di ricarica non USB), DEVONO trovarsi sullo stesso lato della porta micro-USB
• DEVE consentire a un host connesso al dispositivo di accedere ai contenuti del volume dello spazio di archiviazione condiviso utilizzando l'archiviazione di massa USB o il protocollo Media Transfer
• DEVE implementare l'API e le specifiche di Android Open Accessory come descritto nella documentazione dell'SDK Android e DEVE dichiarare il supporto della funzionalità hardwareandroid.hardware.usb.accessory [Risorse, 52]
• DEVE implementare la classe audio USB come descritto nella documentazione dell'SDK Android [Risorse, 66]
• DEVE implementare il supporto per la specifica di ricarica della batteria USB [Risorse, 64] I dispositivi esistenti e nuovi con Android sono vivamente incoraggiati a soddisfare questi requisiti in modo da poter eseguire l'upgrade alle future release della piattaforma
• Il valore di iSerialNumber nel descrittore del dispositivo standard USB DEVE essere uguale al valore di android.os.Build.SERIAL.

Se l'implementazione di un dispositivo include una porta host USB:

• Può utilizzare un fattore di forma della porta non standard, ma in questo caso DEVE essere fornito con un cavo o cavi che adattano la porta a USB-A standard
• DEVE implementare l'API host USB Android come descritto nell'SDK Android e DEVE dichiarare il supporto della funzionalità hardwareandroid.hardware.usb.host [Risorse, 53]

Le implementazioni dei dispositivi DEVONO implementare Android Debug Bridge. Se l'implementazione di un dispositivo omette una porta client USB, DEVE implementare il ponte di debug Android tramite una rete locale (ad esempio Ethernet o 802.11).

8. Compatibilità con il rendimento

Le implementazioni dei dispositivi DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo compatibile con Android, definite nella tabella seguente:

Metrica	Soglia di rendimento	Commenti
Ora di lancio dell'applicazione	Le seguenti applicazioni devono essere lanciate entro il periodo di tempo specificato. Browser: meno di 1300 ms Contatti: meno di 700 ms Impostazioni: meno di 700 ms	Il tempo di lancio viene misurato come tempo totale necessario per completare il caricamento dell'attività predefinita per l'applicazione, incluso il tempo necessario per avviare il processo Linux, caricare il pacchetto Android nella VM Dalvik e chiamare onCreate.
Applicazioni simultanee	Quando sono state avviate più applicazioni, il riavvio di un'applicazione già in esecuzione dopo l'avvio deve richiedere meno tempo rispetto al tempo di avvio originale.

9. Compatibilità del modello di sicurezza

Le implementazioni dei dispositivi DEVONO implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android, come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 54] della documentazione per gli sviluppatori Android. Le implementazioni dei dispositivi DEVONO supportare l'installazione di applicazioni con firma autografa senza richiedere autorizzazioni/certificati aggiuntivi da parte di terze parti/autorità. Nello specifico, i dispositivi compatibili DEVONO supportare i meccanismi di sicurezza descritti nelle seguenti sottosezioni.

9.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni Android come definito nella documentazione per gli sviluppatori Android [Risorse, 54]. Nello specifico, le implementazioni DEVONO applicare ogni autorizzazione definita come descritto nella documentazione dell'SDK. Nessuna autorizzazione può essere omessa, modificata o ignorata. Le implementazioni POSSONO aggiungere autorizzazioni aggiuntive, a condizione che le nuove stringhe ID autorizzazione non siano nello spazio dei nomi android.*.

9.2. Isolamento UID e dei processi

Le implementazioni dei dispositivi DEVONO supportare il modello di sandbox delle applicazioni Android, in cui ogni applicazione viene eseguita come UID di tipo Unix univoco e in un processo distinto. Le implementazioni dei dispositivi DEVONO supportare l'esecuzione di più applicazioni come lo stesso ID utente Linux, a condizione che le applicazioni siano correttamente firmate e costruite, come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 54].

9.3. Autorizzazioni del file system

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di accesso ai file di Android come definito nella documentazione di riferimento Sicurezza e autorizzazioni [Risorse, 54].

9.4. Ambienti di esecuzione alternativi

Le implementazioni dei dispositivi POSSONO includere ambienti di runtime che eseguono applicazioni utilizzando un altro software o tecnologia rispetto alla macchina virtuale Dalvik o al codice nativo. Tuttavia, questi ambienti di esecuzione alternativi NON DEVONO compromettere il modello di sicurezza di Android o la sicurezza delle applicazioni Android installate, come descritto in questa sezione.

I runtime alternativi DEVONO essere applicazioni Android e rispettare il modello di sicurezza Android standard, come descritto altrove nella Sezione 9.

Ai runtime alternativi NON DEVE essere concesso l'accesso alle risorse protette da autorizzazioni non richieste nel file AndroidManifest.xml del runtime tramite il meccanismo <uses-permission>.

I runtime alternativi NON DEVONO consentire alle applicazioni di utilizzare funzionalità protette dalle autorizzazioni Android limitate alle applicazioni di sistema.

I runtime alternativi DEVONO rispettare il modello di sandbox di Android. Nello specifico:

• I runtime alternativi DOVREBBERO installare le app tramite PackageManager in sandbox Android separate (ovvero ID utente Linux e così via).
• I runtime alternativi POSSONO fornire una singola sandbox Android condivisa da tutte le applicazioni che li utilizzano
• I runtime alternativi e le applicazioni installate che utilizzano un runtime alternativo NON DEVONO riutilizzare la sandbox di qualsiasi altra app installata sul dispositivo, tranne che tramite i meccanismi standard di Android per l'ID utente e il certificato di firma condivisi
• I runtime alternativi NON DEVONO essere avviati con, concedere o ricevere accesso alle sandbox corrispondenti ad altre applicazioni Android

I runtime alternativi NON DEVONO essere avviati con, concessi o concessi ad altre applicazioni eventuali privilegi del superutente (root) o di qualsiasi altro ID utente.

I file APK dei runtime alternativi POSSONO essere inclusi nell'immagine di sistema di un'implementazione del dispositivo, ma DEVONO essere firmati con una chiave diversa da quella utilizzata per firmare altre applicazioni incluse nell'implementazione del dispositivo.

Quando installi le applicazioni, i runtime alternativi DEVONO ottenere il consenso dell'utente per le autorizzazioni Android utilizzate dall'applicazione. In altre parole, se un'applicazione deve utilizzare una risorsa del dispositivo per la quale esiste un'autorizzazione Android corrispondente (ad esempio Fotocamera, GPS e così via), il runtime alternativo DEVE informare l'utente che l'applicazione potrà accedere a quella risorsa. Se l'ambiente di runtime non registra le funzionalità dell'applicazione in questo modo, deve elencare tutte le autorizzazioni detenute dal runtime stesso durante l'installazione di qualsiasi applicazione che utilizza il runtime.

9.5. Supporto di più utenti

Android include il supporto di più utenti e fornisce il supporto per l'isolamento completo degli utenti [Risorse, 70].

Le implementazioni dei dispositivi DEVONO soddisfare i seguenti requisiti relativi al supporto multiutente [Risorse, 71]:

• Poiché il comportamento delle API di telefonia sui dispositivi con più utenti non è attualmente definito, le implementazioni dei dispositivi che dichiarano android.hardware.telephony NON DEVONO attivare il supporto multiutente.
• Le implementazioni dei dispositivi DEVONO, per ogni utente, implementare un modello di sicurezza coerente con il modello di sicurezza della piattaforma Android come definito nel documento di riferimento Sicurezza e autorizzazioni nelle API [Risorse, 54]
• Android include il supporto dei profili con limitazioni, una funzionalità che consente ai proprietari di dispositivi di gestire utenti aggiuntivi e le relative funzionalità sul dispositivo. Con i profili con limitazioni, i proprietari di dispositivi possono configurare rapidamente ambienti separati in cui altri utenti possono lavorare, con la possibilità di gestire limitazioni più granulari nelle app disponibili in questi ambienti. Le implementazioni dei dispositivi che includono il supporto di più utenti devono includere il supporto per i profili con limitazioni. Android Open Source Project upstream include un'implementazione che soddisfa questo requisito.

Ogni istanza utente su un dispositivo Android DEVE avere directory di archiviazione esterna separate e isolate. Le implementazioni dei dispositivi POSSONO memorizzare i dati di più utenti sullo stesso volume o file system. Tuttavia, l'implementazione del dispositivo DEVE garantire che le applicazioni di proprietà di un determinato utente e in esecuzione per suo conto non possano elencare, leggere o scrivere dati di proprietà di altri utenti. Tieni presente che i supporti rimovibili, come gli slot per schede SD, possono consentire a un utente di accedere ai dati di un altro tramite un PC host. Per questo motivo, le implementazioni dei dispositivi che utilizzano supporti rimovibili per le API di archiviazione esterna DEVONO criptare i contenuti della scheda SD se è attivata la modalità multiutente utilizzando una chiave memorizzata solo su supporti non rimovibili accessibili solo al sistema. Poiché ciò renderà i contenuti multimediali illeggibili da un PC host, le implementazioni dei dispositivi dovranno passare a MTP o a un sistema simile per fornire ai PC host l'accesso ai dati dell'utente corrente. Di conseguenza, le implementazioni dei dispositivi POSSONO, ma NON DEVONO, attivare il multiutente se utilizzano supporti rimovibili [Risorse, 72] per lo spazio di archiviazione esterno principale.

9.6. Avviso SMS premium

Android include il supporto per avvisare gli utenti di qualsiasi messaggio SMS premium in uscita [Risorse, 73] . Gli SMS premium sono messaggi inviati a un servizio registrato presso un operatore che potrebbero comportare un addebito per l'utente. Le implementazioni dei dispositivi che dichiarano il supporto di android.hardware.telephony DEVONO avvisare gli utenti prima di inviare un messaggio SMS ai numeri identificati dalle espressioni regolari definite nel file /data/misc/sms/codes.xml del dispositivo. L'Android Open Source Project upstream fornisce un'implementazione che soddisfa questo requisito.

9.7. Funzionalità di sicurezza del kernel

La sandbox di Android include funzionalità che possono utilizzare il sistema di controllo dell'accesso obbligatorio (MAC) di Security-Enhanced Linux (SELinux) e altre funzionalità di sicurezza nel kernel di Linux. SELinux o altre funzionalità di sicurezza, se implementate al di sotto del framework Android:

• È NECESSARIO mantenere la compatibilità con le applicazioni esistenti
• NON deve avere un'interfaccia utente visibile, anche quando vengono rilevate violazioni
• NON DEVE essere configurabile dall'utente o dallo sviluppatore

Se un'API per la configurazione dei criteri è esposta a un'applicazione che può colpire un'altra applicazione (ad esempio un'API di amministrazione del dispositivo), l'API NON DEVE consentire configurazioni che compromettono la compatibilità.

I dispositivi DEVONO implementare SELinux e soddisfare i seguenti requisiti, che sono soddisfatti dall'implementazione di riferimento nel progetto Android Open Source upstream.

• DEVE supportare un criterio SELinux che consenta di impostare la modalità SELinux su base di dominio con:
• I domini in modalità di applicazione nell'implementazione di Android Open Source upstream (ad esempio installd, netd e vold) DEVONO essere in modalità di applicazione
• I domini per le applicazioni di terze parti DEVONO rimanere in modalità permissiva per garantire la compatibilità futura
• DOVREBBE caricare i criteri dal file /sepolicy sul dispositivo
• DEVE supportare gli aggiornamenti dinamici del file dei criteri SELinux senza richiedere un aggiornamento dell'immagine di sistema
• DEVE registrare eventuali violazioni delle norme senza interrompere le applicazioni o influire sul comportamento del sistema

Le implementazioni dei dispositivi DOVREBBERO mantenere il criterio SELinux predefinito fornito nel progetto Android Open Source upstream, fino a quando non avranno prima sottoposto a controllo le aggiunte al criterio SELinux. Le implementazioni dei dispositivi DEVONO essere compatibili con l'Android Open Source Project a monte.

9.8. Privacy

Se il dispositivo implementa nel sistema funzionalità che acquisiscono i contenuti visualizzati sullo schermo e/o registrano lo stream audio riprodotto sul dispositivo, DEVE avvisare continuamente l'utente ogni volta che questa funzionalità è attivata e acquisisce/registra attivamente.

9.9. Crittografia completa del disco

Se il dispositivo ha una schermata di blocco, DEVE supportare la crittografia del disco completo.

10. Test di compatibilità del software

Le implementazioni dei dispositivi DEVONO superare tutti i test descritti in questa sezione.

Tuttavia, tieni presente che nessun pacchetto di test software è completamente completo. Per questo motivo, gli implementatori di dispositivi sono vivamente incoraggiati ad apportare il numero minimo di modifiche possibili all'implementazione di riferimento e preferita di Android disponibile nell'Android Open Source Project. In questo modo, ridurrai al minimo il rischio di introdurre bug che creano incompatibilità che richiedono il rifacimento e potenziali aggiornamenti dei dispositivi.

10.1. Compatibility Test Suite (CTS)

Le implementazioni dei dispositivi DEVONO superare la suite di test di compatibilità Android (CTS) [Risorse, 2] disponibile nell'Android Open Source Project, utilizzando il software di spedizione finale sul dispositivo. Inoltre, gli implementatori dei dispositivi DEVONO utilizzare il più possibile l'implementazione di riferimento nella struttura di Android Open Source e DEVONO garantire la compatibilità in caso di ambiguità nel CTS e per eventuali reimplementazioni di parti del codice sorgente di riferimento.

Il CTS è progettato per essere eseguito su un dispositivo reale. Come qualsiasi software, anche il CTS potrebbe contenere bug. Il CTS verrà sottoposto a versionamento indipendentemente da questa definizione di compatibilità e potrebbero essere rilasciate più revisioni del CTS per Android 4.4. Le implementazioni dei dispositivi DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

10.2. Verificatore CTS

Le implementazioni dei dispositivi DEVONO eseguire correttamente tutti i casi applicabili in CTS Verifier. CTS Verifier è incluso nella Compatibility Test Suite e deve essere eseguito da un operatore umano per testare le funzionalità che non possono essere testate da un sistema automatico, ad esempio il funzionamento corretto di una fotocamera e dei sensori.

CTS Verifier include test per molti tipi di hardware, incluso hardware facoltativo. Le implementazioni dei dispositivi DEVONO superare tutti i test per l'hardware di cui sono dotati. Ad esempio, se un dispositivo è dotato di un accelerometro, DEVE eseguire correttamente il caso di test dell'accelerometro in CTS Verifier. I casi di test per le funzionalità indicate come facoltative da questo Documento di definizione della compatibilità POSSONO essere saltati o omessi.

Ogni dispositivo e ogni build DEVONO eseguire correttamente CTS Verifier, come indicato sopra. Tuttavia, poiché molte build sono molto simili, non è previsto che gli implementatori dei dispositivi eseguano esplicitamente il CTS Verifier su build che differiscono solo in modo banale. Nello specifico, le implementazioni dei dispositivi che differiscono da un'implementazione che ha superato lo strumento di verifica CTS solo per l'insieme di lingue, branding e così via inclusi POSSONO omettere il test dello strumento di verifica CTS.

10.3. Applicazioni di riferimento

Gli implementatori dei dispositivi DEVONO testare la compatibilità dell'implementazione utilizzando le seguenti applicazioni open source:

• Le applicazioni "App per Android" [Risorse, 55]
• Replica Island (disponibile nel Google Play Store)

Affinché l'implementazione sia considerata compatibile, ogni app sopra indicata DEVE essere avviata e comportarsi correttamente nell'implementazione.

11. Software aggiornabile

Le implementazioni dei dispositivi DEVONO includere un meccanismo per sostituire l'intero software di sistema. Il meccanismo non deve eseguire upgrade "in tempo reale", ovvero potrebbe essere necessario riavviare il dispositivo.

È possibile utilizzare qualsiasi metodo, a condizione che possa sostituire l'intero software preinstallato sul dispositivo. Ad esempio, qualsiasi dei seguenti approccisoddisfa questo requisito:

• Download OTA (over-the-air) con aggiornamento offline tramite riavvio
• Aggiornamenti "in tethering" tramite USB da un PC host
• Aggiornamenti "offline" tramite riavvio e aggiornamento da un file su archiviazione rimovibile

Il meccanismo di aggiornamento utilizzato DEVE supportare gli aggiornamenti senza cancellare i dati utente. In altre parole, il meccanismo di aggiornamento DEVE preservare i dati privati e condivisi dell'applicazione. Tieni presente che il software Android a monte include un meccanismo di aggiornamento che soddisfa questo requisito.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro la durata ragionevole del prodotto, stabilita in consultazione con il team di compatibilità di Android, che influisce sulla compatibilità delle applicazioni di terze parti, l'implementatore del dispositivo DEVE correggere l'errore tramite un aggiornamento software disponibile che può essere applicato in base al meccanismo appena descritto.

12. Log delle modifiche del documento

La tabella seguente contiene un riepilogo delle modifiche alla definizione di compatibilità in questa release.

Sezione o sezioni	Riepilogo della modifica
3.2.2. Parametri di compilazione	Descrizioni riviste di BRAND, DEVICE e PRODUCT. Ora SERIAL è obbligatorio.
3.2.3.5. Impostazioni app predefinite	Nuova sezione che aggiunge il requisito di conformità alle nuove impostazioni predefinite dell'applicazione
3.3.1 Interfacce a livello di codice dell'applicazione	Sono stati chiariti i valori consentiti per i parametri android.os.Build.CPU_ABI e android.os.Build.CPU_ABI2.
3.4.1. Compatibilità con WebView	È stato aggiunto Chromium come implementazione WebView richiesta.
3.7. Compatibilità con le macchine virtuali	È stato aggiunto il requisito per le densità dello schermo xxhdpi e 400 dpi.
3.8.6. Temi	Aggiornamento per riflettere l'utilizzo delle barre di sistema traslucide.
3.8.12. Posizione	Nuova sezione che aggiunge le impostazioni della località dei requisiti da centralizzare.
3.8.13. Unicode	Nuova sezione che aggiunge il requisito per il supporto delle emoji.
3.9. Amministrazione dispositivo	Le applicazioni amministrative preinstallate indicate non possono essere l'applicazione Proprietario dispositivo predefinita.
5.1. Codec multimediali	È stato aggiunto il requisito del decodificatore VP9. È stata aggiunta la specifica consigliata per i codec VP8 hardware.
5.3. Decodifica video	È stato aggiunto VP9. È stato aggiunto un consiglio per il passaggio alla risoluzione dinamica.
5.4. Registrazione audio	È stata aggiunta REMOTE_SUBMIX come nuova sorgente audio obbligatoria. È stato imposto l'utilizzo dell'API android.media.audiofx.NoiseSuppressor.
6.2.1 Sperimentale	Nuova sezione che introduce il runtime ART e richiede Dalvik come runtime predefinito.
7.1.1. Configurazione schermo	Le proporzioni 1,85 sono state sostituite da 1,86. È stata aggiunta la densità dello schermo di 400 dpi.
7.1.6. Tipi di schermo	È stata aggiunta la configurazione della risoluzione di 640 dpi (4K).
7.2.3. Tasti di navigazione	È stata aggiunta la funzione Recenti come essenziale; la funzione Menu è stata retrocessa in termini di priorità.
7.3.6. Termometro	È stato aggiunto SENSOR_TYPE_AMBIENT_TEMPERATURE come termometro consigliato.
7.4.2.2. Configurazione del link diretto con tunnel Wi-Fi	Nuova sezione che aggiunge il supporto per la configurazione del link diretto tramite tunnel Wi-Fi (TDLS).
7.4.4. Near Field Communication	È stato aggiunto il requisito Host Card Emulation (HCE). È stato sostituito SNEP GET con LLCP (Logical Link Control Protocol) e il profilo Bluetooth Object Push è stato aggiunto come requisito.
7.4.6. Impostazioni sincronizzazione	Nuova sezione che aggiunge il requisito di attivazione della sincronizzazione automatica dei dati per impostazione predefinita.
7.6.1. Memoria e spazio di archiviazione minimi	È stato aggiunto il requisito di impostazione ActivityManager.isLowRamDevice() per i dispositivi con meno di 512 MB di memoria. Aumento dei requisiti di spazio di archiviazione da 512 MB e 1 GB a 1 GB e 2 GB, rispettivamente.
7.6.2. Spazio di archiviazione "esterno" condiviso	Correzioni redazionali, ad esempio la modifica del nome della sezione e il trasferimento del testo pertinente da questa sezione alla sezione 9.5. Le applicazioni contrassegnate possono scrivere nelle directory specifiche del pacchetto sull'unità di archiviazione esterna secondaria.
7.7. USB	È stato aggiunto il requisito che tutti i dispositivi riportino un numero di serie USB.
9.5. Supporto di più utenti	Il testo non specifico per più utenti è stato spostato nella sezione 7.6.2.
9.7. Funzionalità di sicurezza del kernel	Riscritto per indicare il passaggio di SELinux alla modalità di applicazione e il requisito che l'output di SELinux non venga visualizzato nell'interfaccia utente.
9.8. Privacy	Nuova sezione che aggiunge il requisito di attivazione della registrazione audio e video per attivare notifiche continue per l'utente.
9.9. Crittografia completa del disco	Nuova sezione che aggiunge i dispositivi con blocco schermo che supportano la crittografia completa del disco.
12. Log delle modifiche del documento	Nuova sezione che riassume le modifiche al CDD per sezione.

 

13. Contattaci

Puoi contattare gli autori del documento all'indirizzo compatibility@android.com per chiedere chiarimenti e segnalare eventuali problemi che ritieni non trattati nel documento.