Definicja zgodności z Androidem 5.1

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą być spełnione, aby urządzenia były zgodne z Androidem 5.1.

Użycie słów „MUST”, „MUST NOT”, „REQUIRED”, „SHALL”, „SHALL NOT”, „SHOULD”, „SHOULD NOT”, „RECOMMENDED”, „MAY” i „OPTIONAL” jest zgodne ze standardem IETF zdefiniowanym w RFC2119 [Resources, 1].

W tym dokumencie „implementer” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe z Androidem 5.1. „Wdrożenie urządzenia” lub „wdrożeniem” jest rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 5.1, należy spełnić wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty uwzględnione w dokumentacji.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejednoznaczne lub niekompletne, to implementator urządzenia jest odpowiedzialny za zapewnienie zgodności z dotychczasowymi implementacjami.

Z tego powodu projekt Android Open Source [Zasoby, 2] jest zarówno referencją, jak i preferowanym wdrożeniem Androida. Implementatorów urządzeń zachęcamy, aby w jak największym stopniu opierali swoje implementacje na „upstreamowym” kodzie źródłowym dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić innymi implementacjami, zdecydowanie odradzamy taką praktykę, ponieważ przeprowadzenie testów oprogramowania będzie znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu testów zgodności i poza nim. Pamiętaj, że niektóre wymiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów wymienionych w sekcji 14 pochodzi bezpośrednio lub pośrednio z Android SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu. W przypadku rozbieżności między definicją zgodności lub zestawem testów zgodności a dokumentacją pakietu SDK za wiarygodną uznaje się dokumentację pakietu SDK. Wszelkie szczegóły techniczne podane w dokumentach referencyjnych wymienionych w sekcji 14 są uważane za część tej definicji zgodności.

2. Typy urządzeń

Chociaż projekt Android Open Source został wykorzystany do implementacji różnych typów i formatów urządzeń, wiele aspektów architektury i wymagań dotyczących zgodności zostało zoptymalizowanych pod kątem urządzeń przenośnych. Począwszy od Androida 5.0 projekt Android Open Source ma obejmować szerszą gamę typów urządzeń, jak opisano w tej sekcji.

Urządzenie przenośne z Androidem to urządzenie z Androidem, które zwykle jest używane w ręce, np. odtwarzacze mp3, telefony i tablety. Implementacje na urządzeniach przenośnych z Androidem:

• Musi mieć wbudowany ekran dotykowy.
• MUSI mieć źródło zasilania, które zapewnia mobilność, np. baterię.

Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do konsumowania mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo przez użytkowników siedzących w odległości około 3 metrów (interfejs „lean back” lub „10-foot user interface”). Urządzenia Android TV:

• Musi mieć wbudowany ekran LUB zawierać port wyjścia wideo, np. VGA, HDMI lub bezprzewodowy port do wyświetlania.
• NALEŻY zadeklarować funkcje android.software.leanback i android.hardware.type.television [Resources, 3].

Urządzenie typu zegarek z Androidem to implementacja urządzenia z Androidem przeznaczona do noszenia na ciele, np. na nadgarstku.

• Musi mieć ekran o fizycznej długości przekątnej w zakresie od 1,1 do 2,5 cala.
• MUSI zadeklarować funkcję android.hardware.type.watch.
• MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH [Resources, 4].

Wdrożeniem Androida Automotive nazywamy zastosowanie w samochodzie jednostki głównej z Androidem jako systemem operacyjnym dla części lub całości systemu lub funkcji multimedialnych. Implementacje Androida Automotive MUSZĄ obsługiwać uiMode = UI_MODE_TYPE_CAR [Resources, 111].

Aby być zgodnym z Androidem 5.1, wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z wymienionych powyżej typów urządzeń, MUSZĄ spełniać wszystkie wymagania podane w tym dokumencie, chyba że wyraźnie określono, że wymagania te dotyczą tylko określonego typu urządzenia z Androidem.

2.1 Konfiguracje urządzenia

Oto podsumowanie najważniejszych różnic w konfiguracji sprzętu w zależności od typu urządzenia. (puste komórki oznaczają „MOŻE”). Nie wszystkie konfiguracje są opisane w tej tabeli. Więcej informacji znajdziesz w odpowiednich sekcjach dotyczących sprzętu.

Kategoria	Funkcja	Sekcja	Kamera z ręki	Telewizja	Obejrzyj	Automotive	Inne
Urządzenie wejściowe	Pad kierunkowy	7.2.2. Nawigacja bezdotykowa		MUST
	Ekran dotykowy	7.2.4. Dotykowe wprowadzanie danych	MUST		MUST		SHOULD
	mikrofon	7.8.1. Mikrofon	MUST	SHOULD	MUST	MUST	SHOULD
Czujniki	Akcelerometr	7.3.1 Akcelerometr	SHOULD		SHOULD		SHOULD
	GPS	7.3.3. GPS	SHOULD			SHOULD
Łączność	Wi-Fi	7.4.2. IEEE 802.11	SHOULD	MUST		SHOULD	SHOULD
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	SHOULD	SHOULD			SHOULD
	Bluetooth	7.4.3. Bluetooth	SHOULD	MUST	MUST	MUST	SHOULD
	Bluetooth Low Energy	7.4.3. Bluetooth	SHOULD	MUST	SHOULD	SHOULD	SHOULD
	Tryb urządzenia peryferyjnego USB lub hosta	7.7. USB	SHOULD			SHOULD	SHOULD
Urządzenie wyjściowe	Głośniki lub gniazda wyjścia audio	7.8.2. Wyjście audio	MUST	MUST		MUST	MUST

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Zarządzane środowisko wykonywania kodu bajtowego Dalvik jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zestaw interfejsów platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanego środowiska wykonawczego. Implementacje na urządzeniu MUSZĄ zapewniać pełne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK Androida [Zasoby, 5] lub dowolnego interfejsu API oznaczonego znacznikiem „@SystemApi” w kodzie źródłowym Androida.

Implementacje na urządzeniach NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania lub zawierać operacji niemających żadnego efektu, z wyjątkiem sytuacji, w których jest to wyraźnie dozwolone przez tę definicję zgodności.

Ta definicja zgodności zezwala na pominięcie przez implementacje urządzeń niektórych typów sprzętu, dla których Android zawiera interfejsy API. W takich przypadkach interfejsy API MUSZĄ być nadal dostępne i działać w rozsądny sposób. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

3.2. Zgodność z interfejsem API w wersji próbnej

Oprócz zarządzanych interfejsów API z sekcji 3.1 Android zawiera też „miękki” interfejs API działający tylko w czasie wykonywania. Dotyczy to takich elementów aplikacji na Androida jak intencje, uprawnienia i inne podobne aspekty, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z informacjami na stronie pomocy dotyczącej uprawnień [Materiały dodatkowe, 6]. Pamiętaj, że w sekcji 9 znajdziesz dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry tworzenia

Interfejsy API Androida zawierają kilka stałych wartości w klasie android.os.Build [Zasoby, 7], które opisują bieżące urządzenie. Aby zapewnić spójne i znaczeniowe wartości we wszystkich implementacjach urządzeń, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.

Parametr	Szczegóły
VERSION.RELEASE	Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji [Resources, 8].
WERSJ.SDK	Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 5.1 to pole MUSI zawierać wartość całkowitą 22.
VERSION.SDK_INT	Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 5.1 to pole MUSI zawierać wartość całkowitą 22.
VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która określa konkretną wersję bieżąco działającego systemu Android w czytelnym dla człowieka formacie. Tej wartości NIE można używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany w kontroli źródłowej posłużył do wygenerowania kompilacji. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"”).
PLANSZOWE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny wewnętrzny sprzęt używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKA	Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_64_BIT_ABIS	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodu identyfikującą konfigurację funkcji sprzętowych i przemysłowy projekt urządzenia. Wartość tego pola MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Przykład: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać znaków odstępów. Jeśli inne pola zawarte w powyższym szablonie zawierają znaki odstępu, w odciskach palców kompilacji MUSZĄ one zostać zastąpione innym znakiem, np. znakiem podkreślenia („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub katalogu /proc). Powinien być zrozumiały dla człowieka. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
HOST	Ciąg znaków, który w czytelnym dla człowieka formacie jednoznacznie identyfikuje hosta, na którym została utworzona kompilacja. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"”).
ID	Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość wystarczająco istotną, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że: NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"”).
MODEL	Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i reklamowane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („”).
USŁUGA	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodu konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być czytelny dla człowieka, ale niekoniecznie jest przeznaczony do wyświetlania użytkownikom. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SERIAL	Numer seryjny sprzętu, który MUSI być dostępny. Wartość w tym polu MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^([a-zA-Z0-9]{6,20})$”.
TAGI	Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo odróżnia kompilację. To pole MUSI mieć jedną z wartości odpowiadającą 3 typowym konfiguracjom podpisywania na platformie Androida: release-keys, dev-keys, test-keys.
CZAS	Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
TYP	Wartość wybrana przez implementatora urządzenia, która określa konfigurację czasu wykonywania kompilacji. To pole MUSI zawierać jedną z 3 wartości odpowiadających 3 typowym konfiguracjom środowiska wykonawczego Androida: user, userdebug lub eng.
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że: NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"”).

3.2.3. Zgodność z zamiarem

Implementacje urządzeń MUSZĄ uwzględniać system intencji o luźnym połączeniu w Androidzie, jak opisano w sekcjach poniżej. „Honorowanie” oznacza, że implementator urządzenia MUSI udostępnić aktywność lub usługę na Androida, która określa pasujący filtr intencji, który łączy się z każdym określonym wzorcem intencji i wdraża odpowiednie zachowanie.

3.2.3.1. Główne intencje aplikacji

Intencje Androida umożliwiają komponentom aplikacji żądanie funkcji od innych komponentów Androida. Projekt upstream Androida zawiera listę aplikacji uznawanych za podstawowe aplikacje na Androida, które implementują kilka wzorów intencji do wykonywania typowych działań. Podstawowe aplikacje na Androida to:

• Zegar biurkowy
• Przeglądarka
• Kalendarz
• kontakty,
• Galeria
• GlobalSearch
• Wyrzutnia
• Muzyka
• Ustawienia

Implementacje na urządzeniu powinny zawierać podstawowe aplikacje Androida, ale MUSZĄ zawierać komponent realizujący te same wzorce intencji zdefiniowane przez wszystkie „publiczne” komponenty Activity lub Service tych podstawowych aplikacji Androida. Pamiętaj, że komponenty aktywności lub usługi są uważane za „publiczne”, gdy atrybut android:exported jest nieobecny lub ma wartość true.

3.2.3.2. Zastąpienia intencji

Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ umożliwiać zastąpienie przez aplikacje innych firm każdego wzorca intencji, do którego odwołuje się sekcja 3.2.3.1. Implementacja w górę w ramach oprogramowania open source Androida umożliwia to domyślnie. Implementatorzy urządzeń NIE MOGĄ przypisywać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród kilku aplikacji, które obsługują ten sam wzór intencji.

Implementacje urządzeń mogą jednak udostępniać domyślne działania w przypadku określonych wzorów URI (np. http://play.google.com), jeśli domyślne działanie zapewnia bardziej szczegółowy filtr dla danych URI. Na przykład filtr intencji określający URI danych „http://www.android.com” jest bardziej szczegółowy niż filtr przeglądarki „http://”. Wdrożenia na urządzeniach MUSZĄ zawierać interfejs, który umożliwi użytkownikom modyfikowanie domyślnej aktywności dla intencji.

3.2.3.3. Przestrzenie nazw intencji

Implementacje na urządzeniu NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii ani innego kluczowego ciągu znaków w przestrzeni nazw android.* lub com.android.*. Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe intencje lub wzorce intencji przesyłania strumieniowego za pomocą działania ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni pakietu należącej do innej organizacji. Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1. Implementacje na urządzeniach MOGĄ zawierać wzorce intencji, które używają skojarzeń jednoznacznie powiązanych z organizacją. Ten zakaz jest analogiczny do tego, który dotyczy zajęć z języka Java w sekcji 3.6.

3.2.3.4. Zamiary związane z transmisją

Aplikacje innych firm polegają na platformie, która wysyła określone intencje, aby powiadomić je o zmianach w środowisku sprzętowym lub programowym. Urządzenia zgodne z Androidem MUSZĄ transmitować publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje przesyłania są opisane w dokumentacji SDK.

3.2.3.5. Domyślne ustawienia aplikacji

Android zawiera ustawienia, które umożliwiają użytkownikom łatwe wybieranie domyślnych aplikacji, na przykład na ekranie głównym lub do wysyłania SMS-ów. W odpowiednich przypadkach implementacje na urządzeniu MUSZĄ zawierać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak pokazano poniżej.

Implementacje na urządzeniu:

• MUSI obsługiwać intencję android.settings.HOME_SETTINGS, aby wyświetlić domyślne menu ustawień aplikacji na ekranie głównym, jeśli implementacja urządzenia zgłasza android.software.home_screen [Zasoby, 10]
• MUSI zawierać menu ustawień, które wywołuje intencję android.provider.Telephony.ACTION_CHANGE_DEFAULT, aby wyświetlić okno do zmiany domyślnej aplikacji do obsługi SMS-ów, jeśli implementacja urządzenia zgłasza android.hardware.telephony [Resources, 9]
• Musi obsługiwać intent android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić domyślne menu ustawień aplikacji dotykowej i płatności, jeśli implementacja urządzenia zgłasza android.hardware.nfc.hce [Resources, 10]

3.3. Zgodność z natywnym interfejsem API

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku aplikacji .apk jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest silnie zależny od technologii procesora, Android definiuje w NDK Androida kilka interfejsów binarnych aplikacji (ABI). Implementacje na urządzeniach MUSZĄ być zgodne z co najmniej 1 zdefiniowanym interfejsem ABI i MUSZĄ być zgodne z Android NDK, jak opisano poniżej.

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

• MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowej semantyki interfejsu JNI (Java Native Interface).
• MUSI być zgodny ze źródłem (czyli z nagłówkiem) i binarną wersją każdej wymaganej biblioteki z listy poniżej (w przypadku interfejsu ABI).
• MUSI obsługiwać odpowiedni interfejs ABI 32-bitowy, jeśli obsługiwany jest dowolny interfejs ABI 64-bitowy
• MUSI dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS, z których każdy jest listą rozdzieloną przecinkami interfejsów ABI uporządkowanych od najbardziej do najmniej preferowanego.
• NALEŻY zgłaszać za pomocą powyższych parametrów tylko te interfejsy ABI, które są opisane w najnowszej wersji NDK Androida (patrz „NDK Programmer’s Guide | ABI Management” w katalogu docs/).
• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówkowych dostępnych w upstreamowym projekcie Android Open Source.

Te interfejsy API kodu natywnego MUSZĄ być dostępne w aplikacjach, które zawierają kod natywny:

• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Minimalne wsparcie dla C++
• Interfejs JNI
• liblog (rejestrowanie na Androidzie)
• libz (kompresja Zlib)
• libdl (linker dynamiczny)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (własne 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 (obsługa natywnej aktywności Androida)
• libmediandk.so (obsługa natywnych interfejsów API multimediów)
• Obsługa OpenGL, jak opisano poniżej

Pamiętaj, że w kolejnych wersjach NDK na Androida możemy dodać obsługę dodatkowych ABI. Jeśli implementacja urządzenia nie jest zgodna z dotychczasowym wstępnie zdefiniowanym ABI, NIE MOŻE zgłaszać obsługi żadnych ABI.

Pamiętaj, że implementacje na urządzeniu MUSZĄ zawierać libGLESv3.so i MUSZĄ mieć link symboliczny (symbolic link) do libGLESv2.so. Z kolei MUSZĄ wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack [Resources, 11], zgodnie z definicją w wersji NDK android-21. Chociaż wszystkie symbole muszą być obecne, należy w pełni zaimplementować tylko funkcje odpowiadające wersjom i rozszerzeniom OpenGL ES, które są obsługiwane przez urządzenie.

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego bardzo zalecamy implementantom urządzeń korzystanie z implementacji bibliotek wymienionych powyżej z Android Open Source Project.

3.3.2. Zgodność z 32-bitowym kodem natywnym ARM

Architektura ARMv8 wycofuje kilka operacji procesora, w tym niektóre operacje używane w dotychczasowym kodzie natywnym. Na urządzeniach ARM 64-bitowych te przestarzałe operacje MUSZĄ być dostępne dla 32-bitowego kodu natywnego ARM, albo przez obsługę natywnego procesora, albo przez emulację oprogramowania:

• Instrukcje dotyczące SWP i SWPB
• Instrukcja SETEND
• CP15ISB, CP15DSB i CP15DMB

Starsze wersje NDK na Androida używały pliku /proc/cpuinfo do wykrywania funkcji procesora z poziomu kodu natywnego ARM 32-bitowego. Aby zapewnić zgodność z aplikacjami utworzonymi za pomocą tego pakietu NDK, na urządzeniach MUSI znajdować się w pliku /proc/cpuinfo (czytany przez 32-bitowe aplikacje ARM) co najmniej jeden z tych wierszy:

• „Funkcje:”, a następnie lista opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
• „Architektura procesora:”, a następnie liczba całkowita określająca najwyższą obsługiwaną architekturę ARM (np. „8” w przypadku urządzeń ARMv8).

Te wymagania mają zastosowanie tylko wtedy, gdy plik /proc/cpuinfo jest odczytywany przez 32-bitowe aplikacje ARM. Urządzenia nie powinny zmieniać pliku /proc/cpuinfo, gdy jest on odczytywany przez 64-bitowe aplikacje ARM lub aplikacje niebędące ARM.

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Funkcja platformy android.software.webview MUSI być zgłaszana na dowolnym urządzeniu, które zapewnia pełną implementację interfejsu API android.webkit.WebView. Nie należy jej zgłaszać na urządzeniach bez pełnej implementacji interfejsu API. Implementacja Androida Open Source używa kodu z projektu Chromium do implementacji android.webkit.WebView [Resources, 12]. Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla systemu do renderowania stron internetowych, implementatorzy urządzeń MUSZĄ używać określonej kompilacji Chromium w implementacji WebView. Więcej szczegółów:

• Implementacje android.webkit.WebView na urządzeniu MUSZĄ być oparte na kompilacji Chromium z Androida Open Source Project dla Androida 5.1. Ta wersja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView [Resources, 13].
• Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć format:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) 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.
  • Ciąg tekstowy $(WEBVIEW) MOŻE być pominięty, ale jeśli jest obecny, MUSI mieć wartość „wv”, aby wskazać, że jest to widok internetowy.
  • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość parametru 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 upstreamowym projekcie Android Open Source.
  • Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków Mobile.

Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5. Jeśli tak, powinien być zgodny ze specyfikacją HTML5 [Materiały, 14].

3.4.2. Zgodność z przeglądarką

Samodzielna przeglądarka MOŻE być o zasadzie oparta na innej technologii przeglądarki niż WebKit. Jednak nawet jeśli używana jest inna przeglądarka, komponent android.webkit.WebView udostępniany aplikacjom innych firm MUSI być oparty na WebKit, zgodnie z opisem w sekcji 3.4.1.

Implementacje mogą zawierać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (oparta na aplikacji przeglądarki WebKit lub na zamienniku od zewnętrznego dostawcy) POWINNA obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 14]. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej te interfejsy API związane z HTML5:

• pamięć podręczna aplikacji/działanie w trybie offline [Resources, 15]
• tag <video> [Materiały, 16]
• geolokalizacja [Materiały, 17]

Ponadto implementacje urządzeń MUSZĄ obsługiwać interfejs API webstorage HTML5/W3C [Resources, 18] i POWINNY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources, 19]. Pamiętaj, że ponieważ instytucje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.

3.5. Zgodność zachowania interfejsu API

Zachowanie każdego z typów interfejsów API (zarządzanych, miękkich, natywnych i internetowych) musi być zgodne z preferowaną implementacją projektu Android Open Source [Resources, 2]. Niektóre konkretne obszary zgodności to:

• Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• Urządzenia NIE MOGĄ zmieniać semantyki standardowych uprawnień.

Powyższa lista nie jest wyczerpująca. Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem projektu Android Open Source. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie implementować istotnych części systemu.

3.6. Nazwy katalogów interfejsu API

Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:

• java.*
• javax.*
• sun.*
• android.*
• com.android.*,

Zabronione modyfikacje:

• Implementacje na urządzeniu NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę podpisów metod lub klas albo usunięcie klas lub pól klas.
• Implementatorzy urządzeń mogą modyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na opisane zachowanie i sygnaturę w języku Java interfejsów API udostępnionych publicznie.
• Implementatorzy urządzeń NIE MOGĄ dodawać do powyższych interfejsów API żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola lub metody do istniejących klas lub interfejsów).

„Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w poprzednim kodzie źródłowym Androida. Innymi słowy, implementatorzy urządzeń NIE MOGĄ udostępniać nowych interfejsów API ani zmieniać istniejących interfejsów API w wymienionych powyżej przestrzeniach nazw. Implementatorzy urządzeń mogą wprowadzić zmiany przeznaczone tylko do użytku wewnętrznego, ale te zmiany NIE MOGĄ być reklamowane ani w inny sposób udostępniane deweloperom.

Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API, ale nie mogą umieszczać ich w przestrzeni nazw należącej do innej organizacji lub nawiązującej do niej. Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych: mogą to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm. Jeśli implementacja na urządzeniu zawiera niestandardowe interfejsy API spoza standardowego obszaru nazw Androida, muszą one zostać zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które wyraźnie z nich korzystają (za pomocą mechanizmu <uses-library>), odczuwały skutki zwiększonego zużycia pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jeden z wymienionych powyżej nazwanych mian pakietów (np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.

Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Celem tej sekcji jest po prostu utrwalenie tych konwencji i ustanowienie ich jako wiążących poprzez uwzględnienie w tej definicji zgodności.

3.7. Zgodność w czasie działania

Implementacje na urządzeniu MUSZĄ obsługiwać pełny format Dalvik Executable (DEX) oraz specyfikację i semantykę bajtkodów Dalvik [Resources, 20]. Implementatorzy urządzeń powinni używać ART, referencyjnej implementacji upstream formatu wykonywalnego Dalvik oraz systemu zarządzania pakietami referencyjnej implementacji.

Implementacje urządzeń MUSZĄ skonfigurować środowisko uruchomieniowe Dalvik w celu przydzielenia pamięci zgodnie z poprzednią platformą Androida i jak określono w tabeli poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

Pamiętaj, że podane poniżej wartości pamięci są wartościami minimalnymi, a implementacje urządzeń MOGĄ przydzielić więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna pamięć aplikacji
małe/normalne	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48 MB
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	80 MB
	400 dpi (400 dpi)	96 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560 dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
duża	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)	48 MB
	213 dpi (tvdpi)	80 MB
	240 dpi (hdpi)
	280 dpi	96 MB
	320 dpi (xhdpi)	128 MB
	400 dpi (400 dpi)	192 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560 dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
bardzo duża	120 dpi (ldpi)	48 MB
	160 dpi (mdpi)	80 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	280 dpi	144 MB
	320 dpi (xhdpi)	192 MB
	400 dpi (400 dpi)	288 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560 dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Zgodność interfejsu

3.8.1. Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługuje aplikacje innych firm, które mogą zastąpić aplikację uruchamiającą urządzenie (ekran główny). Implementacje na urządzeniu, które umożliwiają aplikacjom innych firm zastępowanie ekranu głównego urządzenia, MUSZĄ deklarować funkcję platformy android.software.home_screen.

3.8.2. Widżety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, który umożliwia aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi [Resources, 21]. Jest to funkcja, która jest MOCNO POLECANA do obsługi na urządzeniach przenośnych. Implementacje urządzeń, które obsługują umieszczanie widżetów na ekranie głównym, MUSZĄ spełniać te wymagania i deklarować obsługę funkcji platformy android.software.app_widgets.

• Aplikacje uruchamiające MUSZĄ zawierać wbudowane funkcje obsługi widżetów aplikacji i umożliwiać użytkownikom dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów bezpośrednio w aplikacji uruchamiającej.
• Implementacje na urządzeniach MUSZĄ umożliwiać renderowanie widżetów o standardowym rozmiarze siatki 4 x 4. Szczegółowe informacje znajdziesz we wskazówkach dotyczących projektowania widżetów aplikacji w dokumentacji pakietu SDK Androida [Materiały, 21].
• Implementacje urządzeń, które obsługują ekran blokady, MOGĄ obsługiwać widżety aplikacji na ekranie blokady.

3.8.3. Powiadomienia

Android zawiera interfejsy API, które umożliwiają deweloperom powiadamianie użytkowników o istotnych zdarzeniach [Zasoby, 22] za pomocą funkcji sprzętowych i programowych urządzenia.

Niektóre interfejsy API umożliwiają aplikacjom wysyłanie powiadomień lub zwracanie uwagi za pomocą sprzętu, w tym dźwięku, wibracji i światła. Implementacje na urządzeniach MUSZĄ obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z dokumentacją pakietu SDK oraz w takim zakresie, w jaki jest to możliwe w ramach sprzętu implementacji urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi prawidłowo wdrażać interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Więcej informacji o tym znajdziesz w sekcji 7.

Ponadto wdrożenie MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępnione w interfejsach API [Zasoby, 23] lub w przewodniku dotyczącym stylu ikon na pasku stanu/systemowym [Zasoby, 24], który w przypadku urządzenia Android TV obejmuje możliwość niewyświetlania powiadomień. Implementatorzy urządzeń MOGĄ zapewnić użytkownikom inne powiadomienia niż te dostępne w referencyjnej implementacji Androida w wersji open source. Jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

Android obsługuje różne powiadomienia, takie jak:

• Powiadomienia z zawartością multimedialną. Interaktywne widoki dla powiadomień o trwających działaniach.
• Powiadomienia z ostrzeżeniem. Widoki interaktywne, z którymi użytkownicy mogą wchodzić w interakcje lub je zamykać bez opuszczania bieżącej aplikacji.
• Powiadomienia na ekranie blokady. Powiadomienia wyświetlane na ekranie blokady z dokładną kontrolą widoczności.

Implementacje urządzeń z Androidem, gdy takie powiadomienia są widoczne, MUSZĄ prawidłowo wykonywać powiadomienia Rich i Heads-up oraz zawierać tytuł/nazwę, ikonę i tekst zgodnie z dokumentacją interfejsów API Androida [Resources, 25].

Android zawiera interfejsy API usługi Notification Listener, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizowania. Implementacje na urządzeniu MUSZĄ prawidłowo i natychmiast wysyłać powiadomienia w całości do wszystkich zainstalowanych usług odsłuchujących włączonych przez użytkownika, w tym wszystkie metadane dołączone do obiektu Notification.

3.8.4. Szukaj

Android zawiera interfejsy API [Resources, 26], które umożliwiają deweloperom dodanie wyszukiwarki do aplikacji oraz udostępnienie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia wpisywanie zapytań, wyświetlanie sugestii podczas pisania i wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania wyszukiwania w ich własnych aplikacjach oraz dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

Implementacje na urządzeniach z Androidem powinny obejmować wyszukiwanie globalne, czyli jeden wspólny interfejs wyszukiwania w całym systemie, który może wyświetlać sugestie w czasie rzeczywistym w odpowiedzi na wpisy użytkownika. Implementacje urządzeń powinny zawierać interfejsy API, które umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika w celu zapewnienia wyszukiwania w ich własnych aplikacjach. Implementacje urządzeń, które implementują interfejs wyszukiwania globalnego, MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono używane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm, które korzystają z tej funkcji, domyślnie wyświetlane powinny być wyniki i sugestie wyszukiwarki internetowej.

3.8.5. Toasty

Aplikacje mogą używać interfejsu Toast API do wyświetlania użytkownikowi krótkich napisów, które nie otwierają się w trybie modalnym i znikają po krótkim czasie [Resources, 27]. Implementacje urządzeń MUSZĄ wyświetlać komunikaty typu Toast aplikacji dla użytkowników w sposób dobrze widoczny.

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 deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i odczucie motywu Holo zdefiniowanego w pakiecie Android SDK [Resources, 28]. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom [Zasoby, 29].

Android zawiera rodzinę motywów „Material” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i odczucie motywu do różnych typów urządzeń z Androidem. Implementacje na urządzeniach MUSZĄ obsługiwać rodzinę motywów „Material” i NIE MOGĄ zmieniać żadnych atrybutów motywu Material ani zasobów udostępnianych aplikacjom [Resources, 30].

Android zawiera też rodzinę motywów „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i odczucie do motywu urządzenia zdefiniowanego przez implementatora urządzenia. Implementacje na urządzeniu mogą modyfikować atrybuty motywu domyślnego urządzenia udostępniane aplikacjom [Zasoby, 29].

Android obsługuje nowy wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom wypełniać obszar za paskiem stanu i paskiem nawigacji treściami aplikacji. Aby zapewnić spójne wrażenia dla deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych implementacjach urządzeń. Dlatego implementacje urządzeń z Androidem MUSZĄ używać koloru białego do ikon stanu systemu (takich jak siła sygnału i poziom naładowania baterii) oraz powiadomień wysyłanych przez system, chyba że ikona wskazuje stan problemowy [Resources, 29].

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej 1 „żywego tapety” [Resources, 31]. Tapety na żywo to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

Urządzenie jest uznawane za zdolne do niezawodnego uruchamiania tapet na żywo, jeśli może uruchamiać wszystkie tapety na żywo bez ograniczeń funkcjonalności przy rozsądznej częstotliwości klatek i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, nie działają prawidłowo, zużywają zbyt dużo energii procesora lub baterii albo działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do obsługi tapety na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Tapeta na żywo nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ używanie przez nią tego kontekstu może powodować konflikty z innymi aplikacjami, które również go używają.

Urządzenia, które mogą niezawodnie wyświetlać tapety na żywo zgodnie z opisem powyżej, POWINNY implementować tapety na żywo. Gdy to zrobią, muszą zgłosić flagę funkcji platformy android.software.live_wallpaper.

3.8.8. Przełączanie aktywności

Kod źródłowy Androida na upstreamie obejmuje ekran przeglądu [Resources, 32], interfejs użytkownika na poziomie systemu do przełączania zadań i wyświetlania ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie, gdy użytkownik ostatnio ją zamknął. Implementacje na urządzeniu, w tym klucz nawigacji do funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmieniać interfejs, ale MUSZĄ spełniać te wymagania:

• MUSI wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
• MUSI obsługiwać co najmniej 20 wyświetlanych aktywności.
• POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz.
• NALEŻY wyświetlić kolor wyróżnienia, ikonę i tytuł ekranu w ostatnich.
• NALEŻY wdrożyć zachowanie przypinania ekranu [Resources, 33] i udostępnić użytkownikowi menu ustawień, aby włączyć tę funkcję.
• NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to do momentu, gdy użytkownik wejdzie w interakcję z ekranem.

W przypadku implementacji urządzeń MOCNO zaleca się używanie interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach) na ekranie przeglądu.

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie danymi wejściowymi oraz edytory metod wejściowych innych firm [Materiały, 34]. 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 IME zgodnie z definicją w dokumentacji pakietu Android SDK.

Implementacje urządzeń, które deklarują funkcję android.software.input_methods, MUSZĄ udostępniać użytkownikowi mechanizm dodawania i konfigurowania 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. Sterowanie multimediami na ekranie blokady

W Androidzie 5.0 interfejs API klienta zdalnego sterowania został wycofany na rzecz szablonu powiadomienia o multimediach, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady [Zasoby, 35]. Implementacje urządzeń, które obsługują ekran blokady (z wyjątkiem implementacji Androida Automotive lub zegarka) MUSZĄ wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia multimedialnego.

3.8.11. Sny

Android obsługuje interaktywne wygaszacze ekranu o nazwie Dreams [Zasoby, 36]. Dreams umożliwia użytkownikom interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia z Androidem Watch MOGĄ wdrażać Dreams, ale inne typy implementacji urządzeń POWINNY uwzględniać obsługę Dreams i zapewnić użytkownikom opcję ustawień umożliwiającą konfigurowanie Dreams w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

Jeśli urządzenie ma czujnik sprzętowy (np. GPS), który może dostarczać współrzędne lokalizacji, tryby lokalizacji MUSZĄ być wyświetlane w menu Lokalizacja w Ustawieniach [Materiały, 37].

3.8.13. Unicode i czcionka

Android obsługuje kolorowe emotikony. Gdy implementacje na urządzeniach z Androidem obejmują metodę wprowadzania IME, urządzenia powinny udostępniać użytkownikowi metodę wprowadzania dla znaków emotikonów zdefiniowanych w Unicode 6.1 [Resources, 38]. Wszystkie urządzenia MUSZĄ obsługiwać renderowanie tych emotikonów w kolorze.

Android obsługuje czcionkę Roboto 2 w różnych grubościach: bezszeryfowa cienka, bezszeryfowa jasna, bezszeryfowa średnia, bezszeryfowa czarna, bezszeryfowa wąska, bezszeryfowa wąska jasna. Wszystkie te czcionki MUSZĄ być uwzględnione w przypadku języków dostępnych na urządzeniu oraz pełnego zakresu Unicode 7.0 w przypadku alfabetów łacińskiego, greckiego i cyrylickiego, w tym zakresów A, B, C i D alfabetu łacińskiego rozszerzonego oraz wszystkich znaków w bloku symboli walutowych w Unicode 7.0.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom z zabezpieczeniami wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne kasowanie danych, za pomocą interfejsu API do zarządzania urządzeniami na Androidzie [Zasoby, 39]. Implementacje na urządzeniach MUSZĄ udostępniać implementację klasy DevicePolicyManager [Resources, 40]. Implementacje urządzeń, które obsługują ekrany blokady z kodem PIN (liczbowym) lub hasłem (alfanumerycznym), MUSZĄ obsługiwać pełny zakres zasad administracyjnych urządzeń zdefiniowanych w dokumentacji pakietu SDK Androida [Zasoby, 39] i zgłaszać funkcję platformy android.software.device_admin.

Implementacje urządzeń mogą mieć wstępnie zainstalowaną aplikację, która wykonuje funkcje administracyjne urządzenia, ale ta aplikacja NIE MOŻE być domyślną aplikacją właściciela urządzenia [Zasoby, 41].

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która ułatwia użytkownikom z niepełnosprawnościami poruszanie się po urządzeniach. Dodatkowo Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak odczytywanie tekstu, informacje zwrotne haptyczne i sterowanie za pomocą kulki/padówka [Resources, 42].

W przypadku implementacji na urządzeniach obowiązują te wymagania:

• Implementacje Androida Automotive powinny zawierać platformę ułatwień dostępu Androida zgodną z domyślną implementacją Androida.
• Implementacje na urządzeniach (z wyjątkiem Androida Automotive) MUSZĄ zawierać implementację platformy ułatwień dostępu w Androidzie zgodną z domyślną implementacją w Androidzie.
• Implementacje na urządzeniach (z wyjątkiem Androida Automotive) MUSZĄ obsługiwać implementacje usług ułatwień dostępu innych firm za pomocą interfejsów android.accessibilityservice API [Zasoby, 43]
• Implementacje na urządzeniach (z wyjątkiem Androida Automotive) MUSZĄ generować zdarzenia AccessibilityEvents i przekazywać je do wszystkich zarejestrowanych implementacji AccessibilityService w sposób zgodny z domyślną implementacją Androida.
• Implementacje urządzeń (Android Automotive i zegarek z Androidem, z wyłączeniem wyjścia audio) MUSZĄ udostępniać użytkownikowi mechanizm umożliwiający włączenie i wyłączenie usług ułatwień dostępu. Interfejs ten MUSI być wyświetlany w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Dodatkowo implementacje na urządzeniu powinny zawierać implementację usługi ułatwień dostępu na urządzeniu oraz mechanizm umożliwiający użytkownikom jej włączenie podczas konfiguracji urządzenia. Implementacja usługi ułatwień dostępu typu open source jest dostępna w ramach projektu Eyes Free [Materiały, 44].

3.11. Zamiana tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS), a także umożliwia dostawcom usług implementowanie usług TTS [Zasoby, 45]. Implementacje urządzeń zgłaszające funkcję android.hardware.audio.output MUSZĄ spełniać te wymagania związane z ramami TTS Androida.

Implementacje Androida Automotive:

• MUSI obsługiwać interfejsy API platformy TTS na Androidzie.
• MOŻE obsługiwać instalację silników TTS innych firm. Jeśli jest to obsługiwane, partnerzy MUSZĄ udostępnić interfejs dostępny dla użytkownika, który umożliwia wybór silnika TTS do użycia na poziomie systemu.

Wszystkie inne implementacje urządzeń:

• Musi obsługiwać interfejsy API frameworku TTS na Androidzie i powinna zawierać mechanizm TTS obsługujący języki dostępne na urządzeniu. Pamiętaj, że upstreamowe oprogramowanie open source na Androida zawiera w pełni funkcjonalną implementację silnika TTS.
• MUSI obsługiwać instalację silników TTS innych firm
• MUSI zawierać interfejs dostępny dla użytkownika, który umożliwia wybór silnika TTS do użycia na poziomie systemu.

3.12. Framework wejścia TV

Interfejs TIF (Android Television Input Framework) upraszcza dostarczanie treści na żywo na urządzeniach z Androidem TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych, które sterują urządzeniami z Androidem TV. Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać ramkę wejścia telewizyjnego [Zasoby, 46].

Implementacje urządzeń, które obsługują TIF, MUSZĄ zadeklarować funkcję platformy android.software.live_tv.

4. Zgodność z pakietem aplikacji

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

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 48], pliku manifestu Androida [Zasoby, 49], kodu bajtowego Dalvik [Zasoby, 20] ani kodu bajtowego RenderScript w taki sposób, aby uniemożliwić ich prawidłowe instalowanie i uruchamianie na innych zgodnych urządzeniach.

5. Zgodność multimedialna

5.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać podstawowe formaty multimediów określone w dokumentacji pakietu SDK Androida [Zasoby, 50], z wyjątkiem przypadków, w których 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 zdefiniowane w tabeli poniżej i zgłaszane za pomocą MediaCodecList [Resources,112]. Implementacje urządzeń MUSZĄ być również w stanie dekodować wszystkie profile zgłoszone w urządzeniu CamcorderProfile [Resources, 113]. Wszystkie te kodeki są udostępniane jako implementacje oprogramowania w ramach preferowanej implementacji Androida z Projektu Android Open Source.

Pamiętaj, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki są wolne od patentów innych firm. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny pamiętać, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich właścicieli patentów.

5.1.1. Kodeki audio

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików i formaty kontenerów
Profil MPEG-4 AAC (AAC LC)	WYMAGANE1	WYMAGANE	Obsługa treści mono/stereo/5.0/5.12 o standardowej częstotliwości próbkowania od 8 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, dekodowanie w Androidzie 3.1 lub nowszym, kodowanie w Androidzie 4.0 lub nowszym, ADIF nie jest obsługiwany) MPEG-TS (.ts, nieprzeskakuj, Android 3.0 lub nowszy)
MPEG-4 HE AAC Profile (AAC+)	WYMAGANE1 (Android 4.1 lub nowszy)	WYMAGANE	Obsługa treści mono/stereo/5.0/5.12 o standardowych częstotliwościach próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2 Profil (ulepszone AAC+)		WYMAGANE	Obsługa treści mono/stereo/5.0/5.12 o standardowych częstotliwościach próbkowania od 16 do 48 kHz.
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu)	WYMAGANE1 (Android 4.1 lub nowszy)	WYMAGANE (Android 4.1 lub nowszy)	Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.
AMR-NB	WYMAGANE3	WYMAGANE3	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
AMR-WB	WYMAGANE3	WYMAGANE3	9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz
FLAC		WYMAGANE (Android 3.1 lub nowszy)	Mono/Stereo (bez kanałów dodatkowych). Częstotliwości próbkowania do 48 kHz (ale na urządzeniach z wyjściami 44,1 kHz zalecamy stosowanie częstotliwości do 44,1 kHz, ponieważ konwerter 48/44,1 kHz nie zawiera filtra dolnoprzepustowego). Zalecamy 16-bitową rozdzielczość. W przypadku 24-bitowej rozdzielczości nie stosuje się ditheringu.	Tylko FLAC (.flac)
MP3		WYMAGANE	Mono/Stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR)	MP3 (.mp3)
MIDI		WYMAGANE	Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Typ 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		WYMAGANE		Ogg (.ogg) Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE	WYMAGANE4 (Android 4.1 lub nowszy)	WYMAGANE	16-bitowy PCM liniowy (częstotliwość do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nieskompresowanych nagrań PCM o częstotliwościach 8000, 11025, 16000 i 44100 Hz.	WAVE (.wav)
Opus		WYMAGANE (Android 5.0 lub nowszy)		Matroska (.mkv)

1 Wymagany w przypadku implementacji urządzeń, które definiują android.hardware.microphone, ale opcjonalny w przypadku implementacji urządzeń z Androidem Watch.

2. Wymagane jest tylko downmixowanie treści 5.0/5.1; nagrywanie lub renderowanie większej liczby kanałów jest opcjonalne.

3 Wymagany w przypadku implementacji na urządzeniach przenośnych z Androidem.

4 Wymagany w przypadku implementacji urządzeń, które definiują android.hardware.microphone, w tym implementacji urządzeń Android Watch.

5.1.2. Kodek obrazu

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików i formaty kontenerów
JPEG	WYMAGANE	WYMAGANE	Podstawowe + progresywne	JPEG (.jpg)
GIF		WYMAGANE		GIF (.gif)
PNG	WYMAGANE	WYMAGANE		PNG (.png)
BMP		WYMAGANE		BMP (.bmp),
WebP	WYMAGANE	WYMAGANE		WebP (.webp),

5.1.3. Kodeki wideo

Kodek wideo jest opcjonalny w przypadku implementacji na urządzeniach z Androidem Watch.

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików/ formaty kontenerów
H.263	WYMAGANE1	WYMAGANE2		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	WYMAGANE2	WYMAGANE2	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, tylko dźwięk AAC, nie można przeskakiwać, Android 3.0 lub nowszy)
H.265 HEVC		WYMAGANE5	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (.mp4)
MPEG-4 SP		WYMAGANE2		3GPP (.3gp)
VP83	WYMAGANE2 (Android 4.3 lub nowszy)	WYMAGANE2 (Android 2.3.3 lub nowszy)	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	WebM (.webm) [Resources, 110 Matroska (.mkv, Android 4.0 lub nowszy)4
VP9		WYMAGANE2 (Android 4.4 lub nowszy)	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) [Resources, 110] Matroska (.mkv, Android 4.0 lub nowszy)4

1 Wymagany w przypadku implementacji urządzeń, które zawierają sprzęt do obsługi aparatu i określają android.hardware.camera lub android.hardware.camera.front.

2 Wymagany w przypadku implementacji na urządzeniach z wyjątkiem zegarków z Androidem.

3 Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo w internecie i usług wideokonferencyjnych, implementacje urządzeń powinny używać sprzętowego kodeka VP8, który spełnia wymagania podane w [Zasoby, 51].

4. Implementacje urządzeń powinny obsługiwać zapisywanie plików Matroska WebM.

5 Zdecydowanie zalecany w przypadku Androida Automotive, opcjonalny w przypadku zegarka z Androidem i wymagany w przypadku wszystkich innych typów urządzeń.

5.2. Kodowanie wideo

Implementacje urządzeń z Androidem, które obsługują kodek H.264, MUSZĄ obsługiwać profil podstawowy poziomu 3 i poniższe profile kodowania wideo SD (standardowej rozdzielczości) oraz POWINNY obsługiwać profil główny poziomu 4 i poniższe profile kodowania wideo HD (wysokiej rozdzielczości). W przypadku urządzeń z Androidem TV MOCNO POLECAMY kodowanie filmów w rozdzielczości HD 1080p przy 30 kl./s.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p1	HD 1080p1
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 kbps	2 Mb/s	4 Mb/s	10 Mb/s

1 W przypadku sprzętu, który obsługuje tę funkcję, ale BARDZO ZALECANA dla urządzeń z Androidem TV.

Implementacje urządzeń z Androidem, które obsługują kodek VP8, MUSZĄ obsługiwać profile kodowania filmów w standardzie SD i POWINNY obsługiwać te profile kodowania filmów w standardzie HD (wysokiej rozdzielczości).

	SD (niska jakość)	SD (wysoka jakość)	HD 720p1	HD 1080p1
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

1 Jeśli jest to obsługiwane przez sprzęt.

5.3. Dekodowanie wideo

Implementacje urządzeń MUSZĄ obsługiwać dynamiczne przełączanie rozdzielczości wideo w tym samym strumieniu w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 udostępnionych deweloperom za pomocą standardowych interfejsów API Androida.

Implementacje urządzeń z Androidem z dekoderami H.264 MUSZĄ obsługiwać profil podstawowy poziomu 3 i poniższe profile dekodowania wideo SD oraz POWINNY obsługiwać profile dekodowania HD. Urządzenia z Androidem TV MUSZĄ obsługiwać profil High Profile Level 4.2 oraz profil dekodowania HD 1080p.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p1	HD 1080p1
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 fps / 60 fps2	30 fps / 60 fps2
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 Wymagane w przypadku implementacji urządzeń z Androidem TV, ale w przypadku innych typów urządzeń tylko wtedy, gdy jest obsługiwane przez sprzęt.

2 Wymagany w przypadku implementacji na urządzeniach z Androidem TV.

Implementacje urządzeń z Androidem, które obsługują kodek VP8 zgodnie z opisem w sekcji 5.1.3, MUSZĄ obsługiwać te profile dekodowania SD i POWINNY obsługiwać profile dekodowania HD. Urządzenia z Androidem TV MUSZĄ obsługiwać profil dekodowania HD 1080p.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p1	HD 1080p1
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 fps / 60 fps2	30 / 60 fps2
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 Wymagane w przypadku implementacji urządzeń z Androidem TV, ale w przypadku innych typów urządzeń tylko wtedy, gdy jest obsługiwane przez sprzęt.

2 Wymagany w przypadku implementacji na urządzeniach z Androidem TV.

Implementacje urządzeń z Androidem, które obsługują kodek VP9 zgodnie z opisem w sekcji 5.1.3, MUSZĄ obsługiwać te profile dekodowania wideo SD i POWINNY obsługiwać profile dekodowania HD. Zalecamy, aby urządzenia z Androidem TV obsługiwały profil dekodowania HD 1080p i powinny obsługiwać profil dekodowania UHD. Jeśli profil dekodowania filmów UHD jest obsługiwany, MUSI obsługiwać 8-bitową głębię kolorów.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 2	UHD 2
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	10 Mb/s	20 Mb/s

1 Wymagane w przypadku implementacji urządzeń z Androidem TV, ale w przypadku innych typów urządzeń tylko wtedy, gdy jest obsługiwane przez sprzęt.

2 MOCNO ZALECANA w przypadku implementacji urządzeń z Androidem TV, jeśli jest to obsługiwane przez sprzęt.

Implementacje urządzeń z Androidem, które obsługują kodek H.265 zgodnie z opisem w sekcji 5.1.3, MUSZĄ obsługiwać profil główny poziomu 3 i poziom główny profilu głównego oraz te profile dekodowania wideo SD, a także POWINNY obsługiwać profile dekodowania HD. Urządzenia z Androidem TV powinny obsługiwać profil Main10 Level 5 Main Tier i profil dekodowania UHD. Urządzenia z Androidem TV powinny obsługiwać profil dekodowania HD 1080p. Jeśli obsługiwany jest profil dekodowania HD 1080p, MUSI on obsługiwać poziom profilu głównego 4.1.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 2	UHD 2
Rozdzielczość wideo	352 x 288 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	10 Mb/s	20 Mb/s

1 Wymagane w przypadku implementacji urządzenia z Androidem TV, ale w przypadku innych typów urządzeń tylko wtedy, gdy jest obsługiwane przez sprzęt.

2 MOCNO ZALECANA w przypadku implementacji na urządzeniach z Androidem TV, jeśli jest to obsługiwane przez sprzęt.

5.4. Nagrywanie dźwięku

Chociaż niektóre wymagania opisane w tej sekcji są oznaczone jako „NALEŻY”, od Androida 4.3 planujemy zmienić je na „MUSI”. Istniejące i nowe urządzenia z Androidem ZALECAMY spełniać te wymagania opisane jako „NALEŻY”, ponieważ w przeciwnym razie nie będą zgodne z Androidem po aktualizacji do przyszłej wersji.

5.4.1. Przechwytywanie dźwięku w formacie RAW

Implementacje urządzeń, które deklarują android.hardware.microphone, MUSZĄ umożliwiać rejestrowanie nieprzetworzonego dźwięku o tych właściwościach:

• Format: Linear PCM, 16-bit
• Częstotliwości próbkowania: 8000, 11025, 16000, 44100
• Kanały: mono

Implementacje urządzeń, które deklarują android.hardware.microphone, POWINNY umożliwiać rejestrowanie surowych treści audio o tych właściwościach:

• Format: Linear PCM, 16-bit
• Częstotliwości próbkowania: 22050, 48000
• Kanały: stereo

5.4.2. Przechwytywanie danych do rozpoznawania głosu

Oprócz powyższych specyfikacji nagrywania, gdy aplikacja rozpoczęła nagrywanie strumienia audio za pomocą źródła audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• Urządzenie POWINIEN mieć w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: ±3 dB w zakresie 100–4000 Hz.
• Czułość wejścia audio powinna być ustawiona tak, aby źródło o poziomie mocy akustycznej (SPL) wynoszącym 90 dB przy częstotliwości 1000 Hz dawało wartość RMS wynoszącą 2500 dla próbek 16-bitowych.
• Poziomy amplitudy PCM POWINNY śledzić zmiany SPL wejścia w zakresie co najmniej 30 dB od –18 dB do +12 dB w stosunku do 90 dB SPL przy mikrofonie.
• Całkowite zniekształcenie harmoniczne POWINIEN być mniejszy niż 1% dla 1 kHz przy 90 dB SPL na wejściu do mikrofonu.
• Przetwarzanie redukcji szumów (jeśli występuje) MUSI być wyłączone.
• Automatyczna kontrola wzmocnienia (jeśli jest dostępna) MUSI być wyłączona.

Jeśli platforma obsługuje technologie tłumienia szumów dostosowane do rozpoznawania mowy, efekt MUSI być możliwy do kontrolowania za pomocą interfejsu API android.media.audiofx.NoiseSuppressor. Ponadto pole UUID w przypadku deskryptora efektu wyciszenia szumu MUSI jednoznacznie identyfikować każdą implementację technologii wyciszania szumu.

5.4.3. Przechwytywanie w celu przekierowania odtwarzania

Klasa android.media.MediaRecorder.AudioSource zawiera źródło audio REMOTE_SUBMIX. Urządzenia, które deklarują android.hardware.audio.output, MUSZĄ prawidłowo zaimplementować źródło audio REMOTE_SUBMIX, aby aplikacja korzystająca z interfejsu API android.media.AudioRecord do nagrywania z tego źródła dźwięku mogła rejestrować miks wszystkich strumieni audio z wyjątkiem:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Odtwarzanie dźwięku

Implementacje urządzeń, które deklarują android.hardware.audio.output, MUSZĄ być zgodne z wymaganiami podanymi w tej sekcji.

5.5.1. Odtwarzanie dźwięku w postaci surowych danych

Urządzenie MUSI umożliwiać odtwarzanie surowych treści audio z tymi cechami:

• Format: Linear PCM, 16-bit
• Częstotliwości próbkowania: 8000, 11025, 16000, 22050, 32000, 44100
• Kanały: mono, stereo

Urządzenie POWINIEN umożliwiać odtwarzanie surowych treści audio o tych cechach:

• Częstotliwości próbkowania: 24000, 48000

5.5.2. Efekty dźwiękowe

Android udostępnia interfejs API do efektów dźwiękowych na potrzeby implementacji na urządzeniu [Materiały, 52]. Implementacje na urządzeniach, które deklarują funkcję android.hardware.audio.output:

• MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, które można kontrolować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.
• MUSI obsługiwać implementację interfejsu API wizualizacji, którą można kontrolować za pomocą klasy Visualizer.
• NALEŻY obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, które można kontrolować za pomocą podklas AudioEffect BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.

5.5.3. Głośność wyjścia audio

Implementacje urządzeń z Androidem TV MUSZĄ obejmować obsługę systemu Master Volume i obniżania głośności wyjścia audio cyfrowego na obsługiwanych wyjściach, z wyjątkiem wyjścia z przepuszczaniem skompresowanego dźwięku (gdzie nie jest wykonywane dekodowanie dźwięku na urządzeniu).

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele rodzajów aplikacji wymaga niskich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

W rozumieniu tego punktu stosuje się następujące definicje:

• opóźnienie wyjścia. Interval między zapisaniem przez aplikację ramki danych kodowanych w formacie PCM a chwilą, gdy odpowiedni dźwięk może być słyszalny dla zewnętrznego słuchacza lub zarejestrowany przez przetwornik.
• opóźnienie zimnego wyjścia. Opóźnienie wyjścia pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na wyjście. Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie reakcji. Interval między momentem, gdy zewnętrzny dźwięk jest prezentowany na urządzeniu, a momentem, gdy aplikacja odczytuje odpowiednią ramkę danych kodowanych w formacie PCM.
• Opóźnienie w przypadku zimnego wejścia. Suma czasu utraconego na wprowadzenie danych i opóźnienia wprowadzania danych dla pierwszej klatki, gdy system wprowadzania danych audio był nieaktywny i wyłączony przed żądaniem.
• ciągłe opóźnienie wejścia. Opóźnienie wejścia w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
• tylko w przypadku jittera na wyjściu. Różnica między poszczególnymi pomiarami wartości opóźnienia w przypadku zimnego wyjścia.
• Jitter na zimnym wejściu. Odchylenie standardowe między poszczególnymi pomiarami wartości opóźnienia wejścia „na zimno”.
• ciągłe opóźnienie w obie strony. Suma opóźnienia ciągłego wejścia i opóźnienia ciągłego wyjścia oraz 5 milisekund.
• OpenSL ES PCM buffer queue API. Zestaw interfejsów OpenSL ES związanych z PCM w Android NDK; zobacz NDK_root/docs/opensles/index.html.

Implementacje urządzeń, które deklarują android.hardware.audio.output, powinny spełniać te wymagania dotyczące wyjścia audio lub przekraczać je:

• opóźnienie wyjścia „na zimno” nie większe niż 100 ms;
• ciągłe opóźnienie wyjścia na poziomie 45 ms lub mniej
• minimalizowanie jittera wyjścia „na zimno”;

Jeśli implementacja urządzenia spełnia wymagania podane w tym rozdziale po początkowej kalibracji przy użyciu interfejsu API kolejki buforowej OpenSL ES PCM, w przypadku opóźnienia ciągłego wyjścia i opóźnienia wyjścia po uruchomieniu na co najmniej 1 obsługiwanym urządzeniu wyjścia audio, MOŻE zgłosić obsługę dźwięku o niskim opóźnieniu, zgłaszając funkcję android.hardware.audio.low_latency za pomocą klasy android.content.pm.PackageManager [Resources, 53]. Jeśli implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku o małej latencji.

Implementacje urządzeń, które zawierają android.hardware.microphone, POWINNY spełniać te wymagania dotyczące wejścia audio:

• opóźnienie na wejściu „na zimno” nieprzekraczające 100 ms,
• ciągłe opóźnienie wejścia na poziomie 30 ms lub mniej,
• ciągłe opóźnienie w obie strony nieprzekraczające 50 ms;
• minimalizowanie jittera danych wejściowych „na zimno”

5.7. Protokoły sieciowe

Urządzenia MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu, zgodnie z dokumentacją pakietu Android SDK [Zasoby, 50]. Urządzenia MUSZĄ obsługiwać te protokoły sieci multimedialnych:

• RTSP (RTP, SDP)
• strumieniowe przesyłanie danych przez HTTP(S) w sposób progresywny;
• Projekt protokołu HTTP(S) do transmisji na żywo, wersja 3 [Resources, 54]

5.8. Secure Media

Implementacje urządzeń, które obsługują bezpieczne wyjście wideo i mogą obsługiwać bezpieczne powierzchnie, MUSZĄ deklarować obsługę Display.FLAG_SECURE. Implementacje urządzeń, które deklarują obsługę flagi Display.FLAG_SECURE, jeśli obsługują protokół wyświetlacza bezprzewodowego, MUSZĄ zabezpieczyć połączenie za pomocą silnego mechanizmu szyfrowania, takiego jak HDCP 2.x lub nowszy w przypadku wyświetlaczy bezprzewodowych Miracast. Podobnie jeśli urządzenia obsługują przewodowy wyświetlacz zewnętrzny, ich implementacje MUSZĄ obsługiwać HDCP 1.2 lub nowszą wersję. Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać HDCP 2.2 w przypadku urządzeń obsługujących rozdzielczość 4K oraz HDCP 1.4 lub nowszą w przypadku niższych rozdzielczości. Implementacja open source w górnym łańcuchu Androida obejmuje obsługę wyświetlaczy bezprzewodowych (Miracast) i przewodowych (HDMI), która spełnia to wymaganie.

6. Zgodność narzędzi dla programistów i opcji

6.1. Narzędzia dla programistów

Implementacje urządzeń MUSZĄ obsługiwać narzędzia deweloperskie Androida udostępniane w pakiecie Android SDK. Zgodne urządzenia z Androidem MUSZĄ być zgodne z:

• Android Debug Bridge (adb) [Materiały, 55]

Implementacje urządzeń MUSZĄ obsługiwać wszystkie funkcje adb zgodnie z dokumentacją w pakiecie Android SDK, w tym dumpsys [Resources, 56]. Demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia włączanie Android Debug Bridge. Jeśli implementacja urządzenia pomija tryb urządzenia peryferyjnego USB, MUSI implementować most debugowania Androida za pomocą sieci lokalnej (np. Ethernet lub 802.11).

Android obsługuje bezpieczne połączenia ADB. Tryb bezpieczny adb umożliwia korzystanie z adb na znanych hostach z uwierzytelnionymi użytkownikami. Implementacje urządzeń MUSZĄ obsługiwać bezpieczny interfejs adb.

• Dalvik Debug Monitor Service (ddms) [Resources, 57]

Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie funkcje DMS zgodnie z dokumentacją do pakietu Android SDK. Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywował Android Debug Bridge, jak opisano powyżej.

• Monkey [Resources, 58]

Implementacje na urządzeniu MUSZĄ zawierać platformę Monkey i musi być ona dostępna dla aplikacji.

• SysTrace [Resources, 59]

Implementacje na urządzeniach MUSZĄ obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu SDK Androida. Systrace musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.

Większość systemów opartych na Linuksie i systemów Apple Macintosh rozpoznaje urządzenia z Androidem za pomocą standardowych narzędzi Android SDK bez dodatkowego wsparcia. Systemy Microsoft Windows zwykle wymagają sterownika dla nowych urządzeń z Androidem. (na przykład nowe identyfikatory dostawców, a czasami nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB w systemach Windows). Jeśli implementacja urządzenia nie jest rozpoznawana przez narzędzie adb udostępnione w standardowym pakiecie Android SDK, implementatorzy urządzeń MUSZĄ udostępnić sterowniki Windowsa, które pozwolą deweloperom na połączenie z urządzeniem przy użyciu protokołu adb. Te sterowniki MUSZĄ być udostępnione dla systemów Windows XP, Windows Vista, Windows 7, Windows 8 i Windows 9 w wersjach 32- i 64-bitowych.

6.2. Opcje programisty

Android zapewnia deweloperom możliwość konfigurowania ustawień związanych z rozwojem aplikacji. Implementacje na urządzeniach MUSZĄ obsługiwać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji [Resources, 60]. W dolnej implementacji Androida menu Opcje dewelopera jest domyślnie ukryte i użytkownicy mogą je otworzyć po naciśnięciu siedmiu (7) razy elementu menu Ustawienia > Informacje o urządzeniu > Numer kompilacji. Implementacje na urządzeniach MUSZĄ zapewniać spójne działanie opcji dla deweloperów. W szczególności implementacje na urządzeniach MUSZĄ domyślnie ukrywać Opcje programisty i MUSZĄ udostępniać mechanizm włączania Opcji programisty, który jest zgodny z implementacją w górnym łańcuchu Androida.

7. Zgodność sprzętowa

Jeśli urządzenie zawiera określony komponent sprzętowy z odpowiednim interfejsem API dla deweloperów innych firm, implementacja urządzenia MUSI wdrażać ten interfejs API zgodnie z dokumentacją pakietu Android SDK. Jeśli interfejs API w pakiecie SDK współdziała ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• Pełne definicje klas (opisane w pakiecie SDK) interfejsów API komponentów MUSZĄ być jednak nadal dostępne.
• Interfejs API MUSI być zaimplementowany w taki sposób, aby nie wykonywał żadnych operacji.
• Metody interfejsu API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
• Metody interfejsu API MUSZĄ zwracać implementacje no-op klas, w których wartości null nie są dozwolone w dokumentacji pakietu SDK.
• Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefony te interfejsy API muszą być implementowane jako operacje bez stanu.

Implementacje urządzeń MUSZĄ konsekwentnie przekazywać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji. [Resources, 53]

7.1. Wyświetlanie i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych [Zasoby, 61]. Urządzenia MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z informacjami podanymi w tej sekcji.

Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w ten sposób:

• fizyczna przekątna. Odległość w calach między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• punkty na cal (dpi). Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1 cala. Jeśli podano wartości dpi, zarówno dpi poziome, jak i pionowy muszą mieścić się w zakresie.
• format. Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli będzie miał współczynnik 854/480 = 1, 779, czyli mniej więcej „16:9”.
• Piksel niezależny od gęstości (dp) Wirtualna jednostka piksela znormalizowana do ekranu o rozdzielczości 160 dpi, obliczana jako: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar ekranu

Interfejs użytkownika Androida obsługuje różne rozmiary ekranu i pozwala aplikacjom uzyskiwać informacje o rozmiarze ekranu urządzenia (czyli „układzie ekranu”) za pomocą android.content.res.Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK. Implementacje na urządzeniach MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z definicją w dokumentacji pakietu Android SDK [Resources, 61] i określonym przez nadrzędną platformę Android. W szczególności implementacje na urządzeniach MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z podanymi niżej wymiarami ekranu w logicznych pikselach niezależnych od gęstości (dp).

• Urządzenia MUSZĄ mieć ekran o wymiarach co najmniej 426 x 320 dp („małe”), chyba że jest to zegarek z Androidem.
• Urządzenia, które zwracają rozmiar ekranu „normalny”, MUSZĄ mieć rozmiar ekranu co najmniej 480 dp x 320 dp.
• Urządzenia, które podają rozmiar ekranu „duży”, MUSZĄ mieć ekran o rozmiarach co najmniej 640 dp x 480 dp.
• Urządzenia, które podają rozmiar ekranu „xlarge”, MUSZĄ mieć ekran o rozmiarach co najmniej 960 dp x 720 dp.

Dodatkowo

• Urządzenia z Androidem Watch MUSZĄ mieć ekran o fizycznej przekątnej o wymiarach od 1,1 do 2,5 cala.
• Inne typy implementacji urządzeń z Androidem, w których ekran jest fizycznie zintegrowany, MUSZĄ mieć ekran o fizycznej przekątnej co najmniej 2,5 cala.

Raportowany rozmiar ekranu urządzenia NIE MOŻE się zmieniać.

Aplikacje mogą opcjonalnie wskazywać obsługiwane rozmiary ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje na urządzeniach MUSZĄ prawidłowo obsługiwać deklarowane przez aplikacje ekrany małe, normalne, duże i bardzo duże, zgodnie z opisem w dokumentacji pakietu SDK Androida.

7.1.1.2. Format obrazu

Format obrazu ekranu MUSI mieć wartość od 1,3333 (4:3) do 1,86 (około 16:9), ale urządzenia z Androidem Watch MOGĄ mieć format 1,0 (1:1), ponieważ taka implementacja urządzenia będzie używać android.content.res.Configuration.uiMode jako UI_MODE_TYPE_WATCH.

7.1.1.3. Gęstość ekranu

Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji. Implementacje urządzeń MUSZĄ raportować tylko jedną z tych gęstości logicznych w ramach interfejsu API android.util.DisplayMetrics. Aplikacje MUSZĄ działać przy tej standardowej gęstości i NIE mogą zmieniać tej wartości w żadnym momencie w przypadku wyświetlacza domyślnego.

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi
• 320 dpi (xhdpi)
• 400 dpi (400 dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560 dpi)
• 640 dpi (xxxhdpi)

Implementacje urządzeń powinny zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna spowoduje, że zgłaszany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany zgodny rozmiar ekranu (szerokość 320 dp), implementacje na urządzeniach powinny zgłaszać następną niżej standardową gęstość w ramach Androida.

7.1.2. Dane dotyczące wyświetleń

Implementacje urządzeń MUSZĄ przekazywać prawidłowe wartości wszystkich danych dotyczących wyświetlacza zdefiniowanych w android.util.DisplayMetrics [Resources, 62] i MUSZĄ przekazywać te same wartości niezależnie od tego, czy jako domyślny wyświetlacz jest używany wbudowany czy zewnętrzny ekran.

7.1.3. Orientacja ekranu

Urządzenia MUSZĄ zgłaszać, które orientacje ekranu obsługują (android.hardware.screen.portrait lub android.hardware.screen.landscape) oraz MUSZĄ zgłaszać co najmniej 1 obsługiwaną orientację. Na przykład urządzenie z ekranem w orientacji poziomej o niezmiennej orientacji, takie jak telewizor czy laptop, POWINNA zgłaszać tylko android.hardware.screen.landscape.

Urządzenia, które obsługują obie orientacje ekranu, MUSZĄ obsługiwać dynamiczną orientację aplikacji w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu. Implementacje urządzeń MOGĄ domyślnie wybierać orientację pionową lub poziomą.

Urządzenia MUSZĄ zwracać prawidłową wartość bieżącego położenia urządzenia, gdy zostanie zapytanie o to za pomocą android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Urządzenia NIE MOGĄ zmieniać zgłaszanego rozmiaru ekranu ani gęstości podczas zmiany orientacji.

7.1.4. akceleracja grafiki 2D i 3D;

Implementacje na urządzeniach MUSZĄ obsługiwać zarówno OpenGL ES 1.0, jak i 2.0, zgodnie z opisem i szczegółami w dokumentacji pakietu SDK Androida. Implementacje na urządzeniach powinny obsługiwać OpenGL ES 3.0 lub 3.1 na urządzeniach, które mogą to obsługiwać. Implementacje na urządzeniu MUSZĄ obsługiwać Android RenderScript, zgodnie z dokumentacją pakietu Android SDK [Zasoby, 63].

Implementacje na urządzeniu MUSZĄ poprawnie identyfikować się jako obsługujące OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 lub OpenGL 3.1. To oznacza, że

• Zarządzane interfejsy API (np. za pomocą metody GLES10.getString()) MUSZĄ zgłaszać obsługę OpenGL ES 1.0 i OpenGL ES 2.0.
• Natywna biblioteka OpenGL w języku C/C++ (interfejsy API dostępne dla aplikacji za pomocą libGLES_v1CM.so, libGLES_v2.so lub libEGL.so) MUSI raportować obsługę OpenGL ES 1.0 i OpenGL ES 2.0.
• Implementacje urządzeń, które deklarują obsługę OpenGL ES 3.0 lub 3.1, MUSZĄ obsługiwać odpowiednie zarządzane interfejsy API oraz zawierać obsługę natywnych interfejsów API C/C++. W implementacjach na urządzeniu, które deklarują obsługę OpenGL ES 3.0 lub 3.1, plik libGLESv2.so MUSI eksportować odpowiednie symbole funkcji oprócz symboli funkcji OpenGL ES 2.0.

Oprócz OpenGL ES 3.1 Android udostępnia pakiet rozszerzeń z interfejsami Java [Resources, 64] oraz obsługę zaawansowanych funkcji graficznych, takich jak teselacja i format kompresji tekstur ASTC. Implementacje urządzeń z Androidem MOGĄ obsługiwać ten pakiet rozszerzeń i – tylko jeśli są w pełni zaimplementowane – MUSZĄ identyfikować obsługę za pomocą flagi funkcji android.hardware.opengles.aep.

Implementacje na urządzeniach MOGĄ stosować dowolne rozszerzenia OpenGL ES. Implementacje urządzeń muszą jednak zgłaszać za pomocą interfejsów API OpenGL ES zarządzanych i natywną wszystkie ciągi znaków rozszerzeń, które obsługują, i odwrotnie – nie muszą zgłaszać ciągów znaków rozszerzeń, których nie obsługują.

Pamiętaj, że Android obsługuje aplikacje, które opcjonalnie mogą wymagać określonych formatów kompresji tekstur OpenGL. Te formaty są zwykle specyficzne dla dostawcy. Android nie wymaga implementacji na urządzeniach żadnego konkretnego formatu kompresji tekstur. NALEŻY jednak dokładnie podać wszystkie obsługiwane formaty kompresji tekstur za pomocą metody getString() w interfejsie OpenGL API.

Android zawiera mechanizm, który umożliwia aplikacjom zadeklarowanie, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, czynności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API [Zasoby, 65].

Implementacje urządzeń MUSZĄ domyślnie włączać akcelerację sprzętową i MUSZĄ wyłączać akcelerację sprzętową, jeśli deweloper tego zażąda, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Androida View.

Ponadto implementacje na urządzeniach MUSZĄ działać zgodnie z dokumentacją Android SDK dotyczącą akceleracji sprzętowej [Resources, 65].

Android zawiera obiekt TextureView, który pozwala deweloperom bezpośrednio integrować tekstury OpenGL ES przyspieszone sprzętowo jako docelowe elementy renderowania w hierarchii interfejsu użytkownika. Implementacje na urządzeniu MUSZĄ obsługiwać interfejs TextureView API i MUSZĄ zachowywać się zgodnie z implementacją na Androidzie.

Android obsługuje atrybut EGL_ANDROID_RECORDABLE, który wskazuje, czy EGLConfig obsługuje renderowanie do okna ANativeWindow, które zapisuje obrazy w filmie. Implementacje urządzeń MUSZĄ obsługiwać rozszerzenie EGL_ANDROID_RECORDABLE [Resources, 66].

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

Android określa „tryb zgodności”, w którym framework działa w trybie „normalnego” rozmiaru ekranu (szerokość 320 dp) na potrzeby starszych aplikacji, które nie zostały opracowane na potrzeby starszych wersji Androida, które nie obsługują niezależności od rozmiaru ekranu.

• Android Automotive nie obsługuje starszego trybu zgodności.
• Wszystkie inne implementacje urządzeń MUSZĄ obsługiwać starszy tryb zgodności aplikacji, który jest implementowany przez kod źródłowy Androida open source. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani nie mogą zmieniać działania samego trybu zgodności.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na ekranie. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida, chyba że w tym dokumencie jest to wyraźnie dozwolone.

• Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować 16-bitową grafikę kolorową, i POWINNY obsługiwać wyświetlacze, które mogą renderować 24-bitową grafikę kolorową.
• Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować animacje.
• Używana technologia wyświetlania MUSI mieć współczynnik proporcji pikseli (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje wyświetlacz dodatkowy, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla programistów, które umożliwiają dostęp do wyświetlaczy zewnętrznych. Jeśli urządzenie obsługuje wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub za pomocą wbudowanego dodatkowego wyświetlacza, implementacja urządzenia MUSI implementować interfejs API menedżera wyświetlacza zgodnie z opisem w dokumentacji Android SDK [Zasoby, 67].

7.2. Urządzenia wejściowe

Urządzenia MUSZĄ obsługiwać ekran dotykowy lub spełniać wymagania wymienione w sekcji 7.2.2 dotyczące nawigacji bezdotykowej.

7.2.1. Klawiatura

Implementacje na urządzeniu:

• MUSI zawierać obsługę platformy zarządzania danymi wejściowymi (która umożliwia deweloperom zewnętrznym tworzenie edytorów metod wejściowych, np. klawiatury ekranowej), jak opisano na stronie http://developer.android.com.
• Musisz udostępnić co najmniej 1 implementację klawiatury ekranowej (niezależnie od tego, czy jest dostępna klawiatura fizyczna), z wyjątkiem urządzeń z Androidem Watch, na których rozmiar ekranu nie uzasadnia stosowania klawiatury ekranowej.
• MOŻE zawierać dodatkowe implementacje klawiatury ekranowej.
• MOŻE zawierać klawiaturę sprzętową.
• Nie wolno używać klawiatury sprzętowej, która nie odpowiada żadnemu z formatów określonych w android.content.res.Configuration.keyboard [Resources, 68] (QWERTY lub 12 klawiszy).

7.2.2. Nawigacja bezdotykowa

Implementacje na urządzeniu:

• MOŻNA pominąć opcję nawigacji bezdotykowej (kulka, pad kierunkowy lub koło) w przypadku implementacji na urządzeniu, które nie jest urządzeniem z Androidem TV.
• MUSI zwracać prawidłową wartość dla android.content.res.Configuration.navigation[Resources, 68].
• MUSI zawierać rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. Implementacja open source w górnym systemie Android zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają niedotykowych elementów sterujących.

7.2.3. Klawisze nawigacyjne

Funkcje Strona główna, Ostatnie i Wstecz (odpowiednio zmapowane na zdarzenia KEYCODE_HOME, KEYCODE_APP_SWITCH i KEYCODE_BACK) są niezbędne w ramach paradygmatu nawigacji w Androidzie.

• Implementacje na urządzeniach przenośnych z Androidem MUSZĄ zawierać funkcje ekranu głównego, ostatnich aplikacji i wstecz.
• Implementacje urządzeń z Androidem TV MUSZĄ zapewniać funkcje Wróć i Strona główna.
• Implementacje urządzeń z Androidem Watch MUSZĄ zawierać funkcję Home dostępną dla użytkownika oraz funkcję Wstecz, z wyjątkiem sytuacji, gdy jest ona w stanie UI_MODE_TYPE_WATCH.
• Implementacje Androida Automotive MUSZĄ zawierać funkcję ekranu głównego i MOGĄ zawierać funkcje Wstecz i Ostatnie.
• Wszystkie inne typy implementacji urządzeń MUSZĄ zawierać funkcje Wróć i Strona główna.

Te funkcje MOGĄ być realizowane za pomocą specjalnych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe) lub MOGĄ być realizowane za pomocą specjalnych klawiszy programowych na określonej części ekranu, gestów, panelu dotykowego itp. Android obsługuje obie implementacje. Wszystkie te funkcje MUSZĄ być dostępne za pomocą pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu) po wyświetleniu.

Funkcja Ostatnie (jeśli jest dostępna) MUSI mieć widoczny przycisk lub ikonę, chyba że jest ukryta razem z innymi funkcjami nawigacji w trybie pełnoekranowym. Nie dotyczy to urządzeń, które są aktualizowane z poprzednich wersji Androida i mają fizyczne przyciski do nawigacji, ale nie mają przycisku Ostatnie.

Funkcje Home i Back (jeśli są dostępne) MUSZĄ mieć widoczny przycisk lub ikonę, chyba że są ukryte razem z innymi funkcjami nawigacji w trybie pełnoekranowym lub gdy parametr uiMode UI_MODE_TYPE_MASK ma wartość UI_MODE_TYPE_WATCH.

Funkcja menu została wycofana na rzecz paska czynności od wersji Androida 4.0. Dlatego nowe implementacje urządzeń z Androidem 5.0 lub nowszym NIE MOGĄ implementować dedykowanego fizycznego przycisku do funkcji menu. Starsze implementacje na urządzeniach NIE powinny zawierać dedykowanego fizycznego przycisku menu. Jeśli jednak taki przycisk jest zaimplementowany, a na urządzeniu działają aplikacje z wartością targetSdkVersion > 10, implementacja urządzenia:

• NALEŻY wyświetlić przycisk menu akcji na pasku akcji, gdy jest on widoczny, a wynikające z tego menu akcji nie jest puste. W przypadku implementacji na urządzeniu wprowadzonej przed Androidem 4.4, ale aktualizowanej do Androida 5.1, zalecamy to rozwiązanie.
• Nie wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku menu na pasku akcji.
• Może wyświetlić wyskakujące menu czynności w zmodyfikowanej pozycji na ekranie, gdy zostanie ono wyświetlone po kliknięciu fizycznego przycisku menu.

Ze względu na zgodność wsteczną implementacje urządzeń MUSZĄ udostępnić aplikacjom funkcję menu, gdy wartość targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Ta funkcja menu powinna być wyświetlana, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Android obsługuje działanie Asystent [Zasoby, 69]. Implementacje urządzeń z Androidem (z wyjątkiem urządzeń z Androidem Watch) MUSZĄ udostępniać użytkownikowi działanie Asystenta przez cały czas działania aplikacji. Akcja Asystent powinna być implementowana jako przytrzymanie przycisku ekranu głównego lub gest przesunięcia w górę po przycisku ekranu głównego. Ta funkcja MOŻE być realizowana za pomocą innego przycisku fizycznego, klawisza programowego lub gestu, ale MUSI być dostępna za pomocą pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są widoczne.

Implementacje na urządzeniach mogą używać oddzielnej części ekranu do wyświetlania klawiszy nawigacyjnych, ale w takim przypadku muszą spełniać te wymagania:

• Klawisze nawigacyjne w implementacji urządzenia MUSZĄ używać osobnej części ekranu, niedostępnej dla aplikacji, i NIE MOGĄ zasłaniać ani w inny sposób zakłócać części ekranu dostępnej dla aplikacji.
• Implementacje urządzeń MUSZĄ udostępniać część ekranu aplikacjom, które spełniają wymagania określone w sekcji 7.1.1.
• Implementacje urządzeń MUSZĄ wyświetlać klawisze nawigacyjne, gdy aplikacje nie określają trybu interfejsu systemu ani nie określają flagi SYSTEM_UI_FLAG_VISIBLE.
• Implementacje urządzeń MUSZĄ wyświetlać klawisze nawigacyjne w nieinwazyjnym trybie „niskiego profilu” (np. przy przyciemnionym ekranie), gdy aplikacje określają flagę SYSTEM_UI_FLAG_LOW_PROFILE.
• Implementacje na urządzeniach MUSZĄ ukrywać klawisze nawigacji, gdy aplikacje określają flagę SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Dotykowe wprowadzanie danych

Implementacje urządzeń powinny mieć system wskaźnika (podobny do myszy lub dotykowy). Jeśli jednak implementacja urządzenia nie obsługuje systemu wprowadzania danych za pomocą wskaźnika, NIE MOŻE zgłaszać stałych funkcji android.hardware.touchscreen ani android.hardware.faketouch. Implementacje urządzeń, które zawierają system wskaźnika:

• NALEŻY obsługiwać wskaźniki śledzone niezależnie, jeśli system wejściowy urządzenia obsługuje wiele wskaźników.
• MUSI raportować wartość android.content.res.Configuration.touchscreen [Resources, 68] odpowiadającą typowi konkretnego ekranu dotykowego na urządzeniu.

Android obsługuje różne ekrany dotykowe, panele dotykowe i urządzenia dotykowe z fałszywym dotykiem. Implementacje urządzeń z ekranem dotykowym są powiązane z wyświetlaczem [Resources, 70], tak aby użytkownik miał wrażenie bezpośredniego manipulowania elementami na ekranie. Użytkownik dotyka bezpośrednio ekranu, więc system nie wymaga żadnych dodatkowych elementów, które wskazywałyby obiekty, którymi można manipulować. Natomiast fałszywy interfejs dotykowy udostępnia system wprowadzania danych, który w przybliżeniu odzwierciedla możliwości ekranu dotykowego. Na przykład mysz lub pilot zdalnego sterowania, które sterują kursorem na ekranie, naśladują dotyk, ale wymagają od użytkownika wskazania lub skupienia się na obiekcie, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, wskaźnik z żyroskopem, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą nazwę android.hardware.faketouch, która odpowiada urządzeniu wejściowemu niewymagającemu dotykowego (opartemu na wskaźniku), takiemu jak mysz lub panel dotykowy, które może odpowiednio emulować wejście dotykowe (w tym obsługę podstawowych gestów) 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ć wymagania dotyczące fałszywego dotyku podane w sekcji 7.2.5.

Implementacje urządzeń MUSZĄ zgłaszać prawidłową funkcję odpowiadającą używanemu typowi danych wejściowych. Implementacje urządzeń, które zawierają ekran dotykowy (jednodotykowy lub lepszy), MUSZĄ zgłaszać stałą funkcję platformy android.hardware.touchscreen. Implementacje urządzeń, które raportują stałą platformy android.hardware.touchscreen, MUSZĄ również raportować stałą platformy android.hardware.faketouch. Implementacje urządzeń, które nie mają ekranu dotykowego (i korzystają tylko z urządzenia wskazującego), NIE MOGĄ zgłaszać żadnych funkcji ekranu dotykowego i MOGĄ zgłaszać tylko android.hardware.faketouch, jeśli spełniają wymagania dotyczące fałszywego dotyku podane w sekcji 7.2.5.

7.2.5. Symulowane dotykowe wprowadzanie danych

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

• MUSI raportować bezwzględne pozycje X i Y wskaźnika na ekranie oraz wyświetlać wizualny wskaźnik na ekranie [Resources, 71].
• NALEŻY zgłaszać zdarzenie dotyku za pomocą kodu działania, który określa stan, który występuje, gdy wskaźnik przesuwa się w dół lub w górę na ekranie [Resources, 71].
• MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co pozwala użytkownikom emulować kliknięcie obiektu na ekranie.
• MUSI obsługiwać sekwencję „wskaźnik w dół, wskaźnik w górę, wskaźnik w dół, wskaźnik w górę” w tym samym miejscu na ekranie w ramach określonego progu czasowego, co pozwala użytkownikom emulować dwukrotne kliknięcie obiektu na ekranie [Resources, 71].
• MUSI obsługiwać wciśnięcie wskaźnika w dowolnym miejscu na ekranie, przesuwanie wskaźnika do dowolnego innego miejsca na ekranie, a następnie zwolnienie wskaźnika, co pozwala użytkownikom emulować przeciąganie palcem.
• MUSI obsługiwać kursor w dół, a potem musi umożliwiać użytkownikom szybkie przesuwanie obiektu w inne miejsce na ekranie, a potem kursor w górę na ekranie, co umożliwia użytkownikom rzucanie obiektem na ekranie.

Urządzenia, które deklarują obsługę android.hardware.faketouch.multitouch.distinct MUSZĄ spełniać wymagania dotyczące obsługi faketouch podane powyżej, a także MUSZĄ obsługiwać śledzenie niezależnych danych wejściowych co najmniej 2 wskaźników.

7.2.6. Obsługa kontrolera gier

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać mapowanie przycisków kontrolerów gier zgodnie z listą poniżej. Wdrożenie na Androidzie obejmuje sterowanie kontrolerem, które spełnia ten wymóg.

7.2.6.1. Mapowania przycisków

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać te mapowania kluczy:

Przycisk	Użycie HID2	Przycisk Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Joystick w górę1 Przycisk w dół1	0x01 0x00393	AXIS_HAT_Y4
przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_X4
Przycisk lewego uchwytu1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Strona główna1	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz1	0x0c 0x0224	KEYCODE_BACK (4)

1 [Zasoby, 72]

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach CA kontrolera do gier (0x01 0x0005).

3 Ta wartość musi mieć minimalną wartość logiczną 0, maksymalną wartość logiczną 7, minimalną wartość fizyczną 0, maksymalną wartość fizyczną 315, jednostki w stopniach oraz rozmiar raportu 4. Wartość logiczna jest zdefiniowana jako obrót zgodnie z kierunkiem ruchu wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i wciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45° i wciśnięcie przycisków w górę i w lewo.

4 [Resources, 71]

Analog Controls1	Użycie HID	Przycisk Android
Lepiej:	0x02 0x00C5	AXIS_LTRIGGER
Prawy spust	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 [Resources, 71]

7.2.7. Pilot

Implementacje urządzeń z Androidem TV powinny zawierać pilota, aby umożliwić użytkownikom dostęp do interfejsu telewizora. Pilot może być urządzeniem fizycznym lub opartym na oprogramowaniu, dostępnym z telefonu komórkowego lub tabletu. Pilot sterujący MUSI spełniać poniższe wymagania.

• Funkcjonalność wyszukiwania. Implementacje urządzeń MUSZĄ wywoływać KEYCODE_SEARCH, gdy użytkownik wywoła wyszukiwanie głosowe na pilocie fizycznym lub opartym na oprogramowaniu.
• Nawigacja. Wszystkie piloty do Androida TV MUSZĄ zawierać przyciski Wstecz, Ekran główny i Wybierz oraz obsługiwać zdarzenia D-pad [Resources, 72].

7.3. Czujniki

Android zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Implementacje urządzeń mogą w ogóle pomijać te czujniki, jak opisano w następnych podrozdziałach. Jeśli urządzenie zawiera określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK i dokumentacją Androida Open Source na temat czujników [Zasoby, 73]. Na przykład implementacje na urządzeniach:

• MUSI dokładnie raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager [Resources, 53].
• MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnych.
• W przypadku wszystkich innych interfejsów API czujników MUSI zachowywać się w rozsądny sposób (np. zwracać odpowiednio wartość true lub false, gdy aplikacje próbują zarejestrować słuchaczy, nie wywoływać słuchaczy czujników, gdy odpowiednie czujniki są nieobecne, itp.).
• Musi raportować wszystkie pomiary czujników, używając odpowiednich wartości Międzynarodowego Systemu Jednostek (SI) dla każdego typu czujnika zgodnie z dokumentacją Android SDK [Resources, 74].
• Powinien raportować czas zdarzenia w nanosekundach zgodnie z definicją w dokumentacji Android SDK, reprezentujący czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano(). Użytkowników obecnych i nowych urządzeń z Androidem bardzo zachęcamy do spełnienia tych wymagań, aby mogli korzystać z przyszłych wersji platformy, w których mogą stać się one wymagane. Błąd synchronizacji powinien być mniejszy niż 100 milisekund [Resources, 75].

Powyższa lista nie jest wyczerpująca. Należy wziąć pod uwagę udokumentowane działanie pakietu Android SDK oraz dokumentację na temat czujników w ramach projektu Open Source Androida [Resources, 73].

Niektóre typy czujników są złożone, co oznacza, że można je uzyskać na podstawie danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego). Implementacje urządzeń powinny stosować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w [Zasobach, 76]. Jeśli implementacja urządzenia zawiera czujnik złożony, MUSI ona implementować czujnik zgodnie z opisem w dokumentacji Androida Open Source dotyczącej czujników złożonych [Zasoby, 76].

Niektóre czujniki Androida obsługują tryb „ciągłego” wyzwalania, który stale zwraca dane [Resources, 77]. W przypadku interfejsów API oznaczonych w dokumentacji pakietu SDK Androida jako ciągłe czujniki implementacje na urządzeniu MUSZĄ stale dostarczać okresowych próbek danych, które POWINNY mieć jitter poniżej 3%, gdzie jitter jest zdefiniowany jako odchylenie standardowe różnicy wartości raportowanych sygnałów czasowych między kolejnymi zdarzeniami.

Pamiętaj, że implementacje na urządzeniu MUSZĄ zapewnić, aby strumień zdarzeń czujnika NIE blokował procesora w urządzeniu przed przejściem w stan zawieszenia ani przed wybudzeniem z tego stanu.

W przypadku kilku aktywnych czujników zużycie energii NIE POWINNA przekraczać sumy zużycia energii podanego dla poszczególnych czujników.

7.3.1. Akcelerometr

Implementacje na urządzeniach powinny zawierać 3-osiowy akcelerometr. Zalecamy, aby urządzenia przenośne z Androidem i zegarki z Androidem zawierały ten czujnik. Jeśli implementacja urządzenia zawiera 3-osiowy akcelerometr, to:

• NALEŻY zaimplementować czujnik TYPE_ACCELEROMETER i o nim poinformować [Resources, 78].
• W przypadku zegarków z Androidem aplikacja MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz, ponieważ takie urządzenia mają bardziej rygorystyczne ograniczenia dotyczące zużycia energii. W przypadku wszystkich innych typów urządzeń częstotliwość ta powinna wynosić 100 Hz.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
• MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida [Zasoby, 74].
• MUSI umożliwiać pomiar od swobodnego spadania do 4-krotnego przyspieszenia ziemskiego (4 g) lub więcej w dowolnej osi.
• Rozdzielczość musi wynosić co najmniej 8 bitów, a zalecana jest co najmniej 16 bitów.
• POWINIEN być kalibrowany podczas użytkowania, jeśli właściwości zmieniają się w trakcie cyklu życia, oraz zachowywać parametry kompensacji między ponownymi uruchamianiami urządzenia.
• POWINIEN być kompensowany temperaturowo.
• MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s2, gdzie odchylenie standardowe powinno być obliczane dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najszybszą częstotliwością próbkowania.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK. Istniejące i nowe urządzenia z Androidem bardzo zalecamy implementację czujnika złożonego TYPE_SIGNIFICANT_MOTION. Jeśli w urządzeniu zastosowano któryś z tych czujników, suma ich poboru mocy MUSI być zawsze mniejsza niż 4 mW, a każdy z nich powinien być mniejszy niż 2 mW i 0,5 mW w stanie dynamicznym lub stałym.
• Jeśli uwzględniono czujnik żyroskopu, MUSISZ zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz POWINIEN zostać zaimplementowany czujnik złożony TYPE_GAME_ROTATION_VECTOR. Zachęcamy do implementacji czujnika TYPE_GAME_ROTATION_VECTOR na istniejących i nowych urządzeniach z Androidem.
• NALEŻY zaimplementować czujnik złożony TYPE_ROTATION_VECTOR, jeśli czujnik żyroskopowy i czujnik magnetometru są również uwzględnione.

7.3.2. Magnetometr

Implementacje urządzeń powinny zawierać 3-osiowy magnetometr (kompas). Jeśli urządzenie ma 3-osiowy magnetometr:

• NALEŻY zaimplementować czujnik TYPE_MAGNETIC_FIELD i NALEŻY RÓWNIEŻ zaimplementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED. Zachęcamy do implementacji czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED na obecnych i nowych urządzeniach z Androidem.
• Musi być w stanie raportować zdarzenia z częstotliwością co najmniej 10 Hz i powinna raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida [Zasoby, 74].
• MUSI umożliwiać pomiar w zakresie od -900 µT do +900 µT na każdej osi przed nasyceniem.
• Wartość przesunięcia dla żelaza stałego MUSI być mniejsza niż 700 µT, a WARTO, aby była mniejsza niż 200 µT. Aby to osiągnąć, należy umieścić magnetometr z dala od pól magnetycznych dynamicznych (wywołanych przez prąd) i statycznych (wywołanych przez magnes).
• Rozdzielczość musi być równa lub większa niż 0,6 µT, a zalecana rozdzielczość powinna być równa lub większa niż 0,2 µ.
• POWINIEN być kompensowany temperaturowo.
• MUSI obsługiwać kalibrację online i kompensację błędów na poziomie sprzętu oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• NALEŻY zastosować kompensację miękkiego żelaza. Kalibrację można przeprowadzić w trakcie użytkowania lub podczas produkcji urządzenia.
• POWINNA mieć odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania, nie większą niż 0, 5 µT.
• NALEŻY zaimplementować czujnik złożony TYPE_ROTATION_VECTOR, jeśli czujnik przyspieszeniomierza i czujnik żyroskopu są również uwzględnione.
• MOŻESZ zaimplementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, jeśli masz też akcelerometr. Jednak jeśli jest ona używana, musi zużywać mniej niż 10 mW, a powinna zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie zbiorczym z częstotliwością 10 Hz.

7.3.3. GPS

Implementacje urządzeń powinny zawierać odbiornik GPS. Jeśli implementacja urządzenia obejmuje odbiornik GPS, powinna zawierać jakąś formę techniki „wspomagania GPS”, aby zminimalizować czas ustalania pozycji przez GPS.

7.3.4. Żyroskop

Implementacje na urządzeniach POWINNY zawierać żyroskop (czujnik zmiany kątowej). Urządzenia NIE powinny mieć czujnika żyroskopu, chyba że mają też 3-osiowy akcelerometr. Jeśli implementacja urządzenia zawiera żyroskop:

• Musisz zaimplementować czujnik TYPE_GYROSCOPE i powinieneś zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED. Istniejące i nowe urządzenia z Androidem powinny implementować czujnik SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.
• W przypadku zegarków z Androidem aplikacja MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz, ponieważ takie urządzenia mają bardziej rygorystyczne ograniczenia dotyczące zużycia energii. W przypadku wszystkich innych typów urządzeń częstotliwość ta powinna wynosić 100 Hz.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość musi wynosić co najmniej 12 bitów, a najlepiej 16 bitów.
• MUSI być wyposażony w kompensację temperatury.
• MUSI być skalibrowany i skompensowany podczas użytkowania oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• WARTOŚĆ musi być mniejsza niż 1e-7 rad^2 / s^2 na Hz (wartość na Hz lub rad^2 / s). Wartość odchylenia standardowego może się zmieniać wraz z częstotliwością próbkowania, ale musi być ograniczona do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie standardowe żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1 e-7 rad^2/s^2.
• NALEŻY zaimplementować czujnik złożony TYPE_ROTATION_VECTOR, jeśli uwzględniono również czujnik przyspieszeniomierza i czujnik magnetometru.
• Jeśli uwzględniono czujnik akcelerometru, MUSISZ zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz POWINIEN zostać zaimplementowany czujnik złożony TYPE_GAME_ROTATION_VECTOR. Zachęcamy do implementacji czujnika TYPE_GAME_ROTATION_VECTOR na istniejących i nowych urządzeniach z Androidem.

7.3.5. barometr;

Implementacje urządzenia POWINNY zawierać barometr (czujnik ciśnienia otoczenia). Jeśli implementacja urządzenia zawiera barometr, musi:

• NALEŻY wdrożyć i zgłaszać czujnik TYPE_PRESSURE.
• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz.
• Musi mieć odpowiednią dokładność, aby umożliwić oszacowanie wysokości.
• MUSI być wyposażony w kompensację temperatury.

7.3.6. Termometr

Implementacje urządzenia MOGĄ zawierać termometr otoczenia (czujnik temperatury). Jeśli jest obecny, MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (w pomieszczeniu) w stopniach Celsjusza.

Implementacje urządzeń MOGĄ, ale NIE POWINNY zawierać czujnika temperatury procesora. Jeśli jest obecny, to MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE, MUSI mierzyć temperaturę procesora urządzenia i NIE MOŻE mierzyć żadnej innej temperatury. Pamiętaj, że typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany w Androidzie 4.0.

7.3.7. Fotometr

Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

Urządzenia mogą być wyposażone w czujnik zbliżeniowy. Urządzenia, które mogą nawiązywać połączenia głosowe i zwracać w getPhoneType dowolną wartość inną niż PHONE_TYPE_NONE, powinny mieć czujnik zbliżeniowy. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy:

• MUSI mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być skierowany na obiekty znajdujące się blisko ekranu, ponieważ głównym celem tego typu czujnika jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy o dowolnej innej orientacji, NIE MOŻE być on dostępny za pomocą tego interfejsu API.
• Musi mieć co najmniej 1 bita dokładności.

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

Termin „telefonia” w rozumieniu interfejsów API Androida i tego dokumentu odnosi się konkretnie do sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów przez sieć GSM lub CDMA. Podczas gdy te połączenia głosowe mogą być przełączane pakietowo, w przypadku Androida są one traktowane niezależnie od wszelkich połączeń danych, które mogą być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API dotyczące „telefonii” w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje urządzeń, które nie mogą wykonywać połączeń ani wysyłać/odbierać SMS-ów, NIE MOGĄ zgłaszać funkcji android.hardware.telephony ani żadnych podfunkcji, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii. W przypadku implementacji na urządzeniach, które nie zawierają sprzętu telefonicznego, należy zaimplementować pełne interfejsy API jako nieobsługujące żadnych operacji.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje urządzeń Android TV MUSZĄ obejmować obsługę co najmniej jednej formy 802.11 (b/g/a/n itp.), a inne typy implementacji urządzeń z Androidem POWINNY obejmować obsługę co najmniej jednej formy 802.11. Jeśli implementacja urządzenia obejmuje obsługę 802.11 i udostępnia tę funkcję aplikacji innej firmy, MUSI zaimplementować odpowiedni interfejs API Androida i:

• MUSI zawierać flagę funkcji sprzętowej android.hardware.wifi.
• NALEŻY zaimplementować interfejs Multicast API zgodnie z opisem w dokumentacji pakietu SDK [Zasoby, 79].
• MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym wtedy, gdy ekran nie jest aktywny.

7.4.2.1. Wi-Fi Direct

Implementacje urządzeń powinny obejmować obsługę Wi-Fi Direct (Wi-Fi peer-to-peer). Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, MUSI ona zaimplementować odpowiedni interfejs API Androida zgodnie z dokumentacją pakietu SDK [Zasoby, 80]. Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, urządzenie:

• MUSI raportować funkcję sprzętową android.hardware.wifi.direct.
• MUSI obsługiwać zwykłe połączenia Wi-Fi.
• NALEŻY obsługiwać jednoczesne działanie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi

Implementacje urządzeń z Androidem TV MUSZĄ obejmować obsługę konfiguracji bezpośredniego połączenia przez tunel (TDLS) Wi-Fi, a inne typy implementacji urządzeń z Androidem POWINNY obejmować obsługę Wi-Fi TDLS zgodnie z opisem w dokumentacji pakietu Android SDK [Resources, 81]. Jeśli implementacja urządzenia obejmuje obsługę TDLS, a TDLS jest włączone przez interfejs API WiFiManager, urządzenie:

• NALEŻY używać TDLS tylko wtedy, gdy jest to możliwe i korzystne.
• POWINIEN zawierać heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku korzystania z punktu dostępu Wi-Fi.

7.4.3. Bluetooth

Android obsługuje Bluetooth i Bluetooth Low Energy [Resources, 82]. Implementacje urządzeń, które obejmują obsługę Bluetooth i Bluetooth Low Energy, MUSZĄ zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy. Implementacje urządzeń powinny stosować odpowiednie profile Bluetooth, takie jak A2DP, AVCP, OBEX itp. Implementacje urządzeń Android TV MUSZĄ obsługiwać Bluetooth i Bluetooth LE.

Implementacje urządzeń z obsługą Bluetooth Low Energy:

• NALEŻY zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• NALEŻY włączyć interfejsy API Bluetooth oparte na GATT (profil ogólny atrybutów) zgodnie z opisem w dokumentacji pakietu SDK i [Materiały, 82].
• NALEŻY obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas implementowania interfejsu API ScanFilter [Resources, 83] i MUSI przekazywać prawidłową wartość miejsca implementacji logiki filtrowania, gdy zostanie zapytany za pomocą metody android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
• NALEŻY obsługiwać przenoszenie skanowania zbiorczego na układ Bluetooth, ale jeśli nie jest to obsługiwane, NALEŻY zwracać wartość „false” w przypadku zapytania za pomocą metody android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported().
• Powinien obsługiwać reklamy wielokrotne z co najmniej 4 boksami, ale jeśli nie obsługuje, to w przypadku zapytania za pomocą metody android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() MUSI zwracać wartość „false”.

7.4.4. Komunikacja Near Field Communication

Urządzenia powinny zawierać nadajnik-odbiornik i powiązany sprzęt do komunikacji Near Field Communication (NFC). Jeśli implementacja urządzenia obejmuje sprzęt NFC i planuje udostępnienie go aplikacjom innych firm, musi:

• Musisz zgłosić funkcję android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature() [Resources, 53].
• MUSI obsługiwać odczytywanie i zapisywanie komunikatów NDEF za pomocą tych standardów NFC:
  • MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) zgodnie z tymi standardami NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • Typy tagów NFC Forum 1, 2, 3 i 4 (zdefiniowane przez NFC Forum)
  • Powinien być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC. Pamiętaj, że chociaż poniższe standardy NFC są opisane jako „NALEŻY”, w przyszłej wersji definicji zgodności planujemy zmienić je na „NALEŻY”. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy bardzo zdecydowanie, aby obecne i nowe urządzenia z tą wersją Androida spełniały te wymagania już teraz, ponieważ dzięki temu będą mogły przejść na przyszłe wersje platformy.
  • NfcV (ISO 15693)
  • MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:
    • ISO 18092
    • LLCP 1.0 (zdefiniowana przez NFC Forum)
    • SDP 1.0 (zdefiniowana przez NFC Forum)
    • Protokół NDEF Push [Resources, 84]
    • SNEP 1.0 (zdefiniowany przez NFC Forum)
  • MUSI zawierać obsługę Android Beam [Resources, 85]:
    • MUSI implementować serwer domyślny SNEP. Prawidłowe komunikaty NDEF otrzymane przez domyślny serwer SNEP MUSZĄ zostać wysłane do aplikacji za pomocą inencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie funkcji Android Beam w ustawieniach NIE MOŻE spowodować wyłączenia wysyłania przychodzących wiadomości NDEF.
    • MUSI obsługiwać intent android.settings.NFCSHARING_SETTINGS, aby wyświetlać ustawienia udostępniania NFC [Resources, 86].
    • MUSI implementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób jak przez serwer SNEP.
    • NALEŻY wdrożyć klienta SNEP i spróbować wysłać wychodzące dane NDEF w ramach komunikacji P2P do domyślnego serwera SNEP, gdy włączona jest funkcja Android Beam. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość na serwer NPP.
    • Musisz zezwolić aktywnościom na pierwszym planie na ustawianie wychodzących wiadomości NDEF P2P za pomocą android.nfc.NfcAdapter.setNdefPushMessage oraz android.nfc.NfcAdapter.setNdefPushMessageCallback oraz android.nfc.NfcAdapter.enableForegroundNdefPush.
    • NALEŻY użyć gestu lub potwierdzenia na ekranie (np. „Dotknij, aby przesłać”) przed wysłaniem wychodzących wiadomości P2P NDEF.
    • NALEŻY włączyć Android Beam domyślnie i MUSI być możliwe wysyłanie i odbieranie danych za pomocą Android Beam, nawet gdy włączony jest inny zastrzeżony tryb NFC P2P.
    • MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, jeśli urządzenie obsługuje profil Bluetooth Object Push. Implementacje urządzeń MUSZĄ obsługiwać przekazywanie połączeń do Bluetooth podczas korzystania z android.nfc.NfcAdapter.setBeamPushUris, poprzez implementację specyfikacji „Connection Handover version 1.2” [Resources, 87] i „Bluetooth Secure Simple Pairing Using NFC version 1.0” [Resources, 88] z Forum NFC. Takie wdrożenie MUSI implementować usługę LLCP z nazwą „urn:nfc:sn:handover” do wymiany żądań przekazywania/rekordów selekcji przekazywania za pomocą NFC. Wdrożenie MUSI używać profilu Bluetooth Object Push do faktycznego przesyłania danych przez Bluetooth. Ze względu na starsze wersje (aby zachować zgodność z urządzeniami z Androidem 4.1) implementacja powinna nadal akceptować żądania SNEP GET w celu wymiany żądania przekazania lub wybranych rekordów przez NFC. Jednak sama implementacja NIE POWINNA wysyłać żądań SNEP GET w celu przejęcia połączenia.
  • W trybie wykrywania NFC MUSI sprawdzać wszystkie obsługiwane technologie.
  • NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne, ekran jest włączony, a ekran blokady odblokowany.

(pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC Forum).

Android obsługuje tryb hosta karty NFC (HCE). Jeśli implementacja urządzenia zawiera układ kontrolera NFC, który obsługuje HCE i przekierowywanie identyfikatora aplikacji (AID), to:

• Musisz podać stałą funkcję android.hardware.nfc.hce.
• MUSI obsługiwać interfejsy API NFC HCE zgodnie z definicją w pakiecie SDK do Androida [