Wersja 1
Ostatnia aktualizacja: 12 stycznia 2015 r.

Copyright © 2015, Google Inc. Wszelkie prawa zastrzeżone.
compatibility@android.com

Spis treści

1. Wprowadzenie 2. Typy urządzeń 2.1 Konfiguracje urządzenia 3. Oprogramowanie 3.1. Zgodność z zarządzanymi interfejsami API 3.2. Zgodność z miękkim interfejsem API 3.2.1. Uprawnienia 3.2.2. Parametry kompilacji 3.2.3. Zgodność z zamiarem 3.2.3.1. Główne intencje aplikacji 3.2.3.2. Zastąpienia intencji 3.2.3.3. Przestrzenie nazw intencji 3.2.3.4. Intencje dotyczące przesyłania wiadomości 3.2.3.5. Domyślne ustawienia aplikacji 3.3. Zgodność z natywnym interfejsem API 3.3.1 Interfejsy binarne aplikacji 3.4. Zgodność z internetem 3.4.1. Zgodność WebView 3.4.2. Zgodność z przeglądarką 3.5. Zgodność zachowania interfejsu API 3.6. Przestrzenie nazw interfejsu API 3.7. Zgodność w czasie działania 3.8. Zgodność interfejsu użytkownika 3.8.1. Menu aplikacji (ekran główny) 3.8.2. Widżety 3.8.3. Powiadomienia 3.8.4. Szukaj 3.8.5. Toasty 3.8.6. Motywy 3.8.7. Animowane tapety 3.8.8. Przełączanie aktywności 3.8.9. Zarządzanie wejściami 3.8.10. Sterowanie multimediami z ekranu blokady 3.8.11. Dreams 3.8.12. Lokalizacja 3.8.13. Unicode i czcionki 3.9. Administracja urządzeniami 3.10. Ułatwienia dostępu 3.11. Zamiana tekstu na mowę 3.12. Platforma obsługi wejść TV 4. Zgodność z pakowaniem aplikacji 5. Zgodność multimedialna 5.1. Kodeki multimedialne 5.1.1. Kodeki audio 5.1.2. Kodek obrazu 5.1.3. Kodek wideo 5.2. Kodowanie wideo 5.3. Dekodowanie wideo 5.4. Nagranie dźwiękowe 5.4.1. Przechwytywanie nieprzetworzonego dźwięku 5.4.2. Uchwyć głos na potrzeby rozpoznawania mowy 5.4.3. Przechwytywanie w celu przekierowania odtwarzania 5.5. Odtwarzanie dźwięku 5.5.1. Odtwarzanie nieprzetworzonego dźwięku 5.5.2. Efekty dźwiękowe 5.5.3. Głośność wyjścia audio 5.6. Opóźnienie dźwięku 5.7. Protokoły sieciowe 5.8. Secure Media 6. Zgodność narzędzi dla programistów i Opcji programisty 6.1. Narzędzia dla programistów 6.2. Opcje programisty 7. Zgodność sprzętu 7.1. Wyświetlacz i grafika 7.1.1. Konfiguracja ekranu 7.1.1.1. Rozmiar ekranu 7.1.1.2. Format obrazu 7.1.1.3. Gęstość ekranu 7.1.2. Dane o wyświetleniach

7.1.3. Orientacja ekranu 7.1.4. akceleracja grafiki 2D i 3D, 7.1.5. Tryb zgodności ze starszymi wersjami aplikacji 7.1.6. Technologia ekranu 7.1.7. Wyświetlacze zewnętrzne 7.2. Urządzenia wejściowe 7.2.1. Klawiatura 7.2.2. Nawigacja bezdotykowa 7.2.3. Klawisze nawigacyjne 7.2.4. Dotykowe wprowadzanie danych 7.2.5. Symulowane dotykowe wprowadzanie danych 7.2.6. Obsługa kontrolera gier 7.2.6.1. Mapowania przycisków 7.2.7. Pilot 7.3. Czujniki 7.3.1. Akcelerometr 7.3.2. magnetometr, 7.3.3. GPS 7.3.4. żyroskop, 7.3.5. Barometr 7.3.6. Termometr 7.3.7. Fotometry 7.3.8. Czujnik zbliżeniowy 7.4. Łączność z danymi 7.4.1. Połączenia telefoniczne 7.4.2. IEEE 802.11 (Wi-Fi) 7.4.2.1. Wi-Fi Direct 7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi 7.4.3. Bluetooth 7.4.4. Komunikacja Near Field Communication 7.4.5. Minimalna obsługa sieci 7.4.6. Ustawienia synchronizacji 7.5. Kamery 7.5.1. Tylny aparat 7.5.2. Przedni aparat 7.5.3. Aparat zewnętrzny 7.5.4. Zachowanie interfejsu Camera API 7.5.5. Orientacja aparatu 7.6. Pamięć i miejsce na dane 7.6.1. Minimalna pamięć i miejsce na dane 7.6.2. Pamięć współdzielona aplikacji 7.7. USB 7.8. Dźwięk 7.8.1. Mikrofon 7.8.2. Wyjście audio 7.8.2.1. Gniazda analogowe 8. Zgodność z wydajnością 8.1. Spójność w interfejsie użytkownika 8.2. Wydajność pamięci 9. Zgodność modelu zabezpieczeń 9.1. Uprawnienia 9.2. UID i izolacja procesów 9.3. Uprawnienia dotyczące systemu plików 9.4. Alternatywne środowiska wykonawcze 9.5. Pomoc dla wielu użytkowników 9.6. Ostrzeżenie dotyczące SMS-ów specjalnych 9.7. Funkcje zabezpieczeń jądra 9.8. Prywatność 9.9. Szyfrowanie całego dysku 9.10. Weryfikacja podczas uruchamiania 10. Testowanie zgodności oprogramowania 10.1. Compatibility Test Suite 10.2. CTS Verifier 11. Oprogramowanie, które można aktualizować 12. Dokumentacja historii zmian 13. Skontaktuj się z nami 14. Materiały

1. Wprowadzenie

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

Użycie słów „MUST” (musi), „MUST NOT” (nie musi), „REQUIRED” (wymagane), „SHALL” (musi), „SHALL NOT” (nie musi), „SHOULD” (zalecane), „MAY” (możliwe) i „OPTIONAL” (opcjonalne) jest zgodne ze standardem IETF zdefiniowanym w dokumencie RFC2119 [Resources, 1].

W tym dokumencie „implementer urządzenia” lub „implementer” oznacza osobę lub organizację opracowującą rozwiązanie sprzętowe/programowe z Androidem 5.0. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 5.0, MUSI ona spełniać 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 kodzie źródłowym „upstream” 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. Implementator jest odpowiedzialny za zapewnienie pełnej zgodności behawioralnej ze standardową implementacją Androida, w tym w ramach pakietu testów zgodności. 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ść, takie jak bateria

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 przekątnej w zakresie od 1,1 do 2,5 cala
• NALEŻY zadeklarować funkcję android.hardware.type.watch
• MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH [Resources, 4]

Aby być zgodnym z Androidem 5.0, 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 dotyczą one 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	Nazwa	Sekcja	Przenośne	Telewizja	Oglądaj	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	SHOULD
Czujniki	Akcelerometr	7.3.1 Akcelerometr	SHOULD		SHOULD	SHOULD
	GPS	7.3.3. GPS	SHOULD
Łączność	Wi-Fi	7.4.2. IEEE 802.11	SHOULD	MUST		SHOULD
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	SHOULD	SHOULD		SHOULD
	Bluetooth	7.4.3. Bluetooth	SHOULD	MUST	MUST	SHOULD
	Bluetooth Low Energy	7.4.3. Bluetooth	SHOULD	MUST	SHOULD	SHOULD
	Tryb urządzenia peryferyjnego USB/ hosta	7.7. USB	SHOULD			SHOULD
Urządzenie wyjściowe	Głośniki lub gniazda wyjścia audio	7.8.2. Wyjście audio	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Ą zawierać kompletne implementacje, w tym wszystkie opisane zachowania, wszystkich udokumentowanych interfejsów API udostępnionych przez pakiet SDK Androida [Zasoby, 5] lub wszystkich interfejsów API oznaczonych znacznikiem „@SystemApi” w kodziku ź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 przeznaczony tylko na czas działania w postaci intencji, uprawnień i podobnych aspektów aplikacji na Androida, 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.0 to pole MUSI mieć wartość całkowitą 21.
VERSION.SDK_INT	Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 5.0 to pole MUSI mieć wartość całkowitą 21.
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 w 7-bitowym formacie 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ść w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie 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ść w tym polu MUSI być kodowalna jako 7-bitowy kod 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.0/LRWXX/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ć możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[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 na urządzeniach MUSZĄ uwzględniać system intencji o luźnym powiązaniu w Androidzie, jak opisano w sekcjach poniżej. „Spełnianie” oznacza, że implementator urządzenia MUSI udostępnić aktywność lub usługę na Androida, która określa pasujący filtr intencji, który wiąże się z właściwym działaniem i wdrożeniem dla każdego określonego wzorca intencji.

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 między innymi 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 dla „http://”. Implementacje na urządzeniach MUSZĄ zawierać interfejs użytkownika umożliwiający 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, „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.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Pełna implementacja interfejsu android.webkit.Webview MOGĄ być udostępniona na zegarkach z Androidem, ale MUSI być udostępniona na wszystkich innych typach urządzeń.

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 w wersji 5.0. 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)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

• Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.
• Wartość ciągu $(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ą

Urządzenia z Androidem TV i Watch mogą pomijać aplikację przeglądarki, ale MUSZĄ obsługiwać publiczne wzorce intencji opisane w sekcji 3.2.3.1. Wszystkie inne typy implementacji na urządzeniach MUSZĄ zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania Internetu przez użytkownika.

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]
• 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 górnym 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 przestrzeni nazw Androida, te interfejsy API MUSZĄ być zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich wyraźnie korzystają (za pomocą mechanizmu), były objęte zwiększonym zużyciem 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 w górę formatu wykonawczego 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 ilość pamięci aplikacji
małe / normalne	120 dpi (ldpi)	16 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	32 MB
	240 dpi (hdpi)
	320 dpi (xhdpi)	64 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)	16 MB
	160 dpi (mdpi)	32 MB
	213 dpi (tvdpi)	64 MB
	240 dpi (hdpi)
	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	160 dpi (mdpi)	64 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	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

Widżety są opcjonalne w przypadku wszystkich implementacji urządzeń z Androidem, ale powinny być obsługiwane na urządzeniach z Androidem.

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi „widżetu aplikacji” [Resources, 21]. Jest to funkcja, którą zdecydowanie zalecamy uwzględnić w implementacjach 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 implementacja MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) udostępnione w interfejsach API [Zasoby, 23] lub w przewodniku po stylu ikon w pasku stanu/systemowym [Zasoby, 24]. 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 elementami multimedialnymi – interaktywne widoki dla powiadomień ciągłych.
• Powiadomienia o zbliżającym się terminie – interaktywne widoki, w których użytkownicy mogą podejmować działania 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ń MUSZĄ prawidłowo wyświetlać i wykonywać te powiadomienia, w tym 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 dodawanie wyszukiwarki do aplikacji oraz udostępnianie danych aplikacji w wyszukiwarce globalnej. 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, aby wyświetlać użytkownikowi krótkie niemodalne ciągi znaków, które 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łym komponencie 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 zgodnie z definicją w pakiecie Android SDK [Zasoby, 28]. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom [Zasoby, 29].

Android 5.0 zawiera rodzinę motywów „Material” w postaci zestawu zdefiniowanych stylów, których deweloperzy aplikacji mogą używać, 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 odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej jednej „żywej tapety” [Zasoby, 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

Ponieważ funkcja Ostatnie jest opcjonalna, wymagania dotyczące implementacji ekranu Przegląd są opcjonalne w przypadku urządzeń Android TV i zegarka z Androidem.

Dostarczony przez Ciebie kod źródłowy Androida obejmuje ekran przeglądu [Zasoby, 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:

• MUST display affiliated recents as a group that moves together
• MUSI obsługiwać co najmniej 20 wyświetlanych aktywności
• POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz
• NALEŻY wyświetlać kolor zaznaczenia, ikonę i tytuł ekranu w ostatnich
• MUSI implementować zachowanie przypinania ekranu [Resources, 33] i udostępnić użytkownikowi menu ustawień, aby włączyć lub wyłączyć tę funkcję
• NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to, aż 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, MUSZĄ obsługiwać szablon powiadomienia multimedialnego wraz z innymi powiadomieniami.

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. Jeśli implementacje urządzeń z Androidem obejmują metodę wprowadzania, urządzenia MUSZĄ udostępniać użytkownikowi metodę wprowadzania dla znaków emotikonów zdefiniowanych w Unicode 6.1 [Resources, 38]. Wszystkie urządzenia MUSZĄ być w stanie renderować te emotikony w kolorze.

Android 5.0 obsługuje czcionkę Roboto 2 w różnych grubościach: bezszeryfowa cienka, bezszeryfowa lekka, bezszeryfowa średnia, bezszeryfowa czarna, bezszeryfowa ściśniona, bezszeryfowa ściśniona lekka. 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 czcionek łacińskich, greckich i cyrylicy, w tym zakresów łacińskich rozszerzonych A, B, C i D 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ądzeniu MUSZĄ zawierać implementację klasy DevicePolicyManager [Resources, 40]. Implementacje urządzeń, które obsługują ekran blokady, MUSZĄ obsługiwać pełny zakres zasad administracyjnych urządzeń zdefiniowanych w dokumentacji Android SDK [Resources, 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]. Implementacje na urządzeniach MUSZĄ zawierać implementację interfejsu dostępności Androida zgodną z domyślną implementacją Androida. Implementacje urządzeń MUSZĄ spełniać te wymagania:

• MUSI obsługiwać implementacje usług ułatwień dostępu innych firm za pomocą interfejsów API android.accessibilityservice [Zasoby, 43]
• MUSI generować zdarzenia AccessibilityEvents i przekazywać je do wszystkich zarejestrowanych implementacji AccessibilityService w sposób zgodny z domyślną implementacją Androida.
• W przypadku implementacji urządzeń z Androidem Watch bez wyjścia audio należy udostępnić użytkownikowi mechanizm włączania i wyłączania 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 na urządzeniu:

• 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 SDK do Androida [Zasoby, 47].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 48], 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 tabelach poniżej. 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	Koder	Dekodery	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 ze standardową 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 nieobsługiwany) • MPEG-TS (.ts, nie można przeskakiwać, 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 i 5.1 z standardową częstotliwością próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2 Profil (ulepszone AAC+)		WYMAGANE	Obsługa treści mono/stereo/5.0/5.1 z standardową częstotliwością 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	REQUIRED3	REQUIRED3	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
AMR-WB	REQUIRED3	REQUIRED3	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	REQUIRED4 (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	Koder	Dekodery	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	Koder	Dekodery	Szczegóły	Obsługiwane typy plików i formaty kontenerów
H.263	WYMAGANE1	REQUIRED2		• 3GPP (.3gp) • MPEG-4 (.mp4)
H.264 AVC	REQUIRED2	REQUIRED2	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, tylko dźwięk AAC, brak możliwości przeskakiwania, Android 3.0 lub nowszy)
H.265 HEVC		REQUIRED2	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (.mp4)
MPEG-4 SP		REQUIRED2		3GPP (.3gp)
VP83	REQUIRED2 (Android 4.3 lub nowszy)	REQUIRED2 (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		REQUIRED2 (Android 4.4 lub nowszy)	Szczegółowe informacje znajdziesz w sekcji 53.	• 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.2. Kodowanie wideo

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

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ść filmu	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 bitów 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ść filmu	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 bitów 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

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

Implementacje urządzeń MUSZĄ obsługiwać dynamiczne przełączanie rozdzielczości wideo w tym samym strumieniu w przypadku kodeków VP8, VP9, H.264 i H.265.

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ść filmu	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 bitów 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ść filmu	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 bitów 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ść filmu	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 bitów 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 następujące profile dekodowania wideo SD. Powinny też obsługiwać profile dekodowania HD. Urządzenia z Androidem: telewizory MUSZĄ obsługiwać profil Main Profile Level 4.1 Main tier i profil dekodowania HD 1080p. POWINNY obsługiwać profil Main10 Level 5 Main Tier i profil dekodowania UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 1	UHD 2
Rozdzielczość filmu	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 bitów 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 Wymagany w implementacjach urządzeń z Androidem TV, jeśli jest obsługiwany 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”. Zalecamy, aby i nowe, i stare urządzenia z Androidem spełniały te wymagania, ponieważ w przeciwnym razie nie będą kompatybilne z Androidem po uaktualnieniu 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 opisów efektów wyciszania szumów MUSI jednoznacznie identyfikować każdą implementację technologii wyciszania szumów.

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 typu 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
• POWINNA 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 – przedział czasu między zapisaniem przez aplikację ramki danych w formacie PCM a chwilą, gdy odpowiedni dźwięk może być słyszalny dla zewnętrznego odbiorcy lub zarejestrowany przez przetwornik.
• Czas oczekiwania na wyjście „na zimno” – czas oczekiwania na wyjście w przypadku pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
• Ciągła latencja wyjściowa – latencja wyjściowa kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie wejścia – przedział czasu między momentem, w którym zewnętrzny dźwięk jest prezentowany na urządzeniu, a momentem, w którym aplikacja odczytuje odpowiednią ramkę danych zakodowanych w formacie PCM.
• Opóźnienie w przypadku zimnego wejścia – suma utraconego czasu wejścia i opóźnienia wejścia dla pierwszego obrazu, gdy system wejścia audio był nieaktywny i wyłączony przed żądaniem.
• Ciągła latencja wejścia – latencja wejścia kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
• Jitter wyjścia zimnego – odchylenie między poszczególnymi pomiarami wartości opóźnienia wyjścia zimnego.
• Jitter danych wejściowych „na zimno” – odchylenie między poszczególnymi pomiarami wartości opóźnienia danych wejściowych „na zimno”.
• Ciągły czas oczekiwania na odpowiedź – suma ciągłego opóźnienia na wejściu i ciągłego opóźnienia na wyjściu oraz 5 milisekund.
• OpenSL ES PCM buffer queue API – zestaw interfejsów API 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 komponentu MUSZĄ być jednak nadal dostępne.
• Działania interfejsu API MUSZĄ być zaimplementowane w sposób, który nie wymaga żadnych działań.
• 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:

• Przekątna fizyczna – odległość w calach między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• Punkty na cal (dpi) – liczba pikseli na odcinku poziomym lub pionowym o długości 1 cala. W przypadku podanych wartości dpi zarówno dpi poziome, jak i pionowe muszą mieścić się w zakresie.
• Współczynnik proporcji – stosunek dłuższego wymiaru ekranu do krótszego. Na przykład wyświetlacz 480 x 854 pikseli to 854 / 480 = 1, 779, czyli w przybliżeniu „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

Urządzenia z Androidem Watch (szczegóły w sekcji 2) MOGĄ mieć mniejsze ekrany, jak opisano w tej sekcji.

Interfejs użytkownika Androida obsługuje różne rozmiary ekranu i pozwala aplikacjom uzyskiwać informacje o rozmiarze ekranu urządzenia (tzw. „rozkł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 rozmiarach co najmniej 426 x 320 dp (małe), chyba że jest to urządzenie z systemem Android Watch.
• Urządzenia, które podają 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 x 720 dp.

Dodatkowo

• Urządzenia z Androidem Watch MUSZĄ mieć ekran o fizycznej przekątnej w zakresie 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 opcjonalnie wskazują, które rozmiary ekranu obsługują, za pomocą atrybutu w pliku AndroidManifest.xml. Implementacje na urządzeniach MUSZĄ poprawnie obsługiwać deklarowane przez aplikacje wsparcie małych, normalnych, dużych i bardzo dużych ekranów, zgodnie z dokumentacją pakietu SDK Androida.

7.1.1.2. Format obrazu

Urządzenia z Androidem Watch mogą mieć format obrazu 1,0 (1:1).

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)
• 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Ą raportować 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 reżimie „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. Implementacje na urządzeniu MUSZĄ zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez kod źródłowy open source Androida. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać czynników ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać zachowania 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 zewnętrzne

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

7.2.1. Klawiatura

Urządzenia z Androidem Watch mogą, ale inne typy urządzeń muszą implementować klawiaturę wirtualną.

Implementacje na urządzeniu:

• MUSI zawierać obsługę ramki zarządzania danymi wejściowymi (która umożliwia zewnętrznym deweloperom tworzenie edytorów metod wprowadzania, np.wirtualnych klawiatur), zgodnie z informacjami 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 uniemożliwia korzystanie z klawiatury ekranowej.
• MOŻE zawierać dodatkowe implementacje klawiatury ekranowej
• MOŻE zawierać klawiaturę sprzętową
• NIE MOŻE zawierać 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

Urządzenia z Androidem TV MUSZĄ obsługiwać D-pad.

Implementacje na urządzeniu:

• MOŻNA pominąć opcję nawigacji bezdotykowej (kulka, pad kierunkowy lub koło), jeśli implementacja urządzenia 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

Wymagania dotyczące dostępności i widoczności funkcji Home, Ostatnie i Wstecz różnią się w zależności od typu urządzenia, jak opisano w tej sekcji.

Funkcje Home, Recents i Back (odpowiednio mapowane 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.
• 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 urządzenia z Androidem 5.0 NIE MOGĄ mieć dedykowanego przycisku fizycznego 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 z aktualizacją do Androida 5.0, zalecamy to rozwiązanie.
• NIE wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po wybraniu przycisku menu na pasku czynności.
• MOŻE wyświetlić wyskakujące menu czynności w zmienionej 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 <= 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 „low profile” (np. przyciemnionym), 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

Urządzenia mobilne i zegarki z Androidem MUSZĄ obsługiwać ekran dotykowy.

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:

• POWINIEN obsługiwać wskaźniki śledzone w pełni 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 5.0 zawiera stałą nazwę android.hardware.faketouch, która odpowiada urządzeniu wejściowemu nieopartyemu na dotyku (z wskaźnikiem), takiemu jak mysz lub panel dotykowy, które może odpowiednio emulować wejście dotykowe (w tym obsługę podstawowych gestów). Wskazuje to, ż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:

• MUST report the absolute X and Y screen positions of the pointer location and display a visual pointer on the screen [Resources, 71]
• MUST report touch event with the action code that specifies the state that occurs on the pointer going down or up on the screen [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ć ruchy kursora w dół, w górę, w dół i 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 następnie umożliwiać użytkownikom szybkie przesuwanie obiektu w inne miejsce na ekranie, a następnie 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:

Button	Użycie HID2	Przycisk Androida
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)
Przycisk w górę na padzie kierunkowym1 przycisk w dół na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_Y4
przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_X4
Przycisk z lewej strony1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk z lewej strony1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewym drążkiem1	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]

Analogowe elementy sterujące1	Użycie HID	Przycisk Androida
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.

• Funkcja 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 pada kierunkowego [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() i podobnych metod
• MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, 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 za pomocą odpowiednich wartości Międzynarodowego Systemu Jednostek (SI) dla każdego typu czujnika zgodnie z dokumentacją pakietu SDK Androida [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ły”, 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ć i zgłaszać czujnik TYPE_ACCELEROMETER [Resources, 78]
• MUSI być w stanie raportować zdarzenia z częstotliwością co najmniej 100 Hz i POWINIEN 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 być w stanie mierzyć 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 kompensować i zachowywać parametry kompensacji między ponownymi uruchamianiami urządzenia.
• POWINNA być kompensowana 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 okresie co najmniej 3 sekund przy najszybszej 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 uwzględniono również czujnik żyroskopowy i magnetometr

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 być w stanie mierzyć wartości 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 wynosić co najmniej 0,6 μT, a najlepiej 0,2 μT
• POWINNA być kompensowana 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 uwzględniono również czujnik przyspieszeniomierza i czujnik żyroskopu
• 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 zawiera 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 umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę
• MUSI być w stanie raportować zdarzenia z częstotliwością co najmniej 100 Hz i POWINIEN 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ć dokładność co najmniej 1 bita

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

„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 „telefonii” w Androidzie odnoszą się konkretnie 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ń z Androidem TV MUSZĄ obsługiwać 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:

• Musisz podać flagę funkcji sprzętowej android.hardware.wifi.
• NALEŻY zaimplementować interfejs API multicast zgodnie z opisem w dokumentacji pakietu SDK [Resources, 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 w stanie aktywnym.

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 działanie 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Ą obsługiwać skonfigurowanie bezpośredniego połączenia przez tunel (TDLS).

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
• SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point

7.4.3. Bluetooth

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać Bluetooth i Bluetooth LE, a implementacje urządzeń z Androidem Watch MUSZĄ obsługiwać 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 Bluetooth API oparte na GATT (profil ogólny atrybutów) zgodnie z opisem w dokumentacji pakietu SDK i [Zasoby, 82]
• NALEŻY obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas implementowania interfejsu API ScanFilter [Resources, 83] i MUSI zgłaszać prawidłową wartość miejsca implementacji logiki filtrowania, gdy jest to zapytanie 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().
• POWINNA obsługiwać reklamy wielokrotne z co najmniej 4 boksami reklamowymi, ale jeśli nie obsługuje, MUSI zwracać wartość „false” w przypadku zapytania za pomocą metody android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

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:

• MUSI zgłaszać 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 istniejące 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 P2P NDEF 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 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 rekordów żądania przekazania/wyboru za pomocą NFC. Wdrożenie MUSI używać profilu Bluetooth Object Push do rzeczywistego 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.
  • POWINIEN być w trybie 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 5.0 obsługuje tryb hosta karty NFC (HCE). Jeśli implementacja urządzenia zawiera kontroler NFC obsługujący 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 Android SDK [Resources, 10]

Implementacje urządzeń mogą też obejmować obsługę czytników/nagrywarek dla tych technologii MIFARE:

• MIFARE Classic
• MIFARE Ultralight
• NDEF na kartach MIFARE Classic

Pamiętaj, że Android zawiera interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia obsługuje MIFARE w roli czytnika/nagrywarki, to:

• Musisz zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• NALEŻY zgłosić funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature() ([Resources, 53]). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie jest ona widoczna jako stała w klasie PackageManager.
• NIE WOLNO implementować odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że implementuje ona też ogólne obsługi NFC zgodnie z opisem w tej sekcji.

Jeśli implementacja urządzenia nie obejmuje sprzętu NFC, NIE MOŻE ona deklarować funkcji android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature() [Resources, 53]i MUSI zaimplementować interfejs NFC API Androida jako no-op.

Klasy android.nfc.NdefMessage i android.nfc.NdefRecord reprezentują format reprezentacji danych niezależny od protokołu, dlatego implementacje na urządzeniach MUSZĄ implementować te interfejsy API, nawet jeśli nie obsługują NFC ani nie deklarują funkcji android.hardware.nfc.

7.4.5. Minimalna funkcjonalność sieci

Implementacje urządzeń MUSZĄ obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o szybkości 200 kbps lub wyższej. Przykłady technologii spełniających to wymaganie to EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN itp.

Implementacje urządzeń, w których podstawowym połączeniem danych jest standard sieci fizycznej (np. Ethernet), POWINNY obejmować obsługę co najmniej jednego popularnego bezprzewodowego standardu danych, np. 802.11 (Wi-Fi).

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

7.4.6. Ustawienia synchronizacji

W implementacjach urządzeń ustawienie głównej autosynchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała wartość „true” [Resources, 89].

7.5. Aparaty

Urządzenia powinny mieć tylny aparat, a opcjonalnie także przedni. Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz. Oznacza to, że rejestruje obrazy z dalszej strony urządzenia, tak jak tradycyjny aparat. Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz, czyli taka, która jest zwykle używana do robienia zdjęć użytkownikowi, na przykład podczas wideokonferencji i podobnych aplikacji.

Jeśli implementacja urządzenia zawiera co najmniej 1 kamerę, aplikacja powinna mieć możliwość jednoczesnego przydzielenia 3 map bitowych o rozmiarze odpowiadającym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu.

7.5.1. Tylny aparat

Implementacje urządzeń powinny zawierać tylny aparat. Jeśli implementacja urządzenia zawiera co najmniej 1 aparat skierowany do tyłu:

• NALEŻY podać flagę funkcji android.hardware.camera i android.hardware.camera.any.
• Rozdzielczość musi wynosić co najmniej 2 megapiksele
• W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) NALEŻY zaimplementować sprzętowy lub programowy autofokus.
• MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
• MOŻE zawierać błysk. Jeśli aparat ma lampę błyskową, to lampa ta NIE MOŻE być włączona, gdy na podglądzie aparatu zarejestrowano instancję android.hardware.Camera.PreviewCallback, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu w urządzeniu, ale tylko aplikacji innych firm, które korzystają z Camera.PreviewCallback.

7.5.2. Przedni aparat

Implementacje urządzeń MOGĄ zawierać przedni aparat. Jeśli implementacja urządzenia zawiera co najmniej 1 przedni aparat:

• MUSI zawierać flagę funkcji android.hardware.camera.any i android.hardware.camera.front
• Rozdzielczość musi wynosić co najmniej VGA (640 x 480 pikseli)
• Domyślnie w interfejsie Camera API NIE MOŻNA używać przedniego aparatu. Interfejs API aparatu w Androidzie obsługuje w szczególny sposób przednie aparaty. Implementacje na urządzeniu NIE MOGĄ konfigurować interfejsu API tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.
• MOŻE zawierać funkcje (takie jak autofokus czy lampa błyskowa) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1
• MUSI odzwierciedlać poziomo strumień wyświetlany przez aplikację w ramach CameraPreview:
  • Jeśli implementacja urządzenia umożliwia użytkownikowi obracanie urządzenia (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika), podgląd aparatu MUSI być odwrócony poziomo względem bieżącej orientacji urządzenia.
  • Jeśli bieżąca aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation()[Resources, 90], podgląd aparatu MUSI być odbiciem lustrzanym w orientacji poziomej w stosunku do orientacji określonej przez aplikację.
  • W przeciwnym razie podgląd MUSI być odbiciem lustrzanym wzdłuż domyślnej poziomej osi urządzenia.
• obraz wyświetlany przez postview MUSI być lustrzany w taki sam sposób jak strumień obrazu podglądu kamery; Jeśli implementacja na urządzeniu nie obsługuje funkcji postview, ten wymóg oczywiście nie ma zastosowania.
• Nie wolno stosować odbicia lustrzanego w przypadku końcowego obrazu stałego lub strumieni wideo zwracanych do aplikacji w ramach wywołań zwrotnych lub zapisywanych w magazynie multimediów.

7.5.3. Kamera zewnętrzna

Implementacje urządzeń z trybem hosta USB MOGĄ obsługiwać zewnętrzną kamerę podłączaną do portu USB. Jeśli urządzenie obsługuje kamerę zewnętrzną, to:

• NALEŻY zadeklarować funkcję platformy android.hardware.camera.external i android.hardware camera.any
• MUSI obsługiwać USB Video Class (UVC 1.0 lub nowsza)
• MOŻE obsługiwać wiele kamer

Obsługa kompresji wideo (np.MJPEG) jest ZALECANA, aby umożliwić przesyłanie nieskompresowanych strumieni o wysokiej jakości (tj. strumieni danych nieprzetworzonych lub niezależnie skompresowanych). Kodowanie filmów za pomocą kamery MOŻE być obsługiwane. W takim przypadku na urządzeniu MUSI być dostępny jednoczesny strumień niekodowany/ MJPEG (w rozdzielczości QVGA lub wyższej).

7.5.4. Zachowanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API umożliwiające dostęp do aparatu. Nowszy interfejs android.hardware.camera2 udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania i sterowanie poszczególnymi klatkami w zakresie ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania i nie tylko.

Starszy pakiet interfejsu API android.hardware.Camera został oznaczony jako przestarzały w Androidzie 5.0, ale powinien być nadal dostępny dla aplikacji korzystających z implementacji na urządzeniach z Androidem. W takim przypadku należy zadbać o dalsze obsługiwanie tego interfejsu API zgodnie z opisem w tej sekcji i w pakiecie SDK Androida.

Implementacje urządzeń MUSZĄ realizować te zachowania w przypadku interfejsów API związanych z aparatami w przypadku wszystkich dostępnych aparatów:

• Jeśli aplikacja nigdy nie wywołała metody android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
• Jeśli aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback i system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w tablicy byte[] przekazane do onPreviewFrame() muszą być w dalszym ciągu w formacie kodowania NV21. Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
• W przypadku interfejsu android.hardware.Camera implementacje urządzeń MUSZĄ obsługiwać format YV12 (oznaczony za pomocą stałej android.graphics.ImageFormat.YV12) w przypadku podglądów aparatu zarówno przedniego, jak i tylnego. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do YV12).
• W przypadku interfejsu android.hardware.camera2 implementacje na urządzeniu muszą obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe w interfejsie API android.media.ImageReader.

Implementacje urządzeń MUSZĄ nadal wdrażać pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida [Zasoby, 91], niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty, które nie mają autofokusa, MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (chociaż nie ma to zastosowania do aparatów bez autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Na przykład mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „udawane” w sposób opisany powyżej.

Implementacje urządzeń MUSZĄ rozpoznawać i przetwarzać nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters, jeśli sprzęt obsługuje tę funkcję. Jeśli sprzęt urządzenia nie obsługuje danej funkcji, interfejs API musi działać zgodnie z opisem. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters(), które nie są opisane jako stałe w interfejsie android.hardware.Camera.Parameters. Oznacza to, że implementacje na urządzeniu MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują techniki obrazowania z efektem HDR (High Dynamic Range), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR [Resources, 92].

Nie wszystkie implementacje urządzeń mogą w pełni obsługiwać wszystkie funkcje interfejsu android.hardware.camera2 API, dlatego implementacje urządzeń MUSZĄ zgłaszać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w Android SDK [Resources, 93] i zgłaszać odpowiednie flagi funkcji frameworka [Resources, 94].

Implementacje urządzeń MUSZĄ również zadeklarować indywidualne funkcje kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji [Zasoby, 94]. Urządzenie musi zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych kamer obsługuje tę funkcję.

Implementacje na urządzeniu MUSZĄ nadawać intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów.

Implementacje na urządzeniu MUSZĄ nadawać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy aparat nagra nowy film, a element obrazu zostanie dodany do magazynu multimediów.

7.5.5. Orientacja aparatu

Przedni i tylny aparat (jeśli są dostępne) MUSZĄ być ustawione tak, aby dłuższy wymiar aparatu był zgodny z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ rejestrować obraz w orientacji poziomej. Ma to zastosowanie niezależnie od naturalnego ułożenia urządzenia, czyli dotyczy zarówno urządzeń z głównym trybem poziomym, jak i z głównym trybem pionowym.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Urządzenia z Androidem TV muszą mieć co najmniej 5 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji.

Pamięć dostępna dla jądra i przestrzeni użytkownika w implementacjach na urządzeniu MUSI być co najmniej równa wartościom minimalnym określonym w tabeli poniżej lub większa od nich. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

Gęstość i rozmiar ekranu	Urządzenie 32-bitowe	Urządzenie 64-bitowe
urządzenia z Androidem Watch (ze względu na mniejsze ekrany);	416 MB	Nie dotyczy
xhdpi lub mniejsze na małych/normalnych ekranach hdpi lub niższą na dużych ekranach. mdpi lub niższą na bardzo dużych ekranach.	512 MB	832 MB
400 dpi lub więcej na małych/normalnych ekranach xhdpi lub wyższa na dużych ekranach tvdpi lub wyższa na bardzo dużych ekranach.	896 MB	1280 MB
560 dpi lub więcej na małych/normalnych ekranach 400 dpi lub więcej na dużych ekranach. xhdpi lub wyższa na bardzo dużych ekranach.	1344 MB	1824 MB

Wartości minimalnej pamięci MUSZĄ być dodatkiem do pamięci już przeznaczonej na komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro.

Urządzenia z Androidem TV muszą mieć co najmniej 5 GB, a inne implementacje urządzeń muszą mieć co najmniej 1,5 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji. Oznacza to, że partycja /data musi mieć co najmniej 5 GB w przypadku urządzeń z Androidem TV i co najmniej 1,5 GB w przypadku innych implementacji urządzeń. Urządzenia z Androidem bardzo mocno zachęcamy do zapewnienia co najmniej 3 GB pamięci nieulotnej na prywatne dane aplikacji, aby umożliwić im przejście na przyszłe wersje platformy.

Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych [Zasoby, 95]. Implementacja menedżera pobierania na urządzeniu MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje urządzeń MUSZĄ oferować współdzielone miejsce na dane dla aplikacji, które często określane jest jako „współdzielone miejsce na dane zewnętrzne”.

Implementacje urządzeń MUSZĄ być skonfigurowane z zainstalowanym domyślnie, „w standardzie” miejscem na dane współdzielone. Jeśli współdzielona pamięć nie jest zamontowana w systemie Linux na ścieżce /sdcard, urządzenie MUSI zawierać link symboliczny z katalogu /sdcard do rzeczywistego punktu zamontowania.

Urządzenia mogą mieć sprzęt umożliwiający użytkownikom dostęp do wymiennych nośników danych, na przykład gniazda kart SD. Jeśli ten slot jest używany do spełnienia wymagań dotyczących wspólnej pamięci, implementacja urządzenia:

• NALEŻY wdrożyć toast lub wyskakujące okienko w interfejsie, aby ostrzec użytkownika, gdy nie ma karty SD.
• MUSI zawierać kartę SD w formacie FAT o pojemności co najmniej 1 GB LUB na opakowaniu i innych materiałach dostępnych w momencie zakupu musi być widoczne, że karta SD musi być kupiona osobno.
• MUSI obsługiwać karty SD domyślnie.

Implementacje na urządzeniach MOGĄ przydzielić pamięć wewnętrzną (nieusuwalną) jako pamięć współdzielona dla aplikacji zawartych w górnym projekcie Android Open Source. Implementacje na urządzeniach POWINNY korzystać z tej konfiguracji i implementacji oprogramowania. Jeśli implementacja urządzenia korzysta z pamięci wewnętrznej (nieusuwalnej) w celu spełnienia wymagań dotyczących współdzielonej pamięci, musi ona mieć co najmniej 1 GB i być zamontowana w katalogu /sdcard (lub /sdcard MUSI być symboliczną lokalizacją fizycznej lokalizacji, jeśli jest zamontowana gdzie indziej).

Implementacje urządzeń MUSZĄ egzekwować uprawnienie android.permission.WRITE_EXTERNAL_STORAGE zgodnie z dokumentacją w przypadku tej pamięci współdzielonej. W przeciwnym razie udostępnione miejsce na dane MUSI być dostępne do zapisu dla każdej aplikacji, która uzyskała tę zgodę.

Implementacje urządzeń, które zawierają wiele ścieżek do pamięci współdzielonej (np. gniazdo karty SD i pamięć wewnętrzna współdzielona) MUSZĄ zezwalać tylko wstępnie zainstalowanym i uprzywilejowanym aplikacjom na Androidzie z uprawnieniem WRITE_EXTERNAL_STORAGE na zapisywanie w drugiej pamięci zewnętrznej (z wyjątkiem katalogów konkretnych pakietów na tej pamięci), ale POWINNY udostępniać treści z obu ścieżek pamięci w przezroczysty sposób za pomocą usługi skanowania multimediów na Androidzie i android.provider.MediaStore.

Niezależnie od formy używanej pamięci współdzielonej implementacje urządzeń MUSZĄ udostępniać mechanizm umożliwiający dostęp do zawartości tej pamięci z komputera hosta, np. za pomocą pamięci masowej USB (UMS) lub protokołu MTP. Implementacje urządzeń MOGĄ używać pamięci masowej USB, ale POWINNY używać protokołu Media Transfer Protocol. Jeśli implementacja na urządzeniu obsługuje protokół Media Transfer Protocol, to:

• POWINIEN być zgodny z hostem MTP na Androidzie, czyli z Android File Transfer. [Resources, 96]
• NALEŻY podać klasę urządzenia USB 0x00
• SHOULD report a USB interface name of 'MTP'

Jeśli implementacja urządzenia nie zawiera portów USB, MUSI ona zapewniać komputerowi hosta dostęp do zawartości współdzielonego magazynu za pomocą innych środków, takich jak system plików sieciowych.

7.7. USB

Implementacje urządzeń powinny obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.

Jeśli implementacja urządzenia zawiera port USB obsługujący tryb peryferyjny:

• Port MUSI umożliwiać podłączenie do hosta USB z portem USB typu A lub C.
• Port powinien być w formacie micro-B, micro-AB lub USB typu C. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, aby można było uaktualnić je do kolejnych wersji platformy.
• Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obrócenie ekranu w ramach oprogramowania we wszystkich aplikacjach (w tym na ekranie głównym), aby wyświetlacz był prawidłowo wyświetlany, gdy urządzenie jest ustawione w taki sposób, że port znajduje się na dole. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK. Jeśli urządzenie jest urządzeniem przenośnym z Androidem, MUSI zaimplementować interfejs AOA API. Implementacje urządzeń zgodne ze specyfikacją AOA:
  • MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory [Resources, 97]
  • NALEŻY zaimplementować klasę audio USB zgodnie z dokumentacją pakietu SDK Androida [Zasoby, 98]
• NALEŻY wdrożyć obsługę poboru prądu 1, 5 A podczas transmisji i trafikowania sygnału HS zgodnie z specyfikacją ładowania akumulatora USB w wersji 1.2 [Resources, 99]. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• Wartość iSerialNumber w standardowym opisie urządzenia USB MUSI być równa wartości android.os.Build.SERIAL.

Jeśli implementacja urządzenia zawiera port USB obsługujący tryb hosta, to:

• NALEŻY używać portu USB typu C, jeśli implementacja urządzenia obsługuje USB 3.1
• MOŻE używać niestandardowego formatu portu, ale w takim przypadku MUSI być dostarczany z kablem lub kablami umożliwiającymi dostosowanie portu do standardowego portu USB typu A lub C.
• MOŻE używać portu micro-AB USB, ale w takim przypadku MUSI być dostarczany z kablem lub kablami dopasowującymi port do standardowego portu USB typu A lub C.
• Zaleca się zaimplementowanie klasy audio USB zgodnie z dokumentacją pakietu Android SDK [Zasoby, 98].
• MUSI implementować interfejs API hosta USB Androida zgodnie z dokumentacją do pakietu Android SDK i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host [Resources, 100]
• Powinien obsługiwać port ładowania w dół strumienia o zakresie prądu 1,5 A – 5 A, jak określono w specyfikacji ładowania baterii USB w wersji 1.2 [Zasoby, 99].

7.8. Audio

7.8.1. mikrofon

Urządzenia mobilne i zegarki z Androidem MUSZĄ mieć mikrofon.

Implementacje na urządzeniu MOGĄ pomijać mikrofon. Jeśli jednak implementacja urządzenia pomija mikrofon, NIE MOŻE raportować stałej funkcji android.hardware.microphone i MUSI zaimplementować interfejs API do nagrywania dźwięku co najmniej jako no-ops zgodnie z sekcją 7. Natomiast w przypadku implementacji urządzeń z mikrofonem:

• NALEŻY podać stałą funkcję android.hardware.microphone
• MUSI spełniać wymagania dotyczące nagrywania dźwięku podane w sekcji 5.4
• MUSI spełniać wymagania dotyczące czasu oczekiwania na dźwięk podane w sekcji 5.6

7.8.2. Wyjście audio

Urządzenia z Androidem Watch MOGĄ mieć wyjście audio.

Implementacje urządzeń z głośnikiem lub z wyjściami audio/multimedialnymi do urządzeń peryferyjnych z wyjściami audio, takich jak słuchawki lub głośniki zewnętrzne:

• Musisz podać stałą funkcję android.hardware.audio.output.
• MUSI spełniać wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5
• MUSI spełniać wymagania dotyczące czasu oczekiwania na dźwięk podane w sekcji 5.6

Jeśli implementacja urządzenia nie obejmuje głośnika ani portu wyjściowego audio, NIE MOŻE ona zgłaszać funkcji android.hardware.audio. Musisz też zaimplementować interfejsy API związane z wyjściem audio jako no-ops.

Implementacja urządzenia Android Watch MOŻE, ALE NIE MUSI mieć wyjścia audio, ale inne typy implementacji urządzeń z Androidem MUSZĄ mieć wyjście audio i deklarować android.hardware.audio.output.

7.8.2.1. Gniazda analogowe

Aby zapewnić zgodność z zespołami słuchawkowymi i innymi akcesoriami audio z wtykiem audio 3,5 mm w ekosystemie Androida [Resources, 101], jeśli implementacja urządzenia zawiera co najmniej 1 port analogowy, co najmniej 1 z tych portów powinien być 4-żyłowym gniazdem słuchawek 3,5 mm. Jeśli urządzenie ma 4-żyłowe złącze jack 3, 5 mm:

• MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem oraz POWINIEN obsługiwać nagrywanie dźwięku w takich słuchawkach i zestawach.
• MUSI obsługiwać wtyczki audio TRRS z kolejnością styków CTIA i POWINIEN obsługiwać wtyczki audio z kolejnością styków OMTP
• W przypadku implementacji urządzenia obsługującej mikrofon, MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio i przesyłać android.intent.action.HEADSET_PLUG z wartością dodatkową mikrofonu ustawioną jako 1.
• NALEŻY obsługiwać wykrywanie i mapowanie na kody klawiszy dla tych 3 zakresów impedancji równoważnej między mikrofonem a przewodami masy w wtyczce audio:
  • 70 Ohm lub mniej: KEYCODE_HEADSETHOOK
  • 210–290 Ohm: KEYCODE_VOLUME_UP
  • 360–680 Ohm: KEYCODE_VOLUME_DOWN
• NALEŻY obsługiwać wykrywanie i mapowanie na kod klawisza w przypadku następującego zakresu impedancji równoważnej między przewodami mikrofonu i uziemienia w gniazdku audio:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• Musi wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po tym, jak wszystkie styki wtyczki dotkną odpowiednich segmentów gniazda.
• MUSI być w stanie wygenerować co najmniej 150 mV +/- 10% napięcia wyjściowego przy impedancji głośnika 32 Ohm
• Napięcie polaryzacji mikrofonu MUSI mieścić się w zakresie 1,8–2,9 V.

8. Zgodność z kampaniami Performance Max

Niektóre minimalne kryteria wydajności są kluczowe dla wrażeń użytkowników i mają wpływ na założenia, które programiści powinni przyjąć podczas tworzenia aplikacji. Urządzenia z Androidem Watch powinny spełniać te kryteria:

8.1. Spójność w interfejsie użytkownika

Implementacje urządzeń MUSZĄ zapewniać płynny interfejs użytkownika przez zapewnienie spójnej liczby klatek i czasu odpowiedzi w przypadku aplikacji i gier. Implementacje na urządzeniu MUSZĄ spełniać te wymagania:

• Stałe opóźnienie klatekNiespójne opóźnienie klatek lub opóźnienie w renderowaniu klatek NIE POWINNY występować częściej niż 5 razy na sekundę, a ich liczba POWINNA być mniejsza niż 1 na sekundę.
• Opóźnienie interfejsu użytkownika: implementacje na urządzeniu MUSZĄ zapewniać użytkownikom niskie opóźnienie podczas przewijania listy zawierającej 10 tys. pozycji, zgodnie z definicją w pakiecie testów zgodności (CTS) dla Androida, w mniej niż 36 sekund.
• Przełączanie zadań – po uruchomieniu wielu aplikacji ponowne uruchomienie już uruchomionej aplikacji MUSI zająć mniej niż 1 sekundę.

8.2. Wydajność dostępu do plikowego wejścia/wyjścia

Implementacje urządzeń MUSZĄ zapewniać spójność wydajności dostępu do plików w przypadku operacji odczytu i zapisu.

• Zapis sekwencyjny: implementacje urządzeń MUSZĄ zapewniać wydajność zapisu sekwencyjnego na poziomie 5 MB/s dla pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Losowy zapis: implementacje urządzeń MUSZĄ zapewniać wydajność losowego zapisu na poziomie 0,5 MB/s dla pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 4 KB.
• Odczyt sekwencyjny: implementacje na urządzeniu MUSZĄ zapewniać wydajność odczytu sekwencyjnego na poziomie 15 MB/s w przypadku pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 10 MB.
• Losowy odczyt: implementacje na urządzeniu MUSZĄ zapewniać wydajność losowego odczytu na poziomie 3,5 MB/s dla pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 4 KB.

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniu MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji na temat zabezpieczeń i uprawnień w interfejsach API [Zasoby, 102] w dokumentacji dla deweloperów Androida. Implementacje urządzeń MUSZĄ obsługiwać instalację samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich lub organów. W szczególności zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następujących podrozdziałach.

9.1. Uprawnienia

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień Androida zgodnie z definicją w dokumentacji dla deweloperów Androida [Zasoby, 102]. W szczególności implementacje MUSZĄ egzekwować każde uprawnienie zdefiniowane w dokumentacji pakietu SDK; żadne uprawnienia nie mogą być pomijane, zmieniane ani ignorowane. Implementacje MOGĄ dodawać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.*.

9.2. UID i izolacja procesów

Implementacje urządzeń MUSZĄ obsługiwać model piaskownicy aplikacji Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie. Implementacje urządzeń MUSZĄ obsługiwać uruchamianie wielu aplikacji jako tego samego identyfikatora użytkownika Linuksa, pod warunkiem, że aplikacje są odpowiednio podpisane i skonstruowane zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień [Zasoby, 102].

9.3. Uprawnienia do systemu plików

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień [Zasoby, 102].

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach mogą obejmować środowiska wykonawcze, które wykonują aplikacje za pomocą innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Jednak takie alternatywne środowiska wykonawcze NIE MOGĄ naruszać modelu zabezpieczeń Androida ani zabezpieczeń zainstalowanych aplikacji na Androida, jak opisano w tej sekcji.

Alternatywny czas wykonywania MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, zgodnie z opisem w sekcji 9.

Innym środowiskom uruchomieniowym NIE wolno przyznawać dostępu do zasobów chronionych przez uprawnienia, o które nie zostało poproszone w pliku AndroidManifest.xml środowiska uruchomieniowego za pomocą mechanizmu.

Alternatywny czas działania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida ograniczone do aplikacji systemowych.

Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida. Dotyczy to zwłaszcza alternatywnych środowisk wykonawczych:

• NALEŻY instalować aplikacje za pomocą menedżera pakietów w oddzielnych piaskownicach Androida (identyfikatory użytkowników Linuksa itp.).
• MOŻE udostępniać jedną piaskownicę Androida wszystkim aplikacjom korzystającym z alternatywnego środowiska wykonawczego.
• i zainstalowanych aplikacji korzystających z alternatywnego środowiska uruchomieniowego, NIE MOŻE ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.
• NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.
• NIE MOŻE być uruchamiana z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom. Nie może też przyznawać innym aplikacjom żadnych uprawnień użytkownika.

Pliki .apk alternatywnych środowisk wykonawczych MOGĄ być uwzględnione w pliku obrazu systemu implementacji urządzenia, ale MUSZĄ być podpisane za pomocą klucza innego niż klucz używany do podpisywania innych aplikacji dołączonych do implementacji urządzenia.

Podczas instalowania aplikacji alternatywne środowisko wykonawcze MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację. Jeśli aplikacja musi korzystać z zasobu urządzenia, do którego dostęp jest możliwy dzięki odpowiednim uprawnieniom Androida (np. do kamery czy GPS), alternatywny czas wykonywania MUSI informować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu. Jeśli środowisko wykonawcze nie rejestruje w taki sposób możliwości aplikacji, MUSI zawierać listę wszystkich uprawnień posiadanych przez środowisko wykonawcze podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.

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

Ta funkcja jest opcjonalna w przypadku wszystkich typów urządzeń.

Android obsługuje wielu użytkowników i pozwala na pełną izolację użytkowników [Zasoby, 103]. Implementacje urządzeń MOGĄ umożliwiać korzystanie z urządzenia przez wielu użytkowników, ale w takim przypadku muszą spełniać te wymagania dotyczące obsługi wielu użytkowników [Materiały, 104]:

• Implementacje urządzeń, które nie deklarują flagi funkcji android.hardware.telephony, MUSZĄ obsługiwać profile ograniczone. Jest to funkcja, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczonymi uprawnieniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
• Z drugiej strony implementacje urządzeń, które deklarują flagę funkcji android.hardware.telephony, NIE MOGĄ obsługiwać profili z ograniczonym dostępem, ale MUSZĄ być zgodne z implementacją kontroli AOSP w celu włączania i wyłączania dostępu innych użytkowników do połączeń głosowych i SMS-ów.
• Implementacje urządzeń MUSZĄ dla każdego użytkownika realizować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonej w dokumentacji referencyjnej Zasady zabezpieczeń i uprawnienia dostępu w interfejsach API [Zasoby, 102].
• Implementacje urządzeń mogą obsługiwać tworzenie użytkowników i profili zarządzanych za pomocą interfejsów API android.app.admin.DevicePolicyManager. Jeśli jest to obsługiwane, należy zadeklarować flagę funkcji platformy android.software.managed_users.
• Implementacje urządzeń, które deklarują flagę funkcji android.software.managed_users, MUSZĄ używać plakietki ikony AOSP w dół strumienia, aby reprezentować zarządzane aplikacje i inne elementy interfejsu użytkownika, takie jak Ostatnie i Powiadomienia.
• Każdy użytkownik na urządzeniu z Androidem MUSI mieć osobne i odizolowane katalogi pamięci zewnętrznej. Implementacje urządzeń MOGĄ przechowywać dane wielu użytkowników na tym samym woluminie lub w tym samym systemie plików. Implementacja urządzenia MUSI jednak zapewnić, aby aplikacje należące do danego użytkownika i działające w jego imieniu nie mogły odczytywać ani zapisywać danych należących do innego użytkownika. Pamiętaj, że wymienne nośniki, takie jak gniazda kart SD, mogą umożliwiać jednemu użytkownikowi dostęp do danych innego użytkownika za pomocą komputera hosta. Z tego powodu implementacje urządzeń, które korzystają z wymiennych nośników danych dla interfejsów API podstawowego zewnętrznego miejsca na dane, MUSZĄ szyfrować zawartość karty SD, jeśli włączono obsługę wielu użytkowników, za pomocą klucza przechowywanego tylko na niewymiennym nośniku danych, do którego dostęp ma tylko system. Ponieważ w takim przypadku dane nie będą czytelne dla komputera hosta, implementacje urządzeń będą musiały przejść na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika. W związku z tym wdrożenia urządzeń MOGĄ, ALE NIE POWINNY włączać funkcji wielu użytkowników, jeśli używają wymiennych nośników [Resources, 105] jako głównej pamięci zewnętrznej.

9,6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje wyświetlanie użytkownikom ostrzeżeń o wysyłanych SMS-ach premium [Zasoby, 106] . SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za które użytkownik może zostać obciążony opłatą. Implementacje urządzeń, które deklarują obsługę interfejsu android.hardware.telephony, MUSZĄ ostrzegać użytkowników przed wysłaniem SMS-a do numerów zidentyfikowanych za pomocą wyrażeń regularnych zdefiniowanych w pliku /data/misc/sms/codes.xml na urządzeniu. Górny projekt Android Open Source udostępnia implementację, która spełnia ten wymóg.

9,7. Funkcje zabezpieczeń jądra

Bezpieczna piaskownica Androida zawiera funkcje korzystające z systemu kontroli dostępu Mandatory Access Control (MAC) w systemie operacyjnym SELinux oraz inne funkcje zabezpieczeń w rdzeniu systemu Linux. SELinux lub inne funkcje zabezpieczeń zaimplementowane w ramach Androida:

• MUSI być zgodna z dotychczasowymi aplikacjami.
• NIE MOŻE zawierać widocznego interfejsu użytkownika, gdy wykryto i skutecznie zablokowano naruszenie zabezpieczeń, ale MOŻE zawierać widoczny interfejs użytkownika, gdy nie zablokowane naruszenie zabezpieczeń doprowadziło do skutecznego wykorzystania luki.
• NIE POWINNA być konfigurowana przez użytkownika ani programistę.

Jeśli interfejs API do konfiguracji zasad jest udostępniony aplikacji, która może wpływać na inną aplikację (np. interfejs Device Administration API), interfejs API MUSI ZABRANIAĆ konfiguracji, które naruszają zgodność.

Urządzenia MUSZĄ implementować SELinux lub, jeśli używają jądra innego niż Linux, równoważny system obowiązkowego kontroli dostępu. Urządzenia muszą też spełniać te wymagania, które są spełnione przez implementację referencyjną w górnym projekcie Android Open Source.

Implementacje na urządzeniu:

• Musisz ustawić SELinux na tryb globalny,
• NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie dozwolonym, w tym domeny związane z urządzeniem lub dostawcą.
• NIGDY nie modyfikuj, nie pomijaj ani nie zastępuj reguł neverallow znajdujących się w folderze external/sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Należy też pamiętać, że polityka MUSI być kompilowana zgodnie ze wszystkimi regułami neverallow, zarówno w domenach AOSP SELinux, jak i w domenach konkretnych urządzeń/producentów.

Implementacje urządzeń powinny zachować domyślne zasady SELinux udostępnione w folderze external/sepolicy w górnym projekcie Android Open Source i tylko rozszerzać te zasady o własną konfigurację. Implementacje urządzeń MUSZĄ być zgodne z poprzednim projektem Android Open Source.

9,8. Prywatność

Jeśli urządzenie implementuje funkcje systemu, które umożliwiają rejestrowanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu, MUSI ono stale informować użytkownika, gdy funkcja jest włączona i aktywnie rejestruje/nagrywa.

9.9. Szyfrowanie całego dysku

Opcjonalnie w przypadku implementacji na urządzeniach z Androidem bez ekranu blokady.

Jeśli implementacja urządzenia ma ekran blokady, urządzenie MUSI obsługiwać szyfrowanie całego dysku z danymi prywatnymi aplikacji (partycja /data) oraz partycji karty SD, jeśli jest to stała, nieusuwalna część urządzenia (Zasoby, 107). W przypadku urządzeń obsługujących szyfrowanie całego dysku szyfrowanie CAŁEGO dysku NALEŻY włączyć na stałe po zakończeniu konfiguracji. W tej wersji platformy Android ten wymóg jest określony jako „NALEŻY”, ale bardzo gorąco go zalecamy, ponieważ w przyszłych wersjach Androida zmieni się on na „NALEŻY”. Szyfrowanie MUSI używać AES z kluczem 128-bitowym (lub większym) i trybu przeznaczonego do przechowywania (na przykład AES-XTS, AES-CBC-ESIV). Klucz szyfrowania NIE MOŻE być zapisywany w pamięci w niezaszyfrowanej formie. Poza okresem aktywnego korzystania klucz szyfrowania POWINIEN być zaszyfrowany algorytmem AES przy użyciu kodu dostępu na ekranie blokady rozciągniętego za pomocą algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt). Jeśli użytkownik nie podał kodu dostępu do ekranu blokady lub wyłączył jego użycie do szyfrowania, system powinien użyć domyślnego kodu dostępu do zapakowania klucza szyfrowania. Jeśli urządzenie udostępnia magazyn kluczy obsługiwany sprzętowo, algorytm rozciągania hasła MUSI być powiązany kryptograficznie z tym magazynem kluczy. Klucza szyfrowania NIE MOŻNA wysyłać z urządzenia (nawet gdy jest on zaszyfrowany za pomocą hasła użytkownika lub klucza powiązanego z urządzeniem). Projekt upstream Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-crypt jądra Linuksa.

9.10. Weryfikacja podczas uruchamiania

Implementacje urządzeń powinny obsługiwać zweryfikowane uruchamianie w celu zapewnienia integralności urządzenia. Jeśli funkcja jest obsługiwana, MUSI zadeklarować flagę funkcji platformy android.software.verified_boot. Chociaż w przypadku tej wersji platformy Android ten wymóg jest określony jako „NALEŻY”, bardzo gorąco zalecamy, aby w przyszłych wersjach Androida zmienił się on na „NALEŻY”. Projekt Android Open Source na upstreamie udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-verity w jądrze Linuksa.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji.

Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Z tego powodu bardzo zalecamy, aby implementujący urządzenia wprowadzali jak najmniej zmian w implementacji referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego wykonania pracy i ewentualnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje urządzeń MUSZĄ przejść testy Compatibility Test Suite (CTS) [Resources, 108] dostępne w ramach projektu Android Open Source, korzystając z ostatecznej wersji oprogramowania na urządzeniu. Dodatkowo implementatorzy urządzeń powinni w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source. Muszą też zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku implementacji części kodu źródłowego referencyjnego.

Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 5.0 może być udostępnionych kilka wersji CTS. Implementacje urządzeń MUSZĄ przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

10.2. Weryfikator CTS

Implementacje na urządzeniu MUSZĄ prawidłowo wykonywać wszystkie odpowiednie przypadki w weryfikatorze CTS. Narzędzie CTS Verifier jest częścią pakietu Compatibility Test Suite i ma być używane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania kamery i czujników.

Narzędzie CTS Verifier zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych. Implementacje urządzeń MUSZĄ przejść wszystkie testy sprzętu, który posiadają. Jeśli na przykład urządzenie ma akcelerometr, MUSI poprawnie wykonać test akcelerometru w CTS Verifier. Przypadki testowe dotyczące funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte.

Każde urządzenie i każda kompilacja MUSZĄ prawidłowo działać z narzędziem CTS Verifier, jak opisano powyżej. Ponieważ jednak wiele wersji jest bardzo podobnych, implementatorzy urządzeń nie muszą uruchamiać narzędzia CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła weryfikację CTS Verifier, tylko zestawem obsługiwanych lokalizacji, marki itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi przeprowadzać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchamianie urządzenia.

Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego fabrycznie zainstalowanego oprogramowania. Na przykład dowolna z tych metod spełnia to wymaganie:

• Pobieranie bezprzewodowe (OTA) z aktualizacją offline po ponownym uruchomieniu
• „Przywiązane” aktualizacje przez USB z komputera głównego
• Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na pamięci wymiennej

Jeśli jednak implementacja urządzenia obejmuje obsługę nielimitowanego połączenia danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), urządzenie MUSI obsługiwać pobieranie przez sieć z aktualizacją offline po ponownym uruchomieniu.

Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać dane prywatne aplikacji i dane współdzielone aplikacji. Pamiętaj, że oprogramowanie Androida na poziomie dostawcy zawiera mechanizm aktualizacji, który spełnia ten wymóg.

W przypadku implementacji urządzeń, które uruchamiają Androida 5.0 lub nowszego, mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest identyczny z oczekiwanym po aktualizacji OTA. Realizacja OTA na podstawie bloków w ramach projektu Android Open Source, dodanego od Androida 5.0, spełnia ten wymóg.

Jeśli po wydaniu urządzenia zostanie w nim wykryty błąd, który wpływa na zgodność aplikacji innych firm, ale w rozsądnym okresie użytkowania urządzenia (określonym w konsultacji z zespołem ds. zgodności Androida), implementator urządzenia MUSI naprawić ten błąd, wprowadzając aktualizację oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

12. Historia zmian dokumentu

W tabeli poniżej znajdziesz podsumowanie zmian w definicji zgodności w tej wersji.

sekcje,	Podsumowanie zmiany
1. Wprowadzenie	Aktualizacja wymagań, aby odwoływały się do dokumentacji pakietu SDK jako wiarygodnego źródła informacji.
2. Typy urządzeń	Definicje typów urządzeń: ręcznych, telewizorów i zegarków.
2.1 Konfiguracja urządzenia	Dodano niepełną listę, która pokazuje różnice w konfiguracji sprzętu na różnych urządzeniach.
3.1. Zgodność z zarządzanym interfejsem API	Musisz też udostępnić w kodzie źródłowym Androida pełne implementacje interfejsów API z oznaczeniem „@SystemApi”.
3.2.2. Parametry tworzenia	Dodano parametry SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS i SUPPORTED_64_BIT_ABIS na liście, zaktualizowano PRODUCT, aby wymagał unikalnych kodów SKU produktów, oraz zaktualizowano TAGS.
3.2.3.1. Główne intencje aplikacji	Uściślone sformułowanie, że wymóg zgodności dotyczy głównie wzorca intencji
3.2.3.5. Domyślne ustawienia aplikacji	Dodano nowe wymagania dotyczące ekranu głównego, NFC i domyślnych aplikacji do obsługi SMS-ów.
3.3.1 Interfejsy binarne aplikacji	Dodano wymagania dotyczące obsługi odpowiednich 32-bitowych ABI, jeśli obsługiwane są 64-bitowe ABI. Zaktualizowano parametry, aby uwzględnić tę zmianę.
3.4.1. Zgodność WebView	Zgodność z Webview wymagana na wszystkich urządzeniach z wyjątkiem zegarków z Androidem. Usunięto wymagania dotyczące lokalizacji.
3.4.2. Zgodność z przeglądarką	Urządzenia z Androidem TV i zegarki mogą pomijać aplikację przeglądarki, ale wszystkie inne typy implementacji urządzeń MUSZĄ ją zawierać.
3.7. Zgodność w czasie działania	Zaktualizowano minimalne wymagania dotyczące pamięci aplikacji
3.8.2. Widżety	Obsługa widżetów jest opcjonalna w przypadku wszystkich typów urządzeń, ale zalecana w przypadku urządzeń przenośnych.
3.8.3. Powiadomienia	Rozwinięte definicje typów obsługiwanych powiadomień.
3.8.4. Szukaj	Urządzenia z Androidem TV MUSZĄ zawierać wyszukiwanie globalne. Pozostałe typy urządzeń
3.8.6. Motywy	Urządzenia MUSZĄ obsługiwać motyw Material Design.
3.8.7. Animowane tapety	Urządzenia z tapetą na żywo MUSZĄ raportować flagę funkcji platformy android.software.live_wallpaper.
3.8.8. Przełączanie aktywności	Zalecane wymaganie obsługi nowego interfejsu Ostatnie. POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz.
3.8.10. Sterowanie multimediami na ekranie blokady	Interfejs zdalnego sterowania klienta API został wycofany na rzecz szablonu powiadomienia o multimediach
3.8.11. Sny	Opcjonalne w przypadku urządzeń z Androidem Watch. Wymagany w przypadku wszystkich innych typów urządzeń.
3.8.13 Unicode i czcionka	Oprócz dotychczasowych wymagań MUSI obsługiwać Roboto 2.
3.12. Framework wejścia TV	Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać interfejs Television Input Framework.
5.1. Kodeki multimedialne	Dodaliśmy 3 sekcje dotyczące kodeków audio, obrazu i wideo.
5.4 Nagranie dźwiękowe	podzielone na podrozdziały,
5.4.1. Przechwytywanie surowego dźwięku	Zdefiniowane cechy dla nieprzetworzonego przechwytywania dźwięku na urządzeniach, które deklarują android.hardware.microphone
5.5. Odtwarzanie dźwięku	Dodano sekcję 5.5. Odtwarzanie dźwięku z 2 podrozdziałami: 5.5.1 Efekty dźwiękowe i 5.5.2. Głośność wyjścia audio
5.6 Opóźnienie dźwięku	Dodaliśmy definicje i wymagania dotyczące jittera wyjściowego w stanie zimnym, jittera wejściowego w stanie zimnym oraz ciągłej zwłoki w obie strony.
5.8 Bezpieczne nośniki danych	Obejmuje wymagania dotyczące bezpiecznych multimediów od wersji 7.1.8. Wyświetlacze zewnętrzne i dodatkowe wymagania dotyczące Androida TV.
6.1. Narzędzia dla programistów	Zaktualizowane zasoby.
6.2.1. Eksperymentalny	Usunięta sekcja
7. Zgodność sprzętowa	Zaktualizowano, aby odzwierciedlić fakt, że implementacje urządzeń MUSZĄ konsekwentnie raportować dokładną konfigurację sprzętową dla tego samego odcisku palca kompilacji.
7.1.1.1. Rozmiar ekranu	Zaktualizowano, aby odzwierciedlić rozmiar ekranu urządzeń z Androidem Watch i to, że wartości nie można zmienić
7.1.1.2. Format obrazu	Zaktualizowano, aby odzwierciedlać współczynnik proporcji ekranu urządzeń z Androidem Watch (1:1).
7.1.3. Orientacja ekranu	Zmieniono, aby odzwierciedlać fakt, że urządzenia z ustawionym ekranem w orientacji poziomej powinny zgłaszać tylko tę orientację.
7.1.4. akceleracja grafiki 2D i 3D;	Dodano, że urządzenia z Androidem MOGĄ obsługiwać pakiet rozszerzeń Androida.
(stara) 7.1.6. Typy ekranów	Sekcja została usunięta
7.1.6. Technologia ekranu	Zaktualizowany współczynnik proporcji piksela (PAR) powinien mieścić się w zakresie od 0,9 do 1,15. (~15% tolerancji)
7.1.7. Wyświetlacze zewnętrzne	Część sekcji została przeniesiona do sekcji 5.8. Secure Media.
7.2.2. Nawigacja bezdotykowa	Urządzenia z Androidem TV MUSZĄ obsługiwać D-pad.
7.2.3. Klawisze nawigacyjne	Dołączony język obsługiwany na różnych typach urządzeń.
7.2.4. Dotykowe wprowadzanie danych	Urządzenia z Androidem Watch MUSZĄ obsługiwać ekran dotykowy.
7.2.6. Obsługa kontrolera gier	Dodano sekcję z wymaganiami dotyczącymi Androida TV.
7.2.7. Pilot	Dodano sekcję z wymaganiami dotyczącymi Androida TV.
7.3. Czujniki	Zdefiniowano ponownie czujniki syntetyczne jako czujniki złożone, a strumienne czujniki jako czujniki ciągłe. Czujniki powinny przekazywać czas zdarzenia w nanosekundach.
7.3.1. Akcelerometr	sprecyzowaliśmy wymagane typy czujników i zmieniliśmy ich wymagania;
7.3.2. Magnetometr	sprecyzowaliśmy wymagane typy czujników i zmieniliśmy ich wymagania;
7.3.4. Żyroskop	sprecyzowaliśmy wymagane typy czujników i zmieniliśmy ich wymagania;
7.3.5. barometr;	Zmieniono z MOŻNA na NALEŻY wdrożyć barometr. Musisz zaimplementować i zgłosić czujnik TYPE_PRESSURE.
7.3.6. Termometr	Urządzenia mogą zawierać termometr otoczenia. MOŻE, ALE NIE MUSI zawierać termometru CPU.
7.3.8. Czujnik zbliżeniowy	Urządzenia, które mogą nawiązywać połączenia głosowe i wskazywać dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType, powinny zawierać czujnik zbliżeniowy.
7.4.2. IEEE 802.11 (Wi-Fi)	Urządzenia z Androidem TV MUSZĄ obsługiwać Wi-Fi. Urządzenia, które obsługują Wi-Fi, muszą raportować android.hardware.wifi.
7.4.2.1. Wi-Fi Direct	MUSI raportować funkcję sprzętową android.hardware.wifi.direct.
7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi	Urządzenia z Androidem TV MUSZĄ obsługiwać Wi-Fi TDLS.
7.5. Aparaty	Jeśli implementacja urządzenia zawiera co najmniej 1 kamerę, aplikacja powinna mieć możliwość jednoczesnego przydzielenia 3 map bitowych o rozmiarze odpowiadającym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu.
7.5.3. Kamery zewnętrzne	Dodano wymagania, aby implementacje urządzeń z trybem hosta USB MOGŁY obejmować obsługę kamery zewnętrznej.
7.5.5. Funkcje systemu kamery	Dodano listę funkcji aparatu i okoliczności, w których należy je zdefiniować.
7.6.1. Minimalna ilość pamięci i miejsca na dane	Zaktualizowano wymagania dotyczące urządzeń 32- i 64-bitowych. Wymagania dotyczące pamięci SVELTE zostały usunięte. Urządzenia MUSZĄ mieć co najmniej 1,5 GB pamięci nieulotnej
7.6.2. Pamięć współdzielona aplikacji	Aktualizacja wymagań dotyczących wymiennych nośników danych dostępnych dla użytkownika
7.6.2. Pamięć współdzielona aplikacji	Zaktualizowano wymagania dotyczące zapisywania danych przez wstępnie zainstalowane aplikacje systemowe na zewnętrznej pamięci masowej.
7.7. USB	Usunięto wymagania dotyczące portów innych niż gniazda ładowania, które muszą znajdować się na tej samej krawędzi co port micro-USB. Zaktualizowano wymagania dotyczące trybu hosta i peryferyjnego.
7.7. USB	Poprawiono literówki w sekcji USB.
7.8.1. Audio	Przeniesiono tutaj sekcję dotyczącą mikrofonu. Dodano wymagania dotyczące portów analogowych Wyjście audio i Audio.
8. Zgodność z kampaniami Performance Max	Dodaliśmy wymagania dotyczące spójności interfejsu.
9,5. Pomoc dla wielu użytkowników	Funkcja obsługi wielu użytkowników jest opcjonalna w przypadku wszystkich typów urządzeń. Szczegółowe wymagania według typu urządzenia w sekcji.
9,5. Pomoc dla wielu użytkowników	Szyfrowanie karty SD jest wymagane w przypadku głównej pamięci zewnętrznej.
9,7. Funkcje zabezpieczeń jądra	MOŻE mieć widoczny interfejs użytkownika, gdy dochodzi do niezablokowanego naruszenia zabezpieczeń, które umożliwia wykorzystanie luki. Domeny w trybie permisywnym są niedozwolone.
9.9. Szyfrowanie całego dysku	Urządzenia z ekranem blokady powinny obsługiwać szyfrowanie całego dysku. W przypadku nowych urządzeń szyfrowanie całego dysku musi być włączone domyślnie.
9.10 Weryfikacja podczas uruchamiania	Dodano sekcję, w której zaleca się, aby implementacje urządzeń obsługiwały uruchamianie zweryfikowane w celu zapewnienia integralności urządzenia.
10.3. Aplikacje referencyjne	Usunięto sekcję z CDD.
11. Oprogramowanie z możliwością aktualizacji	Jeśli urządzenie obsługuje profil 802.11 lub Bluetooth PAN (sieć osobista), MUSI obsługiwać pobieranie przez sieć z aktualizacją offline przez ponowne uruchamianie.
14. Materiały	Zasoby przeniesione z sekcji 2 do sekcji 14

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem [Zasoby, 109] i poprosić o wyjaśnienia lub zgłosić problemy, które nie zostały opisane w dokumencie.

14. Materiały

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

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

3. Funkcje Androida TV: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Funkcja zegarka z Androidem: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

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

6. Informacje o uprawnieniach na Androida: http://developer.android.com/reference/android/Manifest.permission.html

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

8. Dozwolone ciągi znaków wersji Androida 5.0: http://source.android.com//docs/compatibility/5.0/versions

9. Dostawca usług telefonicznych: http://developer.android.com/reference/android/provider/Telephony.html

10. Host Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Pakiet rozszerzeń Androida: http://developer.android.com/guide/topics/graphics/opengl.html#aep

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

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

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

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

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

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

18. Webstorage API HTML5/W3C: http://www.w3.org/TR/webstorage/

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

20. Format pliku wykonywalnego Dalvik i specyfikacja kodu bajtowego: dostępne w kodzie źródłowym Androida w folderze dalvik/docs.

21. Widgety aplikacji: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

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

23. Zasoby aplikacji: https://developer.android.com/guide/topics/resources/available-resources.html

24. Przewodnik po stylu ikon na pasku stanu: http://developer.android.com/design/style/iconography.html

25. Zasoby dotyczące powiadomień: https://developer.android.com/design/patterns/notifications.html

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

27. Toasty: http://developer.android.com/reference/android/widget/Toast.html

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

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

30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Animowane tapety: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Materiały dotyczące ekranu przeglądu: http://developer.android.com/guide/components/recents.html

33. Przypinanie ekranu: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Metody wprowadzania: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Powiadomienie o multimediach: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

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

37. Settings.Secure LOCATION_MODE:

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

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

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

40. Informacje o DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Aplikacja właściciela urządzenia z Androidem:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Interfejsy API usługi dostępności Androida: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Interfejsy API dostępności Androida: http://developer.android.com/reference/android/view/accessibility/package-summary.html

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

45. Interfejsy Text-To-Speech API: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. System wprowadzania danych do telewizora: /devices/tv/index.html

47. dokumentacja narzędzi (dla adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

48. Opis pliku APK na Androida: http://developer.android.com/guide/components/fundamentals.html

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

50. Formaty multimediów na Androidzie: http://developer.android.com/guide/appendix/media-formats.html

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

52. Interfejs API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Klasa android.content.pm.PackageManager i lista funkcji sprzętowych na Androida:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. Projekt protokołu HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Narzędzie do testowania Monkey: http://developer.android.com/tools/help/monkey.html

59. Narzędzie Systrace: http://developer.android.com/tools/help/systrace.html

60. Ustawienia związane z tworzeniem aplikacji na Androida:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

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

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Pakiet rozszerzeń Androida dla OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Sprzętowa akceleracja: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. Rozszerzenie EGL-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

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

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

69. Asystent działań: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

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

71. Interfejs API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html

72. Interfejs API zdarzeń klawisza: http://developer.android.com/reference/android/view/KeyEvent.html

73. Czujniki w ramach projektu Open Source na Androidzie: http://source.android.com/docs/core/interaction/sensors.

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

75. Zdarzenie czujnika sygnatury czasowej: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Czujniki kompozytowe na platformie Android Open Source: http://source.android.com/devices/sensors/composite_sensors.html

77. Tryb ciągłego wyzwalania: http://source.android.com/devices/sensors/base_triggers.html#continuous

78. Czujnik przyspieszeniomierza: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

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

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

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

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

83. Interfejs API Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

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

86. Ustawienia udostępniania przez NFC na Androidzie:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

88. Bezpieczne, proste parowanie Bluetooth za pomocą NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

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

91. Aparat: http://developer.android.com/reference/android/hardware/Camera.html

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

93. Poziom sprzętowy aparatu: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Obsługa wersji aparatu: http://source.android.com/docs/core/camera/versioning

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

96. Android File Transfer: http://www.android.com/filetransfer

97. Akcesoria Open Accessories na Androida: http://developer.android.com/guide/topics/usb/accessory.html.

98. Dźwięk przez USB na Androidzie: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. Specyfikacja ładowania baterii USB, wersja 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

101. Przewodowy zestaw słuchawkowy: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

102. Informacje o zabezpieczeniach i uprawnieniach w Androidzie: http://developer.android.com/guide/topics/security/permissions.html

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

104. Informacje o pamięci zewnętrznej: http://source.android.com/docs/core/storage

105. Interfejsy API zewnętrznego magazynu: http://developer.android.com/reference/android/os/Environment.html

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

107. Szyfrowanie w ramach projektu Android Open Source: http://source.android.com/devices/tech/encryption/index.html

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

109. Forum Zgodność z Androidem: https://groups.google.com/forum/#!forum/android-compatibility

110. Projekt WebM: http://www.webmproject.org/

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu SDK. W każdym przypadku, gdy dokument definicji zgodności lub pakiet Compatibility Test Suite są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w wymienionych powyżej dokumentach są uznawane za część tej Definicji zgodności.