Definizione di compatibilità di Android 2.1

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

1. Introduzione

Questo documento elenca i requisiti che devono essere soddisfatti affinché gli smartphone siano compatibili con Android 2.1.

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 del dispositivo" o "implementatore" è una persona o un'organizzazione che sviluppa una soluzione hardware/software con Android 2.1. Un'"implementazione del dispositivo" o "implementazione" è la soluzione hardware/software così sviluppata.

Per essere considerate compatibili con Android 2.1, le implementazioni dei dispositivi:

  • DEVONO soddisfare i requisiti presentati in questa definizione di compatibilità, inclusi eventuali documenti incorporati tramite riferimento.
  • DEVE superare la versione più recente del Compatibility Test Suite (CTS) di Android disponibile al momento del completamento del software di implementazione del dispositivo. Il CTS è disponibile nell'ambito dell'Android Open Source Project [Risorse, 2]. Il CTS testa molti, ma non tutti, i componenti descritti in questo documento.

Se questa definizione o la CTS non sono chiare, ambigue o incomplete, è 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 sul codice sorgente "upstream" disponibile nel progetto open source Android. Sebbene alcuni componenti possano essere ipocritamente sostituiti con implementazioni alternative, questa pratica è vivamente sconsigliata, in quanto superare i test CTS diventerà notevolmente più difficile. È responsabilità dell'implementatore garantire la piena compatibilità comportamentale con l'implementazione Android standard, incluso e oltre il Compatibility Test Suite. Infine, tieni presente che alcune sostituzioni e modifiche dei componenti sono vietate esplicitamente 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/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 a android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Stringhe di versione consentite per Android 2.1: http://source.android.com/docs/compatibility/2.1/versions.html
  8. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Specifiche della macchina virtuale Dalvik: disponibili nel codice sorgente di Android, in dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Notifiche: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Risorse per le applicazioni: http://code.google.com/android/reference/available-resources.html
  14. Linee guida per lo stile delle icone della barra di stato: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  16. Toast: http://developer.android.com/reference/android/widget/Toast.html
  17. Sfondi animati: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. App per Android: http://code.google.com/p/apps-for-android
  19. Documentazione dello strumento di riferimento (per adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  20. Descrizione del file APK Android: http://developer.android.com/guide/topics/fundamentals.html
  21. File manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Strumento di test Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Supporto di più schermi: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. Spazio delle coordinate del sensore: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Documentazione di riferimento per la sicurezza e le autorizzazioni di Android: http://developer.android.com/guide/topics/security/security.html
  29. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Molte di queste risorse sono ricavate direttamente o indirettamente dall'SDK Android 2.1 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

La piattaforma Android include un insieme di API gestite, un insieme di API native e un insieme di API cosiddette "soft" come il sistema Intent e le API per le applicazioni web. Questa sezione descrive in dettaglio le API hard e soft fondamentali per la compatibilità, nonché alcuni altri comportamenti tecnici e dell'interfaccia utente pertinenti. Le implementazioni dei dispositivi DEVONO essere conformi a tutti i requisiti di questa sezione.

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 2.1 [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à.

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. Questa sezione descrive in dettaglio le API "soft" e i comportamenti di sistema richiesti per la compatibilità con Android 2.1. Le implementazioni dei dispositivi DEVONO soddisfare tutti i requisiti presentati in questa sezione.

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 10 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
android.os.Build.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].
android.os.Build.VERSION.SDK La versione del sistema Android attualmente in esecuzione, in un formato accessibile al codice dell'applicazione di terze parti. Per Android 2.1, questo campo DEVE avere il valore intero 7.
android.os.Build.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 inviate 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 ("").
android.os.Build.BOARD 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. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.BRAND Un valore scelto dall'implementatore del dispositivo che identifica il nome della società, dell'organizzazione, della persona fisica e così via che ha prodotto il dispositivo in formato leggibile. Un possibile utilizzo di questo campo è indicare l'OEM e/o l'operatore che ha venduto il dispositivo. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o una stringa vuota ("").
android.os.Build.DEVICE Un valore scelto dall'implementatore del dispositivo che identifica la configurazione o la revisione specifica della cassa (a volte chiamata "design industriale") del dispositivo. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.FINGERPRINT Una stringa che identifica in modo univoco questa build. DEVE essere ragionevolmente leggibile da una persona. DEVE seguire questo modello:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Ad esempio:
acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
L'impronta NON DEVE includere spazi. Se altri campi inclusi nel modello riportato sopra contengono spazi, questi DEVONO essere sostituiti con il carattere underscore ASCII ("_") nell'impronta.
android.os.Build.HOST 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 ("").
android.os.Build.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. Non sono previsti requisiti per il formato specifico di questo campo, tranne per il fatto che NON DEVE essere nullo o la stringa vuota ("").
android.os.Build.MODEL 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 ("").
android.os.Build.PRODUCT Un valore scelto dall'implementatore del dispositivo contenente il nome di sviluppo o il nome in codice del dispositivo. DEVE essere leggibile, ma non necessariamente pensato per essere visualizzato dagli 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 ("").
android.os.Build.TAGS Un elenco separato da virgole di tag scelti dall'implementatore del dispositivo che contraddistinguono ulteriormente la build. Ad esempio, "unsigned,debug". Questo campo NON deve essere nullo o una stringa vuota (""), ma è accettabile un singolo tag (ad es. "release").
android.os.Build.TIME Un valore che rappresenta il timestamp della compilazione.
android.os.Build.TYPE 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".
android.os.Build.USER 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

Android utilizza gli intent per realizzare un'integrazione con accoppiamento lasco tra le applicazioni. Questa sezione descrive i requisiti relativi ai pattern di Intent che DEVONO essere rispettati dalle implementazioni dei dispositivi. 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 Android upstream definisce una serie di applicazioni di base, come un tastierino telefonico, un calendario, un elenco contatti, un lettore musicale 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
  • Calcolatrice
  • Fotocamera
  • Contatti
  • Email
  • Galleria
  • GlobalSearch
  • Avvio app
  • LivePicker (ovvero l'applicazione di selezione degli sfondi animati; PUÒ essere omessa se il dispositivo non supporta gli sfondi animati, come indicato nella Sezione 3.8.5).
  • Messaggistica (noto anche come "MMS")
  • Musica
  • Telefono
  • Impostazioni
  • SoundRecorder

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, gli implementatori dei dispositivi DEVONO consentire a ogni schema di intent definito nelle app di sistema di base di essere sostituito da applicazioni di terze parti. Il progetto open source Android upstream lo consente per impostazione predefinita. Gli implementatori dei dispositivi NON DEVONO assegnare privilegi speciali all'utilizzo di questi pattern di intent da parte delle applicazioni di sistema o impedire alle applicazioni di terze parti di associarsi e assumere il controllo di questi pattern. Questo divieto include nello specifico, a titolo esemplificativo, la disattivazione dell'interfaccia utente "Chooser" che consente all'utente di scegliere tra più applicazioni che gestiscono tutte lo stesso pattern di intent.

Nota: questa sezione è stata modificata dall'Erratum EX6580.

3.2.3.3. Spazi dei nomi degli intent

Gli implementatori 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.*. Gli implementatori di dispositivi NON DEVONO includere componenti Android che supportano nuovi pattern di intent o intent di trasmissione utilizzando una stringa ACTION, CATEGORY o un'altra stringa chiave in uno spazio del pacchetto appartenente a un'altra organizzazione. Gli implementatori dei dispositivi NON DEVONO modificare o estendere nessuno dei pattern di intent utilizzati dalle app di base elencate nella sezione 3.2.3.1.

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.3. Compatibilità con le API native

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. Le implementazioni dei dispositivi DEVONO includere il supporto per il codice eseguito nell'ambiente gestito per chiamare il codice nativo, utilizzando la semantica standard di Java Native Interface (JNI). Le seguenti API DEVONO essere disponibili per il codice nativo:

  • libc (libreria C)
  • libm (libreria matematica)
  • Interfaccia JNI
  • libz (compressione Zlib)
  • liblog (logging Android)
  • Supporto minimo per C++
  • Supporto di OpenGL, come descritto di seguito

Le implementazioni dei dispositivi DEVONO supportare OpenGL ES 1.0. I dispositivi che non dispongono dell'accelerazione hardware DEVONO implementare OpenGL ES 1.0 utilizzando un renderer software. Le implementazioni dei dispositivi DOVREBBERO implementare la maggior parte delle funzionalità di OpenGL ES 1.1 supportate dall'hardware del dispositivo. Le implementazioni dei dispositivi DOVREBBERO fornire un'implementazione per OpenGL ES 2.0, se l'hardware è in grado di offrire prestazioni ragionevoli su queste API.

Queste librerie DEVONO essere compatibili con il codice sorgente (ovvero compatibili con gli header) e con i file binari (per una determinata architettura del processore) con le versioni fornite in Bionic dal progetto Android Open Source. Poiché le implementazioni di Bionic non sono completamente compatibili con altre implementazioni come la libreria GNU C, gli implementatori di dispositivi DEVONO utilizzare l'implementazione di Android. Se gli implementatori dei dispositivi utilizzano un'implementazione diversa di queste librerie, devono garantire la compatibilità di intestazioni, file binari e comportamenti.

Le implementazioni dei dispositivi DEVONO segnalare con precisione l'interfaccia ABI (Application Binary) nativa supportata dal dispositivo tramite l'APIandroid.os.Build.CPU_ABI. L'ABI DEVE essere una delle voci documentate nell'ultima versione dell'NDK di Android, nel filedocs/CPU-ARCH-ABIS.txt. Tieni presente che le release aggiuntive dell'Android NDK potrebbero introdurre il supporto di ABI aggiuntivi.

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à con le API web

Molti sviluppatori e applicazioni si basano sul comportamento della classe android.webkit.WebView [Resources, 8] per le loro interfacce utente, pertanto l'implementazione di WebView deve essere compatibile con tutte le implementazioni di Android. L'implementazione Android Open Source utilizza il motore di rendering WebKit per implementare WebView.

Poiché non è possibile sviluppare una suite di test completa per un browser web, gli implementatori di dispositivi DEVONO utilizzare la build upstream specifica di WebKit nell'implementazione di WebView. Nello specifico:

  • WebView DEVE utilizzare la build WebKit 530.17 dall'albero di origine Android Open Source per Android 2.1. Questa build include un insieme specifico di funzionalità e correzioni di sicurezza per WebView.
  • La stringa dello user agent segnalata da WebView DEVE essere nel seguente formato:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • Il valore della stringa $(VERSION) DEVE essere uguale al valore di android.os.Build.VERSION.RELEASE
    • Il valore della stringa $(LOCALE) DEVE seguire le convenzioni ISO per il codice paese e la lingua e DEVE fare riferimento alle impostazioni internazionali attualmente configurate del dispositivo
    • 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

Le implementazioni POSSONO includere una stringa user agent personalizzata nell'applicazione browser autonoma. Inoltre, il browser autonomo POTREBBE essere basato su una tecnologia di browser alternativa (come Firefox, Opera e così via). Tuttavia, anche se viene fornita un'applicazione browser alternativa, il componente WebView fornito alle applicazioni di terze parti DEVE essere basato su WebKit, come sopra.

La configurazione di WebView DEVE includere il supporto per il database HTML5, la cache dell'applicazione e le API di geolocalizzazione [Risorse, 9]. WebView DEVE includere il supporto per il tag <video> HTML5 in qualche forma. L'applicazione Browser autonoma (basata sull'applicazione Browser WebKit a monte o su un'applicazione sostitutiva di terze parti) DEVE includere il supporto per le stesse funzionalità HTML5 appena elencate per WebView.

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 il significato di un Intent 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 una determinata autorizzazione

L'elenco riportato sopra non è esaustivo e la responsabilità di garantire la compatibilità del comportamento è degli implementatori dei dispositivi. 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.

La Compatibility Test Suite (CTS) testa porzioni significative della piattaforma per verificarne la compatibilità di comportamento, ma non tutte. È responsabilità dell'implementatore garantire la compatibilità del comportamento con il progetto Android Open Source.

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" nel codice sorgente di Android upstream. In altre parole, gli implementatori di dispositivi NON DEVONO esporre nuove API o modificare quelle esistenti negli spazi dei nomi indicati sopra. Gli implementatori di dispositivi POSSONO apportare modifiche solo per uso interno, ma queste modifiche NON DEVONO essere pubblicizzate o esposte in altro modo 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.

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, 10].

Le implementazioni dei dispositivi DEVONO configurare Dalvik in modo da allocare almeno 16 MB di memoria a ogni applicazione sui dispositivi con schermi classificati come a media o bassa densità. Le implementazioni dei dispositivi DEVONO configurare Dalvik in modo da allocare almeno 24 MB di memoria a ogni applicazione sui dispositivi con schermi classificati come ad alta densità. Tieni presente che le implementazioni dei dispositivi POSSONO allocare più memoria rispetto a queste cifre, ma non sono tenute a farlo.

3.8. Compatibilità dell'interfaccia utente

La piattaforma Android include alcune API per sviluppatori che consentono di eseguire il collegamento all'interfaccia utente di sistema. Le implementazioni dei dispositivi DEVONO incorporare queste API di interfaccia utente standard nelle interfacce utente personalizzate che sviluppano, come spiegato di seguito.

3.8.1. 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, 11]. La release di riferimento di Android Open Source include un'applicazione Avvio app che include elementi dell'interfaccia utente che consentono all'utente di aggiungere, visualizzare e rimuovere AppWidget dalla schermata Home.

Gli implementatori del dispositivo POSSONO sostituire un'alternativa al Launcher di riferimento (ovvero la schermata Home). I lanciatori alternativi DEVONO includere il supporto integrato per gli AppWidget ed esporre elementi dell'interfaccia utente per aggiungere, configurare, visualizzare e rimuovere gli AppWidget direttamente all'interno del lanciatore. I lanciatori alternativi POSSONO omettere questi elementi dell'interfaccia utente. Tuttavia, se vengono omessi, l'implementatore del dispositivo DEVE fornire un'applicazione separata accessibile dal lanciatore che consenta agli utenti di aggiungere, configurare, visualizzare e rimuovere gli AppWidget.

3.8.2. Notifiche

Android include API che consentono agli sviluppatori di notificare agli utenti eventi importanti [Risorse, 12]. Gli implementatori di dispositivi DEVONO fornire supporto per ogni classe di notifica così definita; nello specifico: suoni, vibrazione, luce e barra di stato.

Inoltre, l'implementazione DEVE eseguire il rendering corretto di tutte le risorse (icone, file audio e così via) previste nelle API [Risorse, 13] o nella guida di stile delle icone della barra di stato [Risorse, 14]. 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 indicato sopra.

Android include API [Risorse, 15] che consentono agli sviluppatori di incorporare la ricerca nelle loro applicazioni ed esporre i dati delle loro 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.

Le implementazioni dei dispositivi POSSONO includere interfacce utente di ricerca alternative, ma DEVONO includere un pulsante di ricerca dedicato, hard o soft, che può essere utilizzato in qualsiasi momento in qualsiasi app per richiamare il framework di ricerca, con il comportamento previsto nella documentazione dell'API.

3.8.4. Auguri

Le applicazioni possono utilizzare l'API "Toast" (definita in [Risorse, 16]) 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.5. 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, 17]. 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.

4. Compatibilità del software di riferimento

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

  • Calcolatrice (inclusa nell'SDK)
  • Lunar Lander (incluso nell'SDK)
  • Le applicazioni "App per Android" [Risorse, 18].

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

Inoltre, le implementazioni dei dispositivi DEVONO testare ogni voce di menu (inclusi tutti i sottomenu) di ciascuna di queste applicazioni di test di fumosità:

  • ApiDemos (incluso nell'SDK)
  • ManualSmokeTests (incluso in CTS)

Ogni scenario di test nelle applicazioni sopra indicate DEVE essere eseguito correttamente nell'implementazione del dispositivo.

5. Compatibilità con il pacchettizzazione delle applicazioni

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

Le implementazioni dei dispositivi NON DEVONO estendere i formati .apk [Risorse, 20], Android Manifest [Risorse, 21] o bytecode Dalvik [Risorse, 10] 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.

6. Compatibilità multimediale

Le implementazioni dei dispositivi DEVONO supportare i seguenti codec multimediali. 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 titolari di brevetti pertinenti.

Audio
Nome Codificatore Decodificatore Dettagli Formato file/container
AAC LC/LTP   X Contenuti mono/stereo in qualsiasi combinazione di velocità in bit standard fino a 160 Kbps e frequenze di campionamento comprese tra 8 e 48 kHz 3GPP (.3gp) e MPEG-4 (.mp4, .m4a). Nessun supporto per AAC non compresso (.aac)
HE-AACv1 (AAC+)   X
HE-AACv2 (AAC+ migliorato)   X
AMR-NB X X 4,75-12,2 Kbps campionati a 8 kHz 3GPP (.3gp)
AMR-WB   X 9 frequenze da 6,60 kbit/s a 23,85 kbit/s campionate a 16 kHz 3GPP (.3gp)
MP3   X Mono/stereo 8-320 Kbps a velocità in bit costante (CBR) o variabile (VBR) MP3 (.mp3)
MIDI   X 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). Sono supportati anche i formati RTTTL/RTX (.rtttl, .rtx), OTA (.ota) e iMelody (.imy)
Ogg Vorbis   X   Ogg (.ogg)
PCM   X PCM lineare a 8 e 16 bit (frequenze fino al limite dell'hardware) WAVE (.wav)
Immagine
JPEG X X base+progressive  
GIF   X    
PNG X X    
BMP   X    
Video
H.263 X X   File 3GPP (.3gp)
H.264   X   File 3GPP (.3gp) e MPEG-4 (.mp4)
Profilo semplice MPEG4   X   File 3GPP (.3gp)

Tieni presente che la tabella sopra non elenca requisiti specifici per la velocità in bit per la maggior parte dei codec video. Il motivo è che, in pratica, l'hardware dei dispositivi attuali non supporta necessariamente le velocità in bit che corrispondono esattamente alle velocità in bit richieste specificate dagli standard pertinenti. Le implementazioni dei dispositivi DEVONO supportare la massima velocità in bit possibile sull'hardware, fino ai limiti definiti dalle specifiche.

7. Compatibilità degli 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, 19]
    Le implementazioni dei dispositivi DEVONO supportare tutte le funzioni adb come documentato nell'SDK Android. Il daemon adb lato dispositivo DOVREBBE essere inattivo per impostazione predefinita, ma DEVE essere presente un meccanismo accessibile all'utente per attivare Android Debug Bridge.
  • Dalvik Debug Monitor Service (noto come ddms) [Risorse, 19]
    Le implementazioni del dispositivo 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, 22]
    Le implementazioni del dispositivo DEVONO includere il framework Monkey e metterlo a disposizione delle applicazioni.

8. Compatibilità hardware

Android è progettato per supportare gli implementatori di dispositivi che creano configurazioni e fattori di forma innovativi. Allo stesso tempo, gli sviluppatori Android si aspettano determinate API, hardware e sensori su tutti i dispositivi Android. Questa sezione elenca le funzionalità hardware che tutti i dispositivi compatibili con Android 2.1 devono supportare.

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 definito nella documentazione dell'SDK Android. Se un'API nell'SDK interagisce con un componente hardware dichiarato facoltativo e l'implementazione del dispositivo non lo possiede:

  • le definizioni di classi per le API del componente DEVONO essere 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

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 informazioni accurate sulla configurazione hardware tramite i metodi getSystemAvailableFeatures() e hasSystemFeature(String) della classe android.content.pm.PackageManager.

8.1. Display

Android 2.1 include funzionalità che eseguono determinate operazioni di scalabilità e trasformazione automatica in alcune circostanze, per garantire che le applicazioni di terze parti funzionino abbastanza bene su una serie di configurazioni hardware [Risorse, 23]. I dispositivi DEVONO implementare correttamente questi comportamenti, come descritto in questa sezione.

Per Android 2.1, queste sono le configurazioni di visualizzazione più comuni:

Tipo di schermo Larghezza (pixel) Altezza (pixel) Intervallo di lunghezza diagonale (pollici) Gruppo di dimensioni dello schermo Gruppo di densità dello schermo
QVGA 240 320 2,6 - 3,0 Piccolo Bassa
WQVGA 240 400 3,2 - 3,5 Normale Bassa
FWQVGA 240 432 3,5 - 3,8 Normale Bassa
HVGA 320 480 3,0 - 3,5 Normale Intermedia
WVGA 480 800 3,3 - 4,0 Normale Alto
FWVGA 480 854 3,5 - 4,0 Normale Alto
WVGA 480 800 4,8 - 5,5 Grande Intermedia
FWVGA 480 854 5,0 - 5,8 Grande Intermedia

Le implementazioni dei dispositivi corrispondenti a una delle configurazioni standard riportate sopra DEVONO essere configurate per segnalare le dimensioni dello schermo indicate alle applicazioni tramite la classe android.content.res.Configuration [Resources, 24].

Alcuni pacchetti .apk hanno manifest che non li identificano come supportanti un intervallo di densità specifico. Quando esegui queste applicazioni, si applicano i seguenti vincoli:

  • Le implementazioni dei dispositivi DEVONO interpretare le risorse in un file APK che non dispongono di un qualificatore di densità come valore predefinito "medium" (noto come "mdpi" nella documentazione dell'SDK).
  • Quando operi su uno schermo a densità "bassa", le implementazioni dei dispositivi DEVONO ridurre le risorse medium/mdpi di un fattore 0,75.
  • Quando operi su uno schermo ad alta densità, le implementazioni dei dispositivi DEVONO aumentare le dimensioni degli asset medium/mdpi di un fattore 1,5.
  • Le implementazioni dei dispositivi NON DEVONO ridimensionare gli asset all'interno di un intervallo di densità e DEVONO ridimensionare gli asset esattamente in base a questi fattori tra intervalli di densità.

8.1.2. Configurazioni di display non standard

Le configurazioni di visualizzazione che non corrispondono a una delle configurazioni standard elencate nella Sezione 8.1.1 richiedono ulteriori considerazioni e interventi per essere compatibili. Gli implementatori di dispositivi DEVONO contattare il team di compatibilità Android come previsto nella Sezione 12 per ottenere le classificazioni per il bucket delle dimensioni dello schermo, la densità e il fattore di scalabilità. Quando vengono fornite queste informazioni, le implementazioni dei dispositivi DEVONO implementarle come specificato.

Tieni presente che alcune configurazioni del display (ad esempio schermi molto grandi o molto piccoli e alcuni rapporti di aspetto) sono fondamentalmente incompatibili con Android 2.1. Pertanto, gli implementatori dei dispositivi sono invitati a contattare il team di compatibilità di Android il prima possibile durante il processo di sviluppo.

8.1.3. Metriche relative alla visualizzazione

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

8.2. 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 tastiere virtuali) come descritto su developer.android.com
  • DEVE fornire almeno un'implementazione della tastiera su schermo (indipendentemente dal fatto che sia presente 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, 24] (ovvero QWERTY o 12 tasti)

8.3. Navigazione non tocco

Implementazioni dei dispositivi:

  • POTREBBE omettere le opzioni di navigazione non touch (ad esempio, trackball, D-pad o rotella)
  • DEVE riportare il valore corretto per android.content.res.Configuration.navigation [Risorse, 24]

8.4. Orientamento schermo

I dispositivi compatibili DEVONO supportare l'orientamento dinamico da parte 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.

8.5. Input touchscreen

Implementazioni dei dispositivi:

  • DEVE avere un touchscreen
  • PUO' avere un touchscreen capacitivo o resistivo
  • DEVE riportare il valore di android.content.res.Configuration [Resources, 24] che corrisponde al tipo di touchscreen specifico sul dispositivo

8.6. USB

Implementazioni dei dispositivi:

  • DEVE implementare un client USB, collegabile a un host USB con una porta USB-A standard
  • DEVE implementare Android Debug Bridge tramite USB (come descritto nella sezione 7)
  • DEVE implementare la specifica dell'archivio di massa USB per consentire a un host collegato al dispositivo di accedere ai contenuti del volume /sdcard
  • DOVREBBE utilizzare il fattore di forma micro USB sul lato del dispositivo
  • PUO' includere una porta non standard sul lato del dispositivo, ma in questo caso DEVE essere fornito con un cavo in grado di collegare il pinout personalizzato alla porta USB-A standard

8.7. Tasti di navigazione

Le funzioni Home, Menu 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, indipendentemente dallo stato dell'applicazione. Queste funzioni DEVONO essere implementate tramite pulsanti dedicati. POSSONO essere implementati utilizzando software, gesti, pannelli touch e così via, ma in questo caso DEVONO essere sempre accessibili e non oscurare o interferire con l'area di visualizzazione dell'applicazione disponibile.

Gli implementatori dei dispositivi DEVONO anche fornire una chiave di ricerca dedicata. Gli implementatori di dispositivi POSSONO anche fornire tasti di invio e di fine per le chiamate.

8.8. Networking di dati wireless

Le implementazioni dei dispositivi DEVONO includere il supporto per la rete di dati wireless ad alta velocità. Nello specifico, le implementazioni dei dispositivi DEVONO includere il supporto di almeno un protocollo di dati wireless in grado di supportare una velocità di almeno 200 Kbit/s. Alcuni esempi di tecnologie che soddisfano questo requisito sono EDGE, HSPA, EV-DO, 802.11g e così via.

Se un'implementazione del dispositivo include una determinata modalità per la quale l'SDK Android include un'API (ad esempio Wi-Fi, GSM o CDMA), l'implementazione DEVE supportare l'API.

I dispositivi POSSONO implementare più di una forma di connettività dati wireless. I dispositivi POSSONO implementare la connettività dati cablata (ad esempio Ethernet), ma DEVONO includere almeno una forma di connettività wireless, come sopra indicato.

8.9. Fotocamera

Le implementazioni dei dispositivi DEVONO includere una videocamera. La videocamera inclusa:

  • 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.

Le implementazioni dei dispositivi DEVONO implementare i seguenti comportamenti per le API relative alle videocamere:

  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 di 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. Questo è il formato utilizzato in modo nativo dalla famiglia di hardware 7K. In altre parole, NV21 DEVE essere il valore predefinito.

Le implementazioni dei dispositivi DEVONO implementare l'API Camera completa inclusa nella documentazione dell'SDK Android 2.1 [Risorse, 26], 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).

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 costanti di stringa passate al metodo android.hardware.Camera.setParameters() diverse da quelle documentate come costanti in android.hardware.Camera.Parameters, a meno che alle costanti non venga anteposto un prefisso costituito da una stringa che indichi il nome dell'implementatore del dispositivo. In altre parole, le implementazioni dei dispositivi DEVONO supportare tutti i parametri della videocamera standard se il hardware lo consente e NON DEVONO supportare tipi di parametri della videocamera personalizzati, a meno che i nomi dei parametri non siano chiaramente indicati tramite un prefisso di stringa come non standard.

8.10. Accelerometro

Le implementazioni dei dispositivi DEVONO includere un accelerometro a 3 assi e DEVONO essere in grado di inviare eventi a una frequenza minima di 50 Hz. Il sistema di coordinate utilizzato dall'accelerometro DEVE essere conforme al sistema di coordinate del sensore Android, come descritto nelle API Android (vedi [Risorse, 27]).

8.11. Bussola

Le implementazioni dei dispositivi DEVONO includere una bussola a 3 assi e DEVONO essere in grado di inviare eventi a una frequenza minima di 10 Hz. Il sistema di coordinate utilizzato dalla bussola deve essere conforme al sistema di coordinate del sensore Android come definito nell'API Android (vedi [Risorse, 27]).

8.12. GPS

Le implementazioni dei dispositivi DEVONO includere un GPS e DOVREBBERO includere una qualche forma di tecnica di "GPS assistito" per ridurre al minimo il tempo di accoppiamento del GPS.

8.13. Telefonia

Android 2.1 PUÒ essere utilizzato su dispositivi che non includono hardware di telefonia. In altre parole, Android 2.1 è 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.

Consulta anche la sezione 8.8, Rete dati wireless.

8.14. Memoria e spazio di archiviazione

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

Le implementazioni dei dispositivi DEVONO avere almeno 150 MB di spazio di archiviazione non volatile disponibile per i dati utente. In altre parole, la partizione /data deve avere almeno 150 MB.

Nota: questa sezione è stata modificata dall'Erratum EX6580.

8.15. Spazio di archiviazione condiviso dell'applicazione

Le implementazioni dei dispositivi DEVONO offrire spazio di archiviazione condiviso per le applicazioni. Lo spazio di archiviazione condiviso fornito DEVE avere una dimensione minima di 2 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.

Indipendentemente dalla forma di spazio di archiviazione condiviso utilizzato, lo spazio di archiviazione condiviso DEVE implementare l'archiviazione di massa USB, come descritto nella Sezione 8.6. Come spedito, lo spazio di archiviazione condiviso DEVE essere montato con il file system FAT.

È 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 2 GB con il dispositivo venduto agli utenti e deve essere montata per impostazione predefinita. In alternativa, se un'implementazione del dispositivo utilizza spazio di archiviazione interno fisso per soddisfare questo requisito, lo spazio di archiviazione DEVE avere una dimensione minima di 2 GB e essere montato su /sdcard (o /sdcard DEVE essere un link simbolico alla posizione fisica se è montato altrove).

Nota: questa sezione è stata aggiunta dall'Erratum EX6580.

8.16. Bluetooth

Le implementazioni dei dispositivi DEVONO includere un trasmettitore Bluetooth. Le implementazioni dei dispositivi DEVONO attivare l'API Bluetooth basata su RFCOMM come descritto nella documentazione dell'SDK [Risorse, 29]. Le implementazioni dei dispositivi DEVONO implementare profili Bluetooth pertinenti, come A2DP, AVRCP, OBEX e così via, a seconda dei casi.

Nota: questa sezione è stata aggiunta dall'Erratum EX6580.

9. Compatibilità con il rendimento

Uno degli obiettivi del Programma di compatibilità Android è offrire ai consumatori un'esperienza con le applicazioni coerente. Le implementazioni compatibili devono garantire non solo che le applicazioni funzionino correttamente sul dispositivo, ma anche che lo facciano con un rendimento ragionevole e un'esperienza utente complessivamente positiva. Le implementazioni dei dispositivi DEVONO soddisfare le metriche di prestazioni chiave di un dispositivo compatibile con Android 2.1 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
  • MMS/SMS: meno di 700 ms
  • AlarmClock: meno di 650 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.  

10. 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, 28] della documentazione per 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.

10.1. Autorizzazioni

Le implementazioni dei dispositivi DEVONO supportare il modello di autorizzazioni di Android come definito nella documentazione per gli sviluppatori Android [Risorse, 28]. 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.*.

10.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, 28].

10.3. Autorizzazioni del file system

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

11. 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 2.1. Le implementazioni dei dispositivi DEVONO superare la versione CTS più recente disponibile al momento del completamento del software del dispositivo.

12. 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. Tieni presente che il software Android upstream include un meccanismo di aggiornamento chesoddisfa questo requisito.

Se viene rilevato un errore nell'implementazione di un dispositivo dopo il rilascio, ma entro il periodo di tempo ragionevole del prodotto stabilito 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 secondo il meccanismo appena descritto.

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.