Definicja zgodności z Androidem 5.1

Spis treści

1. Wprowadzenie

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

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

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

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

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

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

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

2. Typy urządzeń

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

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

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

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

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

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

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

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

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

2.1 Konfiguracje urządzenia

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

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

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

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

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

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

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

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

3.2.1. Uprawnienia

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

3.2.2. Parametry tworzenia

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

Parametr Szczegóły
VERSION.RELEASE Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji [Resources, 8].
WERSJ.SDK Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 5.1 to pole MUSI zawierać wartość całkowitą 22.
VERSION.SDK_INT Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 5.1 to pole MUSI zawierać wartość całkowitą 22.
VERSION.INCREMENTAL Wartość wybrana przez implementatora urządzenia, która określa konkretną wersję bieżąco działającego systemu Android w czytelnym dla człowieka formacie. Tej wartości NIE można używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany w kontroli źródłowej posłużył do wygenerowania kompilacji. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"”).
PLANSZOWE Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny wewnętrzny sprzęt używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKA Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_64_BIT_ABIS Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2 Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodu identyfikującą konfigurację funkcji sprzętowych i przemysłowy projekt urządzenia. Wartość tego pola MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
FINGERPRINT Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi on być zgodny z tym szablonem:

$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Przykład: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys

Odcisk palca NIE MOŻE zawierać znaków odstępów. Jeśli inne pola zawarte w powyższym szablonie zawierają znaki odstępu, w odciskach palców kompilacji MUSZĄ one zostać zastąpione innym znakiem, np. znakiem podkreślenia („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy ASCII.
SPRZĘT Nazwa sprzętu (z wiersza poleceń jądra lub katalogu /proc). Powinien być zrozumiały dla człowieka. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
HOST Ciąg znaków, który w czytelnym dla człowieka formacie jednoznacznie identyfikuje hosta, na którym została utworzona kompilacja. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"”).
ID Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość wystarczająco istotną, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że: NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"”).
MODEL Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i reklamowane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („”).
USŁUGA Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodu konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być czytelny dla człowieka, ale niekoniecznie jest przeznaczony do wyświetlania użytkownikom. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SERIAL Numer seryjny sprzętu, który MUSI być dostępny. Wartość w tym polu MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^([a-zA-Z0-9]{6,20})$”.
TAGI Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo odróżnia kompilację. To pole MUSI mieć jedną z wartości odpowiadającą 3 typowym konfiguracjom podpisywania na platformie Androida: release-keys, dev-keys, test-keys.
CZAS Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
TYP Wartość wybrana przez implementatora urządzenia, która określa konfigurację czasu wykonywania kompilacji. To pole MUSI zawierać jedną z 3 wartości odpowiadających 3 typowym konfiguracjom środowiska wykonawczego Androida: user, userdebug lub eng.
UŻYTKOWNIK Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że: NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"”).

3.2.3. Zgodność z zamiarem

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

3.2.3.1. Główne intencje aplikacji

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

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

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

3.2.3.2. Zastąpienia intencji

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

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

3.2.3.3. Przestrzenie nazw intencji

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

3.2.3.4. Zamiary związane z transmisją

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

3.2.3.5. Domyślne ustawienia aplikacji

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

Implementacje na urządzeniu:

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

3.3. Zgodność z natywnym interfejsem API

3.3.1. Interfejsy binarne aplikacji

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

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

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

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

  • libc (biblioteka C)
  • libm (biblioteka matematyczna)
  • Minimalne wsparcie dla C++
  • Interfejs JNI
  • liblog (rejestrowanie na Androidzie)
  • libz (kompresja Zlib)
  • libdl (linker dynamiczny)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libEGL.so (własne zarządzanie powierzchnią OpenGL)
  • libjnigraphics.so
  • libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
  • libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
  • libandroid.so (obsługa natywnej aktywności Androida)
  • libmediandk.so (obsługa natywnych interfejsów API multimediów)
  • Obsługa OpenGL, jak opisano poniżej

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

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

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

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

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

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

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

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

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

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Urządzenia z Androidem Watch MOGĄ, ale wszystkie inne implementacje urządzeń MUSZĄ udostępniać pełną implementację interfejsu android.webkit.Webview API.

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

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

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.
    • Ciąg tekstowy $(WEBVIEW) MOŻE być pominięty, ale jeśli jest obecny, MUSI mieć wartość „wv”, aby wskazać, że jest to widok internetowy.
    • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość parametru android.os.Build.MODEL.
    • Wartość ciągu $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID.
    • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w upstreamowym projekcie Android Open Source.
    • Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków Mobile.

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

3.4.2. Zgodność z przeglądarką

Implementacje Androida na telewizory, zegarki i system Android Automotive MOGĄ pomijać aplikację przeglądarki, ale MUSZĄ obsługiwać publiczne wzorce intencji zgodnie z opisem w sekcji 3.2.3.1. Wszystkie inne typy implementacji urządzeń 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:

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

3.5. Zgodność zachowania interfejsu API

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

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

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

3.6. Nazwy katalogów interfejsu API

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

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

Zabronione modyfikacje:

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

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

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

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

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

3.7. Zgodność w czasie działania

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

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

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

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

3.8. Zgodność interfejsu

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

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

3.8.2. Widżety

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óry umożliwia aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi [Resources, 21]. Jest to funkcja, która jest MOCNO POLECANA do obsługi na urządzeniach przenośnych. Implementacje urządzeń, które obsługują umieszczanie widżetów na ekranie głównym, MUSZĄ spełniać te wymagania i deklarować obsługę funkcji platformy android.software.app_widgets.

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

3.8.3. Powiadomienia

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

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

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

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

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

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

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

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

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

3.8.5. Toasty

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

3.8.6. Motywy

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

Android zawiera rodzinę motywów „Holo” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i odczucie motywu Holo zdefiniowanego w pakiecie Android SDK [Resources, 28]. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom [Zasoby, 29].

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

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

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

3.8.7. Animowane tapety

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

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

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

3.8.8. Przełączanie aktywności

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

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

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

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

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie danymi wejściowymi oraz edytory metod wejściowych innych firm [Materiały, 34]. Implementacje urządzeń, które umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm na urządzeniu, MUSZĄ deklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy IME zgodnie z definicją w dokumentacji pakietu Android SDK.

Implementacje urządzeń, które deklarują funkcję android.software.input_methods, MUSZĄ udostępniać użytkownikowi mechanizm dodawania i konfigurowania metod wprowadzania danych innych firm. Implementacje urządzeń MUSZĄ wyświetlać interfejs ustawień w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Sterowanie multimediami na ekranie blokady

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

3.8.11. Sny

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

3.8.12. Lokalizacja

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

3.8.13. Unicode i czcionka

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

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

3.9. Administracja urządzeniem

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

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

3.10. Ułatwienia dostępu

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

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

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

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

3.11. Zamiana tekstu na mowę

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

Implementacje Androida Automotive:

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

Wszystkie inne implementacje urządzeń:

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

3.12. Framework wejścia TV

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

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

4. Zgodność z pakietem aplikacji

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

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

5. Zgodność multimedialna

5.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać podstawowe formaty multimediów określone w dokumentacji pakietu SDK Androida [Zasoby, 50], z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tym dokumencie. W szczególności implementacje urządzeń MUSZĄ obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w tabeli poniżej i zgłaszane za pomocą MediaCodecList [Resources,112]. Implementacje urządzeń MUSZĄ być również w stanie dekodować wszystkie profile zgłoszone w urządzeniu CamcorderProfile [Resources, 113]. Wszystkie te kodeki są udostępniane jako implementacje oprogramowania w ramach preferowanej implementacji Androida z Projektu Android Open Source.

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

5.1.1. Kodeki audio

Format/kodek za pomocą kodera. Dekoder Szczegóły Obsługiwane typy plików i formaty kontenerów
Profil MPEG-4 AAC

(AAC LC)

 WYMAGANE1 WYMAGANE Obsługa treści mono/stereo/5.0/5.12 o standardowej częstotliwości próbkowania od 8 do 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS raw AAC (.aac, dekodowanie w Androidzie 3.1 lub nowszym, kodowanie w Androidzie 4.0 lub nowszym, ADIF nie jest obsługiwany)
  • MPEG-TS (.ts, nieprzeskakuj, Android 3.0 lub nowszy)
MPEG-4 HE AAC Profile (AAC+) WYMAGANE1
(Android 4.1 lub nowszy)		 WYMAGANE Obsługa treści mono/stereo/5.0/5.12 o standardowych częstotliwościach próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2

Profil (ulepszone AAC+)

 WYMAGANE Obsługa treści mono/stereo/5.0/5.12 o standardowych częstotliwościach próbkowania od 16 do 48 kHz.
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu) WYMAGANE1

(Android 4.1 lub nowszy)

 WYMAGANE

(Android 4.1 lub nowszy)

 Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.
AMR-NB WYMAGANE3 WYMAGANE3 4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz 3GPP (.3gp)
AMR-WB WYMAGANE3 WYMAGANE3 9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz
FLAC WYMAGANE
(Android 3.1 lub nowszy)		 Mono/Stereo (bez kanałów dodatkowych). Częstotliwości próbkowania do 48 kHz (ale na urządzeniach z wyjściami 44,1 kHz zalecamy stosowanie częstotliwości do 44,1 kHz, ponieważ konwerter 48/44,1 kHz nie zawiera filtra dolnoprzepustowego). Zalecamy 16-bitową rozdzielczość. W przypadku 24-bitowej rozdzielczości nie stosuje się ditheringu. Tylko FLAC (.flac)
MP3 WYMAGANE Mono/Stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR) MP3 (.mp3)
MIDI WYMAGANE Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody
  • Typ 0 i 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis WYMAGANE
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE WYMAGANE4
(Android 4.1 lub nowszy)		 WYMAGANE 16-bitowy PCM liniowy (częstotliwość do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nieskompresowanych nagrań PCM o częstotliwościach 8000, 11025, 16000 i 44100 Hz. WAVE (.wav)
Opus WYMAGANE
(Android 5.0 lub nowszy)		 Matroska (.mkv)

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

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

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

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

5.1.2. Kodek obrazu

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

5.1.3. Kodeki wideo

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

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

(Android 4.3 lub nowszy)

 WYMAGANE2

(Android 2.3.3 lub nowszy)

 Więcej informacji znajdziesz w sekcji 5.2 i 5.3.
  • WebM (.webm) [Resources, 110
  • Matroska (.mkv, Android 4.0 lub nowszy)4
VP9 WYMAGANE2
(Android 4.4 lub nowszy)		 Więcej informacji znajdziesz w sekcji 5.3.
  • WebM (.webm) [Resources, 110]
  • Matroska (.mkv, Android 4.0 lub nowszy)4

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

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

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

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

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

5.2. Kodowanie wideo

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ść wideo 320 x 240 pikseli 720 x 480 piks. 1280 x 720 pikseli 1920 x 1080 piks.
liczba klatek na sekundę, 20 kl./s 30 klatek/s 30 klatek/s 30 klatek/s
Szybkość transmisji wideo 384 kbps 2 Mb/s 4 Mb/s 10 Mb/s

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

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

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

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

5.3. Dekodowanie wideo

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 wszystkich kodeków VP8, VP9, H.264 i H.265 udostępnionych deweloperom za pomocą standardowych interfejsów API Androida.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4. Nagrywanie dźwięku

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

5.4.1. Przechwytywanie dźwięku w formacie RAW

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

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

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

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

5.4.2. Przechwytywanie danych do rozpoznawania głosu

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

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

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

5.4.3. Przechwytywanie w celu przekierowania odtwarzania

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

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

5.5. Odtwarzanie dźwięku

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

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

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

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

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

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

5.5.2. Efekty dźwiękowe

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

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

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

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

5.6. Opóźnienie dźwięku

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

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

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

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

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

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

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

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

5.7. Protokoły sieciowe

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

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

5.8. Secure Media

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

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

6.1. Narzędzia dla programistów

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

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.

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.

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

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

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

6.2. Opcje programisty

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

7. Zgodność sprzętowa

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

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

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

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

7.1. Wyświetlanie i grafika

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

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

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

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar ekranu

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 (czyli „układzie ekranu”) za pomocą android.content.res.Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK. Implementacje na urządzeniach MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z definicją w dokumentacji pakietu Android SDK [Resources, 61] i określonym przez nadrzędną platformę Android. W szczególności implementacje na urządzeniach MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z podanymi niżej wymiarami ekranu w logicznych pikselach niezależnych od gęstości (dp).

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

Dodatkowo

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

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

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

7.1.1.2. Format obrazu

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)
  • 280 dpi
  • 320 dpi (xhdpi)
  • 400 dpi (400 dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560 dpi)
  • 640 dpi (xxxhdpi)

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

7.1.2. Dane dotyczące wyświetleń

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

7.1.3. Orientacja ekranu

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

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

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

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

7.1.4. akceleracja grafiki 2D i 3D;

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

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

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

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

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

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

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

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

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

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

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

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

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

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

7.1.6. Technologia ekranu

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

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

7.1.7. Wyświetlacze dodatkowe

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

7.2. Urządzenia wejściowe

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

7.2.1. Klawiatura

Implementacje Androida na zegarek i Androida Automotive MOGĄ zawierać klawiaturę ekranową. Wszystkie inne implementacje urządzeń MUSZĄ zawierać klawiaturę wirtualną i musi:

Implementacje na urządzeniu:

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

7.2.2. Nawigacja bezdotykowa

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) w przypadku implementacji na urządzeniu, które nie jest urządzeniem z Androidem TV.
  • MUSI zwracać prawidłową wartość dla android.content.res.Configuration.navigation[Resources, 68].
  • MUSI zawierać rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. Implementacja open source w górnym systemie Android zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają niedotykowych elementów sterujących.

7.2.3. Klawisze nawigacyjne

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 Strona główna, Ostatnie i Wstecz (odpowiednio zmapowane na zdarzenia KEYCODE_HOME, KEYCODE_APP_SWITCH i KEYCODE_BACK) są niezbędne w ramach paradygmatu nawigacji w Androidzie.

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

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

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

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

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

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

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

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

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

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

7.2.4. Dotykowe wprowadzanie danych

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:

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

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

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

7.2.5. Symulowane dotykowe wprowadzanie danych

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

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

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

7.2.6. Obsługa kontrolera gier

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

7.2.6.1. Mapowania przycisków

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

Przycisk Użycie HID2 Przycisk Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Joystick w górę1

Przycisk w dół1

 0x01 0x00393 AXIS_HAT_Y4
przycisk w lewo na padzie kierunkowym1

Przycisk w prawo na padzie kierunkowym1

 0x01 0x00393 AXIS_HAT_X4
Przycisk lewego uchwytu1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Strona główna1 0x0c 0x0223 KEYCODE_HOME (3)
Wstecz1 0x0c 0x0224 KEYCODE_BACK (4)

1 [Zasoby, 72]

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

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

4 [Resources, 71]

Analog Controls1 Użycie HID Przycisk Android
Lepiej: 0x02 0x00C5 AXIS_LTRIGGER
Prawy spust 0x02 0x00C4 AXIS_RTRIGGER
Lewy joystick 0x01 0x0030

0x01 0x0031

 AXIS_X

AXIS_Y
Prawy joystick 0x01 0x0032

0x01 0x0035

 AXIS_Z

AXIS_RZ

1 [Resources, 71]

7.2.7. Pilot

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

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

7.3. Czujniki

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

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

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

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

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

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

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

7.3.1. Akcelerometr

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

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

7.3.2. Magnetometr

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

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

7.3.3. GPS

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

7.3.4. Żyroskop

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

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

7.3.5. barometr;

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

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

7.3.6. Termometr

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

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

7.3.7. Fotometr

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

7.3.8. Czujnik zbliżeniowy

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

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

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje urządzeń 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:

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

7.4.2.1. Wi-Fi Direct

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

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

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.
  • POWINIEN zawierać heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku korzystania z punktu dostępu Wi-Fi.

7.4.3. Bluetooth

Implementacje Androida na zegarki i systemy samochodowe MUSZĄ obsługiwać Bluetooth. Implementacje telewizorów z Androidem MUSZĄ obsługiwać Bluetooth i Bluetooth LE.

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

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

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

7.4.4. Komunikacja Near Field Communication

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

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

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

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

  • Musisz podać stałą funkcję android.hardware.nfc.hce.
  • MUSI obsługiwać interfejsy API NFC HCE zgodnie z definicją w pakiecie SDK do Androida [Zasoby, 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 MOŻE implementować odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że implementuje 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 implementacji urządzenia ustawienie głównej autosynchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała wartość „prawda” [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:

  • MUSI zawierać flagę funkcji android.hardware.camera i android.hardware.camera.any.
  • Rozdzielczość musi wynosić co najmniej 2 Mpix.
  • W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany 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:

  • NALEŻY podać 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 aparatów 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ć lustrzany w sposób poziomy 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 nowszy).
  • 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 oraz 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ć zorientowane 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 bez względu na naturalną orientację urządzenia, czyli dotyczy zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

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
  • 280 dpi lub mniej na małych/normalnych ekranach
  • mdpi lub niższym na dużych ekranach.
  • ldpi lub niższą na bardzo dużych ekranach.
 424 MB 704 MB
  • xhdpi lub wyższa na małych/normalnych ekranach
  • hdpi lub wyższa na dużych ekranach.
  • mdpi lub wyższa 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.

Implementacje urządzeń z mniej niż 512 MB pamięci dostępnej dla jądra i przestrzeni użytkownika, z wyjątkiem urządzeń Android Watch, MUSZĄ zwracać wartość „true” dla metody ActivityManager.isLowRamDevice().

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 użyciem współdzielonego magazynu zamontowanego domyślnie „out of the box”. Jeśli współdzielony magazyn nie jest zamontowany na ścieżce /sdcard w systemie Linux, urządzenie MUSI zawierać symboliczny link z katalogu /sdcard do rzeczywistego punktu montowania.

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:

  • MUSI zawierać wyskakujące powiadomienie lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy nie ma karty SD.
  • MUSI zawierać kartę SD w formacie FAT o pojemności co najmniej 1 GB LUB musi być na niej informacja w opakowaniu i innych materiałach dostępnych w momencie zakupu, że karta SD musi być kupiona osobno.
  • MUSI domyślnie zamontować kartę SD.

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 na urządzeniu korzysta z wewnętrznego (nieusuwalny) pamięci masowej, aby spełnić wymagania dotyczące współdzielonej pamięci masowej, a ta pamięć MOŻE współdzielić miejsce z poufnymi danymi aplikacji, musi mieć rozmiar co najmniej 1 GB i być zamontowana w katalogu /sdcard (lub /sdcard MUSI być symboliczną lokalizacją w przypadku 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 współdzielonej pamięci (np. gniazdo karty SD i współdzielona pamięć wewnętrzna), MUSZĄ zezwalać tylko wstępnie zainstalowanym i uprzywilejowanym aplikacjom na Androida z uprawnieniem WRITE_EXTERNAL_STORAGE na zapisywanie danych w drugim miejscu zewnętrznej pamięci, z wyjątkiem sytuacji, gdy zapisywanie odbywa się w katalogach dotyczących pakietu lub w ramach URI zwróconych przez wywołanie inencji ACTION_OPEN_DOCUMENT_TREE.

Implementacje urządzeń powinny jednak udostępniać treści z obu ścieżek pamięci w przezroczysty sposób za pomocą usługi skanera multimediów w Androidzie i android.provider.MediaStore.

Niezależnie od formy używanego współdzielonego miejsca na dane, jeśli implementacja urządzenia ma port USB z obsługą trybu urządzenia peryferyjnego USB, MUSI ona zapewniać jakiś mechanizm dostępu do zawartości współdzielonego miejsca na dane z komputera hosta. Implementacje urządzeń mogą używać pamięci masowej USB, ale powinny używać protokołu Media Transfer Protocol, aby spełnić ten wymóg. Jeśli implementacja urządzenia obsługuje protokół Media Transfer Protocol:

  • POWINIEN być zgodny z hostem MTP na Androidzie, czyli aplikacją Android File Transfer [Resources, 96].
  • NALEŻY podać klasę urządzenia USB 0x00.
  • Powinien zwracać nazwę interfejsu USB „MTP”.

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 [Resources, 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żyć 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 umożliwiającymi podłączenie do portu USB typu A lub C.
  • Zaleca się zaimplementowanie klasy USB audio zgodnie z dokumentacją pakietu Android SDK [Zasoby, 98].
  • Musisz zaimplementować interfejs API hosta USB Androida zgodnie z dokumentacją do pakietu Android SDK. Musisz też 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

Implementacje na urządzeniach przenośnych, zegarkach i w samochodach z Androidem MUSZĄ zawierać 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:

  • MUSI raportować stałą funkcję android.hardware.audio.output.
  • MUSI spełniać wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5.
  • Muszą być spełnione wymagania dotyczące opóźnienia dźwięku 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 zestawach słuchawkowych stereo z mikrofonem.
  • MUSI obsługiwać wtyczki audio TRRS z kolejnością styków CTIA i POWINIEN obsługiwać wtyczki audio z kolejnością styków OMTP.
  • Jeśli implementacja urządzenia obsługuje mikrofon, MUSI obsługiwać wykrywanie mikrofonu na podłączonym akcesorium audio i nadawać android.intent.action.HEADSET_PLUG z wartością dodatkową mikrofonu ustawioną na 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 wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów w gniazdku.
  • 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 systemem Android Watch powinny spełniać te kryteria, a inne typy implementacji urządzeń muszą je spełniać:

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ły czas opóźnienia klatek. Niespójny czas oczekiwania na wyświetlenie 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 raz na sekundę.
  • Opóźnienia w interfejsie użytkownika. Implementacje na urządzeniach MUSZĄ zapewniać użytkownikom niskie opóźnienia podczas przewijania listy zawierającej 10 tys. pozycji, zgodnie z definicją w pakiecie testów zgodności Androida (CTS) w mniej niż 36 sekund.
  • Przełączanie zadań. Gdy uruchomionych jest kilka 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 pamięci wewnętrznej w przypadku operacji odczytu i zapisu.

  • Sekwencyjny zapis. Implementacje urządzeń MUSZĄ zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 5 MB/s w przypadku pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
  • Losowe zapisywanie. Implementacje urządzeń MUSZĄ zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s w przypadku pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
  • Czytanie sekwencyjne. Implementacje urządzeń MUSZĄ zapewniać wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s w przypadku pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 10 MB.
  • Losowe czytanie. Implementacje urządzeń MUSZĄ zapewniać wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s w przypadku 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.

Alternatywnym środowiskom wykonawczym NIE MOŻNA przyznawać dostępu do zasobów chronionych przez uprawnienia, których nie zażądano w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

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 zainstalowane aplikacje korzystające z alternatywnego środowiska wykonawczego NIE MOGĄ 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 przyznawać takich uprawnień innym aplikacjom. Nie może też przyznawać innym aplikacjom żadnych uprawnień ani nie może ich otrzymywać od innych aplikacji.

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 stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Zasady zabezpieczeń i uprawnienia w interfejsach API [Resources, 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 używają wymiennych nośników dla interfejsów API do podstawowej pamięci zewnętrznej, MUSZĄ szyfrować zawartość karty SD, jeśli włączono tryb wieloużytkownika, za pomocą klucza przechowywanego tylko na nośniku niewymiennym, dostępnym tylko dla systemu. Ponieważ w takim przypadku media 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

Piaskownica Androida zawiera funkcje, które mogą korzystać z systemu kontroli dostępu (MAC) Security-Enhanced Linux (SELinux) i innych funkcji zabezpieczeń w rdzeniu systemu Linux. SELinux lub inne funkcje zabezpieczeń, jeśli są zaimplementowane w ramach Androida:

  • MUSI być zgodna z dotychczasowymi aplikacjami.
  • Nie może być widoczny interfejs użytkownika, gdy wykryto i pomyślnie zablokowano naruszenie zabezpieczeń, ale może być widoczny interfejs użytkownika, gdy nie zablokowane naruszenie zabezpieczeń powoduje skuteczne wykorzystanie luki.
  • NIE powinny być konfigurowalne przez użytkownika ani dewelopera.

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 równoważny system obowiązkowego kontroli dostępu, jeśli używają jądra innego niż Linux, oraz spełniać te wymagania, które są spełnione przez implementację referencyjną w górnym projekcie Android Open Source.

Implementacje na urządzeniu:

  • MUSI obsługiwać zasadę SELinux, która umożliwia ustawienie trybu SELinux dla poszczególnych domen, oraz MUSI skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie dozwolonym, w tym domeny związane z urządzeniem lub dostawcą.
  • NALEŻY wczytać zasady z pliku /sepolicy na urządzeniu.
  • Nie wolno modyfikować, pomijać ani zastępować reguł neverallow obecnych w pliku sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Zasady muszą być kompilowane ze wszystkimi regułami neverallow, zarówno w domenach AOSP SELinux, jak i w domenach konkretnych urządzeń/producentów.
  • MUSI obsługiwać dynamiczne aktualizacje pliku zasad SELinux bez konieczności aktualizacji obrazu systemu.

Implementacje urządzeń powinny zachować domyślną politykę SELinux udostępnioną w upstreamowym projekcie Android Open Source do czasu, aż zostaną zweryfikowane ich dodatki do polityki SELinux. 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.

Jeśli implementacja urządzenia zawiera mechanizm, który domyślnie kieruje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. w ramach wstępnego wczytania usługi VPN z uprawnieniami android.permission.CONTROL_VPN), przed włączeniem tego mechanizmu implementacja urządzenia MUSI poprosić użytkownika o zgodę.

9.9. Szyfrowanie całego dysku

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

Jeśli implementacja urządzenia obsługuje ekran blokady z PIN-em (numerycznym) lub HASŁEM (alfanumerycznym), urządzenie MUSI obsługiwać szyfrowanie całego dysku danych prywatnych aplikacji (partycji /data), a także partycji karty SD, jeśli jest to stała, nieusuwalna część urządzenia (Resources, 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

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacja urządzenia obsługuje tę funkcję, MUSI:

  • Zadeklaruj flagę funkcji platformy android.software.verified_boot
  • Przeprowadzanie weryfikacji w ramach każdego ciągu uruchamiania
  • Rozpocznij weryfikację od klucza sprzętowego, który jest źródłem zaufania, i przejdź aż do partycji systemowej.
  • Zaimplementuj każdy etap weryfikacji, aby sprawdzić integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na następnym etapie.
  • Używaj algorytmów weryfikacji o tak silnej sile jak to zalecają aktualne zalecenia NIST dotyczące algorytmów haszowania (SHA-256) i kluczy publicznych (RSA-2048).

Implementacje urządzeń powinny obsługiwać uruchamianie w trybie zweryfikowanym w celu zapewnienia integralności urządzenia. Chociaż w tej wersji platformy Android wymagane jest spełnienie tego wymogu, zdecydowanie zalecamy spełnienie go, ponieważ w przyszłych wersjach Androida stanie się ono obowiązkowe. Projekt upstream Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-verity jądra 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.1 może być wydanych 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 wykonywać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchomienie 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:

  • „Over-the-air (OTA)” pobieranie z aktualizacją offline przez ponowne uruchomienie
  • Aktualizacje przez USB z komputera-gospodarza
  • Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na nośniku wymiennym

Jeśli jednak implementacja urządzenia obejmuje obsługę nielimitowanego połączenia danych, takiego jak profil 802.11 lub profil PAN (sieć osobista) Bluetooth:

  • Implementacje Androida Automotive powinny obsługiwać pobieranie OTA z aktualizacją offline przez ponowne uruchamianie.
  • Wszystkie inne implementacje urządzeń MUSZĄ obsługiwać pobieranie OTA z aktualizacją offline przez ponowne uruchamianie.

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.1 lub nowszego, MECHANIZM AKTUALIZACJI POWINIEN obsługiwać weryfikację, czy obraz systemu jest identyczny z oczekiwanym po aktualizacji OTA. Wersja OTA oparta na blokach w upstreamowym projekcie Android Open Source, dodana w Androidzie 5.1, 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.

Sekcja Podsumowanie zmiany
2. Typy urządzeń Dodano definicję implementacji Androida Automotive.
2.1 Konfiguracje urządzenia Dodano kolumnę dla implementacji Androida Automotive.
3.3.2. Zgodność z 32-bitowym kodem natywnym ARM Dodano nową sekcję.
3.4.1. Zgodność WebView Zaktualizowaliśmy wymagania dotyczące ciągu znaków klienta użytkownika webview, aby uwzględnić zmiany w implementacji upstream.
3.4.2. Zgodność z przeglądarką Dodano implementacje Androida w samochodach jako kolejny przypadek, w którym MOŻNA pominąć aplikację przeglądarki.
3.7. Zgodność w czasie działania Zaktualizowano wymagany rozmiar stosu w czasie działania na potrzeby mniejszych ekranów i dodano wymagania dotyczące nowego zbiornika dpi (280 dpi).
3.8.3. Powiadomienia Wyjaśnienie wymagań dotyczących powiadomień w przypadku implementacji na zegarki, telewizory i systemy Android Automotive.
3.8.8. Przełączanie aktywności Zmniejsz wymaganą liczbę tytułów w sekcji Informacje.
3.8.10. Sterowanie multimediami na ekranie blokady Wyjaśnienie wymagań dotyczących implementacji na zegarek i system Android Automotive.
3.8.13. Unicode i czcionka Zmniejszone wymagania dotyczące metody wprowadzania emotikonów.
3.9. Administracja urządzeniem Uściślone warunki, w których przypadku musi być obsługiwany pełny zakres zasad administracji urządzenia.
3.10. Ułatwienia dostępu Dodano wymagania dotyczące Androida Automotive.
3.11. Tekst na mowę Dodano wymagania dotyczące Androida Automotive.
5.1. Kodeki multimedialne Wymagane dekodowanie kodeków zgłoszonych przez CamcorderProfile.
5.1.3 Kodeki wideo Dodano wymagania dotyczące Androida Automotive.
5.4. Nagrywanie dźwięku Doprecyzowaliśmy język na początku sekcji, aby wymagania oznaczone jako „MUST” były odczytywane jako „REQUIRED”.
7.1.1.3. Gęstość ekranu Dodano nową rozdzielczość ekranu (280 dpi).
7.1.5. Tryb zgodności ze starszymi wersjami aplikacji Dodano wymagania dotyczące Androida Automotive.
7.2 Urządzenia wejściowe Dodano ogólne wprowadzenie.
7.2.1. Klawiatura Dodano wymagania dotyczące Androida Automotive.
7.2.3. Klawisze nawigacyjne Dodano wymagania dotyczące Androida Automotive.
7.3.1. Akcelerometr Zmniejszenie wymagań dotyczących częstotliwości raportowania na zegarku z Androidem.
7.3.4. Żyroskop Zmniejszenie wymagań dotyczących częstotliwości raportowania na zegarku z Androidem.
7.4.3 Bluetooth Dodano wymagania dotyczące Androida Automotive.
7.4.4. Komunikacja Near Field Communication Uściślone warunki, w których emulacja hosta karty jest wymagana.
7.6.1. Minimalna ilość pamięci i miejsca na dane Zaktualizowano minimalne wymagania dotyczące pamięci dla urządzeń z ekranem o niższej rozdzielczości i dodano wymaganie twardego limitu isLowRamDevice().
7.6.2. Pamięć współdzielona aplikacji Aktualizacja wymagań, gdy wymagane jest wsparcie dostępu do hosta.
7.7 USB Naprawianie literówek w sekcji USB
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.6.2. Pamięć współdzielona aplikacji Aplikacje mogą używać ACTION_OPEN_DOCUMENT_TREE do zapisywania danych w pamięci zewnętrznej.
7.6.2. Pamięć współdzielona aplikacji Wyjaśnienie, że /sdcard może udostępniać pamięć z katalogiem /data
7.7 USB Usuń zbędny wymóg dotyczący UMS/MTP z wersji 7.7
7.8.1. mikrofon Dodano wymagania dotyczące Androida Automotive.
8.2. Wydajność dostępu do plikowego wejścia/wyjścia Wyjaśnione wymagania.
9,5. Pomoc dla wielu użytkowników Szyfrowanie karty SD jest wymagane w przypadku głównej pamięci zewnętrznej.
9,8. Prywatność Dodano wymóg dotyczący prywatności w przypadku wstępnie zainstalowanych sieci VPN.
9.9. Szyfrowanie całego dysku Uściślone warunki, w których przypadku wymagane jest szyfrowanie całego dysku.
9.10. Weryfikacja podczas uruchamiania Uściślone zostało wyjaśnienie definicji weryfikacji podczas uruchamiania.
11. Oprogramowanie z możliwością aktualizacji Wyjaśnienie, że w przypadku implementacji Androida Automotive wymagane jest pobieranie OTA, ale nie jest to wymagane.

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.1: http://source.android.com/compatibility/5.1/versions.html

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://html.spec.whatwg.org/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/tools/help/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: /devices/input/diagnostics.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/devices/tech/input/touch-devices.html

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 Androida: http://source.android.com/devices/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. Otwarte czujniki mieszane Androida: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Tryb ciągłego aktywowania: /docs/core/interaction/sensors/report-modes#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/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://members.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ługiwane wersje aparatu: http://source.android.com/devices/camera/versioning.html

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/connectivity/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 przez USB: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

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

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

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 na Androidzie o otwartym kodzie źródłowym: http://source.android.com/docs/security/features/encryption

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/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Interfejs API MediaCodecList na Androida: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Interfejs API Androida CamcorderProfile: http://developer.android.com/reference/android/media/CamcorderProfile.html

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida SDK i pod względem funkcjonalności jest identycznych 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.