Użycie zwrotów „musi”, „nie może”, „wymagane”, „należy”, „nie powinno”, „powinno”, „nie powinno”, „zalecane”, „może” i „opcjonalne” jest zgodne ze standardem IETF zdefiniowane w RFC2119 [ Zasoby, 1 ].

W niniejszym dokumencie „wykonawca urządzenia” lub „wykonawca” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z systemem Android 4.4. „Implementacja urządzenia” lub „implementacja” to opracowane w ten sposób rozwiązanie sprzętowe/programowe.

Aby urządzenia zostały uznane za zgodne z systemem Android 4.4, MUSZĄ spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszelkie dokumenty włączone przez odniesienie.

Jeżeli ta definicja lub testy oprogramowania opisane w sekcji 10 są ciche, niejednoznaczne lub niekompletne, obowiązkiem wdrażającego urządzenie jest zapewnienie zgodności z istniejącymi implementacjami.

Z tego powodu projekt Android Open Source [ Zasoby, 3 ] jest zarówno referencyjną, jak i preferowaną implementacją Androida. Zdecydowanie zachęca się osoby wdrażające urządzenia, aby w największym możliwym stopniu opierały swoje implementacje na „źródłowym” kodzie źródłowym dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można hipotetycznie zastąpić alternatywnymi implementacjami, praktyka ta jest zdecydowanie odradzana, ponieważ zdanie testów oprogramowania stanie się znacznie trudniejsze. Obowiązkiem wdrażającego jest zapewnienie pełnej zgodności behawioralnej ze standardową implementacją Androida, w tym i poza pakietem testów zgodności. Na koniec należy pamiętać, że niniejszy dokument wyraźnie zabrania niektórych zamian i modyfikacji komponentów.

2. Zasoby

Poziomy wymagań IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Omówienie programu zgodności z Androidem: http://source.android.com/docs/compatibility/index.html

Projekt Android Open Source: http://source.android.com/

Definicje API i dokumentacja: http://developer.android.com/reference/packages.html

Informacje o uprawnieniach systemu Android: http://developer.android.com/reference/android/Manifest.permission.html

Informacje o kompilacji android.os.Build: http://developer.android.com/reference/android/os/Build.html

Ciągi dozwolonych wersji Androida 4.4: http://source.Android.com/docs/compatibility/4.4/versions.html

Skrypt renderujący: http://developer.android.com/guide/topics/graphics/renderscript.html

Akceleracja sprzętowa: http://developer.android.com/guide/topics/graphics/hardware-accel.html

Klasa android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Możliwości HTML5 offline: http://dev.w3.org/html5/spec/Overview.html#offline

Tag wideo HTML5: http://dev.w3.org/html5/spec/Overview.html#video

API geolokalizacji HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API przechowywania stron internetowych HTML5/W3C: http://www.w3.org/TR/webstorage/

API HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/

Specyfikacja maszyny wirtualnej Dalvik: dostępna w kodzie źródłowym Androida, pod adresem dalvik/docs

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html

Przewodnik po stylu ikon paska stanu: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html

Tosty: http://developer.android.com/reference/android/widget/Toast.html

Motywy: http://developer.android.com/guide/topics/ui/themes.html

Klasa R.style: http://developer.android.com/reference/android/R.style.html

Animowane tapety: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Administracja urządzeniami z Androidem: http://developer.android.com/guide/topics/admin/device-admin.html

Informacje o menedżerze DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

Interfejsy API usługi dostępności systemu Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

Interfejsy API ułatwień dostępu dla systemu Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

Projekt Eyes Free: http://code.google.com/p/eyes-free

Interfejsy API zamiany tekstu na mowę: http://developer.android.com/reference/android/speech/tts/package-summary.html

Dokumentacja narzędzia referencyjnego (dla adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

Opis pliku apk na Androida: http://developer.android.com/guide/topics/fundamentals.html

Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-intro.html

Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

Klasa Android android.content.pm.PackageManager i lista funkcji sprzętowych: http://developer.android.com/reference/android/content/pm/PackageManager.html

Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

Interfejs API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Protokół NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

Interfejs API orientacji kamery: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

Kamera: http://developer.android.com/reference/android/hardware/Camera.html

Akcesoria do Androida Open: http://developer.android.com/guide/topics/usb/accessory.html

Interfejs API hosta USB: http://developer.android.com/guide/topics/usb/host.html

Informacje dotyczące zabezpieczeń i uprawnień systemu Android: http://developer.android.com/guide/topics/security/permissions.html

Aplikacje na Androida: http://code.google.com/p/apps-for-android

Menedżer pobierania Androida: http://developer.android.com/reference/android/app/DownloadManager.html

Przesyłanie plików w systemie Android: http://www.android.com/filetransfer

Formaty multimediów dla Androida: http://developer.android.com/guide/appendix/media-formats.html

Projekt protokołu HTTP do transmisji na żywo: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Przekazanie połączenia NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Bezpieczne, proste parowanie Bluetooth za pomocą NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Interfejs API multiemisji Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Asystent akcji: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Specyfikacja ładowania USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html

Dźwięk USB w systemie Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Ustawienia udostępniania NFC w systemie Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Widget blokady i ekranu głównego: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

Informacje o UserManager: http://developer.android.com/reference/android/os/UserManager.html

Informacje o pamięci zewnętrznej: https://source.Android.com/docs/core/storage

Interfejsy API pamięci zewnętrznej: http://developer.android.com/reference/android/os/Environment.html

Krótki kod SMS: http://en.wikipedia.org/wiki/Short_code

Klient zdalnego sterowania multimediami: http://developer.android.com/reference/android/media/RemoteControlClient.html

Menedżer wyświetlania: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Sny: http://developer.android.com/reference/android/service/dreams/DreamService.html

Ustawienia związane z tworzeniem aplikacji na Androida: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

Rozszerzenie EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

Interfejs API zdarzeń ruchu: http://developer.android.com/reference/android/view/MotionEvent.html

Konfiguracja wejścia dotykowego: http://source.android.com/docs/core/interaction/input/touch-devices.html

Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

Zgodność z WebView: http://www.chromium.org/

Aplikacja właściciela urządzenia z systemem Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html

Wymagania dotyczące kodowania sprzętu RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

Ustawienia. Bezpieczny LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

Narzędzie do rozpoznawania treści: http://developer.android.com/reference/android/content/ContentResolver.html

SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html

Emulacja karty oparta na hoście: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

Dostawca telefonii: http://developer.android.com/reference/android/provider/Telephony.html

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z zestawu SDK systemu Android i będzie funkcjonalnie identycznych z informacjami zawartymi w dokumentacji tego zestawu SDK. W każdym przypadku, gdy niniejsza Definicja Zgodności lub Zestaw Testów Zgodności nie zgadza się z dokumentacją SDK, dokumentacja SDK jest uważana za wiarygodną. Wszelkie szczegóły techniczne podane w odnośnikach zawartych powyżej są uznawane za część niniejszej Definicji Zgodności.

3. Oprogramowanie

3.1. Zgodność zarządzanego interfejsu API

Zarządzane (oparte na Dalvik) środowisko wykonawcze jest głównym narzędziem dla aplikacji na Androida. Interfejs programowania aplikacji systemu Android (API) to zestaw interfejsów platformy Android udostępnianych aplikacjom działającym w zarządzanym środowisku maszyny wirtualnej. Implementacje urządzeń MUSZĄ zapewniać kompletne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK systemu Android [ Zasoby, 4 ].

Implementacje urządzeń NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani podpisów, odbiegać od udokumentowanego zachowania ani zawierać zakazu wykonywania operacji, z wyjątkiem przypadków wyraźnie dozwolonych w niniejszej definicji zgodności.

Niniejsza definicja zgodności pozwala na pominięcie niektórych typów sprzętu, dla którego system Android zawiera interfejsy API, w implementacjach urządzeń. W takich przypadkach interfejsy API MUSZĄ nadal być obecne i zachowywać się w rozsądny sposób. Szczegółowe wymagania dotyczące tego scenariusza można znaleźć w sekcji 7 .

3.2. Zgodność z miękkim interfejsem API

Oprócz zarządzanych interfejsów API z sekcji 3.1, system Android zawiera także istotny „miękki” interfejs API przeznaczony wyłącznie do środowiska wykonawczego w postaci takich elementów, jak intencje, uprawnienia i podobne aspekty aplikacji systemu Android, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

Osoby wdrażające urządzenia MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie odniesienia do uprawnień [ Zasoby, 5 ]. Należy pamiętać, że w sekcji 9 wymieniono dodatkowe wymagania związane z modelem zabezpieczeń systemu Android.

3.2.2. Parametry kompilacji

Interfejsy API systemu Android zawierają wiele stałych w klasie android.os.Build [ Resources, 6 ], które mają opisywać bieżące urządzenie. Aby zapewnić spójne, znaczące wartości we wszystkich implementacjach urządzeń, poniższa tabela zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi MUSZĄ być zgodne implementacje urządzeń.

Parametr	Uwagi
WYDANIE WERSJI	Wersja aktualnie działającego systemu Android, w formacie czytelnym dla człowieka. To pole MUSI zawierać jedną z wartości ciągu znaków zdefiniowanych w [ Resources, 7 ].
WERSJA.SDK	Wersja aktualnie działającego systemu Android, w formacie dostępnym dla kodu aplikacji innych firm. W systemie Android 4.4 to pole MUSI mieć wartość całkowitą 19.
WERSJA.SDK_INT	Wersja aktualnie działającego systemu Android, w formacie dostępnym dla kodu aplikacji innych firm. W systemie Android 4.4 to pole MUSI mieć wartość całkowitą 19.
WERSJA.INKREMENTALNA	Wartość wybrana przez realizatora urządzenia, określająca konkretną wersję aktualnie działającego systemu Android, w formacie czytelnym dla człowieka. Tej wartości NIE WOLNO ponownie używać w przypadku różnych kompilacji udostępnianych użytkownikom końcowym. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany kontroli źródła został użyty do wygenerowania kompilacji. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
TABLICA	Wartość wybrana przez wdrażającego urządzenie, identyfikująca konkretny sprzęt wewnętrzny używany przez urządzenie, w formacie czytelnym dla człowieka. Możliwym zastosowaniem tego pola jest wskazanie konkretnej wersji płytki zasilającej urządzenie. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
MARKA	Wartość odzwierciedlająca markę związaną z urządzeniem, znaną użytkownikom końcowym. MUSI być w formacie czytelnym dla człowieka i POWINIEN reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
Procesor_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz Sekcję 3.3: Zgodność z natywnym interfejsem API .
Procesor_ABI2	Nazwa drugiego zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz Sekcję 3.3: Zgodność z natywnym interfejsem API .
URZĄDZENIE	Wartość wybrana przez realizatora urządzenia, zawierająca nazwę rozwinięcia lub nazwę kodową identyfikującą konfigurację cech sprzętowych i projekt przemysłowy urządzenia. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
ODCISK PALCA	Ciąg, który jednoznacznie identyfikuje tę kompilację. POWINIEN być w miarę czytelny dla człowieka. MUSI być zgodny z tym szablonem: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Na przykład: `acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys` Odcisk palca NIE MOŻE zawierać białych znaków. Jeśli inne pola zawarte w powyższym szablonie zawierają białe znaki, MUSZĄ one zostać zastąpione w odcisku palca kompilacji innym znakiem, takim jak znak podkreślenia („_”). Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII.
SPRZĘT KOMPUTEROWY	Nazwa sprzętu (z wiersza poleceń jądra lub /proc). POWINIEN być w miarę czytelny dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
GOSPODARZ	Ciąg znaków, który jednoznacznie identyfikuje host, na którym została zbudowana kompilacja, w formacie czytelnym dla człowieka. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
ID	Identyfikator wybrany przez wdrażającego urządzenie w celu odniesienia się do konkretnej wersji, w formacie czytelnym dla człowieka. To pole może być takie samo jak pole android.os.Build.VERSION.INCREMENTAL, ale POWINNO być wartością na tyle znaczącą, aby użytkownicy końcowi mogli rozróżnić kompilacje oprogramowania. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
MODEL	Wartość wybrana przez realizatora urządzenia, zawierająca nazwę urządzenia znaną użytkownikowi końcowemu. POWINNA to być ta sama nazwa, pod którą urządzenie jest sprzedawane i sprzedawane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
PRODUKT	Wartość wybrana przez wdrażającego urządzenie zawierająca nazwę rozwojową lub nazwę kodową konkretnego produktu (SKU), która POWINNA być unikalna w ramach tej samej marki. MUSI być czytelny dla człowieka, ale niekoniecznie jest przeznaczony do przeglądania przez użytkowników końcowych. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
SERYJNY	Numer seryjny sprzętu, który MUSI być dostępny. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^([a-zA-Z0-9]{6,20})$"` .
TAGI	Rozdzielana przecinkami lista tagów wybranych przez realizatora urządzenia, która dodatkowo wyróżnia kompilację. Na przykład „bez znaku, debugowanie”. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
CZAS	Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
TYP	Wartość wybrana przez realizatora urządzenia, określająca konfigurację środowiska uruchomieniowego kompilacji. To pole POWINNO mieć jedną z wartości odpowiadających trzem typowym konfiguracjom środowiska uruchomieniowego Androida: „user”, „userdebug” lub „eng”. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu `"^[a-zA-Z0-9.,_-]+$"` .
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).

3.2.3. Zamierzona kompatybilność

Implementacje urządzeń MUSZĄ być zgodne z systemem Android dotyczącym luźnego połączenia, zgodnie z opisem w poniższych sekcjach. Przez „honorowany” rozumie się, że osoba wdrażająca urządzenie MUSI udostępnić działanie lub usługę Androida, która określa pasujący filtr intencji oraz wiąże się i implementuje prawidłowe zachowanie dla każdego określonego wzorca intencji.

3.2.3.1. Podstawowe cele aplikacji

Projekt Android upstream definiuje szereg podstawowych aplikacji, takich jak kontakty, kalendarz, galeria zdjęć, odtwarzacz muzyki i tak dalej. Osoby wdrażające urządzenia MOGĄ zastąpić te aplikacje wersjami alternatywnymi.

Jednakże wszelkie takie alternatywne wersje MUSZĄ uwzględniać te same wzorce zamierzeń, które zapewnił wcześniejszy projekt. Na przykład, jeśli urządzenie zawiera alternatywny odtwarzacz muzyki, musi nadal przestrzegać wzorca intencji wydanego przez aplikacje innych firm w celu wybrania utworu.

Następujące aplikacje są uważane za podstawowe aplikacje systemu Android:

Zegar biurkowy
Przeglądarka
Kalendarz
Łączność
Galeria
Globalne wyszukiwanie
Wyrzutnia
Muzyka
Ustawienia

Podstawowe aplikacje systemu Android obejmują różne komponenty Aktywności lub Usługi, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub może mieć wartość „true”.

Dla każdej Aktywności lub Usługi zdefiniowanej w jednej z podstawowych aplikacji systemu Android, która nie jest oznaczona jako niepubliczna za pomocą atrybutu android:exported o wartości „false”, implementacje urządzenia MUSZĄ zawierać komponent tego samego typu implementujący ten sam filtr intencji wzorce jako podstawowa aplikacja systemu Android.

Innymi słowy, implementacja urządzenia MOŻE zastąpić podstawowe aplikacje systemu Android; jeśli jednak tak się stanie, implementacja urządzenia MUSI obsługiwać wszystkie wzorce intencji zdefiniowane przez każdą zastępowaną podstawową aplikację systemu Android.

3.2.3.2. Zastąpienie zamiaru

Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ umożliwiać zastąpienie każdego wzorca intencji, o którym mowa w sekcji 3.2.3.1, przez aplikacje innych firm. Domyślnie pozwala na to implementacja open source Androida; osobom wdrażającym urządzenia NIE WOLNO przypisywać specjalnych uprawnień aplikacjom systemowym do korzystania z tych wzorców zamierzeń ani uniemożliwiać aplikacjom stron trzecich wiązania się z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności, ale nie ogranicza się do wyłączenia interfejsu użytkownika „Chooser”, który pozwala użytkownikowi wybierać pomiędzy wieloma aplikacjami, z których wszystkie obsługują ten sam wzorzec intencji.

Jednakże implementacje urządzeń MOGĄ zapewniać domyślne działania dla określonych wzorców URI (np. http://play.google.com), jeśli domyślne działanie zapewnia bardziej szczegółowy filtr URI danych. Na przykład filtr intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż filtr przeglądarki dla „http://”. Implementacje urządzeń MUSZĄ zapewniać interfejs użytkownika umożliwiający użytkownikom modyfikowanie domyślnej aktywności dotyczącej intencji.

3.2.3.3. Przestrzenie nazw intencji

Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który uwzględnia nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu kluczy w przestrzeni nazw android.* lub com.android.*. Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnych komponentów Androida, które honorują jakiekolwiek nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu klucza w przestrzeni pakietu należącej do innej organizacji. Osoby wdrażające urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1. Implementacje urządzeń MOGĄ obejmować wzorce intencji wykorzystujące przestrzenie nazw wyraźnie i wyraźnie powiązane z ich własną organizacją.

Zakaz ten jest analogiczny do zakazu określonego dla klas języka Java w sekcji 3.6.

3.2.3.4. Zamierzenia transmisji

Aplikacje stron trzecich wykorzystują platformę do emitowania określonych intencji w celu powiadamiania ich o zmianach w środowisku sprzętu lub oprogramowania. Urządzenia kompatybilne z Androidem MUSZĄ nadawać publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje rozgłaszania są opisane w dokumentacji zestawu SDK.

3.2.3.5. Domyślne ustawienia aplikacji

W Androidzie 4.4 dodano ustawienia, które pozwalają użytkownikom wybrać domyślne aplikacje domowe i SMS-y. Implementacje urządzeń MUSZĄ zapewniać dla każdego podobne menu ustawień użytkownika, zgodne ze wzorcem filtra Intent i metodami API opisanymi w dokumentacji SDK [ Zasoby, 91 ].

3.3. Natywna kompatybilność API

3.3.1 Interfejsy binarne aplikacji

Kod zarządzany działający w Dalvik może wywoływać kod natywny dostarczony w pliku .apk aplikacji jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest w dużym stopniu zależny od podstawowej technologii procesora, system Android definiuje wiele interfejsów binarnych aplikacji (ABI) w pakiecie Android NDK w pliku docs/CPU-ARCH-ABIS.html . Jeśli implementacja urządzenia jest zgodna z jednym lub większą liczbą zdefiniowanych interfejsów ABI, POWINNA implementować zgodność z zestawem Android NDK, jak poniżej.

Jeśli implementacja urządzenia obejmuje obsługę interfejsu ABI systemu Android, to:

MUSI obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywołania kodu natywnego przy użyciu standardowej semantyki Java Native Interface (JNI)
MUSI być kompatybilny ze źródłem (tj. zgodny z nagłówkiem) i kompatybilny binarnie (dla ABI) z każdą wymaganą biblioteką z poniższej listy
MUSI dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pośrednictwem interfejsu API android.os.Build.CPU_ABI i parametrów android.os.Build.CPU_ABI2 .
MUSI raportować za pośrednictwem android.os.Build.CPU_ABI2 tylko te ABI udokumentowane w najnowszej wersji Androida NDK, w pliku docs/CPU-ARCH-ABIS.html
MUSI zgłosić za pośrednictwem android.os.Build.CPU_ABI tylko jeden z ABI wymienionych poniżej

armeabi-v7a
x86
mipsy

POWINNO zostać zbudowane przy użyciu kodu źródłowego i plików nagłówkowych dostępnych w pierwotnym projekcie Android Open Source

Dla aplikacji zawierających kod natywny MUSZĄ być dostępne następujące interfejsy API kodu natywnego:

libc (biblioteka C)
libm (biblioteka matematyczna)
Minimalne wsparcie dla C++
Interfejs JNI
liblog (logowanie na Androida)
libz (kompresja Zlib)
libdl (dynamiczny linker)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.0)
libEGL.so (natywne zarządzanie powierzchnią OpenGL)
libjnigraphics.so
libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
libandroid.so (natywna obsługa aktywności w systemie Android)
Obsługa OpenGL zgodnie z opisem poniżej

Należy pamiętać, że przyszłe wersje zestawu Android NDK mogą wprowadzać obsługę dodatkowych interfejsów ABI. Jeśli implementacja urządzenia nie jest kompatybilna z istniejącym, predefiniowanym ABI, NIE MOŻE w ogóle zgłaszać obsługi żadnego ABI.

Należy pamiętać, że implementacje urządzeń MUSZĄ zawierać bibliotekę libGLESv3.so oraz łącze symboliczne (symboliczne) do biblioteki libGLESv2.so. W implementacjach urządzeń, które deklarują obsługę OpenGL ES 3.0, libGLESv2.so MUSI eksportować symbole funkcji OpenGL ES 3.0 oprócz symboli funkcji OpenGL ES 2.0.

Zgodność kodu natywnego jest wyzwaniem. Z tego powodu należy powtórzyć, że BARDZO zachęca się twórców urządzeń do korzystania z wcześniejszych implementacji bibliotek wymienionych powyżej, aby zapewnić kompatybilność.

3.4. Zgodność sieciowa

3.4.1. Zgodność z WebView

Implementacja Androida Open Source wykorzystuje kod z projektu Chromium do implementacji android.webkit.WebView [ Zasoby, 10 ] . Ponieważ nie jest możliwe opracowanie kompleksowego zestawu testów dla systemu renderowania stron internetowych, osoby wdrażające urządzenia MUSZĄ używać określonej wersji Chromium w implementacji WebView. Konkretnie:

Implementacje urządzenia android.webkit.WebView MUSZĄ być oparte na kompilacji Chromium z pierwotnego projektu Android Open Source dla systemu Android 4.4. Ta kompilacja zawiera określony zestaw poprawek funkcjonalności i zabezpieczeń dla WebView. [ Zasoby, 83 ]
Ciąg agenta użytkownika zgłaszany przez WebView MUSI mieć następujący format:
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
- Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE .
- Wartość ciągu $(LOCALE) jest opcjonalna, POWINNA być zgodna z konwencjami ISO dotyczącymi kodu kraju i języka oraz POWINNA odnosić się do aktualnie skonfigurowanych ustawień regionalnych urządzenia. W przypadku pominięcia końcowy średnik MUSI zostać również usunięty.
- Wartość ciągu $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL .
- Wartość ciągu $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID .
- Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w pierwotnym projekcie Android Open Source.
- Implementacje urządzeń MOGĄ pomijać Mobile w ciągu agenta użytkownika.

Komponent WebView POWINIEN zawierać obsługę możliwie największej ilości HTML5 [ Zasoby, 11 ].

3.4.2. Zgodność przeglądarki

Implementacje urządzeń MUSZĄ obejmować samodzielną aplikację przeglądarki do przeglądania stron internetowych przez zwykłego użytkownika. Samodzielna przeglądarka MOŻE być oparta na technologii przeglądarki innej niż WebKit. Jednakże, nawet jeśli używana jest alternatywna aplikacja przeglądarki, komponent android.webkit.WebView dostarczany aplikacjom innych firm MUSI być oparty na WebKit, jak opisano w Sekcji 3.4.1.

Implementacje MOGĄ dostarczać niestandardowy ciąg agenta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (niezależnie od tego, czy jest oparta na wcześniejszej aplikacji przeglądarki WebKit, czy na zamienniku innej firmy) POWINNA obsługiwać możliwie najwięcej HTML5 [ Zasoby, 11 ]. Co najmniej implementacje urządzeń MUSZĄ obsługiwać każdy z tych interfejsów API powiązanych z HTML5:

pamięć podręczna aplikacji/działanie offline [ Zasoby, 12 ]
tag <video> [ Zasoby, 13 ]
geolokalizacja [ Zasoby, 14 ]

Ponadto implementacje urządzeń MUSZĄ obsługiwać interfejs API HTML5/W3C do przechowywania danych internetowych [ Zasoby, 15 ] i POWINNY obsługiwać interfejs API HTML5/W3C IndexedDB [ Zasoby, 16 ]. Należy pamiętać, że w miarę jak organy odpowiedzialne za standardy tworzenia stron internetowych będą faworyzować IndexedDB zamiast przechowywania danych w Internecie, oczekuje się, że IndexedDB stanie się wymaganym komponentem przyszłej wersji Androida.

3.5. Zgodność behawioralna API

Zachowanie każdego z typów API (zarządzanego, miękkiego, natywnego i internetowego) musi być spójne z preferowaną implementacją nadrzędnego projektu Android Open Source [ Zasoby, 3 ]. Niektóre konkretne obszary zgodności to:

Urządzenia NIE MOGĄ zmieniać zachowania ani semantyki standardowej Intencji
Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (takiego jak usługa, działanie, dostawca treści itp.).
Urządzenia NIE MOGĄ zmieniać semantyki standardowego pozwolenia

Powyższa lista nie jest kompletna. Zestaw testów zgodności (CTS) testuje znaczną część platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Obowiązkiem realizatora jest zapewnienie zgodności behawioralnej z projektem Android Open Source. Z tego powodu osoby wdrażające urządzenia POWINNY używać kodu źródłowego dostępnego w ramach projektu Android Open Source, tam gdzie to możliwe, zamiast ponownie wdrażać znaczące części systemu.

3.6. Przestrzenie nazw API

Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych przez język programowania Java. Aby zapewnić kompatybilność z aplikacjami innych firm, twórcom urządzeń NIE WOLNO wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:

Jawa.*
javax.*
słońce.*
android.*
com.android.*

Zabronione modyfikacje obejmują:

Implementacje urządzeń NIE WOLNO modyfikować publicznie udostępnionych interfejsów API na platformie Android poprzez zmianę jakichkolwiek podpisów metod lub klas albo poprzez usuwanie klas lub pól klas.
Osoby wdrażające urządzenia MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na określone zachowanie i podpis w języku Java jakichkolwiek publicznie udostępnianych interfejsów API.
Implementatorom urządzeń NIE WOLNO dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy albo pola lub metody do istniejących klas lub interfejsów) do powyższych interfejsów API.

„Element publicznie eksponowany” to dowolny konstrukt, który nie jest ozdobiony znacznikiem „@hide” używanym w pierwotnym kodzie źródłowym Androida. Innymi słowy, twórcom urządzeń NIE WOLNO ujawniać nowych interfejsów API ani zmieniać istniejących interfejsów API w przestrzeniach nazw wymienionych powyżej. Osoby wdrażające urządzenia MOGĄ wprowadzać modyfikacje wyłącznie do użytku wewnętrznego, ale modyfikacje te NIE MOGĄ być reklamowane ani w żaden inny sposób udostępniane programistom.

Osoby wdrażające urządzenia MOGĄ dodawać niestandardowe interfejsy API, ale żadne takie interfejsy API NIE MOGĄ znajdować się w przestrzeni nazw będącej własnością innej organizacji lub odnoszącej się do innej organizacji. Na przykład twórcom urządzeń NIE WOLNO dodawać interfejsów API do com.google.* lub podobnej przestrzeni nazw; może to zrobić tylko Google. Podobnie Google NIE WOLNO dodawać interfejsów API do przestrzeni nazw innych firm. Dodatkowo, jeśli implementacja urządzenia zawiera niestandardowe interfejsy API spoza standardowej przestrzeni nazw Androida, te interfejsy API MUSZĄ być spakowane w udostępnionej bibliotece Androida, aby zwiększone wykorzystanie pamięci miało wpływ tylko na aplikacje, które jawnie z nich korzystają (poprzez mechanizm <uses-library> ). takich interfejsów API.

Jeśli osoba wdrażająca urządzenie zaproponuje ulepszenie jednej z powyższych przestrzeni nazw pakietów (na przykład poprzez dodanie przydatnej nowej funkcjonalności do istniejącego interfejsu API lub dodanie nowego interfejsu API), osoba wdrażająca POWINNA odwiedzić stronę source.android.com i rozpocząć proces wprowadzania zmian i zgodnie z informacjami zawartymi na tej stronie.

Należy pamiętać, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java; ta sekcja ma po prostu na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi poprzez włączenie ich do niniejszej definicji zgodności.

3.7. Zgodność z maszyną wirtualną

Implementacje urządzeń MUSZĄ obsługiwać pełną specyfikację kodu bajtowego Dalvik Executable (DEX) i semantykę maszyny wirtualnej Dalvik [ Zasoby, 17 ].

Implementacje urządzeń MUSZĄ skonfigurować Dalvik do alokacji pamięci zgodnie z platformą Android i zgodnie z poniższą tabelą. (Zobacz sekcję 7.1.1 , aby zapoznać się z definicjami rozmiaru i gęstości ekranu.)

Należy pamiętać, że wartości pamięci określone poniżej są uważane za wartości minimalne, a implementacje urządzeń MOGĄ przydzielać więcej pamięci na aplikację.

Rozmiar ekranu	Gęstość ekranu	Pamięć aplikacji
mały / normalny / duży	ldpi/mdpi	16 MB
mały / normalny / duży	tvdpi/hdpi	32 MB
mały / normalny / duży	xhdpi	64 MB
mały / normalny / duży	400dpi	96 MB
mały / normalny / duży	xxHDPI	128MB
mały / normalny / duży	xxxhdpi	256 MB
xduży	mdpi	32 MB
xduży	tvdpi/hdpi	64 MB
xduży	xhdpi	128MB
xduży	400dpi	192 MB
xduży	xxHDPI	256 MB
xduży	xxxhdpi	512 MB

3.8. Zgodność interfejsu użytkownika

3.8.1. Program uruchamiający (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługę aplikacji innych firm, które zastępują program uruchamiający urządzenie (ekran główny). Implementacje urządzeń, które umożliwiają aplikacjom innych firm zastąpienie ekranu głównego urządzenia MUSZĄ deklarować funkcję platformy android.software.home_screen .

3.8.2. Widżety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który umożliwia aplikacjom udostępnianie „AppWidget” użytkownikowi końcowemu [ Zasoby, 18 ]. Implementacje urządzeń obsługujące osadzanie widżetów na ekranie głównym MUSZĄ spełniać poniższe wymagania i deklarować obsługę funkcji platformy android.software.app_widgets .

Programy uruchamiające urządzenia MUSZĄ zawierać wbudowaną obsługę AppWidgets i udostępniać interfejs użytkownika, aby móc dodawać, konfigurować, przeglądać i usuwać AppWidgets bezpośrednio w programie uruchamiającym.
Implementacje urządzeń MUSZĄ umożliwiać renderowanie widżetów o wymiarach 4 x 4 w standardowym rozmiarze siatki. (Szczegółowe informacje można znaleźć we wskazówkach dotyczących projektowania widżetów aplikacji w dokumentacji zestawu SDK systemu Android [ Zasoby, 18 ].
Implementacje urządzeń obejmujące obsługę ekranu blokady MUSZĄ obsługiwać widżety aplikacji na ekranie blokady.

3.8.3. Powiadomienia

Android zawiera interfejsy API, które umożliwiają programistom powiadamianie użytkowników o ważnych wydarzeniach [ Zasoby, 19 ] przy użyciu funkcji sprzętu i oprogramowania urządzenia.

Niektóre interfejsy API umożliwiają aplikacjom wykonywanie powiadomień lub przyciąganie uwagi za pomocą sprzętu, w szczególności dźwięku, wibracji i światła. Implementacje urządzeń MUSZĄ obsługiwać powiadomienia korzystające z funkcji sprzętowych, zgodnie z opisem w dokumentacji zestawu SDK i w zakresie, w jakim jest to możliwe w przypadku sprzętu implementującego urządzenie. Na przykład, jeśli implementacja urządzenia zawiera wibrator, MUSI poprawnie implementować interfejsy API wibracji. Jeśli w implementacji urządzenia brakuje sprzętu, odpowiednie interfejsy API MUSZĄ zostać zaimplementowane jako nieoperacyjne. Należy pamiętać, że to zachowanie jest szczegółowo opisane w sekcji 7.

Dodatkowo implementacja MUSI poprawnie renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) przewidziane w interfejsach API [ Zasoby, 20 ] lub w przewodniku po stylach ikon paska stanu/paska systemu [ Zasoby, 21 ]. Osoby wdrażające urządzenia MOGĄ zapewniać użytkownikowi alternatywne środowisko powiadomień niż zapewniane przez referencyjną implementację Android Open Source; jednakże takie alternatywne systemy powiadamiania MUSZĄ obsługiwać istniejące zasoby powiadamiania, jak powyżej.

Android obsługuje rozbudowane powiadomienia, takie jak interaktywne widoki bieżących powiadomień. Implementacje urządzeń MUSZĄ prawidłowo wyświetlać i wykonywać zaawansowane powiadomienia, zgodnie z dokumentacją w interfejsach API systemu Android.

3.8.4. Szukaj

Android zawiera interfejsy API [ Zasoby, 22 ], które umożliwiają programistom włączenie wyszukiwania do swoich aplikacji i udostępnienie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcjonalność składa się z jednego, ogólnosystemowego interfejsu użytkownika, który umożliwia użytkownikom wprowadzanie zapytań, wyświetla sugestie podczas wpisywania przez użytkownika i wyświetla wyniki. Interfejsy API systemu Android umożliwiają programistom ponowne wykorzystanie tego interfejsu do wyszukiwania w ich własnych aplikacjach oraz dostarczanie wyników do wspólnego interfejsu użytkownika wyszukiwania globalnego.

Implementacje urządzeń MUSZĄ obejmować pojedynczy, współdzielony, ogólnosystemowy interfejs użytkownika wyszukiwania, umożliwiający wyświetlanie sugestii w czasie rzeczywistym w odpowiedzi na dane wprowadzone przez użytkownika. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają programistom ponowne wykorzystanie tego interfejsu użytkownika w celu zapewnienia wyszukiwania we własnych aplikacjach. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono uruchamiane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm korzystające z tej funkcjonalności, domyślnym zachowaniem POWINNO być wyświetlanie wyników i sugestii wyszukiwarki internetowej.

3.8.5. Tosty

Aplikacje mogą używać interfejsu API „Toast” (zdefiniowanego w [ Resources, 23 ]) do wyświetlania użytkownikowi końcowemu krótkich, niemodalnych ciągów znaków, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać toasty z aplikacji dla użytkowników końcowych w jakiś dobrze widoczny sposób.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm umożliwiający aplikacjom stosowanie stylów w całej aktywności lub aplikacji.

Android zawiera rodzinę motywów „Holo” jako zestaw zdefiniowanych stylów, z których mogą korzystać twórcy aplikacji, jeśli chcą dopasować wygląd i działanie motywu Holo zgodnie z definicją w zestawie SDK systemu Android [ Zasoby, 24 ]. Implementacje urządzeń NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom [ Zasoby, 25 ].

System Android zawiera także rodzinę motywów „Device Default” jako zestaw zdefiniowanych stylów, z których mogą korzystać twórcy aplikacji, jeśli chcą dopasować wygląd i styl motywu urządzenia zgodnie z definicją osoby wdrażającej urządzenie. Implementacje urządzeń MOGĄ modyfikować atrybuty motywu DeviceDefault udostępniane aplikacjom [ Zasoby, 25 ].

Od wersji 4.4 system Android obsługuje teraz nowy wariant motywu z półprzezroczystymi paskami systemowymi, dzięki czemu twórcy aplikacji mogą wypełniać obszar za paskiem stanu i nawigacji zawartością aplikacji. Aby zapewnić spójność środowiska deweloperskiego w tej konfiguracji, ważne jest zachowanie stylu ikony paska stanu w różnych implementacjach urządzeń. Dlatego w implementacjach urządzeń z systemem Android MUSI być używany kolor biały dla ikon stanu systemu (takich jak siła sygnału i poziom naładowania baterii) oraz powiadomień wysyłanych przez system, chyba że ikona wskazuje problematyczny stan [ Zasoby, 25 ].

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który umożliwia aplikacjom udostępnianie użytkownikowi końcowemu jednej lub większej liczby „animowanych tapet” [ Zasoby, 26 ]. Animowane tapety to animacje, wzory i podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które są wyświetlane jako tapeta za innymi aplikacjami.

Uważa się, że sprzęt umożliwia niezawodne uruchamianie animowanych tapet, jeśli umożliwia uruchamianie wszystkich animowanych tapet, bez ograniczeń funkcjonalności, z rozsądną liczbą klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie, nieprawidłowe działanie tapet i/lub aplikacji, nadmierne zużycie energii procesora lub baterii albo działanie z niedopuszczalnie niską liczbą klatek na sekundę, uznaje się, że sprzęt nie jest w stanie uruchomić tapety na żywo. Na przykład niektóre animowane tapety mogą wykorzystywać kontekst Open GL 1.0 lub 2.0 do renderowania swojej zawartości. Animowana tapeta nie będzie działać niezawodnie na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ użycie animowanej tapety w kontekście OpenGL może powodować konflikt z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

Implementacje urządzeń umożliwiających niezawodne uruchamianie animowanych tapet, jak opisano powyżej, POWINNY implementować animowane tapety. Implementacje urządzeń, w przypadku których stwierdzono, że nie działają niezawodnie animowane tapety, jak opisano powyżej, NIE MOGĄ implementować animowanych tapet.

3.8.8. Wyświetlanie najnowszego zastosowania

Pierwotny kod źródłowy systemu Android zawiera interfejs użytkownika umożliwiający wyświetlanie najnowszych aplikacji przy użyciu miniaturowego obrazu stanu graficznego aplikacji w momencie ostatniego opuszczenia aplikacji przez użytkownika. Implementacje urządzeń MOGĄ zmienić lub wyeliminować ten interfejs użytkownika; planowana jest jednak przyszła wersja Androida, która będzie w większym stopniu wykorzystywać tę funkcjonalność. W przypadku implementacji urządzeń zdecydowanie zaleca się korzystanie z interfejsu użytkownika starszego systemu Android (lub podobnego interfejsu opartego na miniaturach) w przypadku najnowszych aplikacji, w przeciwnym razie mogą one nie być kompatybilne z przyszłą wersją Androida.

3.8.9. Zarządzanie wejściami

Android obejmuje obsługę zarządzania danymi wejściowymi i obsługę edytorów metod wprowadzania innych firm. Implementacje urządzeń, które umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm na urządzeniu, MUSZĄ deklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z definicją w dokumentacji zestawu SDK systemu Android.

Implementacje urządzeń deklarujące funkcję android.software.input_methods MUSZĄ zapewniać dostępny dla użytkownika mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania danych innych firm. Implementacje urządzeń MUSZĄ wyświetlać interfejs ustawień w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS .

3.8.10. Zdalne sterowanie multimediami na ekranie blokady

System Android obsługuje interfejs API zdalnego sterowania, który umożliwia aplikacjom multimedialnym integrację z elementami sterującymi odtwarzaniem wyświetlanymi w widoku zdalnym, np. na ekranie blokady urządzenia [ Zasoby, 74 ]. Implementacje urządzeń obsługujące ekran blokady w urządzeniu i umożliwiające użytkownikom dodawanie widżetów na ekranie głównym MUSZĄ obejmować obsługę osadzania pilotów na ekranie blokady urządzenia [ Zasoby, 69 ].

3.8.11. Sny

Android obsługuje interaktywne wygaszacze ekranu o nazwie Dreams [ Zasoby, 76 ]. Dreams umożliwia użytkownikom interakcję z aplikacjami, gdy urządzenie ładujące jest bezczynne lub zadokowane w stacji dokującej na biurku. Implementacje urządzeń MUSZĄ obejmować obsługę Dreams i zapewniać użytkownikom opcję konfiguracji Dreams.

3.8.12. Lokalizacja

Tryby lokalizacji MUSZĄ być wyświetlane w menu Lokalizacja w Ustawieniach [ Zasoby, 87 ]. Usługi lokalizacyjne świadczone za pośrednictwem usługi SettingInjectorService wprowadzonej w systemie Android 4.4 muszą być wyświetlane w tym samym menu lokalizacji [ Zasoby, 89 ].

3.8.13. Unikod

Android 4.4 obsługuje kolorowe znaki emoji. Implementacje urządzeń z systemem Android MUSZĄ zapewniać użytkownikowi metodę wprowadzania znaków Emoji zdefiniowanych w Unicode 6.1 [ Zasoby, 82 ] i MUSZĄ umożliwiać renderowanie tych znaków emoji w kolorowych glifach.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom dbającym o bezpieczeństwo wykonywanie funkcji administrowania urządzeniem na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł lub zdalne czyszczenie, za pośrednictwem interfejsu API administrowania urządzeniami z systemem Android [ Zasoby, 27 ]. Implementacje urządzeń MUSZĄ zapewniać implementację klasy DevicePolicyManager [ Zasoby, 28 ]. Implementacje urządzeń obejmujące obsługę ekranu blokady MUSZĄ obsługiwać pełny zakres zasad administrowania urządzeniami zdefiniowanych w dokumentacji zestawu SDK systemu Android [ Zasoby, 27 ].

Implementacje urządzeń MOGĄ mieć preinstalowaną aplikację wykonującą funkcje administracyjne urządzenia, ale ta aplikacja NIE MOŻE być instalowana od razu po wyjęciu z pudełka jako domyślna aplikacja właściciela urządzenia [ Zasoby, 84 ].

3.10. Dostępność

Android zapewnia warstwę ułatwień dostępu, która pomaga użytkownikom niepełnosprawnym łatwiej poruszać się po urządzeniach. Ponadto system Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu odbieranie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnych, takich jak zamiana tekstu na mowę, informacje dotykowe i nawigacja za pomocą trackballa/padu kierunkowego [ Zasoby, 29 ]. Implementacje urządzeń MUSZĄ zapewniać implementację struktury ułatwień dostępu Androida zgodną z domyślną implementacją Androida. W szczególności implementacje urządzeń MUSZĄ spełniać następujące wymagania.

Implementacje urządzeń MUSZĄ obsługiwać implementacje usług dostępności innych firm za pośrednictwem interfejsów API android.accessibilityservice [ Zasoby, 30 ].
Implementacje urządzeń MUSZĄ generować AccessibilityEvents i dostarczać te zdarzenia do wszystkich zarejestrowanych implementacji AccessibilityService w sposób zgodny z domyślną implementacją Androida.
Implementacje urządzeń MUSZĄ zapewniać dostępny dla użytkownika mechanizm włączania i wyłączania usług ułatwień dostępu i MUSZĄ wyświetlać ten interfejs w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS .

Ponadto implementacje urządzeń POWINNY zapewniać implementację usługi dostępności na urządzeniu i POWINNY zapewniać użytkownikom mechanizm umożliwiający włączenie usługi dostępności podczas konfiguracji urządzenia. Implementacja usługi dostępności typu open source jest dostępna w projekcie Eyes Free [ Zasoby, 31 ].

3.11. Tekst na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS) i umożliwia dostawcom usług zapewnianie implementacji usług TTS [ Zasoby, 32 ]. Implementacje urządzeń MUSZĄ spełniać te wymagania związane ze strukturą Android TTS:

Implementacje urządzeń MUSZĄ obsługiwać interfejsy API platformy Android TTS i POWINNY zawierać silnik TTS obsługujący języki dostępne na urządzeniu. Należy pamiętać, że oprogramowanie typu open source dla systemu Android zawiera w pełni funkcjonalną implementację silnika TTS.
Implementacje urządzeń MUSZĄ obsługiwać instalację silników TTS innych firm.
Implementacje urządzeń MUSZĄ zapewniać interfejs dostępny dla użytkownika, który umożliwia użytkownikom wybór silnika TTS do użycia na poziomie systemu.

4. Zgodność opakowań aplikacji

Implementacje urządzeń MUSZĄ instalować i uruchamiać pliki „.apk” systemu Android wygenerowane przez narzędzie „aapt” zawarte w oficjalnym zestawie SDK systemu Android [ Zasoby, 33 ].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów .apk [ Resources, 34 ], Android Manifest [ Resources, 35 ], Dalvik bytecode [ Resources, 17 ] ani formatu kodu bajtowego renderscript w sposób uniemożliwiający prawidłową instalację i działanie tych plików na komputerze inne kompatybilne urządzenia. Osoby wdrażające urządzenia POWINNY używać referencyjnej implementacji Dalvik i systemu zarządzania pakietami implementacji referencyjnej.

5. Kompatybilność multimediów

Implementacje urządzeń MUSZĄ obejmować co najmniej jedną formę wyjścia audio, taką jak głośniki, gniazdo słuchawkowe, złącze głośników zewnętrznych itp.

5.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać podstawowe formaty multimediów określone w dokumentacji zestawu SDK systemu Android [ Zasoby, 58 ], chyba że jest to wyraźnie dozwolone w tym dokumencie. W szczególności implementacje urządzeń MUSZĄ obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów określone w poniższych tabelach. Wszystkie te kodeki są dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.

Należy pamiętać, że ani firma Google, ani organizacja Open Handset Alliance nie zapewniają, że te kodeki nie są obciążone patentami stron trzecich. Osobom zamierzającym używać tego kodu źródłowego w sprzęcie lub oprogramowaniu informuje się, że implementacje tego kodu, w tym w oprogramowaniu typu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich posiadaczy patentów.

Należy pamiętać, że w tabelach tych nie wymieniono konkretnych wymagań dotyczących szybkości transmisji bitów dla większości kodeków wideo, ponieważ obecny sprzęt urządzenia niekoniecznie obsługuje przepływności dokładnie odpowiadające wymaganym przepływnościom określonym przez odpowiednie standardy. Zamiast tego implementacje urządzeń POWINNY obsługiwać najwyższą przepływność bitową praktyczną na sprzęcie, aż do limitów określonych w specyfikacjach.

Typ	Format/kodek	Koder	Dekoder	Detale	Typy plików/formaty kontenerów
Audio	Profil MPEG-4 AAC (AAC LC)	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt mikrofonowy i definiujących `android.hardware.microphone` .	WYMAGANY	Obsługa treści mono/stereo/5.0/5.1* przy standardowych częstotliwościach próbkowania od 8 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, dekodowanie w systemie Android 3.1+, kodowanie w systemie Android 4.0+, ADIF nie jest obsługiwane) MPEG-TS (.ts, brak możliwości wyszukiwania, Android 3.0 lub nowszy)
	Profil MPEG-4 HE AAC (AAC+)	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt mikrofonowy i definiujących android.hardware.microphone	WYMAGANY	Obsługa treści mono/stereo/5.0/5.1* przy standardowych częstotliwościach próbkowania od 16 do 48 kHz.
	Profil MPEG-4 HE AAC v2 (ulepszony AAC+)		WYMAGANY	Obsługa treści mono/stereo/5.0/5.1* przy standardowych częstotliwościach próbkowania od 16 do 48 kHz.
	Typ obiektu audio MPEG-4 ER AAC ELD (Enhanced Low Delay AAC)	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt mikrofonowy i definiujących android.hardware.microphone	WYMAGANY	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
	AMR-NB	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt mikrofonowy i definiujących `android.hardware.microphone` .	WYMAGANY	Próbkowanie od 4,75 do 12,2 kb/s przy 8 kHz	3GPP (.3gp)
	AMR-WB	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt mikrofonowy i definiujących `android.hardware.microphone` .	WYMAGANY	9 szybkości od 6,60 kbit/s do 23,85 kbit/s, próbkowanie przy 16 kHz	3GPP (.3gp)
	FLAC		WYMAGANY (Android 3.1+)	Mono/Stereo (bez trybu wielokanałowego). Częstotliwości próbkowania do 48 kHz (ale do 44,1 kHz jest zalecane w przypadku urządzeń z wyjściem 44,1 kHz, ponieważ moduł próbkowania od 48 do 44,1 kHz nie zawiera filtra dolnoprzepustowego). Zalecany 16-bitowy; nie zastosowano ditheringu dla wersji 24-bitowej.	Tylko FLAC (.flac).
	MP3		WYMAGANY	Mono/Stereo 8–320 Kb/s, stała (CBR) lub zmienna przepływność (VBR)	MP3 (.mp3)
	MIDI		WYMAGANY	MIDI Typ 0 i 1. DLS Wersja 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Wpisz 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbisa		WYMAGANY		Ogg (.ogg) Matroska (.mkv)
	PCM/FALA	WYMAGANY	WYMAGANY	8-bitowy i 16-bitowy liniowy PCM** (szybkość do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nagrywania surowego PCM przy częstotliwościach 8000,16000 i 44100 Hz	FALI (.wav)
Obraz	JPG	WYMAGANY	WYMAGANY	Podstawowy+progresywny	JPEG (.jpg)
	GIF-y		WYMAGANY		GIF (.gif)
	PNG	WYMAGANY	WYMAGANY		PNG (.png)
	BMP		WYMAGANY		BMP (.bmp)
	WEBP	WYMAGANY	WYMAGANY		WebP (.webp)
Wideo	H.263	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt kamery i definiujących `android.hardware.camera` lub `android.hardware.camera.front` .	WYMAGANY		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	WYMAGANE w przypadku implementacji urządzeń obejmujących sprzęt kamery i definiujących `android.hardware.camera` lub `android.hardware.camera.front` .	WYMAGANY	Profil bazowy (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, tylko dźwięk AAC, brak możliwości wyszukiwania, Android 3.0 lub nowszy)
	MPEG-4 SP		WYMAGANY		3GPP (.3gp)
	VP8****	WYMAGANY (Android 4.3+)	WYMAGANY (Android 2.3.3+)		WebM (.webm) i Matroska (.mkv, Android 4.0+)***
	VP9		WYMAGANY (Android 4.4+)		WebM (.webm) i Matroska (.mkv, Android 4.0+)***

*Uwaga: wymagany jest wyłącznie downmiks zawartości 5.0/5.1; nagrywanie lub renderowanie więcej niż 2 kanałów jest opcjonalne.
**Uwaga: 16-bitowe liniowe przechwytywanie PCM jest obowiązkowe. Przechwytywanie 8-bitowego liniowego sygnału PCM nie jest obowiązkowe.
***Uwaga: implementacje urządzeń POWINNY umożliwiać zapisywanie plików Matroska WebM.
****Uwaga: Aby zapewnić akceptowalną jakość usług strumieniowego przesyłania wideo w Internecie i wideokonferencji, implementacje urządzeń POWINNY używać sprzętowego kodeka VP8, który spełnia wymagania zawarte w [ Zasoby, 86 ].

5.2. Kodowanie wideo

Implementacje urządzeń z Androidem, które zawierają kamerę skierowaną do tyłu i deklarują android.hardware.camera POWINNY obsługiwać następujące profile kodowania wideo H.264.

	SD (niska jakość)	SD (wysoka jakość)	HD (jeśli jest obsługiwany przez sprzęt)
Rozdzielczość wideo	176 x 144 pikseli	480 x 360 pikseli	1280 x 720 pikseli
Ilość klatek	12 kl./s	30 kl./s	30 kl./s
Szybkość transmisji wideo	56 Kb/s	500 Kb/s lub więcej	2 Mb/s lub więcej
Kodek audio	AAC-LC	AAC-LC	AAC-LC
Kanały audio	1 (mono)	2 (stereo)	2 (stereo)
Szybkość transmisji dźwięku	24 Kb/s	128 Kb/s	192 Kb/s

Implementacje urządzeń z Androidem, które zawierają kamerę skierowaną do tyłu i deklarują android.hardware.camera POWINNY obsługiwać następujące profile kodowania wideo VP8

	SD (niska jakość)	SD (wysoka jakość)	HD 720p (Jeśli jest obsługiwany przez sprzęt)	HD 1080p (Jeśli jest obsługiwany przez sprzęt)
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Ilość klatek	30 kl./s	30 kl./s	30 kl./s	30 kl./s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.3. Dekodowanie wideo

Implementacje urządzeń z systemem Android POWINNY obsługiwać następujące profile dekodowania wideo VP8, VP9 i H.264. Implementacje urządzeń POWINNY także obsługiwać dynamiczne przełączanie rozdzielczości wideo w tym samym strumieniu dla kodeków VP8, VP9 i H.264.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p (Jeśli jest obsługiwany przez sprzęt)	HD 1080p (Jeśli jest obsługiwany przez sprzęt)
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Ilość klatek	30 kl./s	30 kl./s	30 kl./s	30 kl./s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.4. Nagrywanie dźwięku

Gdy aplikacja korzysta z interfejsu API android.media.AudioRecord w celu rozpoczęcia nagrywania strumienia audio, implementacje urządzeń zawierające sprzęt mikrofonowy i deklarujące android.hardware.microphone MUSZĄ próbkować i nagrywać dźwięk przy każdym z poniższych zachowań:

Urządzenie POWINNO wykazywać w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości; w szczególności ±3 dB, od 100 Hz do 4000 Hz
Czułość wejściową audio NALEŻY ustawić tak, aby źródło mocy akustycznej (SPL) o poziomie mocy akustycznej 90 dB przy 1000 Hz dawało wartość RMS 2500 dla próbek 16-bitowych.
Poziomy amplitudy PCM POWINNY liniowo śledzić zmiany wejściowego SPL w zakresie co najmniej 30 dB od -18 dB do +12 dB w odniesieniu do 90 dB SPL na mikrofonie.
Całkowite zniekształcenia harmoniczne POWINNY być mniejsze niż 1% dla 1 kHz przy poziomie wejściowym SPL 90 dB.

Oprócz powyższych specyfikacji nagrywania, gdy aplikacja rozpoczęła nagrywanie strumienia audio przy użyciu źródła dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

Przetwarzanie redukcji szumów, jeśli jest obecne, MUSI zostać wyłączone.
Automatyczna kontrola wzmocnienia, jeśli jest obecna, MUSI być wyłączona.

Od wersji Androida 4.4 klasa android.media.MediaRecorder.AudioSource ma nowe źródło dźwięku: REMOTE_SUBMIX . Urządzenia MUSZĄ prawidłowo implementować źródło dźwięku REMOTE_SUBMIX , aby aplikacja korzystająca z interfejsu API android.media.AudioRecord do nagrywania z tego źródła dźwięku mogła przechwytywać miks wszystkich strumieni audio z wyjątkiem następujących:

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

Uwaga: chociaż niektóre wymagania opisane powyżej są określone jako „POWINNY” od wersji Androida 4.3, w definicji zgodności w przyszłej wersji planuje się zmienić je na „MUSI”. Oznacza to, że te wymagania są opcjonalne w Androidzie 4.4, ale będą wymagane w przyszłej wersji. Zdecydowanie zaleca się, aby istniejące i nowe urządzenia z systemem Android spełniały te wymagania , w przeciwnym razie nie będą w stanie zapewnić zgodności z systemem Android po aktualizacji do przyszłej wersji.

Jeśli platforma obsługuje technologie tłumienia szumów dostosowane do rozpoznawania mowy, efektem MUSI być kontrolowanie za pomocą interfejsu API android.media.audiofx.NoiseSuppressor . Co więcej, pole „uuid” deskryptora efektu tłumika szumów MUSI jednoznacznie identyfikować każdą implementację technologii tłumienia szumów.

5.5. Opóźnienie dźwięku

Opóźnienie dźwięku to opóźnienie czasowe, w jakim sygnał audio przechodzi przez system. Wiele klas aplikacji opiera się na krótkich opóźnieniach, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

Na potrzeby tej sekcji:

„opóźnienie wyjściowe” definiuje się jako odstęp między zapisaniem przez aplikację ramki danych zakodowanych w formacie PCM a momentem, gdy odpowiedni dźwięk może zostać usłyszany przez zewnętrzny słuchacz lub zaobserwowany przez przetwornik
„zimne opóźnienie wyjściowe” definiuje się jako opóźnienie wyjściowe dla pierwszej ramki, gdy wyjściowy system audio był bezczynny i wyłączony przed żądaniem
„ciągłe opóźnienie wyjściowe” definiuje się jako opóźnienie wyjściowe dla kolejnych klatek, gdy urządzenie już odtwarza dźwięk
„opóźnienie wejściowe” to odstęp czasu między przedstawieniem do urządzenia dźwięku zewnętrznego a odczytaniem przez aplikację odpowiedniej ramki danych zakodowanych w formacie PCM
„zimne opóźnienie wejścia” definiuje się jako sumę utraconego czasu wejścia i opóźnienia wejścia dla pierwszej ramki, gdy system wejściowy audio był bezczynny i wyłączony przed żądaniem
„ciągłe opóźnienie wejścia” definiuje się jako opóźnienie wejścia dla kolejnych klatek, podczas gdy urządzenie już przechwytuje dźwięk
„OpenSL ES PCM bufor kolejki API” to zestaw powiązanych z PCM interfejsów API OpenSL ES w systemie Android NDK; zobacz NDK_root /docs/opensles/index.html

Zgodnie z sekcją 5 wszystkie kompatybilne implementacje urządzeń MUSZĄ zawierać co najmniej jedną formę wyjścia audio. Implementacje urządzeń POWINNY spełniać lub przekraczać następujące wymagania dotyczące opóźnień wyjściowych:

Opóźnienie zimnego wyjścia wynoszące 100 milisekund lub mniej
ciągłe opóźnienie wyjściowe 45 milisekund lub mniej

Jeśli implementacja urządzenia spełnia wymagania niniejszej sekcji po jakiejkolwiek początkowej kalibracji podczas korzystania z interfejsu API w kolejce bufora OpenSl ES PCM, dla ciągłego opóźnienia wyjściowego i opóźnienia wyjściowego na co najmniej jednym obsługiwanym urządzeniu wyjściowym audio, może zgłaszać obsługę dźwięku o niskiej opóźnieniu audio , zgłaszając funkcję „Android.hardware.audio.low-Latency” za pośrednictwem klasy android.content.pm.PackageManager . [ Zasoby, 37 ] I odwrotnie, jeśli wdrożenie urządzenia nie spełnia tych wymagań, nie może zgłaszać obsługi dźwięku o niskiej opóźnieniu.

W sekcji 7.2.5 Sprzęt mikrofonowy może być pominięty przez implementacje urządzeń.

Implementacje urządzeń, które obejmują sprzęt mikrofonowy i deklarują android.hardware.microphone powinny spełniać te wejściowe wymagania opóźnienia dźwięku:

Opóźnienie zimnego wejścia 100 milisekund lub mniej
ciągłe opóźnienie wejściowe 50 milisekund lub mniej

5.6. Protokoły sieciowe

Urządzenia muszą obsługiwać protokoły sieci multimediów do odtwarzania audio i wideo, jak określono w dokumentacji Android SDK [ Resources, 58 ]. W szczególności urządzenia muszą obsługiwać następujące protokoły sieci mediów:

RTSP (RTP, SDP)
Progresywne przesyłanie strumieniowe HTTP
HTTP (S) Protokół przesyłania strumieniowego na żywo, wersja 3 [ Zasoby, 59 ]

6. Zgodność narzędzi i opcji programistycznych

6.1. Narzędzia deweloperskie

Implementacje urządzeń muszą obsługiwać narzędzia programistów Androida dostarczone w systemie Android SDK. W szczególności urządzenia kompatybilne z Androidem muszą być kompatybilne z:

Android Debug Bridge (znany jako ADB) [ Resources, 33 ]
Implementacje urządzeń muszą obsługiwać wszystkie funkcje adb , jak udokumentowano w systemie Android SDK. Demon adb po stronie urządzenia musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika do włączenia mostu debugowego Androida.
Android zawiera obsługę bezpiecznego ADB. Secure ADB umożliwia ADB na znanych uwierzytelnionych hostach. Implementacje urządzeń muszą obsługiwać bezpieczny ADB.
Dalvik Debug Monitor Service (znany jako DDMS) [ Resources, 33 ]
Implementacje urządzeń muszą obsługiwać wszystkie funkcje ddms , jak udokumentowano w systemie Android SDK. Ponieważ ddms korzysta z adb , obsługa ddms powinna być domyślnie nieaktywna, ale musi być obsługiwana za każdym razem, gdy użytkownik aktywuje most debugowania Androida, jak wyżej.
Monkey [ Resources, 36 ]
Implementacje urządzeń muszą zawierać Framework Monkey i udostępnić je do korzystania z aplikacji.
SYSTRACE [ Zasoby, 33 ]
Implementacje urządzeń muszą obsługiwać narzędzie Systrace, jak udokumentowano w systemie Android SDK. Systrace musi być domyślnie nieaktywna i musi istnieć mechanizm dostępny dla użytkownika do włączenia Systrace.

Większość systemów opartych na systemie Linux i Apple Macintosh rozpoznaje urządzenia z Androidem za pomocą standardowych narzędzi SDK z Androidem, bez dodatkowego wsparcia; Jednak systemy Microsoft Windows zazwyczaj wymagają sterownika nowych urządzeń z Androidem. (Na przykład nowe identyfikatory dostawców, a czasem nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB dla systemów systemu Windows.) Jeśli implementacja urządzenia jest nierozpoznana przez narzędzie adb , jak podano w standardowym systemie Android SDK, implementatorzy urządzeń muszą zapewnić sterowniki Windows umożliwiające programistom łączenie się urządzenie za pomocą protokołu adb . Sterowniki te muszą być dostarczone dla systemu Windows XP, Windows Vista, Windows 7 i Windows 8, zarówno w wersji 32-bitowej, jak i 64-bitowej.

6.2. Opcje programistyczne

Android zawiera obsługę programistów w konfigurowaniu ustawień związanych z tworzeniem aplikacji. Implementacje urządzeń muszą uhonorować Android.Settings.application_development_settings, aby pokazać ustawienia związane z opracowywaniem aplikacji [ Zasoby, 77 ]. Implementacja z Androidem na Androidzie Upstream domyślnie ukrywa menu opcji programistów i umożliwia użytkownikom uruchamianie opcji programisty po naciśnięciu siedmiu (7) razy w ustawieniach> O elemencie menu numeru. Implementacje urządzeń muszą zapewnić spójne wrażenia dla opcji programistów. W szczególności implementacje urządzeń muszą domyślnie ukryć opcje programistów i muszą zapewnić mechanizm umożliwiający opcje programistów zgodne z implementacją Androida w górę.

6.2.1. Eksperymentalny

Android 4.4 wprowadza ART, eksperymentalny czas wykonawczy z systemem Android, dostępny w menu opcji programistów do podglądu. Implementacje urządzeń powinny obejmować ART (libart.so) i obsługiwać podwójny rozruch z opcji programistów, ale muszą zachować Dalvik (libdvm.so) jako domyślny czas wykonywania.

7. Kompatybilność sprzętu

Jeśli urządzenie zawiera konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla twórców stron trzecich, implementacja urządzenia musi zaimplementować ten interfejs API, jak opisano w dokumentacji Android SDK. Jeśli interakcja API w SDK oddziałuje z komponentem sprzętowym, który jest opcjonalny, a implementacja urządzenia nie posiada tego komponentu:

Kompletne definicje klas (jak udokumentowane przez SDK) dla interfejsów API komponentu muszą być nadal obecne
Zachowania interfejsu API muszą być wdrażane jako brak-ops w jakiś rozsądny sposób
Metody API muszą zwrócić wartości zerowe, w których dozwolone przez dokumentację SDK
Metody API muszą zwrócić implementacje NO-OP klas, w których wartości zerowe nie są dozwolone przez dokumentację SDK
Metody API nie mogą rzucać wyjątkami, które nie udokumentowane przez dokumentację SDK

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefoniczne interfejsy API muszą być wdrażane jako rozsądne brak.

Implementacje urządzeń muszą dokładnie zgłaszać dokładne informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) na klasie android.content.pm.PackageManager . [ Zasoby, 37 ]

7.1. Wyświetlacz i grafika

Android zawiera urządzenia, które automatycznie dostosowują zasoby aplikacji i układy interfejsu użytkownika odpowiednio dla urządzenia, aby zapewnić, że aplikacje stron trzecich działają dobrze w różnych konfiguracjach sprzętowych [ zasoby, 38 ]. Urządzenia muszą prawidłowo zaimplementować te interfejsy API i zachowania, jak szczegółowo opisano w tej sekcji.

Jednostki odnoszące się do wymagań w niniejszej sekcji są zdefiniowane w następujący sposób:

„Fizyczny rozmiar przekątny” to odległość w calach między dwoma przeciwnymi zakątkami oświetlonej części wyświetlacza.
„DPI” (oznacza „kropki na cal”) to liczba pikseli objęty liniowym rozpiętością poziomym lub pionowym 1 ”. W przypadku wymienionych wartości DPI zarówno poziome, jak i pionowe DPI muszą być w zakresie.
„Współczynnik kształtu” to stosunek dłuższego wymiaru ekranu do krótszego wymiaru. Na przykład wyświetlacz 480x854 pikseli wynosiłby 854 /480 = 1,779, lub około „16: 9”.
„Piksel niezależny od gęstości” lub („dp”) to wirtualna jednostka pikseli znormalizowana do ekranu 160 dpi, obliczona jako: pixels = dps * (density / 160) .

7.1.1. Konfiguracja ekranu

Rozmiar ekranu

Framework interfejsu użytkownika Android obsługuje różne rozmiary ekranu i pozwala aplikacjom na zapytanie o rozmiar ekranu urządzenia (czyli „układ ekranu”) za pośrednictwem android.content.res.Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK . Implementacje urządzeń muszą zgłosić prawidłowy rozmiar ekranu zgodnie z definicją w dokumentacji Androida SDK [ zasoby, 38 ] i określone przez platformę Android na Android. W szczególności implementacje urządzeń muszą zgłosić prawidłowy rozmiar ekranu zgodnie z następującymi wymiarami ekranu Pixel niezależne od gęstości logicznej.

Urządzenia muszą mieć rozmiary ekranu co najmniej 426 dp x 320 dp („mały”)
Urządzenia, które zgłaszają rozmiar ekranu „normalny”, muszą mieć rozmiary ekranu co najmniej 480 dp x 320 dp
Urządzenia, które zgłaszają rozmiar ekranu „Large”, muszą mieć rozmiary ekranu co najmniej 640 dp x 480 dp
Urządzenia, które zgłaszają rozmiar ekranu „Xlarge”, muszą mieć rozmiary ekranu co najmniej 960 dp x 720 dp

Ponadto urządzenia muszą mieć rozmiary ekranu o co najmniej 2,5 cala w fizycznym rozmiarze przekątnej.

Urządzenia nie mogą w żadnym momencie zmieniać zgłoszonego rozmiaru ekranu.

Aplikacje opcjonalnie wskazują, które rozmiary ekranu obsługują za pośrednictwem atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje urządzeń muszą poprawnie honorować podaną obsługę aplikacji dla małych, normalnych, dużych, dużych i Xlarge, jak opisano w dokumentacji Android SDK.

Proporcje ekranu

Współczynnik kształtu musi być wartością od 1,3333 (4: 3) do 1,86 (około 16: 9)

Gęstość ekranu

Ramy interfejsu użytkownika Androida definiuje zestaw standardowych gęstości logicznej, aby pomóc programistom aplikacji w ukierunkowaniu zasobów aplikacji. Implementacje urządzeń muszą zgłosić jedną z następujących gęstości logicznych systemów Android Framework za pośrednictwem interfejsów API android.util.DisplayMetrics i muszą wykonywać aplikacje przy tej standardowej gęstości.

120 DPI, znane jako „LDPI”
160 DPI, znany jako „MDPI”
213 DPI, znane jako „TVDPI”
240 DPI, znany jako „HDPI”
320 DPI, znany jako „XHDPI”
400 DPI, znane jako „400dpi”
480 DPI, znane jako „xxhdpi”
640 DPI, znane jako „xxxhdpi”

Implementacje urządzeń powinny zdefiniować standardową gęstość systemu Android Framework, która jest liczbowo najbliżej gęstości fizycznej ekranu, chyba że ta gęstość logiczna popycha zgłoszony rozmiar ekranu poniżej minimalnego obsługiwanego. Jeśli standardowa gęstość systemu Android Framework, która jest numerycznie najbliżej gęstości fizycznej, powoduje rozmiar ekranu, który jest mniejszy niż najmniejszy obsługiwany kompatybilny rozmiar ekranu (szerokość 320 dp), implementacje urządzeń powinny zgłosić kolejną najniższą gęstość standardowej struktury Androida.

7.1.2. Wyświetl metryki

Implementacje urządzeń muszą zgłaszać prawidłowe wartości dla wszystkich wskaźników wyświetlania zdefiniowanych w android.util.DisplayMetrics [ Resources, 39 ].

7.1.3. Orientacja ekranu

Urządzenia muszą obsługiwać dynamiczną orientację według aplikacji do orientacji ekranu portretowego lub krajobrazu. Oznacza to, że urządzenie musi szanować żądanie aplikacji dotyczące określonej orientacji ekranu. Implementacje urządzeń mogą wybrać orientację portretową lub krajobrazową jako domyślną.

Urządzenia muszą zgłosić prawidłową wartość bieżącej orientacji urządzenia, za każdym razem, gdy jest zapytany za pośrednictwem Android.Content.Res.Configuration.orientacja, Android.View.display.getorientation () lub inne interfejsy API.

Urządzenia nie mogą zmieniać zgłoszonego rozmiaru lub gęstości ekranu podczas zmiany orientacji.

Urządzenia muszą zgłaszać, które orientacje ekranowe obsługują ( android.hardware.screen.portrait i/lub android.hardware.screen.landscape ) i muszą zgłosić co najmniej jedną obsługiwaną orientację. Na przykład urządzenie z ekranem krajobrazu o stałej orientacji, takie jak telewizja lub laptop, musi zgłaszać tylko android.hardware.screen.landscape .

7.1.4. Akceleracja grafiki 2D i 3D

Implementacje urządzeń muszą obsługiwać zarówno OpenGL ES 1.0, jak i 2.0, w sposób uosabiany i szczegółowy w dokumentacjach SDK z Androidem. Implementacje urządzeń powinny obsługiwać OpenGL ES 3.0 na urządzeniach zdolnych do obsługi OpenGL ES 3.0. Implementacje urządzeń muszą również obsługiwać Android RenderScript, jak szczegółowo opisano w dokumentacji Android SDK [ Zasoby, 8 ].

Implementacje urządzeń muszą również poprawnie identyfikować się jako obsługujące OpenGL ES 1.0, OpenGL ES 2.0 lub OpenGL ES 3.0. To jest:

Zarządzane interfejsy API (takie jak metoda GLES10.getString() ) muszą zgłosić obsługę OpenGL ES 1.0 i OpenGL ES 2.0
Natywne interfejsy API OpenGL C/C ++ (to znaczy dostępne dla aplikacji za pośrednictwem libgles_v1cm.so, libgles_v2.so lub libgl.so) muszą zgłaszać obsługę OpenGL ES 1.0 i OpenGL ES 2.0.
Implementacje urządzeń, które deklarują obsługę OpenGL ES 3.0, muszą obsługiwać interfejsy API zarządzane OpenGL ES 3.0 i zawierać obsługę natywnych interfejsów API C/C ++. W przypadku implementacji urządzeń, które deklarują obsługę OpenGL ES 3.0, LibGleSv2.To musi wyeksportować symbole funkcji OpenGL ES 3.0 oprócz symboli funkcji OpenGL ES 2.0.

Implementacje urządzeń mogą wdrożyć wszelkie pożądane rozszerzenia OpenGL ES. Jednak implementacje urządzeń muszą zgłaszać za pośrednictwem zarządzanych i natywnych interfejsów API OpenGL Evel API, które obsługują, i odwrotnie nie mogą zgłaszać ciągów rozszerzenia, których nie obsługują.

Należy pamiętać, że Android zawiera obsługę aplikacji, aby opcjonalnie określić, że wymagają one określonych formatów kompresji tekstury OpenGL. Formaty te są zazwyczaj specyficzne dla dostawcy. Wdrożenia urządzeń nie są wymagane przez Androida w celu wdrożenia jakiegokolwiek konkretnego formatu kompresji tekstury. Powinny jednak dokładnie zgłosić dowolne formaty kompresji tekstury, które obsługują, metodą getString() w API OpenGL.

Android zawiera mechanizm aplikacji do deklarowania, że chcą włączyć przyspieszenie sprzętowe dla grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą manifestowanego tagu android:hardwareAccelerated lub bezpośrednie wywołania interfejsu API [ zasoby, 9 ].

W Android 4.4 implementacje urządzeń muszą domyślnie włączyć przyspieszenie sprzętowe i muszą wyłączyć przyspieszenie sprzętowe, jeśli programista poprosi, aby ustawienie android:hardwareAccelerated="false" lub wyłączanie przyspieszenia sprzętowego bezpośrednio za pośrednictwem API View Androida.

Ponadto implementacje urządzeń muszą wykazywać zachowanie zgodne z dokumentacją Androida SDK na temat przyspieszenia sprzętu [ Zasoby, 9 ].

Android zawiera obiekt TextureView , który pozwala programistom bezpośrednio integrować faktury OpenGL-accelerowane sprzętowo jako cele renderujące w hierarchii interfejsu użytkownika. Implementacje urządzeń muszą obsługiwać interfejs API TextureView i muszą wykazywać spójne zachowanie z implementacją Androida na Androidzie.

Android zawiera obsługę EGL_ANDROID_RECORDABLE , atrybut EGLConfig, który wskazuje, czy EGLConfig obsługuje renderowanie anativeWindow, który rejestruje obrazy do filmu. Implementacje urządzeń muszą obsługiwać rozszerzenie EGL_ANDROID_RECORDABLE [ Resources, 79 ].

7.1.5. Tryb zgodności starszych aplikacji

Android określa „tryb kompatybilności”, w którym framework działa w trybie „normalnego” wielkości ekranu (szerokość 320 dp) z korzyścią dla starszych aplikacji nie opracowanych dla starych wersji Androida, które wcześniej nie są w stanie niezależności wielkości ekranu. Implementacje urządzeń muszą zawierać obsługę starszego trybu kompatybilności aplikacji, zaimplementowany przez kod open source z Android. Oznacza to, że implementacje urządzeń nie mogą zmieniać wyzwalaczy ani progów, w których tryb kompatybilności jest aktywowany i nie mogą zmieniać zachowania samego trybu kompatybilności.

7.1.6. Typy ekranu

Ekrany implementacji urządzeń są klasyfikowane jako jeden z dwóch typów:

Implementacje wyświetlania o stałym piksele: Ekran to pojedynczy panel, który obsługuje tylko szerokość i wysokość pojedynczego piksela. Zazwyczaj ekran jest fizycznie zintegrowany z urządzeniem. Przykłady obejmują telefony komórkowe, tablety i tak dalej.
Implementacje wyświetlania zmiennych pikseli: Implementacja urządzenia nie ma wbudowanego ekranu i zawiera port wyjściowy wideo, taki jak VGA, HDMI lub port bezprzewodowy do wyświetlania, lub ma osadzony ekran, który może zmienić wymiary pikseli. Przykłady obejmują telewizory, pudełka z zestawem i tak dalej.

Implementacje urządzeń o stałym pikselu

Implementacje urządzeń o stałym pikselu mogą wykorzystywać ekrany o dowolnych wymiarach pikseli, pod warunkiem, że spełniają one wymagania określone w tej definicji zgodności.

Implementacje o stałym pikseli mogą zawierać port wyjściowy wideo do użytku z wyświetlaczem zewnętrznym. Jeśli jednak ten wyświetlacz jest kiedykolwiek używany do uruchamiania aplikacji, urządzenie musi spełniać następujące wymagania:

Urządzenie musi zgłosić te same wskaźniki konfiguracji ekranu i wyświetlania, jak szczegółowo opisano w sekcjach 7.1.1 i 7.1.2, jako wyświetlacz stałego piksela.
Urządzenie musi zgłosić tę samą gęstość logiczną, co wyświetlacz stałego piksela.
Urządzenie musi zgłaszać wymiary ekranu, które są takie same jak, lub bardzo blisko wyświetlacza stałego piksela.

Na przykład tablet o wielkości 7 "przekątnej o rozdzielczości 1024x600 pikseli jest uważany za implementację dużego wyświetlania MDPI o stałym piksele. Jeśli zawiera port wyjściowy wideo, który wyświetla się na 720p są wykonywane tylko w dużym oknie MDPI, niezależnie od tego, czy używany jest wyświetlacz o stałym pikselu, czy port wyjściowy wideo.

Implementacje urządzeń o zmiennym pikselu

Implementacje urządzeń o zmiennym pikseli muszą obsługiwać co najmniej jeden z 1280x720, 1920x1080 lub 3840x2160 (to znaczy 720p, 1080p lub 4k). Implementacje urządzeń z wyświetlaczami zmiennej pikseli nie mogą obsługiwać żadnej innej konfiguracji ekranu ani trybu. Implementacje urządzeń z ekranami zmiennej pikseli mogą zmienić konfigurację ekranu lub tryb w czasie wykonywania lub w czasie rozruchu. Na przykład użytkownik zestawu zestawu może zastąpić wyświetlacz 720p na wyświetlacz 1080p, a implementacja urządzenia może odpowiednio się dostosować.

Ponadto implementacje urządzeń o zmiennej pikseli muszą zgłosić następujące wiadra konfiguracyjne dla tych wymiarów pikseli:

1280x720 (znany również jako 720p): „duży” rozmiar ekranu, „TVDPI” (213 DPI)
1920x1080 (znany również jako 1080p): „duży” rozmiar ekranu, gęstość „xhdpi” (320 dpi)
3840x2160 (znany również jako 4K): „duży” rozmiar ekranu, „xxxhdpi” (640 dpi) gęstość

W przypadku przejrzystości implementacje urządzeń o zmiennych wymiarach pikseli są ograniczone do 720p, 1080p lub 4K w Android 4.4 i muszą być skonfigurowane do zgłaszania rozmiaru ekranu i gęstości, jak wspomniano powyżej.

7.1.7. Technologia ekranu

Platforma Androida zawiera interfejsy API, które pozwalają aplikacjom na rejestrowanie bogatej grafiki na wyświetlacz. Urządzenia muszą obsługiwać wszystkie te interfejsy API zgodnie z definicją systemu Android SDK, chyba że jest to wyraźnie dozwolone w tym dokumencie. Konkretnie:

Urządzenia muszą obsługiwać wyświetlacze zdolne do renderowania 16-bitowej kolorowej grafiki i powinny obsługiwać wyświetlacze zdolne do 24-bitowej kolorowej grafiki.
Urządzenia muszą obsługiwać wyświetlacze zdolne do renderowania animacji.
Zastosowana technologia wyświetlania musi mieć współczynnik kształtu pikseli (PAR) między 0,9 a 1,1. Oznacza to, że współczynnik kształtu pikseli musi znajdować się w pobliżu kwadratowego (1,0) z 10% tolerancją.

7.1.8. Wyświetlacze zewnętrzne

Android zawiera obsługę wyświetlania wtórnego, aby umożliwić możliwości udostępniania mediów i interfejsy API programistów w celu uzyskania dostępu do wyświetlaczy zewnętrznych. Jeśli urządzenie obsługuje wyświetlacz zewnętrzny za pośrednictwem przewodowego, bezprzewodowego lub wbudowanego dodatkowego połączenia wyświetlania, implementacja urządzenia musi zaimplementować interfejs API Display Manager, jak opisano w dokumentacji Android SDK [ zasoby, 75 ]. Implementacje urządzeń, które obsługują bezpieczne wyjście wideo i są w stanie obsługiwać bezpieczne powierzchnie, muszą zadeklarować obsługę Display.FLAG_SECURE . W szczególności implementacje urządzeń, które deklarują obsługę Display.FLAG_SECURE , muszą obsługiwać HDCP 2.x lub wyższy dla wyświetlaczy Wireless Miracast lub HDCP 1.2 lub wyższy dla wyświetlaczy przewodowych. Implementacja open source z Androidem na Androidzie obejmuje obsługę wyświetlaczy bezprzewodowych (miracast) i przewodowych (HDMI), które spełniają ten wymóg.

7.2. Urządzenia wejściowe

7.2.1. Klawiatura

Implementacje urządzeń:

Musi zawierać obsługę frameworka zarządzania wejściowym (która pozwala twórcom stron trzecich tworzyć silniki zarządzania wejściową - tj. Klawiatura miękka), jak szczegółowo opisano na stronie http://developer.android.com
Musi zapewnić co najmniej jedną implementację klawiatury miękkiej (niezależnie od tego, czy obecna jest klawiatura twardej)
Może obejmować dodatkowe implementacje klawiatury miękkiej
Może obejmować klawiaturę sprzętową
Nie może zawierać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard [ Resources, 40 ] (to znaczy Qwerty lub 12-klawisze)

7.2.2. Nawigacja bezdotykowa

Implementacje urządzeń:

Może pominąć opcję nawigacji bez dotyku (to znaczy może pominąć trackball, d-pad lub koło)
Musi zgłosić prawidłową wartość dla android.content.res.Configuration.navigation [ Resources, 40 ]
Musi zapewnić rozsądny alternatywny mechanizm interfejsu użytkownika do wyboru i edycji tekstu, kompatybilny z silnikami zarządzania wejściowymi. Implementacja open source na Androidzie na Androidzie obejmuje mechanizm wyboru odpowiedni do użytku z urządzeniami, w których brakuje wejść nawigacyjnych innych niż dotychczas.

7.2.3. Klawisze nawigacyjne

Funkcje domu, recenzentów i pleców są niezbędne dla paradygmatu nawigacji z Androidem. Implementacje urządzeń muszą udostępniać te funkcje użytkownikowi przez cały czas podczas uruchamiania aplikacji. Funkcje te można zaimplementować za pomocą dedykowanych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe) lub mogą być zaimplementowane przy użyciu dedykowanych kluczy oprogramowania na odrębnej części ekranu, gestów, panelu dotykowego itp. Android obsługuje obie implementacje. Wszystkie te funkcje muszą być dostępne za pomocą jednego działania (np. Tap, dwukrotnego kliknięcia lub gestu), gdy są widoczne.

Funkcje tylne i rentowne powinny mieć widoczny przycisk lub ikonę, chyba że są ukryte wraz z innymi funkcjami nawigacyjnymi w trybie pełnym ekranem. Funkcja domowa musi mieć widoczny przycisk lub ikonę, chyba że jest ukryta wraz z innymi funkcjami nawigacyjnymi w trybie pełnym ekranem.

Funkcja menu jest przestarzała na korzyść paska akcji od Androida 4.0. Implementacje urządzeń nie powinny implementować dedykowanego przycisku fizycznego dla funkcji menu. Jeśli przycisk fizycznego menu jest zaimplementowany, a urządzenie uruchamia aplikacje z targetSdkVersion > 10, implementacja urządzenia:

Aby uruchamiać urządzenie z Android 4.4, należy wyświetlić przycisk przepełnienia akcji na pasku akcji, gdy pasek akcji jest widoczny, a powstałe menu przepełnienia akcji nie jest puste.
W przypadku istniejącego urządzenia uruchomionego z wcześniejszą wersją, ale aktualizacją do Androida 4.4, powinno wyświetlić przycisk przepełnienia akcji na pasku akcji, gdy pasek akcji jest widoczny, a wynikające z tego wyskakujące menu menu przepełnienia akcji nie jest puste.
Nie może modyfikować położenia wyskakującego przelewu akcji wyświetlonego, wybierając przycisk przepełnienia na pasku akcji.
Może sprawić, że wyskakujące przepełnienie akcji w zmodyfikowanej pozycji na ekranie, gdy jest wyświetlany, wybierając przycisk menu fizycznego.

Aby uzyskać kompatybilność wsteczną, implementacje urządzeń muszą udostępnić funkcję menu w aplikacjach, gdy targetSdkVersion <= 10, przez przycisk fizyczny, klucz oprogramowania lub gesty. Ta funkcja menu powinna być prezentowana, chyba że jest ukryta wraz z innymi funkcjami nawigacyjnymi.

Android obsługuje działanie pomocy [ zasoby, 63 ]. Implementacje urządzeń muszą udostępniać działanie pomocy użytkownikowi przez cały czas podczas uruchamiania aplikacji. Działanie pomocy należy zaimplementować jako długą prasę przycisku Home lub gest w górę na klucz Home Software. Ta funkcja może być zaimplementowana za pomocą innego przycisku fizycznego, klucza oprogramowania lub gestów, ale musi być dostępna za pomocą jednego działania (np. Tap, dwukrotnym kliknięciem lub gestem), gdy widoczne są inne klucze nawigacyjne.

Implementacje urządzeń mogą wykorzystywać odrębną część ekranu do wyświetlania klawiszy nawigacyjnych, ale jeśli tak, to muszą spełniać te wymagania:

Klawisze nawigacyjne wdrażania urządzeń muszą korzystać z odrębnej części ekranu, niedostępnej dla aplikacji, i nie mogą zaciemniać ani ingerować w część ekranu dostępnego dla aplikacji.
Implementacje urządzeń muszą udostępnić część wyświetlacza do aplikacji, które spełniają wymagania zdefiniowane w sekcji 7.1.1 .
Implementacje urządzeń muszą wyświetlać klucze nawigacyjne, gdy aplikacje nie określają trybu interfejsu użytkownika systemu lub określić SYSTEM_UI_FLAG_VISIBLE .
Implementacje urządzeń muszą prezentować klawisze nawigacyjne w trybie dyskretnym „niski profil” (np. Dimmed), gdy aplikacje określają SYSTEM_UI_FLAG_LOW_PROFILE .
Implementacje urządzeń muszą ukryć klawisze nawigacyjne, gdy aplikacje określają SYSTEM_UI_FLAG_HIDE_NAVIGATION .

7.2.4. Wejście na ekranie dotykowym

Implementacje urządzeń powinny mieć jakiś system wejściowy wskaźnika (albo podobny do myszy lub dotyk). Jeśli jednak implementacja urządzenia nie obsługuje systemu wejściowego wskaźnika, nie może zgłaszać android.hardware.touchscreen lub android.hardware.faketouch Funkcja stała. Implementacje urządzeń, które obejmują system wejściowy wskaźnika:

Powinien obsługiwać w pełni niezależnie śledzone wskaźniki, jeśli system wejściowy urządzenia obsługuje wiele wskaźników
Musi zgłosić wartość android.content.res.Configuration.touchscreen [ Zasoby, 40 ] odpowiadający typowi konkretnego ekranu dotykowego na urządzeniu

Android zawiera obsługę różnych ekranów dotykowych, podkładek dotykowych i fałszywych urządzeń wejściowych dotykowych. Implementacje urządzeń oparte na ekranie dotykowym są powiązane z wyświetlaczem [ zasoby, 81 ], tak aby użytkownik miał wrażenie bezpośrednio manipulowania elementami na ekranie. Ponieważ użytkownik bezpośrednio dotyka ekranu, system nie wymaga żadnych dodatkowych afordancji, aby wskazać manipulowanie obiektów. Natomiast fałszywy interfejs dotykowy zapewnia system wejściowy użytkownika, który zbliża się do podzbioru możliwości ekranu dotykowego. Na przykład myszy lub zdalne sterowanie, które napędza kursor na ekranie, przybliża dotyk, ale wymaga od użytkownika najpierw punktu lub skupienia, a następnie kliknięcia. Liczne urządzenia wejściowe, takie jak mysz, Trackpad, mysz oparta na żyroskopie, wskaźnik żyroskopowy, joystick i multi-dtouch Trackpad, mogą obsługiwać fałszywe interakcje dotykowe. Android 4.0 zawiera stałą funkcję android.hardware.faketouch , który odpowiada urządzeniu wejściowym o wysokiej wierności (to znaczy oparte na wskaźnikach), takie jak mysz lub trackpad, które może odpowiednio emulować wejście dotykowe (w tym podstawowy gest gestowy Obsługa) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego. Implementacje urządzeń, które deklarują funkcję fałszywego dotyku, muszą spełniać fałszywe wymagania dotykowe w sekcji 7.2.5 .

Implementacje urządzeń muszą zgłosić prawidłową funkcję odpowiadającą typowi zastosowanego wejścia. Implementacje urządzeń zawierające ekran dotykowy (pojedynczy dotyk lub lepszy) muszą zgłosić funkcję platformy stałą android.hardware.touchscreen . Implementacje urządzeń, które zgłaszają stałą funkcję platformy android.hardware.touchscreen musi również zgłosić funkcję platformy stałą android.hardware.faketouch . Implementacje urządzeń, które nie obejmują ekranu dotykowego (i polegające na urządzeniu wskaźnikowym) nie mogą zgłaszać żadnej funkcji ekranu dotykowego i muszą zgłaszać tylko android.hardware.faketouch , jeśli spełniają fałszywe wymagania dotykowe w rozdziale 7.2.5 .

7.2.5. Fałszywe wejście dotykowe

Implementacje urządzeń, które deklarują obsługę android.hardware.faketouch

Musi zgłosić bezwzględne pozycje ekranu x i y lokalizacji wskaźnika i wyświetlić wskaźnik wizualny na ekranie [ zasoby, 80 ]
Musi zgłosić zdarzenie dotykowe z kodem działania [ Zasoby, 80 ], które określa zmianę stanu, która występuje na wskaźniku down lub up na ekranie [ Zasoby, 80 ]
Musi obsługiwać wskaźnik down i up obiektu na ekranie, który pozwala użytkownikom naśladować dotknięcie obiektu na ekranie
Musi obsługiwać down , up , wskaźnik down , a następnie up w tym samym miejscu na obiekcie na ekranie w progu czasowym, co pozwala użytkownikom naśladować podwójny dotknięcie obiektu na ekranie [ zasoby, 80 ]
Musi obsługiwać wskaźnik down dowolnym punkcie na ekranie, wskaźnik przenosi się do dowolnego innego dowolnego punktu na ekranie, a następnie up , który pozwala użytkownikom naśladować przeciągnięcie dotyku
Musi obsługiwać wskaźnik down , a następnie umożliwić użytkownikom szybkie przeniesienie obiektu do innej pozycji na ekranie, a następnie wskaźnik up na ekranie, co pozwala użytkownikom rzucić obiekt na ekranie

Urządzenia, które deklarują obsługę android.hardware.faketouch.multitouch.distinct muszą spełniać wymagania dotyczące FakeTouch powyżej, a także muszą obsługiwać wyraźne śledzenie dwóch lub więcej niezależnych wskaźników.

7.2.6. Mikrofon

Implementacje urządzeń mogą pominąć mikrofon. Jeśli jednak implementacja urządzenia pomija mikrofon, nie może zgłaszać stałej funkcji android.hardware.microphone i musi zaimplementować interfejs API rejestrującego dźwięki jako NO-OPS na sekcję 7 . I odwrotnie, implementacje urządzeń, które mają mikrofon:

Musi zgłosić stałą funkcję android.hardware.microphone
Powinien spełniać wymagania jakości dźwięku w sekcji 5.4
Powinien spełniać wymagania opóźnienia dźwięku w sekcji 5.5

7.3. Czujniki

Android zawiera interfejsy API do dostępu do różnych typów czujników. Implementacje urządzeń mogą zasadniczo pomijać te czujniki, jak przewidziano w następujących podrozdziałach. Jeśli urządzenie zawiera określony typ czujnika, który ma odpowiedni interfejs API dla twórców stron trzecich, implementacja urządzenia musi zaimplementować ten interfejs API, jak opisano w dokumentacji Android SDK. Na przykład implementacje urządzeń:

Musi dokładnie zgłosić obecność lub brak czujników w klasie android.content.pm.PackageManager . [ Zasoby, 37 ]
Musi zwrócić dokładną listę obsługiwanych czujników za pośrednictwem SensorManager.getSensorList() i podobnych metod
Musi zachować rozsądnie w przypadku wszystkich innych interfejsów API czujników (na przykład poprzez zwracanie prawdy lub fałszu, gdy aplikacje próbują zarejestrować słuchaczy, nie dzwoniąc do słuchaczy, gdy odpowiednie czujniki nie są obecne; itp.)
Musi zgłosić wszystkie pomiary czujników za pomocą odpowiednich międzynarodowych systemów jednostek (tj. Metryka) dla każdego typu czujnika, zgodnie z definicją w dokumentacji Androida SDK [ Zasoby, 41 ]

Powyższa lista nie jest kompleksowa; Udokumentowane zachowanie systemu SDK z Androidem należy uznać za autorytatywne.

Niektóre typy czujników są syntetyczne, co oznacza, że można je wyprowadzić z danych dostarczonych przez jeden lub więcej innych czujników. (Przykłady obejmują czujnik orientacji i liniowy czujnik przyspieszenia.) Implementacje urządzeń powinny zaimplementować te typy czujników, gdy obejmują one warunkowe czujniki fizyczne.

Android zawiera pojęcie czujnika „przesyłania strumieniowego”, który jest taki, który zwraca dane w sposób ciągły, a nie tylko wtedy, gdy dane zmieniają się. Implementacje urządzeń muszą stale dostarczać okresowe próbki danych dla dowolnego interfejsu API wskazanego przez dokumentację Android SDK jako czujnik przesyłania strumieniowego. Należy pamiętać, że implementacje urządzeń muszą upewnić się, że strumień czujnika nie może uniemożliwić procesora urządzenia przed wejściem do stanu zawieszenia lub przebudzenia ze stanu zawieszenia.

7.3.1. Akcelerometr

Implementacje urządzeń powinny zawierać 3-osiowy akcelerometr. Jeśli implementacja urządzenia zawiera 3-osiowy akcelerometr, to:

Powinien być w stanie dostarczyć zdarzenia z prędkością 120 Hz lub większej. Należy zauważyć, że chociaż powyższa częstotliwość akcelerometru jest określana jako „powinna” dla Androida 4.4, planowana jest definicja kompatybilności dla przyszłej wersji, aby zmienić je na „musi”. Oznacza to, że standardy te są opcjonalne na Androidzie, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia, które działają na Androida, są bardzo mocno zachęcane do spełnienia tych wymagań w Android , aby mogły uaktualnić do przyszłych wydań platform
Musi być zgodny z systemem współrzędnych czujników Androida, jak szczegółowo opisano w interfejsach API z Androidem (patrz [ Zasoby, 41 ])
Musi być w stanie pomieścić od swobodnego opadu do dwóch razy grawitacji (2G) lub więcej na dowolnym trójwymiarowym wektorze
Musi mieć 8 bitów dokładności lub więcej
Musi mieć odchylenie standardowe nie większe niż 0,05 m/s^2

7.3.2. Magnetometr

Implementacje urządzeń powinny zawierać 3-osiowy magnetometr (tj. Kompas.) Jeśli urządzenie zawiera magnetometr 3-osiowy, IT:

Musi być w stanie dostarczyć zdarzenia z prędkością 10 Hz lub większymi
Musi być zgodny z systemem współrzędnych czujników Androida, jak szczegółowo opisano w interfejsach API z Androidem (patrz [ Zasoby, 41 ]).
Musi być w stanie próbkować szereg mocy pola odpowiednio do pokrycia pola geomagnetycznego
Musi mieć 8 bitów dokładności lub więcej
Musi mieć odchylenie standardowe nie większe niż 0,5 µt

7.3.3. GPS

Implementacje urządzeń powinny obejmować odbiornik GPS. Jeśli implementacja urządzenia zawiera odbiornik GPS, powinna zawierać jakąś formę techniki „wspomaganego GPS”, aby zminimalizować czas blokady GPS.

7.3.4. Żyroskop

Implementacje urządzeń powinny obejmować żyroskop (tj. Czujnik zmiany kątowej.) Urządzenia nie powinny zawierać czujnika żyroskopu, chyba że uwzględniono również 3-osiowy akcelerometr. Jeśli implementacja urządzenia zawiera żyroskop, to:

Musi być kompensowany temperaturą.
Musi być w stanie pomiar zmian orientacji do 5,5*Pi Radian/sekundę (to znaczy około 1000 stopni na sekundę).
Powinien być w stanie dostarczyć zdarzenia w wysokości 200 Hz lub większych. Należy zauważyć, że chociaż powyższa częstotliwość żyroskopu jest określana jako „powinna” dla Androida 4.4, planowana jest definicja kompatybilności dla przyszłej wersji, aby zmienić je na „musi”. Oznacza to, że standardy te są opcjonalne na Androidzie, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia, które prowadzą Android, są bardzo zachęcane do spełnienia tych wymagań , aby mogły uaktualnić przyszłe wydania platformy.
Musi mieć 12 bitów dokładności lub więcej
Musi mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub Rad^2 / s). Wariancja może się różnić w zależności od szybkości próbkowania, ale musi być ograniczona tą wartością. Innymi słowy, jeśli mierzysz wariancję żyroskopu przy prędkości próbkowania 1 Hz, nie powinno to być większe niż 1e-7 rad^2/s^2.
Musi mieć znaczniki czasu tak blisko, kiedy zdarzenie sprzętowe nastąpiło, jak to możliwe. Stałe opóźnienie należy usunąć.

7.3.5. Barometr

Implementacje urządzeń mogą obejmować barometr (tj. Czujnik ciśnienia powietrza w otoczeniu.) Jeśli implementacja urządzenia zawiera barometr, IT:

Musi być w stanie dostarczyć zdarzenia z prędkością 5 Hz lub większymi
Musi mieć odpowiednią precyzję, aby umożliwić oszacowanie wysokości
Musi być kompensowany temperaturą

7.3.6. Termometr

Implementacje urządzeń mogą obejmować termometr otoczenia (tj. Czujnik temperatury). Jeśli jest obecny, należy go zdefiniować jako SENSOR_TYPE_AMBIENT_TEMPERATURE i musi mierzyć temperaturę otoczenia (pomieszczenia) w stopniach Celsjusza.

Implementacje urządzeń mogą, ale nie powinny obejmować czujnika temperatury procesora. Jeśli jest obecny, należy go zdefiniować jako SENSOR_TYPE_TEMPERATURE , musi on zmierzyć temperaturę procesora urządzenia i nie może mierzyć żadnej innej temperatury. UWAGA, że typ czujnika SENSOR_TYPE_TEMPERATURE był przestarzały w Android 4.0.

7.3.7. Fotometr

Implementacje urządzeń mogą obejmować fotometr (tj. Czujnik światła otoczenia.)

7.3.8. Czujnik zbliżeniowy

Implementacje urządzeń mogą obejmować czujnik bliskości. Jeśli implementacja urządzenia zawiera czujnik bliskości, musi mierzyć bliskość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik bliskości musi być zorientowany do wykrywania obiektów blisko ekranu, ponieważ głównym celem tego typu czujnika jest wykrycie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik bliskości z jakąkolwiek inną orientacją, nie może być dostępna za pośrednictwem tego interfejsu API. Jeśli implementacja urządzenia ma czujnik bliskości, musi mieć 1-bit dokładności lub więcej.

7.4. Łączność danych

7.4.1. Telefonia

„Teleflencja” używana przez interfejsy API Androida i ten dokument odnosi się specjalnie do sprzętu związanego z umieszczaniem połączeń głosowych i wysyłania wiadomości SMS za pośrednictwem sieci GSM lub CDMA. Chociaż te połączenia głosowe mogą, ale nie muszą być przełączane pakietami, są one do celów Androida uważanego za niezależne od jakiejkolwiek łączności danych, które można zaimplementować za pomocą tej samej sieci. Innymi słowy, funkcja „telefonii” Androida i interfejsy API odnoszą się specjalnie do połączeń głosowych i SMS; Na przykład implementacje urządzeń, które nie mogą umieszczać połączeń ani wysyłać/odbierać wiadomości SMS, nie mogą zgłaszać funkcji „Android.hardware.telephony” ani żadnych sub-fauru, niezależnie od tego, czy korzystają z sieci komórkowej do łączności danych.

Android może być używany na urządzeniach, które nie zawierają sprzętu telefonii. Oznacza to, że Android jest kompatybilny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, musi wdrożyć pełne wsparcie dla interfejsu API dla tej technologii. Implementacje urządzeń, które nie zawierają sprzętu telefonii, muszą zaimplementować pełne interfejsy API jako NO-OPS.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje urządzeń z Androidem powinny zawierać obsługę jednej lub więcej form 802.11 (b/g/a/n itp.) Jeśli implementacja urządzenia zawiera obsługę 802.11, musi zaimplementować odpowiedni interfejs API z Androidem.

Implementacje urządzeń muszą wdrożyć interfejs API multiemisji, jak opisano w dokumentacji SDK [ Zasoby, 62 ]. Implementacje urządzeń, które obejmują obsługę Wi-Fi, muszą obsługiwać multiemisję DNS (MDN). Implementacje urządzeń nie mogą filtrować pakietów MDNS (224.0.0.251) w dowolnym momencie działania, w tym wtedy, gdy ekran nie jest w stanie aktywnym.

7.4.2.1. Bezpośrednie Wi-Fi

Implementacje urządzeń powinny obejmować obsługę Wi-Fi Direct (Wi-Fi peer-to-peer). Jeśli implementacja urządzenia zawiera obsługę Wi-Fi Direct, musi zaimplementować odpowiedni API Android, jak opisano w dokumentacji SDK [ Zasoby, 68 ]. Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, to:

Musi obsługiwać regularną operację Wi-Fi
Powinien obsługiwać jedno-FI i bezpośrednie działanie Wi-Fi

7.4.2.2. Konfiguracja bezpośredniego łącza tunelowanego Wi-Fi

Implementacje urządzeń powinny zawierać obsługę tunelowanej przez Wi-Fi Tunned Bezpośrednie konfigurację linków (TDLS), jak opisano w dokumentacji Android SDK [ Resources, 85 ]. Jeśli implementacja urządzenia zawiera obsługę TDLS i TDLS, jest włączona przez API WIFIMANAGER, urządzenie:

Powinien używać TDL tylko wtedy, gdy jest to możliwe i korzystne.
Powinien mieć trochę heurystyki i nie używać TDL, gdy jego wydajność może być gorsza niż przejście przez punkt dostępu Wi-Fi.

7.4.3. Bluetooth

Implementacje urządzeń powinny obejmować transceiver Bluetooth. Implementacje urządzeń, które obejmują transceiver Bluetooth, muszą włączyć interfejs Bluetooth oparty na RFCOMM, jak opisano w dokumentacji SDK i deklaruj funkcję sprzętu Android.hardware.bluetooth [ Resources, 42 ]. Implementacje urządzeń powinny zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp., W odpowiednich dla urządzenia.

Implementacje urządzeń, które obejmują obsługę Bluetooth GATT (ogólny profil atrybutów), aby umożliwić komunikację z urządzeniami Bluetooth Smart lub Smart Ready, muszą włączyć interfejs API Bluetooth oparty na GATT, jak opisano w dokumentacji SDK i deklaruj funkcję sprzętu Android.hardware.bluetooth_le [ Zasoby, 42 ].

7.4.4. Komunikacja bliskiego zasięgu

Implementacje urządzeń powinny obejmować transceiver i powiązany sprzęt do komunikacji bliskiego pola (NFC). Jeśli implementacja urządzenia zawiera sprzęt NFC, to:

Musi zgłosić funkcję Android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature() . [ Zasoby, 37 ]
Musi być w stanie czytać i pisać wiadomości NDEF za pomocą następujących standardów NFC:
- Musi być zdolny do działania jako czytnik/pisarz forum NFC (zgodnie z definicją specyfikację techniczną Forum NFC NFCFORUM-TS-Digitalprotocol-1.0) za pomocą następujących standardów NFC:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - ISODEP (ISO 14443-4)
  - Forum NFC Typy 1, 2, 3, 4 (zdefiniowane przez forum NFC)
Powinien być w stanie czytać i pisać wiadomości NDEF za pomocą następujących standardów NFC. Zauważ, że chociaż poniższe standardy NFC są określane jako „powinny”, planowana jest definicja kompatybilności dla przyszłej wersji, aby je zmienić na „musi”. Oznacza to, że te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia, które uruchamiają tę wersję Androida, są teraz bardzo zachęcane do spełnienia tych wymagań , aby mogły uaktualnić do przyszłych wydań platform.
- NFCV (ISO 15693)
Musi być zdolny do przesyłania i odbierania danych za pośrednictwem następujących standardów i protokołów peer-to-peer:
- ISO 18092
- LLCP 1.0 (zdefiniowane przez forum NFC)
- SDP 1.0 (zdefiniowane przez forum NFC)
- Protokół push NDEF [ Resources, 43 ]
- SNEP 1.0 (zdefiniowane przez forum NFC)
Musi zawierać wsparcie dla Android Beam [ Resources, 65 ]:
- Musi zaimplementować domyślny serwer SNEP. Prawidłowe komunikaty NDEF otrzymane przez domyślny serwer SNEP należy wysłać do aplikacji za pomocą intencji Android.nfc.Action_NDEF_DISCOVERED. Wyłączanie wiązki Androida w ustawieniach nie może wyłączyć wysyłki przychodzącego komunikatu NDEF.
- Implementacje urządzeń muszą uhonorować Android.Settings.nfcShaRing_Settings, aby pokazać ustawienia udostępniania NFC [ Zasoby, 67 ].
- Musi zaimplementować serwer NPP. Wiadomości odbierane przez serwer NPP muszą być przetwarzane w taki sam sposób, jak serwer domyślny SNEP.
- Musi zaimplementować klienta SNEP i spróbować wysłać wychodzącą NDEF P2P na domyślny serwer SNEP, gdy Android Beam jest włączony. Jeśli nie znaleziono domyślnego serwera SNEP, klient musi próbować wysłać na serwer NPP.
- Musi umożliwić działanie na pierwszym planie na ustawienie komunikatu NDEF P2P za pomocą android.nfc.nfcadapter.setndefpushmessage i android.nfc.nfcadapter.setndefpushmessageCallback i android.nfc.nfcadapter.enablenDefpush.
- Powinny użyć gestu lub potwierdzenia na ekranie, takim jak „dotyk do belki”, przed wysłaniem wychodzących wiadomości NDEF P2P.
- Powinien domyślnie włączyć wiązkę Androida
- Musi obsługiwać przekazanie połączenia NFC do Bluetooth, gdy urządzenie obsługuje profil push obiektu Bluetooth. Implementacje urządzeń muszą obsługiwać przekazanie połączeń do Bluetooth podczas korzystania z Android.nfc.nfcadapter.setBeampushuris, wdrażając specyfikacje „Połączenie w wersji 1.2” i „Bezpieczne proste parowanie Bluetooth za pomocą wersji NFC 1.0” [ Zasoby, 61] specyfikacje z 61 ] Forum NFC. Taka implementacja musi zaimplementować usługę LLCP z nazwą usługi „URN: NFC: SN: Przekazanie” do wymiany żądania przekazania/Wybierz rekordy przez NFC i musi użyć profilu pchania obiektu Bluetooth dla rzeczywistego transferu danych Bluetooth. Z starszych powodów (aby pozostać kompatybilna z urządzeniami z Androidem 4.1), implementacja powinna nadal zaakceptować SNEP PEZ PEZUJĄCE żądania wymiany żądania przekazania/Wybierz rekordy w stosunku do NFC. Jednak sama implementacja nie powinna wysyłać żądań SNEP, aby wykonywać przekazanie połączenia.
Musi sondować wszystkie obsługiwane technologie w trybie odkrywania NFC.
Powinien być w trybie odkrywania NFC, gdy urządzenie nie śpi z aktywnym ekranem i odblokowaniem ekranu blokady.

(Należy pamiętać, że publicznie dostępne linki nie są dostępne dla specyfikacji forum JIS, ISO i NFC cytowanych powyżej.)

Android 4.4 wprowadza obsługę trybu emulacji karty gospodarza NFC (HCE). Jeśli implementacja urządzenia obejmuje kontroler NFC zdolny do routingu HCE i identyfikatora aplikacji (AID), to:

Musi zgłosić stałą funkcję android.hardware.nfc.hce
Musi obsługiwać interfejsy API NFC HCE zgodnie z definicją w systemie Android SDK [ Resources, 90 ]

Ponadto implementacje urządzeń mogą obejmować obsługę czytelnika/pisarza dla następujących technologii MiFare.

Mifare Classic (NXP MF1S503X [ Resources, 44 ], MF1S703X [ Resources, 45 ])
Mifare Ultralight (NXP MF0ICU1 [ Resources, 46 ], MF0ICU2 [ Resources, 47 ])
NDEF On Mifare Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Zauważ, że Android zawiera interfejsy API dla tych typów MiFare. Jeśli implementacja urządzenia obsługuje Mifare w roli czytnika/pisarza, to:

Musi zaimplementować odpowiednie interfejsy API Androida, jak udokumentowano przez Android SDK
Musi zgłosić funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature() . [ Zasoby, 37 ] Zauważ, że nie jest to standardowa funkcja Androida i jako taka nie wydaje się stała w klasie PackageManager .
Nie może wdrożyć odpowiednich interfejsów API Androida ani zgłaszania funkcji com.nxp.mifare, chyba że implementuje również ogólne obsługę NFC, jak opisano w niniejszej sekcji

Jeśli implementacja urządzenia nie zawiera sprzętu NFC, nie może zadeklarować funkcji Android.hardware.nfc z android.content.pm.PackageManager.hasSystemFeature() [ Zasoby, 37 ] i musi zaimplementować API Android NFC jako A nie-op.

Ponieważ klasy android.nfc.NdefMessage i android.nfc.NdefRecord reprezentują format reprezentacji danych niezależny od protokołu, implementacje urządzeń muszą zaimplementować te interfejsy API, nawet jeśli nie zawierają obsługi NFC lub zadeklarują funkcję android.hardware.nfc.

7.4.5. Minimalna wydajność sieci

Implementacje urządzeń muszą obejmować obsługę jednej lub więcej form sieci danych. W szczególności implementacje urządzeń muszą zawierać obsługę co najmniej jednego standardu danych zdolnych do 200 kbit/s lub większych. Przykłady technologii spełniających ten wymóg obejmują Edge, HSPA, EV-DO, 802.11g, Ethernet itp.

Implementacje urządzeń, w których fizyczny standard sieci (taki jak Ethernet) jest głównym połączeniem danych, powinno również obejmować obsługę co najmniej jednego wspólnego standardu danych bezprzewodowych, takich jak 802.11 (Wi-Fi).

Urządzenia mogą zaimplementować więcej niż jedną formę łączności danych.

7.4.6. Synchronizuj ustawienia

Implementacje urządzeń muszą domyślnie ustawić główną ustawienie automatycznego synchronizacji, aby metoda getMasterSyncAutomatically() zwróciła „true” [ zasoby, 88 ].

7,5. Kamery

Implementacje urządzeń powinny obejmować kamerę skierowaną do tyłu i mogą obejmować aparat przedni. Kamera skierowana do tyłu to aparat znajdujący się z boku urządzenia naprzeciwko wyświetlacza; Oznacza to, że obrazuje sceny po drugiej stronie urządzenia, jak tradycyjny aparat. Przedni aparat to aparat położony po tej samej stronie urządzenia co wyświetlacz; Oznacza to, że aparat zwykle używany do obrazowania użytkownika, na przykład w przypadku wideokonferencji i podobnych aplikacji.

7.5.1. Kamera skierowana w tył

Implementacje urządzeń powinny obejmować kamerę skierowaną do tyłu. Jeśli implementacja urządzenia zawiera kamerę skierowaną do tyłu, to:

Musi mieć rozdzielczość co najmniej 2 megapikseli
Powinien mieć sprzętowy automatyczny skupienie, albo oprogramowanie auto-skutków zaimplementowane w sterowniku aparatu (przezroczyste dla oprogramowania aplikacyjnego)
Może mieć sprzęt stałego lub EDOF (rozszerzona głębokość pola)
Może obejmować błysk. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

7.5.2. Kamera przednia

Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

MUST have a resolution of at least VGA (that is, 640x480 pixels)
MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the urządzenie.
MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:

If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
Otherwise, the preview MUST be mirrored along the device's default horizontal axis.

MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. (If the device implementation does not support postview, this requirement obviously does not apply.)
MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Zachowanie API aparatu

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

Device implementations MUST implement the full Camera API included in the Android SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4. Orientacja aparatu

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Pamięć i przechowywanie

7.6.1. Minimalna pamięć i miejsce do przechowywania

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace MUST return the value "true" for ActivityManager.isLowRamDevice() .

Device implementations MUST have at least 1GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 1GB. Device implementations that run Android are very strongly encouraged to have at least 2GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Shared External Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps. The upstream Android Open Source Project includes an implementation that uses internal device storage for shared external storage APIs; device implementations SHOULD use this configuration and software implementation.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST NOT allow Android applications to write to the secondary external storage, except for their package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

7.7. USB

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Androidare very strongly encouraged to meet these requirements in Android so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases
The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Zgodność wydajności

Device implementations MUST meet the key performance metrics of an Android- compatible device defined in the table below:

Metryczny	Performance Threshold	Uwagi
Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

9. Zgodność modelu zabezpieczeń

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1. Uprawnienia

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2. UID i izolacja procesu

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3. Uprawnienia systemu plików

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. Alternatywne środowiska wykonawcze

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Konkretnie:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9,5. Wsparcie dla wielu użytkowników

Android includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
Android includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage.

9.6. Ostrzeżenie SMS-em premium

Android includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Funkcje bezpieczeństwa jądra

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

MUST maintain compatibility with existing applications
MUST not have a visible user interface, even when violations are detected
SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

it MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis with:

domains that are in enforcing mode in the upstream Android Open Source implementation (such as installd, netd, and vold) MUST be in enforcing mode
domain(s) for third-party applications SHOULD remain in permissive mode to ensure continued compatibility

it SHOULD load policy from /sepolicy file on the device
it MUST support dynamic updates of the SELinux policy file without requiring a system image update
it MUST log any policy violations without breaking applications or affecting system behavior

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9,8. Prywatność

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9,9. Szyfrowanie całego dysku

IF the device has lockscreen, the device MUST support full-disk encryption.

10. Testowanie kompatybilności oprogramowania

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Zestaw testów zgodności

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.4. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. Weryfikator CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Aplikacje referencyjne

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Google Play Store)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. Oprogramowanie z możliwością aktualizacji

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. Dziennik zmian dokumentu

The following table contains a summary of the changes to the Compatibility Definition in this release.

Sekcje)	Summary of change
3.2.2. Parametry kompilacji	Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now required.
3.2.3.5. Domyślne ustawienia aplikacji	New section that adds requirement to comply with new default application settings
3.3.1 Interfejsy binarne aplikacji	Clarified allowed values for the `android.os.Build.CPU_ABI` and `android.os.Build.CPU_ABI2` parameters.
3.4.1. Zgodność z WebView	Added Chromium as required WebView implementation.
3.7. Zgodność z maszyną wirtualną	Added requirement for xxhdpi and 400dpi screen densities.
3.8.6. Motywy	Updated to reflect use of translucent system bars.
3.8.12. Lokalizacja	New section that adds requirement location settings be centralized.
3.8.13. Unicode	New section that adds requirement for emoji support.
3.9. Administracja urządzeniem	Noted preinstalled administrative applications cannot be the default Device Owner application.
5.1. Kodeki multimedialne	Added VP9 decoder requirement. Added recommended specification for hardware VP8 codecs.
5.3. Dekodowanie wideo	Added VP9. Added recommendation for dynamic resolution switching.
5.4. Nagrywanie dźwięku	Added `REMOTE_SUBMIX` as new required audio source. Made use of `android.media.audiofx.NoiseSuppressor` API a requirement.
6.2.1 Experimental	New section that introduces the ART runtime and requires Dalvik as the default runtime.
7.1.1. Konfiguracja ekranu	Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.
7.1.6. Screen Types	Added 640 dpi (4K) resolution configuration.
7.2.3. Klawisze nawigacyjne	Added Recents function as essential; demoted Menu function in priority.
7.3.6. Termometr	Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.
7.4.2.2. Konfiguracja bezpośredniego łącza tunelowanego Wi-Fi	New section that adds support for Wi-Fi Tunneled Direct Link Setup (TDLS).
7.4.4. Komunikacja bliskiego zasięgu	Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push Profile as a requirement.
7.4.6. Synchronizuj ustawienia	New section that adds requirement auto-sync data be enabled by default.
7.6.1. Minimalna pamięć i miejsce do przechowywania	Added `ActivityManager.isLowRamDevice()` setting requirement for devices with less than 512MB of memory. Increased storage requirements from 512MB and 1GB to 1GB and 2GB, respectively.
7.6.2. Shared "External" Storage	Editorial fixes such as change of section name, and moved text that fits in this section from section 9.5. Noted applications may write to their package-specific directories on secondary external storage.
7.7. USB	Added requirement all devices report a USB serial number.
9,5. Wsparcie dla wielu użytkowników	Moved non multi-user specific text to section 7.6.2.
9.7. Funkcje bezpieczeństwa jądra	Rewritten to note switch of SELinux to enforcing mode and requirement SELinux output not be rendered in the user interface.
9,8. Prywatność	New section that adds requirement audio and video recording must trigger continuous notifications to the user.
9,9. Szyfrowanie całego dysku	New section that adds requirement devices with lockscreen support full-disk encryption.
12. Dziennik zmian dokumentu	New section that summarizes changes in the CDD by section.

13. Skontaktuj się z nami

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.