Definicja zgodności z Androidem 6.0

Spis treści

1. Wprowadzenie

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

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 „implementator urządzenia” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z Androidem 6.0. „Wdrożenie urządzenia” lub „wdrożeniem” jest rozwiązanie sprzętowo-programowe.

Aby można było uznać urządzenie za zgodne z Androidem 6.0, jego implementacja MUSI spełniać wymagania podane w tej definicji zgodności, w tym wszystkie dokumenty uwzględnione w ramach odwołania.

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. IMPLEMENTATOROM URZĄDZEŃ MOCNO POLECAMY, aby w jak największym stopniu opierali swoje implementacje na kodzie źródłowym „upstream” dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić innymi implementacjami, ZDECYTOWANIE zalecamy, aby nie stosować tej praktyki, ponieważ przejście testów oprogramowania stanie się 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:

  • Musisz zadeklarować funkcję android.hardware.type.automotive.
  • MUSI obsługiwać uiMode = UI_MODE_TYPE_CAR [Resources, 5].

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

2.1 Konfiguracje urządzenia

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

Kategoria 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 POWINIEN SHOULD
Łączność Wi-Fi 7.4.2. IEEE 802.11 SHOULD MUST POWINIEN 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 POWINIEN 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 Android SDK [Resources, 6] lub dowolnego interfejsu API oznaczonego znacznikiem „@SystemApi” w kodze ź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 referencyjnej Uprawnienia [Zasoby, 7]. 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 [Resources, 8], które służą do opisywania bieżącego urządzenia. 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, 9].
WERSJ.SDK Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 6.0 to pole MUSI zawierać wartość całkowitą 23.
VERSION.SDK_INT Wersja aktualnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 6.0 to pole MUSI zawierać wartość całkowitą 23.
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:6.0/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 i niepowtarzalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. 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 („"”).
SECURITY_PATCH Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi ono wskazywać, że kompilacja zawiera wszystkie poprawki zabezpieczeń opublikowane w ramach wyznaczonego publicznego komunikatu bezpieczeństwa Androida. Musi mieć format [RRRR-MM-DD], który odpowiada jednemu z łańcuchów znaków z  publicznych biuletynów zabezpieczeń Androida dotyczących poziomu zabezpieczeń, na przykład „2015-11-01”.
BASE_OS Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z kompilacją z wyjątkiem poprawek dostarczonych w publicznym biuletynie o zabezpieczeniach Androida. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, należy zwrócić pusty ciąg 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. Rozwiązywanie intencji

Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ umożliwiać zastąpienie każdego wzorca intencji, do którego odwołuje się sekcja 3.2.3.1, przez aplikacje innych firm. 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 na urządzeniu MUSZĄ zawierać interfejs użytkownika umożliwiający modyfikowanie domyślnej aktywności dla intencji.

Implementacje urządzeń mogą jednak udostępniać domyślne aktywności w przypadku określonych wzorów URI (np. http://play.google.com), gdy domyślna aktywność udostępnia bardziej szczegółowy atrybut dla URI danych. Na przykład wzór filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzór intencji przeglądarki „http://”.

Android zawiera też mechanizm umożliwiający aplikacjom innych firm deklarowanie wiarygodnego domyślnego zachowania w przypadku linkowania aplikacji w przypadku niektórych typów intencji identyfikatora URI sieci Web [Resources, 140]. Gdy takie deklaracje autorytatywne są zdefiniowane w wzorach filtrów intencji aplikacji, implementacje na urządzeniu:

  • NALEŻY spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji Digital Asset Links [Zasoby, 141] wdrożone przez menedżera pakietów w górnym projekcie Android Open Source.
  • W trakcie instalacji aplikacji MUSISZ spróbować zweryfikować filtry intencji UIR i ustawić wszystkie zweryfikowane filtry intencji UIR jako domyślne moduły obsługi aplikacji dla ich identyfikatorów UIR.
  • MOŻE ustawić określone filtry intencji URI jako domyślne moduły obsługi aplikacji dla swoich identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne potencjalne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia wykonuje tę funkcję, MUSI udostępnić użytkownikowi odpowiednie zastąpienia wzorców dla poszczególnych adresów URI w menu ustawień.
  • Musisz udostępnić użytkownikowi ustawienia linków do aplikacji w ustawieniach aplikacji w ten sposób:
    • Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby aplikacja: zawsze otwierała się, zawsze pytała lub nigdy się nie otwierała. Musi to dotyczyć wszystkich docelowych filtrów identyfikatorów URI.
    • Użytkownik MUSI mieć możliwość wyświetlenia listy docelowych filtrów intencji URI.
    • Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie konkretnych docelowych filtrów intencji URI, które zostały zweryfikowane, na podstawie poszczególnych filtrów intencji.
    • Implementacja na urządzeniu MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych docelowych filtrów URI, jeśli implementacja na urządzeniu pozwala na weryfikację niektórych docelowych filtrów URI, a nie innych.

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ć wywołanie android.settings.HOME_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji na ekranie głównym, jeśli implementacja urządzenia zgłasza android.software.home_screen [Resources, 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, 11]
  • MUSI obsługiwać intent android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić domyślne menu ustawień aplikacji do obsługi funkcji Tap and Pay, 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 ABI, które są udokumentowane i opisane w najnowszej wersji dokumentacji Android NDK ABI Management [Resources, 12], a także NALEŻY uwzględnić obsługę rozszerzenia Advanced SIMD (a.k.a. NEON) [Resources, 13].
  • 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, 14], 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.

Implementacje na urządzeniu, jeśli zawierają natywną bibliotekę o nazwie libvulkan.so, MUSZĄ eksportować symbole funkcji i zapewnić implementację interfejsu Vulkan 1.0 API oraz rozszerzeń VK_KHR_surface, VK_KHR_swapchain i VK_KHR_android_surface zgodnie z definicją Khronos Group i przejść testy zgodności Khronos.

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego MOCNO zaleca się implementatorom 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 korzysta z kodu z projektu Chromium do implementacji android.webkit.WebView [Resources, 15]. 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 6.0. Ta wersja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView [Resources, 16].
  • Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć format:

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

    • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.
    • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość parametru android.os.Build.MODEL.
    • Wartość ciągu $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID.
    • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w upstreamowym projekcie Android Open Source.
    • Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków Mobile.

Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5, a jeśli tak, to powinien być zgodny ze specyfikacją HTML5 [Resources, 17].

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 (opracowana na podstawie aplikacji przeglądarki WebKit lub zastępczej aplikacji innej firmy) POWINNA obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 17]. 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 w standardzie HTML5/W3C [Resources, 21] i POWINNY obsługiwać interfejs API IndexedDB w standardzie HTML5/W3C [Resources, 22]. 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 być zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich wyraźnie korzystają (za pomocą mechanizmu <uses-librarygt;), 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, 23]. 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
Android Watch 120 dpi (ldpi) 32 MB
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36 MB
280 dpi
320 dpi (xhdpi) 48 MB
360 dpi
400 dpi (400 dpi) 56 MB
420 dpi (420 dpi) 64 MB
480 dpi (xxhdpi) 88 MB
560 dpi (560 dpi) 112 MB
640 dpi (xxxhdpi) 154 MB
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
360 dpi
400 dpi (400 dpi) 96 MB
420 dpi (420 dpi) 112 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
360 dpi 160 MB
400 dpi (400 dpi) 192 MB
420 dpi (420 dpi) 228 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
360 dpi 240 MB
400 dpi (400 dpi) 288 MB
420 dpi (420 dpi) 336 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 końcowemu [Zasoby, 24]. Jest to funkcja, którą MOCNO POLECAMY uwzględnić w implementacjach na urządzeniach przenośnych. Implementacje urządzeń, które obsługują umieszczanie widżetów na ekranie głównym, MUSZĄ spełniać te wymagania i deklarować obsługę funkcji platformy android.software.app_widgets.

  • Aplikacje uruchamiające MUSZĄ zawierać wbudowane funkcje obsługi widżetów aplikacji i umożliwiać użytkownikom dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów bezpośrednio w aplikacji uruchamiającej.
  • Implementacje na urządzeniach MUSZĄ umożliwiać renderowanie widżetów o standardowym rozmiarze siatki 4 x 4. Szczegółowe informacje znajdziesz we wskazówkach dotyczących projektowania widżetów aplikacji w dokumentacji pakietu SDK Androida [Materiały dodatkowe, 24].
  • 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, 25] 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 w ramach implementacji MUSISZ poprawnie renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępnione w interfejsach API [Zasoby, 26] lub w przewodniku dotyczącym stylu ikonek na pasku stanu/systemowym [Zasoby, 27], który w przypadku urządzenia z Androidem 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 na urządzeniach 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ą w Android API [Resources, 28].

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, 29], które umożliwiają deweloperom dodanie wyszukiwarki do aplikacji oraz udostępnienie danych aplikacji w globalnej wyszukiwarce systemowej. 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.

Implementacje urządzeń z Androidem POWINNY implementować na urządzeniu asystenta, aby obsługiwać działanie asystenta [Resources, 30].

Android zawiera też interfejsy API do obsługi asystenta, które umożliwiają aplikacjom określenie, ile informacji o bieżącym kontekście ma być udostępnianych asystentowi na urządzeniu [Zasoby, 31]. Implementacje urządzeń obsługujące działanie Assist MUSZĄ wyraźnie wskazywać użytkownikowi, kiedy kontekst jest udostępniany, wyświetlając białe światło na krawędziach ekranu. Aby zapewnić użytkownikowi wyraźną widoczność, wskazanie MUSI odpowiadać lub przekraczać czas trwania i jasność implementacji projektu Android Open Source.

3.8.5. Toasty

Aplikacje mogą używać interfejsu Toast API, aby wyświetlać użytkownikowi krótkie niemodalne ciągi znaków, które znikają po krótkim czasie [Resources, 32]. 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 zgodnie z definicją w pakiecie Android SDK [Zasoby, 33]. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom [Zasoby, 34].

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ądzeniu MUSZĄ obsługiwać rodzinę motywów „Material” i NIE MOGĄ zmieniać żadnych atrybutów motywu Material ani zasobów udostępnianych aplikacjom [Zasoby, 35].

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

Android obsługuje wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom aplikacji wypełnić 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 na ikonach stanu systemu (takich jak siła sygnału i poziom naładowania baterii) oraz w powiadomieniach wysyłanych przez system, chyba że ikona wskazuje stan problemowy lub aplikacja prosi o jasny pasek stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Gdy aplikacja poprosi o jasny pasek stanu, implementacje urządzeń z Androidem MUSZĄ zmienić kolor ikon stanu systemu na czarny [Resources, 34].

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej 1 „żywego tapeta” [Zasoby, 36]. 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 poziomie upstream obejmuje ekran przeglądu [Resources, 37], 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 6 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, 38] 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 zalecamy używanie na ekranie przeglądu interfejsu Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie danymi wejściowymi oraz edytory metod wejściowych innych firm [Materiały dodatkowe, 39]. 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

Interfejs API klienta sterowania zdalnego jest wycofany w Androidzie 5.0 na rzecz szablonu powiadomienia o multimediach, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady [Zasoby, 40] jako powiadomienia na ekranie blokady. Implementacje na urządzeniu MUSZĄ poprawnie renderować szablon powiadomienia o multimediach w ramach powiadomień na ekranie blokady opisanych w sekcji 3.8.3.

3.8.11. Sny

Android obsługuje interaktywne wygaszacze ekranu o nazwie Dreams [Materiały, 41]. 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 przekazywać współrzędne lokalizacji, w menu Lokalizacja w Ustawieniach [Materiały, 42] muszą być wyświetlane tryby lokalizacji.

3.8.13. Unicode i czcionka

Android obsługuje kolorowe emotikony. Gdy implementacje urządzeń z Androidem obejmują metodę wprowadzania, urządzenia powinny udostępniać użytkownikowi metodę wprowadzania dla znaków emoji zdefiniowanych w Unicode 6.1 [Resources, 43]. 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 dbającym o bezpieczeństwo wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne wymazywanie danych, za pomocą interfejsu API administracji urządzenia z Androidem [Zasoby, 44]. Implementacje na urządzeniu MUSZĄ zawierać implementację klasy DevicePolicyManager [Resources, 45]. 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, 44] i zgłaszać funkcję platformy android.software.device_admin.

3.9.1 Obsługa administracyjna urządzenia

3.9.1.1 Obsługa administracyjna właściciela urządzenia

Jeśli implementacja urządzenia deklaruje funkcję android.software.device_admin, przepływ konfiguracji urządzenia musi umożliwiać rejestrowanie aplikacji kontrolera zasad dotyczących urządzeń (DPC) jako aplikacji właściciela urządzenia [ Zasoby, 46]. Implementacje urządzeń mogą mieć wstępnie zainstalowaną aplikację, która wykonuje funkcje administracyjne urządzenia, ale ta aplikacja NIE MOŻE być ustawiona jako aplikacja właściciela urządzenia bez wyraźnej zgody lub działania użytkownika lub administratora urządzenia.

Proces obsługi administracyjnej właściciela urządzenia (proces inicjowany przez android.app.action.PROVISION_MANAGED_DEVICE [ Resources, 47]) MUSI być zgodny z implementacją AOSP.

Jeśli implementacja urządzenia zgłasza android.hardware.nfc, NFC MUSI być włączony, nawet podczas konfiguracji urządzenia, aby umożliwić właścicielom urządzeń korzystanie z NFC [Zasoby, 48].

3.9.1.2 Zarządzanie profilem zarządzanym

Jeśli implementacja urządzenia deklaruje android.software.managed_users, musi być możliwe zarejestrowanie aplikacji kontrolera zasad dotyczących urządzeń (DPC) jako właściciela nowego profilu zarządzanego [ Zasoby, 49]

Proces obsługi administracyjnej profilu zarządzanego (przepływ danych inicjowany przez android.app.action.PROVISION_MANAGED_PROFILE [ Resources, 50]) MUSI być zgodny z implementacją AOSP.

3.9.2 Obsługa profilu zarządzanego

Urządzenia obsługujące profile zarządzane to urządzenia, które:

Urządzenia obsługujące profile zarządzane MUSZĄ:

  • Zadeklaruj flagę funkcji platformy android.software.managed_users.
  • Obsługa profili zarządzanych za pomocą interfejsów API android.app.admin.DevicePolicyManager
  • Zezwalanie na utworzenie tylko 1 profilu zarządzanego [Zasoby, 50]
  • Użyj plakietki ikony (podobnej do plakietki AOSP upstream work) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i Powiadomienia.
  • Wyświetlanie ikony powiadomienia (podobnej do plakietki AOSP upstream) w celu wskazania, że użytkownik jest w aplikacji w profilu zarządzanym
  • wyświetlać komunikat informujący, że użytkownik jest w profilu zarządzanym, gdy urządzenie się obudzi (ACTION_USER_PRESENT) i aplikacja na pierwszym planie znajduje się w profilu zarządzanym;
  • Jeśli istnieje profil zarządzany, wyświetl w oknie „Wybór intencji” wizualne elementy umożliwiające użytkownikowi przekierowanie intencji z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach kontrolera zasad urządzenia.
  • Jeśli istnieje profil zarządzany, wyświetl te opcje dla użytkownika głównego i zarządzanego profilu:
    • oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i użytkowania pamięci w przypadku głównego użytkownika i profilu zarządzanego.
    • niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównego użytkownika lub profilu zarządzanym.
    • niezależne zarządzanie aplikacjami zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
    • niezależne zarządzanie kontami w ramach profilu głównego użytkownika lub profilu zarządzanego,
  • Upewnij się, że domyślna aplikacja do wybierania numerów może wyszukiwać informacje o dzwoniącym z zarządzanego profilu (jeśli taki istnieje) obok informacji z profilu głównego, jeśli zezwala na to kontroler zasad urządzenia.
  • MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń dla urządzenia z możliwością korzystania przez wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako dodatkowy użytkownik oprócz głównego użytkownika.

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ń związanych z użytkownikiem i systemem oraz generowanie alternatywnych mechanizmów sprzężenia zwrotnego, takich jak konwersja tekstu na mowę, sprzężenie zwrotne haptyczne i sterowanie za pomocą kulki sterującej lub panelu dotykowego [Resources, 51].

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ądzeniu (z wyjątkiem Androida Automotive) MUSZĄ obsługiwać implementacje usług ułatwień dostępu innych firm za pomocą interfejsów API android.accessibilityservice. [Resources, 52]
  • 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, 53].

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, 54]. 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ć interfejs TV Input Framework [Zasoby, 55].

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

3.12.1. Aplikacja TV

W przypadku każdej implementacji urządzenia, która deklaruje obsługę aplikacji Live TV, MUSI być zainstalowana aplikacja telewizyjna (aplikacja TV). Projekt Android Open Source udostępnia implementację aplikacji TV.

Domyślna aplikacja telewizyjna musi zapewniać dostęp do kanałów z zainstalowanych i zewnętrznych źródeł sygnału. Pamiętaj, że zainstalowane dane wejściowe obejmują wszystkie dane wejściowe podane domyślnie, niezależnie od tego, czy są one oparte na TIF, czy nie.

Aplikacja TV MUSI udostępniać funkcje umożliwiające instalowanie i używanie kanałów TV [Resources, 56] oraz spełniać te wymagania:

  • Implementacje urządzeń MUSZĄ umożliwiać instalowanie i zarządzanie zewnętrznymi danymi wejściowymi na podstawie TIF (zewnętrzne dane wejściowe) [Resources, 57].
  • Implementacje urządzeń MOGĄ zapewniać wizualne oddzielenie wstępnie zainstalowanych danych wejściowych na podstawie TIF (zainstalowanych danych wejściowych) [Zasoby, 58] od danych wejściowych pochodzących od innych firm.
  • Implementacje urządzeń NIE MOGĄ wyświetlać danych wejściowych innych firm w odległości większej niż jedno działanie nawigacyjne od aplikacji na telewizor (np. rozwinięcie listy danych wejściowych innych firm z aplikacji na telewizor).

3.12.1.1. Elektroniczny przewodnik po programach

Implementacje urządzeń z Androidem TV MUSZĄ wyświetlać nakładkę informacyjną i interaktywną, która MUSI zawierać elektroniczny przewodnik po programach (EPG) wygenerowany na podstawie wartości w polach TvContract.Programs [Zasoby, 59]. EPG musi spełniać te wymagania:

  • EPG MUSI wyświetlać informacje ze wszystkich zainstalowanych wejść i wejść innych firm.
  • EPG MOŻE zapewnić wizualne oddzielenie zainstalowanych wejść od wejść zewnętrznych.
  • W przypadku EPG MOCNO POLECAMY wyświetlanie zainstalowanych wejść i wejść zewnętrznych z równą widocznością. EPG NIE MOŻE wyświetlać wejść innych firm, które są oddalone o więcej niż jedno działanie nawigacyjne od zainstalowanych wejść w EPG.
  • Gdy użytkownik zmienia kanał, implementacje urządzeń MUSZĄ wyświetlić dane EPG dotyczące aktualnie odtwarzanego programu.

3.12.1.2. Nawigacja

Urządzenia wejściowe (np. pilot, aplikacja do sterowania pilotem lub kontroler do gier) na urządzeniu z Androidem TV MUSZĄ umożliwiać poruszanie się po wszystkich aktywnych sekcjach ekranu za pomocą pada kierunkowego. Aby zmienić kanały telewizji na żywo, gdy na ekranie nie ma żadnej sekcji, w której można wykonać działanie, NALEŻY UŻYWAĆ przycisków w górę i w dół na panelu sterującym.

Aplikacja na telewizorze powinna przekazywać kluczowe zdarzenia do wejść HDMI przez CEC.

3.12.1.3. Łączenie aplikacji z wejściem TV

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać łączenie aplikacji z wejściami telewizyjnymi, co pozwala na tworzenie linków do bieżącej aktywności w innej aktywności (np. link do programu na żywo do powiązanych treści) [Resources, 60]. Aplikacja TV MUSI wyświetlać link do aplikacji z wejściami TV, jeśli jest on dostępny.

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

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 62], manifestu Androida [Zasoby, 49], kodu bajtowego Dalvik [Zasoby, 23] 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 Android SDK [Resources, 64], z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tym dokumencie. W szczególności implementacje na urządzeniu MUSZĄ obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w tabelach poniżej i zgłaszane za pomocą MediaCodecList [Resources, 65]. Implementacje na urządzeniach MUSZĄ być również w stanie dekodować wszystkie profile zgłoszone w urządzeniu CamcorderProfile [Resources, 66] oraz MUSZĄ być w stanie dekodować wszystkie formaty, które mogą kodować. 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
MPEG-4 Profile 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
Profile (enhanced 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 częstotliwością próbkowania 16 kHz
FLAC WYMAGANE
(Android 3.1 lub nowszy)		 Mono/Stereo (bez kanałów dodatkowych). Częstotliwości próbkowania do 48 kHz (ale zalecane są częstotliwości do 44,1 kHz na urządzeniach z wyjściami 44,1 kHz, ponieważ próbkowanie w dół z 48 na 44,1 kHz nie obejmuje filtra dolnoprzepustowego). ZALECANA głębia 16-bitowa. W przypadku 24-bitów nie jest stosowany dithering. 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

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-2 TS (.ts, tylko dźwięk AAC, brak możliwości przeskakiwania, Android 3.0 lub nowszy)
H.265 HEVC WYMAGANE5 Więcej informacji znajdziesz w sekcji 5.3. MPEG-4 (.mp4)
MPEG-2 ZDECYDOWANIE ZALECANE6 Profil główny MPEG2-TS
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) [Materiały, 67
  • 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) [Zasoby, 67]
  • 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 i usług wideokonferencji, implementacje urządzeń powinny używać sprzętowego kodeka VP8, który spełnia wymagania podane w [Zasobach, 68].

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

5 ZALECANA w przypadku Androida Automotive, opcjonalna w przypadku zegarka z Androidem i wymagana w przypadku wszystkich innych typów urządzeń.

6 Dotyczy tylko implementacji na urządzeniach z Androidem TV.

5.2. Kodowanie wideo

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

Implementacje urządzeń z Androidem z koderimi H.263 MUSZĄ obsługiwać podstawowy profil poziomu 45.

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). Zalecamy używanie urządzeń Android TV do kodowania 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 i częstotliwości klatek w ramach tego samego strumienia za pomocą standardowych interfejsów API Androida dla wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym oraz do maksymalnej rozdzielczości obsługiwanej przez każdy z tych kodeków na urządzeniu.

Implementacje urządzeń z Androidem i dekoderami H.263 MUSZĄ obsługiwać poziom profilu Baseline 30.

Implementacje urządzeń z Androidem z dekoderami MPEG-4 MUSZĄ obsługiwać profil Simple na poziomie 3.

Implementacje urządzeń z Androidem z dekoderami H.264 MUSZĄ obsługiwać profil główny poziomu 3.1 oraz następujące profile dekodowania filmów SD. POWINNY one obsługiwać profile dekodowania filmów 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 60 kl./s 30 fps / 60 fps2
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 8 Mb/s 20 Mb/s

1 WYMAGANE, gdy wysokość podana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu.

2 WYMAGANE 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, gdy wysokość podana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu.

2 WYMAGANE 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 wideo UHD jest obsługiwany, MUSI obsługiwać 8-bitową głębię kolorów i POWINIEN obsługiwać profil VP9 2 (10-bitowy).

SD (niska jakość) SD (wysoka jakość) HD 720p1 HD 1080p2 UHD2
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 60 kl./s 60 kl./s
Szybkość transmisji wideo 600 Kb/s 1,6 Mb/s 4 Mb/s 5 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 istniejących implementacji urządzeń z Androidem TV, jeśli są one 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. Zalecamy, aby urządzenia z Androidem TV obsługiwały profil dekodowania UHD i profil dekodowania HD 1080p. Jeśli profil dekodowania HD 1080p jest obsługiwany, MUSI obsługiwać poziom główny profilu głównego 4.1. Jeśli dekodowanie UHD jest obsługiwane, urządzenie MUSI obsługiwać profil Main10 poziomu 5 poziomu głównego.

SD (niska jakość) SD (wysoka jakość) HD 720p1 HD 1080p2 UHD2
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 60 kl./s2 60 kl./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 dotychczasowych implementacji na urządzeniach z Androidem TV, jeśli są one 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”. Właścicielom istniejących i nowych urządzeń z Androidem ZALECAMY spełnienie tych wymagań, ponieważ w przeciwnym razie nie będą oni mogli korzystać z Androida po przejściu na nową wersję.

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

Przechwytywanie przy powyższych częstotliwościach próbkowania MUSI odbywać się bez interpolacji, a każde próbkowanie w dół MUSI zawierać odpowiedni filtr antyaliasingowy.

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

Jeśli nagrywanie przy użyciu powyższych współczynników próbkowania jest obsługiwane, to nagrywanie MUSI być wykonywane bez próbkowania w górę przy dowolnym współczynniku wyższym niż 16000:22050 lub 44100:48000. Każde próbkowanie w górę lub w dół MUSI obejmować odpowiedni filtr antyaliasingu.

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 poziomu wejściowego na mikrofonie.
  • 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, 69]. 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 jeden okres buforowania. Okres bufora pozwala aplikacji na przetworzenie danych i zminimalizowanie różnicy fazy między strumieniami wejściowym i wyjściowym.
  • 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.

W przypadku implementacji urządzeń, które deklarują interfejs android.hardware.audio.output, MOCNO zaleca się spełnienie lub przekroczenie tych wymagań dotyczących wyjścia audio:

  • 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 buforów OpenSL ES PCM w przypadku opóźnienia ciągłego wyjścia i opóźnienia zimnego wyjścia na co najmniej 1 obsługiwanym urządzeniu z wyjściami audio, zdecydowanie zalecamy zgłoszenie obsługi dźwięku o niskiej latencji. Aby to zrobić, użyj funkcji android.hardware.audio.low_latency za pomocą klasy android.content.pm.PackageManager [Resources, 70]. Jeśli implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku o małej latencji.

W przypadku implementacji urządzeń, które zawierają android.hardware.microphone, MOCNO zaleca się spełnienie tych wymagań dotyczących dźwięku wejściowego:

  • 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 SDK Androida [Resources, 64]. 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) Live Streaming, wersja 3 [Resources, 71]

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.

5.9. MusicaI Instrument Digital Interface (MIDI)

Jeśli implementacja urządzenia obsługuje przesyłanie danych MIDI między aplikacjami (wirtualne urządzenia MIDI) i obsługuje MIDI przez wszystkie te urządzenia sprzętowe obsługujące MIDI, dla których zapewnia ogólne połączenia niebędące MIDI, to BARDZO ZALECAMY zgłoszenie obsługi funkcji android.software.midi za pomocą klasy android.content.pm.PackageManager [Resources, 70].

Urządzenia MIDI:

  • Tryb hosta USB (sekcja 7.7 USB)
  • Tryb urządzenia peryferyjnego USB (sekcja 7.7 USB)

Jeśli implementacja urządzenia zapewnia ogólne połączenie niebędące połączeniem MIDI za pomocą określonego wyżej sprzętowego interfejsu MIDI, ale nie obsługuje MIDI za pomocą tego sprzętowego interfejsu, to NIE MOŻE zgłaszać obsługi funkcji android.software.midi.

MIDI przez Bluetooth LE w roli centralnej (sekcja 7.4.3 Bluetooth) jest w stanie próbnym. Implementacja urządzenia, która zgłasza funkcję android.software.midi i zapewnia ogólne połączenie niebędące połączeniem MIDI przez Bluetooth LE, POWINNA obsługiwać MIDI przez Bluetooth LE.

5.10. Profesjonalny dźwięk

Jeśli implementacja urządzenia spełnia wszystkie wymagania wymienione poniżej, zdecydowanie zalecamy zgłoszenie obsługi funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager [Resources, 70].

  • Implementacja urządzenia MUSI zgłaszać obsługę funkcji android.hardware.audio.low_latency.
  • Ciągłe opóźnienie sygnału audio w obie strony, zgodnie z definicją w sekcji 5.6 Opóźnienie sygnału audio, MUSI wynosić 20 ms lub mniej i POWINNA wynosić 10 ms lub mniej na co najmniej jednej obsługiwanej ścieżce.
  • Jeśli urządzenie ma 4-żyłowe gniazdo słuchawek 3,5 mm, ciągłe opóźnienie dźwięku w obie strony MUSI wynosić 20 ms lub mniej na ścieżce gniazda słuchawek, a POWINNA wynosić 10 ms lub mniej na ścieżce gniazda słuchawek.
  • Implementacja urządzenia MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
  • Tryb hosta USB MUSI implementować klasę dźwięku USB.
  • Jeśli urządzenie ma port HDMI, jego implementacja MUSI obsługiwać wyjście stereo i 8 kanałów w głębi 20- lub 24-bitowej oraz 192 kHz bez utraty głębi bitowej lub próbkowania.
  • Implementacja urządzenia MUSI zgłaszać obsługę funkcji android.software.midi.
  • Jeśli urządzenie ma 4-żyłowe gniazdo słuchawek 3,5 mm, zalecamy, aby jego implementacja była zgodna z sekcją Specyfikacja urządzenia mobilnego (gniazdo) specyfikacji przewodowego zestawu słuchawkowego (wersja 1.1).

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, 73]. 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 10 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 [Zasoby, 77]. 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, 70]

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, 78]. 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 [Zasoby, 78] i określonym przez platformę źródłową Androida. 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)
  • 360 dpi
  • 400 dpi (400 dpi)
  • 420 dpi (420 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Ą zgłaszać prawidłowe wartości wszystkich danych dotyczących wyświetlacza zdefiniowanych w android.util.DisplayMetrics [Resources, 79] i MUSZĄ zgłaszać 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, 80].

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, 81] oraz natywną 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ć przyspieszenie sprzętowe grafiki 2D na poziomie aplikacji, czynności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API [Zasoby, 82].

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

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

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 pakietu Android SDK [Zasoby, 84].

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 należy dołączać klawiatury sprzętowej, która nie odpowiada żadnemu z formatów określonych w android.content.res.Configuration.keyboard [Resources, 85] (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 raportować prawidłową wartość android.content.res.Configuration.navigation[Resources, 85].
  • 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 urządzenia z Androidem 6.0 i nowszym NIE MOGĄ mieć dedykowanego przycisku fizycznego do funkcji menu. Starsze implementacje na urządzeniach NIE powinny zawierać dedykowanego fizycznego przycisku menu. Jeśli jednak taki przycisk jest zaimplementowany, a na urządzeniu działają aplikacje z wartością targetSdkVersion > 10, implementacja urządzenia:

  • NALEŻY wyświetlić przycisk menu akcji na pasku akcji, gdy jest on widoczny, a wynikające z tego menu akcji nie jest puste. W przypadku implementacji na urządzeniu wydanym przed Androidem 4.4, ale aktualizowanym do Androida 6.0, 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.

Implementacje na urządzeniach z Androidem, które obsługują działanie Asystenta [Zasoby, 30], MUSZĄ umożliwiać dostęp do tego elementu za pomocą pojedynczego działania (np.kliknięcia, podwójnego kliknięcia lub gestu), gdy widoczne są inne klawisze nawigacyjne. BARDZO ZALECAMY używanie przycisku ekranu głównego lub klawisza oprogramowania jako pojedynczego działania.

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, 85] 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, 86], 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ć absolutne pozycje X i Y wskaźnika na ekranie oraz wyświetlać wizualny wskaźnik na ekranie [Resources, 87].
  • NALEŻY zgłaszać zdarzenie dotyku z kodem działania, który określa stan, gdy wskaźnik porusza się w dół lub w górę na ekranie [Resources, 87].
  • 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ć w tym samym miejscu na ekranie w ramach określonego progu czasowego wciśnięcie i odblokowanie wskaźnika, a następnie ponowne wciśnięcie i odblokowanie wskaźnika, co pozwala użytkownikom emulować dwukrotne kliknięcie obiektu na ekranie [Resources, 87].
  • 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)
Przycisk w górę na padzie kierunkowym1
Przycisk w dół na padzie kierunkowym1		 0x01 0x00393 AXIS_HAT_Y4
Przycisk w lewo na padzie kierunkowym1
Przycisk w prawo na padzie kierunkowym1		 0x01 0x00393 AXIS_HAT_X4
Przycisk 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 [Materiały, 88]

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, 87]

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 [Zasoby, 87]

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łać KEYCODE_SEARCH (lub KEYCODE_ASSIST, jeśli urządzenie obsługuje asystenta), gdy użytkownik wywoła wyszukiwanie głosowe na pilocie zdalnym 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, 88].

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 na urządzeniu MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK i dokumentacji Androida Open Source na temat czujników [Zasoby, 89]. Na przykład implementacje na urządzeniach:

  • MUSI dokładnie raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager [Resources, 70].
  • 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 z Międzynarodowego Systemu Jednostek (SI) dla każdego typu czujnika zgodnie z dokumentacją Android SDK [Resources, 90].
  • 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(). Właścicielom istniejących i nowych urządzeń z Androidem MOCNO POLECAMY spełnienie tych wymagań, aby mogli oni korzystać z przyszłych wersji platformy, w których mogą one stać się wymaganym elementem. Błąd synchronizacji powinien być mniejszy niż 100 milisekund [Resources, 91].
  • Musi przekazywać dane z czujnika z maksymalnym opóźnieniem 100 ms + 2 * sample_time w przypadku przesyłanego strumieniowo czujnika z minimalnym wymaganym opóźnieniem 5 ms + 2 * sample_time, gdy aktywny jest procesor aplikacji. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.
  • Pierwsza próbka czujnika MUSI zostać zgłoszona w ciągu 400 milisekund + 2 * sample_time od momentu aktywacji czujnika. W przypadku tej próbki dopuszczalna jest dokładność 0.

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

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 wykorzystywać te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w [Zasobach, 92]. Jeśli implementacja urządzenia zawiera czujnik złożony, MUSI ona być zgodna z opisem w dokumentacji Androida dotyczącej czujników złożonych [Zasoby, 92].

Niektóre czujniki Androida obsługują tryb „ciągły”, który stale zwraca dane [Resources, 93]. 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. W przypadku urządzeń przenośnych z Androidem i zegarków z Androidem MOCNO ZALECAMY uwzględnienie tego czujnika. Jeśli implementacja urządzenia zawiera 3-osiowy akcelerometr, to:

  • NALEŻY zaimplementować czujnik TYPE_ACCELEROMETER i zgłosić go [Resources, 94].
  • 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, 90].
  • 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 12 bitów, a najlepiej 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. W przypadku obecnych i nowych urządzeń z Androidem 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. Zalecamy implementację czujnika TYPE_GAME_ROTATION_VECTOR na istniejących i nowych urządzeniach z Androidem.
  • Jeśli w urządzeniu jest też czujnik żyroskopu i czujnik magnetometru, MUSISZ zaimplementować czujnik złożony TYPE_ROTATION_VECTOR.

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. W przypadku obecnych i nowych urządzeń z Androidem MOCNO zalecamy wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • 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, 90].
  • 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. W przypadku obecnych i nowych urządzeń z Androidem MOCNO zalecamy implementację czujnika 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 czujnik przyspieszeniomierza i czujnik magnetometru są również uwzględnione.
  • 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. Zalecamy implementację 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.3.9. Czujniki o wysokiej wierności

Implementacje urządzeń obsługujące zestaw czujników o wyższej jakości, które mogą spełniać wszystkie wymagania wymienione w tej sekcji, MUSZĄ wskazywać obsługę za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Urządzenie deklarujące android.hardware.sensor.hifi_sensors MUSI obsługiwać wszystkie te typy czujników, które spełniają wymagania jakościowe podane poniżej:

  • SENSOR_TYPE_ACCELEROMETER
    • Zakres pomiarowy musi wynosić co najmniej -8 g do +8 g
    • Rozdzielczość pomiaru MUSI wynosić co najmniej 1024 LSB/G.
    • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
    • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 200 Hz
    • Szum pomiarowy nie może przekraczać 400 uG/√Hz
    • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 3000 zdarzeń czujnika
    • Musisz mieć ustawienie batchingu z zużyciem energii nie większym niż 3 mW
  • SENSOR_TYPE_GYROSCOPE
    • Zakres pomiarowy musi wynosić co najmniej -1000 do +1000 dps
    • Rozdzielczość pomiaru MUSI wynosić co najmniej 16 LSB/dps
    • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
    • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 200 Hz
    • Szum pomiarowy nie może przekraczać 0,014°/s/√Hz
  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED z takimi samymi wymaganiami jakości jak SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • Zakres pomiarowy musi wynosić co najmniej -900 do +900 uT
    • ROZDZIAŁKA: rozdzielczość pomiaru musi wynosić co najmniej 5 LSB/uT
    • Częstotliwość pomiarów musi wynosić co najmniej 5 Hz.
    • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 50 Hz
    • Szum pomiarowy nie może być większy niż 0,5 uT
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co SENSOR_TYPE_GEOMAGNETIC_FIELD, a dodatkowo:
    • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 600 zdarzeń czujnika
  • SENSOR_TYPE_PRESSURE
    • Zakres pomiarowy musi wynosić co najmniej 300–1100 hPa.
    • Rozdzielczość pomiaru musi wynosić co najmniej 80 LSB/hPa
    • Częstotliwość pomiarów MUSI wynosić co najmniej 1 Hz.
    • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 10 Hz.
    • NAPISY musi mieć poziom szumu pomiarowego nieprzekraczający 2 Pa/√Hz
    • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika
    • Musisz mieć zużycie energii podczas grupowania nie większe niż 2 mW
  • TYPE_GAME_ROTATION_VECTOR
    • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
    • Musi mieć zużycie energii na etapie grupowania nie większe niż 4 mW.
  • SENSOR_TYPE_SIGNIFICANT_MOTION
    • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
  • SENSOR_TYPE_STEP_DETECTOR
    • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 100 zdarzeń czujnika
    • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
    • Musisz mieć użycie energii na potrzeby grupowania nie większe niż 4 mW
  • SENSOR_TYPE_STEP_COUNTER
    • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
  • SENSOR_TILT_DETECTOR
    • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.

Takie urządzenie musi też spełniać te wymagania dotyczące podsystemu czujników:

  • Sygnatury czasowe tego samego zdarzenia fizycznego zarejestrowanego przez czujnik przyspieszeniomierza, żyroskopu i magnetometru MUSZĄ być oddalone od siebie o nie więcej niż 2,5 milisekundy.
  • Sygnatury czasowe zdarzeń czujnika żyroskopu MUSZĄ być oparte na tej samej podstawie czasowej co podsystem kamery i mieć błąd nieprzekraczający 1 ms.
  • Opóźnienie przesyłania próbek do HAL DOPUSZCZLIWE jest mniejsze niż 5 milisekund od momentu, gdy dane są dostępne na fizycznym sprzęcie czujnika.
  • Zużycie energii NIE MOŻE być wyższe niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie jest w ruchu, przy włączonej dowolnej kombinacji tych czujników:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona moc pobieraną przez cały łańcuch czujników – czujnik, wszelkie obwody pomocnicze, dowolny dedykowany system przetwarzania czujników itp.

Implementacja urządzenia deklarująca interfejs android.hardware.sensor.hifi_sensors MOŻE obsługiwać te typy czujników, ale jeśli są one obecne, MUSZĄ spełniać te minimalne wymagania dotyczące możliwości buforowania:

  • SENSOR_TYPE_PROXIMITY: 100 zdarzeń czujnika

7.3.10. Czytnik linii papilarnych

Urządzenia z bezpieczną blokadą ekranu POWINNY zawierać czytnik linii papilarnych. Jeśli implementacja urządzenia zawiera czytnik linii papilarnych i odpowiednią usługę API dla deweloperów zewnętrznych, musi:

  • MUSI deklarować obsługę funkcji android.hardware.fingerprint.
  • NALEŻY w pełni wdrożyć odpowiedni interfejs API zgodnie z opisem w dokumentacji Android SDK [Materiały, 95].
  • Wskaźnik fałszywych akceptacji NIE MOŻE być wyższy niż 0,002%.
  • MOCNO ZALECAMY, aby odsetek błędów odrzucenia na podstawie pomiarów na urządzeniu był mniejszy niż 10%.
  • W przypadku jednego zarejestrowanego palca zalecamy, aby opóźnienie było krótsze niż 1 s (mierzone od momentu dotknięcia czujnika linii papilarnych do momentu odblokowania ekranu).
  • W przypadku weryfikacji odcisku palca po 5 nieudanych próbach należy ZAWSZE ograniczyć czas oczekiwania na próbę do co najmniej 30 sekund.
  • Musisz mieć implementację magazynu kluczy opartą na sprzęcie i wykonywać dopasowywanie odcisków palców w zaufanym środowisku wykonawczym (TEE) lub na chipie z bezpiecznym kanałem do TEE.
  • Wszystkie dane odcisku palca muszą być zaszyfrowane i uwierzytelnione kryptograficznie, aby nie mogły być pobierane, odczytywane ani zmieniane poza zaufanym środowiskiem wykonawczym (TEE), zgodnie z instrukcjami implementacji na stronie projektu Android Open Source [Resources, 96].
  • Musisz uniemożliwić dodanie odcisku palca bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejących danych logowania urządzenia (kodu PIN, wzoru lub hasła) lub dodanie nowych, które są chronione przez TEE. W ramach implementacji projektu Android Open Source udostępniono mechanizm umożliwiający wykonanie tej czynności.
  • NIE WOLNO zezwalać aplikacjom innych firm na rozróżnianie poszczególnych odcisków palców.
  • MUSI honorować flagę DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • W przypadku uaktualnienia z wersji starszej niż Android 6.0 należy bezpiecznie przenieść dane odcisków palców, aby spełniały powyższe wymagania, lub je usunąć.
  • NALEŻY użyć ikony odcisku palca Androida udostępnionej w projekcie Android Open Source.

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 [Resources, 97].
  • 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:
    • nawet wtedy, gdy ekran nie jest aktywny.
    • W przypadku implementacji urządzeń z Androidem TV nawet w stanie gotowości.

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 zaimplementować odpowiedni interfejs API Androida zgodnie z dokumentacją pakietu SDK [Zasoby, 98]. 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), a inne typy implementacji urządzeń z Androidem POWINNY obejmować obsługę TDLS, zgodnie z opisem w dokumentacji pakietu Android SDK [Resources, 99]. 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, 100]. 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ólnych atrybutów) zgodnie z opisem w dokumentacji pakietu SDK i [Zasoby, 100].
  • ZALECAMY stosowanie nieprzekraczalnego czasu oczekiwania na rozwiązanie adresu prywatnego (RPA) wynoszącego nie więcej niż 15 minut oraz rotowanie adresu po upływie tego czasu, aby chronić prywatność użytkowników.
  • NALEŻY obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas implementowania interfejsu API ScanFilter [Zasoby, 101] i MUSI zwracać 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, 70].
  • 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 X 6319-4)
      • IsoDep (ISO 14443-4)
      • Typy tagów NFC Forum 1, 2, 3 i 4 (zdefiniowane przez NFC Forum)
    • ZDECYDOWANIE POLECAMY, aby aplikacja była w stanie odczytywać i zapisywać wiadomości NDEF, a także dane w postaci surowej za pomocą tych standardów NFC. Pamiętaj, że chociaż poniższe standardy NFC są opisane jako „MOCNO ZALECANE”, w przyszłej wersji definicji zgodności planujemy zmienić je na „WYMAGANE”. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
      • NfcV (ISO 15693)
    • Urządzenie MUSI umieć odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodem kreskowym Thinfilm NFC [Resources, 102].
    • MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:
      • ISO 18092
      • LLCP 1.2 (zdefiniowany przez NFC Forum)
      • SDP 1.0 (zdefiniowana przez NFC Forum)
      • Protokół NDEF Push [Zasoby, 103]
      • SNEP 1.0 (zdefiniowany przez NFC Forum)
    • MUSI zawierać obsługę Android Beam [Materiały, 104]:
      • 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ć działanie android.settings.NFCSHARING_SETTINGS, aby wyświetlać ustawienia udostępniania NFC [Resources, 105].
      • 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, 106] i „Bluetooth Secure Simple Pairing Using NFC version 1.0” [Resources, 107] 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 Androida [Resources, 108].

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, 70]. Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie pojawia się jako stała w klasie android.content.pm.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, 70] i MUSI zaimplementować interfejs NFC 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.

Urządzenia MUSZĄ zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, a także natywnych interfejsów API, takich jak gniazda AF_INET6. Wymagany poziom obsługi IPv6 zależy od typu sieci:

  • Urządzenia obsługujące sieci Wi-Fi MUSZĄ obsługiwać skrót podwójny i IPv6 w sieci Wi-Fi.
  • Urządzenia obsługujące sieci Ethernet MUSZĄ obsługiwać działanie w ramach podwójnego stosu w sieci Ethernet.
  • Urządzenia, które obsługują dane komórkowe, POWINNY obsługiwać IPv6 (tylko IPv6 lub ewentualnie stos podwójny) w przypadku danych komórkowych.
  • Gdy urządzenie jest jednocześnie połączone z kilkoma sieciami (np. Wi-Fi i komórkowej transmisji danych), MUSI jednocześnie spełniać te wymagania w każdej sieci, z którą jest połączone.

IPv6 MUSI być domyślnie włączony.

Aby zapewnić taką samą niezawodność komunikacji IPv6 jak w IPv4, pakiety unicast IPv6 wysyłane na urządzenie NIE MOGĄ być odrzucane, nawet gdy ekran nie jest aktywny. Zbędne pakiety IPv6 w ramach transmisji wielodostępnej, takie jak powtarzające się identyczne reklamacje routera, MOGĄ być ograniczane pod względem szybkości w sprzęcie lub oprogramowaniu układowym, jeśli jest to konieczne ze względu na oszczędność energii. W takich przypadkach ograniczenie szybkości NIE MOŻE spowodować utraty połączenia IPv6 na żadnej sieci zgodnej z IPv6, która używa okresów ważności RA wynoszący co najmniej 180 sekund.

W trybie Doze musisz zachować połączenie IPv6.

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ść „true” [Resources, 109].

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, 110], 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, 111], 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: wdrożenia urządzeń, które obsługują techniki obrazowania z użyciem szerokiego zakresu dynamicznego (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR [Resources, 112].

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, 113] i zgłaszać odpowiednie flagi funkcji frameworka [Resources, 114].

Implementacje urządzeń MUSZĄ też deklarować indywidualne funkcje kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i deklarować odpowiednie flagi funkcji [Zasoby, 114]; urządzenie musi zdefiniować flagę funkcji, jeśli którakolwiek 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ń. W przypadku implementacji urządzeń z Androidem ZALECAMY, aby na potrzeby prywatnych danych aplikacji było dostępne co najmniej 3 GB pamięci nieulotnej. Dzięki temu będzie można uaktualnić urządzenie do przyszłych wersji platformy.

Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych [Zasoby, 115]. 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ółdzielonego miejsca na dane (np. gniazdo karty SD i wspólne miejsce na dane wewnętrzne) MUSZĄ zezwalać tylko wstępnie zainstalowanym i uprzywilejowanym aplikacjom na Androida z uprawnieniem WRITE_EXTERNAL_STORAGE na zapisywanie danych w zewnętrznym miejscu na dane, z wyjątkiem sytuacji, gdy zapisywanie odbywa się w katalogach dotyczących pakietu lub w ramach URI zwróconego przez wywołanie intencji 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 skanowania 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 Androida, czyli aplikacją Android File Transfer [Resources, 116].
  • NALEŻY podać klasę urządzenia USB 0x00.
  • Powinien zwracać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

W przypadku urządzeń, w których port urządzenia z wymiennym nośnikiem jest w długotrwałej stabilnej lokalizacji, np. w komorze baterii lub innej osłonie ochronnej [Zasoby, 117], MOCNO zaleca się stosowanie adoptowalnego miejsca na dane.

Implementacje urządzeń, takich jak telewizory, MOGĄ umożliwiać stosowanie portów USB, ponieważ urządzenie ma być nieruchome, a nie mobilne. W przypadku innych implementacji urządzeń mobilnych MOCNO POLECAMY stosowanie przenośnego miejsca na dane w stabilnej lokalizacji, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

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, 118].
    • MUSI obsługiwać nawiązywanie komunikacji z użyciem protokołu AOA podczas pierwszego połączenia z hostem USB, który działa jako urządzenie dodatkowe, bez konieczności zmiany domyślnego trybu USB.
    • NALEŻY zaimplementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK [Resources, 119].
    • Klasa pamięci masowej USB MUSI zawierać ciąg tekstowy „android” na końcu opisu interfejsu iInterface klasy pamięci masowej USB.
  • NALEŻY wdrożyć obsługę poboru prądu 1, 5 A podczas przesyłania danych i treningu HS zgodnie z specyfikacją ładowania akumulatora USB w wersji 1.2 [Zasoby, 120]. 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.
    • standard rezystorów typu C.
  • 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.
  • MOCNO zalecamy implementację klasy USB audio zgodnie z dokumentacją pakietu Android SDK [Resources, 119].
  • 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, 121].
  • POWINNA obsługiwać ładowanie urządzenia w trybie hosta; reklamować prąd źródła co najmniej 1,5 A zgodnie z sekcją Parametry zakończenia specyfikacji kabla i złącza USB typu C, wersja 1.2 [] w przypadku złączy USB typu C lub używać zakresu prądu wyjściowego portu downstream(CDP) zgodnie ze specyfikacją ładowania baterii USB, wersja 1.2 [Resources, 120] w przypadku złączy Micro-AB.

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
  • ZALECAMY obsługę nagrywania w zakresie ultradźwięków zgodnie z opisem w sekcji 7.8.3.

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.
  • ZDECYDOWANIE POLECAMY obsługę odtwarzania zbliżonego do ultradźwięków zgodnie z opisem w sekcji 7.8.3

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 zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z gniazda słuchawek 3,5 mm w ekosystemie Androida [Resources, 122], jeśli implementacja urządzenia zawiera co najmniej 1 port analogowy, co najmniej 1 z tych portów(złącze audio) powinien mieć 4 żyły i gniazdo 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.

7.8.3. Zbliżenie ultradźwiękowe

Dźwięk w zakresie ultradźwięku to pasmo 18,5–20 kHz. Implementacje urządzeń MUSZĄ prawidłowo zgłaszać obsługę funkcji dźwięku w zakresie ultradźwięków za pomocą interfejsu AudioManager.getProperty API w ten sposób:

  • Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND to „true”, to
    • Średnia moc wyjściowa mikrofonu w zakresie 18,5–20 kHz MUSI być mniejsza niż 15 dB poniżej wartości w zakresie 2 kHz.
    • Stosunek sygnału do szumu (SNR) mikrofonu w zakresie 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI wynosić co najmniej 50 dB.
  • Jeśli parametr PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”, średnia odpowiedź głośnika w zakresie 18,5–20 kHz MUSI być niższa o co najmniej 40 dB od odpowiedzi w zakresie 2 kHz.

8. Wydajność i moc

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

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

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

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

8.3. Tryby oszczędzania energii

Wszystkie aplikacje wyłączone z trybu wstrzymania aplikacji lub Doze MUSZĄ być widoczne dla użytkownika. Ponadto uruchamianie, konserwacja, algorytmy wybudzania i użycie globalnych ustawień systemu tych trybów oszczędzania energii NIE mogą odbiegać od projektu Android Open Source.

8.4. Rachunkowość zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii przez aplikację. Dlatego implementacje na urządzeniach:

  • Musi być możliwe śledzenie zużycia energii przez komponent sprzętowy i przypisywanie tego zużycia do konkretnych aplikacji. W szczególności:
    • MUSI zawierać profil poboru mocy dla poszczególnych komponentów, który definiuje bieżącą wartość poboru mocy dla każdego komponentu sprzętowego oraz przybliżony pobór mocy z baterii powodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source [Resources, 123].
    • Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
    • NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
    • MUSI zgłaszać zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
  • Musisz udostępnić deweloperowi aplikacji możliwość korzystania z tych opcji za pomocą polecenia adb shell dumpsys batterystats w powłoce [Resources, 124].
  • MUSI obsługiwać działanie android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień pokazujące zużycie energii [Resources, 125].

9. Zgodność modelu zabezpieczeń

Implementacje urządzeń MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji API [Zasoby, 126] 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, 126]. 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.*.

Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania. Aplikacje z wartością targetSdkVersion > 22 wysyłają je w czasie działania. Implementacje na urządzeniu:

  • MUSI wyświetlać specjalny interfejs, aby użytkownik mógł zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs, za pomocą którego użytkownik może zarządzać uprawnieniami w czasie działania.
  • Musisz mieć jedną i tylko jedną implementację obu interfejsów użytkownika.
  • NIE MOŻESZ przyznawać żadnych uprawnień na czas działania aplikacjiom wstępnie zainstalowanym, chyba że:
    • zgoda użytkownika może zostać uzyskana przed użyciem danych przez aplikację;
    • uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego wstępnie zainstalowana aplikacja jest ustawiona jako domyślny moduł obsługi;

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

9.3. Uprawnienia do systemu plików

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień dostępu do plików Androida zgodnie z opisem w dokumentacji poświęconej zabezpieczeniom i uprawnieniom [Zasoby, 126].

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, 127]. Implementacje urządzeń MOGĄ umożliwiać korzystanie z urządzenia przez wielu użytkowników, ale muszą spełniać te wymagania dotyczące obsługi wielu użytkowników [Resources, 128]:

  • 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, jak określono w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia w interfejsach API [Resources, 126].
  • Każdy użytkownik na urządzeniu z Androidem MUSI mieć osobne i odizolowane katalogi pamięci zewnętrznej. Implementacje urządzeń MOGĄ przechowywać dane wielu użytkowników na tym samym woluminie lub w tym samym systemie plików. Implementacja urządzenia MUSI jednak zapewnić, aby aplikacje należące do danego użytkownika i działające w jego imieniu nie mogły odczytywać ani zapisywać danych należących do innego użytkownika. Pamiętaj, że wymienne nośniki, takie jak gniazda kart SD, mogą umożliwiać jednemu użytkownikowi dostęp do danych innego użytkownika za pomocą komputera hosta. Z tego powodu implementacje urządzeń, które korzystają z wymiennych nośników danych dla interfejsów API podstawowego zewnętrznego miejsca na dane, MUSZĄ szyfrować zawartość karty SD, jeśli włączono obsługę wielu użytkowników, za pomocą klucza przechowywanego tylko na niewymiennym nośniku danych, do którego dostęp ma tylko system. Ponieważ w takim przypadku 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 implementacje urządzeń MOGĄ, ALE NIE POWINNY umożliwiać korzystania z wielu użytkowników, jeśli używają wymiennych nośników danych [Resources, 129] 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 [Resources, 130]. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za które użytkownik może zostać obciążony opłatą. Implementacje urządzeń, które deklarują obsługę interfejsu android.hardware.telephony, MUSZĄ ostrzegać użytkowników przed wysłaniem SMS-a do numerów zidentyfikowanych za pomocą wyrażeń regularnych zdefiniowanych w pliku /data/misc/sms/codes.xml na urządzeniu. Górny projekt Android Open Source udostępnia implementację, która spełnia ten wymóg.

9,7. Funkcje zabezpieczeń jądra

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

  • MUSI być zgodna z dotychczasowymi aplikacjami.
  • Nie może 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, jeśli używają jądra innego niż Linux, równoważny system obowiązkowego kontroli dostępu. Urządzenia MUSZĄ też spełniać te wymagania, które są spełnione przez implementację referencyjną w górnym projekcie Android Open Source.

Implementacje na urządzeniu:

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

Implementacje urządzeń powinny zachować domyślne zasady SELinux udostępnione w folderze external/sepolicy projektu Android Open Source, a następnie dodać do tych zasad własne ustawienia. Implementacje na urządzeniu 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ę.

Jeśli implementacja urządzenia ma port USB z obsługą trybu urządzeń peryferyjnych, MUSI wyświetlić interfejs z prośbą o zgodę użytkownika przed przyznaniem dostępu do zawartości współdzielonego magazynu danych przez port USB.

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 bezpieczny ekran blokady, który zwraca wartość „true” w przypadku metody KeyguardManager.isDeviceSecure() [Resources, 131], a urządzenie nie jest urządzeniem o ograniczonej pamięci, o czym informuje metoda ActivityManager.isLowRamDevice() [Resources, 132], to urządzenie MUSI obsługiwać szyfrowanie całego dysku [Resources, 132] danych prywatnych aplikacji (partycja /data), a także partycji współdzielonej pamięci aplikacji (partycja /sdcard), jeśli jest to stały, nieusuwalny element urządzenia.

W przypadku implementacji urządzeń obsługujących szyfrowanie całego dysku i mających wydajność szyfrowania Advanced Encryption Standard (AES) powyżej 50 MiB/s szyfrowanie całego dysku MUSI być domyślnie włączone po zakończeniu konfiguracji urządzenia. Jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida z zaszyfrowaniem całego dysku wyłączonym domyślnie, takie urządzenie nie może spełniać wymagań poprzez aktualizację oprogramowania systemowego i MOŻE być wyłączone z obowiązku.

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). Wschodzący projekt 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 niezmiennego 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).

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-verity w jądrze Linuksa.

Począwszy od Androida 6.0 implementacje urządzeń z wydajnością szyfrowania Advanced Encryption Standard (AES) powyżej 50 MiB/sekund MUSZĄ obsługiwać szyfrowanie zweryfikowane w celu zapewnienia integralności urządzenia. Jeśli implementacja urządzenia została już uruchomiona bez obsługi weryfikowanego uruchamiania w starszej wersji Androida, takie urządzenie nie może dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego i jest zatem zwolnione z tego wymogu.

9.11. Klucze i dane logowania

System Keystore Androida [Resources, 133] pozwala deweloperom aplikacji przechowywać klucze kryptograficzne w kontenerze i wykorzystywać je w operacjach kryptograficznych za pomocą interfejsu KeyChain API [Resources, 134] lub interfejsu Keystore API [Resources, 135].

Wszystkie implementacje urządzeń z Androidem MUSZĄ spełniać te wymagania:

  • NIE należy ograniczać liczby generowanych kluczy. NALEŻY umożliwić zaimportowanie co najmniej 8192 kluczy.
  • Uwierzytelnianie na ekranie blokady MUSI ograniczać liczbę prób i powinno używać algorytmu zwalniania w zależności od liczby prób, który jest implementowany w ramach projektu Android Open Source.
  • Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady i ma bezpieczny sprzęt, na przykład element zabezpieczeń, na którym można zaimplementować zaufane środowisko wykonawcze (TEE), to:
    • Zdecydowanie zalecamy utworzenie kopii zapasowej implementacji magazynu kluczy na bezpiecznym sprzęcie. Projekt źródłowy Android Open Source udostępnia implementację Keymaster Hardware Abstraction Layer (HAL), która może być używana do spełnienia tego wymagania.
    • NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady na zabezpieczonym sprzęcie, jeśli urządzenie ma implementację magazynu kluczy z użyciem sprzętu, i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętowej Gatekeeper (HAL), która może być używana do spełnienia tego wymagania [Resources, 136].

Pamiętaj, że chociaż powyższe wymagania dotyczące TEE są opisane jako „MOCNO ZALECANE”, w definicji zgodności planowanej na następną wersję interfejsu API zmienimy je na „WYMAGANE”. Jeśli urządzenie zostało już uruchomione w starszej wersji Androida i nie ma zaimplementowanego zaufanego systemu operacyjnego na bezpiecznym sprzęcie, może nie spełniać wymagań aktualizacji oprogramowania systemowego. Dlatego MOCNO POLECAMY zaimplementowanie TEE.

9.12. Usuwanie danych

Urządzenia MUSZĄ udostępniać użytkownikom mechanizm „przywracania danych do ustawień fabrycznych”, który umożliwia logiczne i fizyczne usunięcie wszystkich danych z wyjątkiem obrazu systemu oraz danych na innych partycjach, które można uznać za część obrazu systemu. Musi być zgodny z odpowiednimi branżowymi standardami usuwania danych, takimi jak NIST SP800-88. Musisz go używać do implementacji interfejsu wipeData() API (części interfejsu Android Device Administration API) opisanego w sekcji 3.9 Zarządzanie urządzeniami.

Urządzenia mogą oferować szybkie czyszczenie danych, które polega na logicznym wymazaniu danych.

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 ZALECAMY deweloperom urządzeń wprowadzanie jak najmniejszej liczby zmian w dostępnej w ramach Projektu Android Open Source referencyjnej i preferowanej implementacji Androida. 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 zgodności Android Compatibility Test Suite (CTS) [Resources, 137] dostępne w ramach projektu Android Open Source, przy użyciu oprogramowania do ostatecznej wersji urządzenia. 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 na potrzeby Androida 6.0 może być wydawanych wiele 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 w wersji 6.0 lub nowszej, 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.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolowanie instalacji aktualizacji systemu. Aby ułatwić to zadanie, podsystem aktualizacji systemu na urządzeniach, które raportują android.software.device_admin, MUSI implementować zachowanie opisane w klasie SystemUpdatePolicy [ Resources, 138].

12. Historia zmian dokumentu

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

Sekcja Podsumowanie zmian
Różne Wystąpienia słowa „encouraged” (zachęcany) zostały zastąpione słowem „RECOMMENDED” (zalecany).
2. Typy urządzeń Aktualizacja implementacji Androida Automotive
3.2.2. Parametry tworzenia Dodatki dotyczące numeru seryjnego sprzętu i poziomu poprawki zabezpieczeń kompilacji
3.2.3.2. Rozwiązywanie intencji Sekcja „Zastąpienia intencji” została przemianowana na „Rozwiązywanie konfliktów intencji” i zawiera nowe wymagania dotyczące autorytatywnego łączenia z domyślną aplikacją
3.3.1. Interfejsy binarne aplikacji Dodatki dotyczące obsługi ABI Androida; zmiana związana z nazwą biblioteki Vulkan
3.4.1. Zgodność WebView Zmiana ciągu znaków klienta użytkownika zgłaszanego przez WebView
3.7. Zgodność w czasie działania Zmiany w tabeli przydziału pamięci
3.8.4. Szukaj Aktualizacje dotyczące wymagań Asystenta
3.8.6. Motywy Dodano wymóg obsługi czarnych ikon systemowych, gdy jest to wymagane przez flagę SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
3.8.8. Przełączanie aktywności Zwolnienie z wymogu dotyczącego liczby tytułów w sekcji Omówienie.
3.8.10. Sterowanie multimediami na ekranie blokady Sterowanie multimediami na ekranie blokady: szczegółowe informacje znajdziesz w sekcji 3.8.3.
3.9.1. Obsługa administracyjna urządzenia Zawiera nowe sekcje dotyczące udostępniania właściciela urządzenia i profilu zarządzanego
3.9.2. Pomoc dotycząca profilu zarządzanego Nowa sekcja z wymaganiami dotyczącymi obsługi funkcji zarządzanego profilu na urządzeniach
3.12.1. Aplikacja TV Dodano sekcję wyjaśniającą wymagania dotyczące aplikacji na telewizory z Androidem.
3.12.1.1. Elektroniczny przewodnik po programach Dodano sekcję wyjaśniającą wymagania dotyczące EPG w przypadku urządzeń Android Television
3.12.1.2. Nawigacja Dodano sekcję, w której wyjaśniono wymagania dotyczące nawigacji w aplikacji TV na urządzeniach z Androidem TV
3.12.1.3. Łączenie aplikacji z wejściem TV Dodaliśmy sekcję, w której wyjaśniliśmy wymagania dotyczące obsługi łączenia aplikacji z wejściem telewizyjnym w przypadku urządzeń z Androidem TV.
5.1. Kodeki multimedialne Aktualizacje dotyczące obsługi podstawowych formatów multimediów i dekodowania.
5.1.3. Kodeki wideo Zmiany i uzupełnienia dotyczące Androida TV
5.2. Kodowanie wideo Zmiany dla koderów
5.3. Dekodowanie wideo zmiany dotyczące dekoderów, w tym obsługa dynamicznej rozdzielczości i liczby klatek oraz inne funkcje;
5.4. Nagrywanie dźwięku Dodatki związane z przechwytywaniem dźwięku
5.6. Opóźnienie dźwięku Aktualizacja dotycząca zgłaszania obsługi dźwięku o niskiej latencji
5.10. Profesjonalny dźwięk Ogólne zmiany dotyczące obsługi profesjonalnego dźwięku; zmiany specyfikacji urządzeń mobilnych (gniazda), trybu hosta audio USB i inne zmiany
5.9. MusicaI Instrument Digital Interface (MIDI) Dodano nową sekcję na temat opcjonalnego wsparcia dla interfejsu MIDI (Musical Instrument Digital Interface)
6.1. Narzędzia dla programistów Aktualizacja sterowników obsługujących system Windows 10
7.1.1.3. Gęstość ekranu Aktualizacje dotyczące gęstości ekranu, np. związane z zegarkiem z Androidem
7.2.3. Klawisze nawigacyjne Zaktualizowano wymagania dotyczące implementacji urządzeń, które obejmują działanie Asystenta
7.3. Czujniki (i pododdziały) Nowe wymagania dotyczące niektórych typów czujników
7.3.9. Czujniki o wysokiej wierności Nowa sekcja z wymaganiami dotyczącymi urządzeń obsługujących czujniki o wysokiej jakości
7.3.10. Czytnik linii papilarnych Nowa sekcja dotycząca wymagań związanych z czytnikami linii papilarnych
7.4.2. IEEE 802.11 (Wi-Fi) Aktualizacje dotyczące obsługi multicast DNS (mDNS)
7.4.3. Bluetooth Dodatek dotyczący rozwiązywalnego adresu prywatnego (RPA) dla Bluetooth Low Energy (BLE)
7.4.4. Komunikacja Near Field Communication Dodatek do wymagań dotyczących komunikacji Near Field Communication (NFC)
7.4.5. Minimalna funkcjonalność sieci Dodano wymagania dotyczące obsługi IPv6
7.6.3. Pamięć dostosowywana Nowa sekcja dotycząca implementacji pamięci dostosowywanej
7.7. USB Wymagania dotyczące implementacji specyfikacji AOA
7.8.3. Zbliżenie ultradźwiękowe Dodatki związane z półprzewodnikowymi funkcjami nagrywania, odtwarzania i dźwięku Zmniejszenie wymagań dotyczących stosunku sygnału do szumu mikrofonu w przypadku mikrofonu ultradźwiękowego.
8.3. Tryby oszczędzania energii Nowa sekcja z wymaganiami dotyczącymi trybów Czuwanie aplikacji i Uśpienie
8.4. Rachunkowość zużycia energii Nowa sekcja z wymaganiami dotyczącymi śledzenia zużycia energii przez komponenty sprzętowe i przypisywania tego zużycia do konkretnych aplikacji
9.1. Uprawnienia Dodatek do wymagań dotyczących uprawnień
9,7. Funkcje zabezpieczeń jądra Aktualizacje SE Linux
9,8. Prywatność Uwaga dotycząca zgody użytkownika na dostęp do współdzielonego miejsca na dane przez port USB
9.9. Szyfrowanie całego dysku Wymagania dotyczące pełnego szyfrowania dysku
9.10. Weryfikacja podczas uruchamiania Dodatkowy wymóg dotyczący zweryfikowanego uruchamiania
9.11. Klucze i dane logowania Nowa sekcja wymagań związanych z kluczami i danymi logowania
9.12. Usuwanie danych Nowa sekcja „Przywracanie danych fabrycznych”
11. Oprogramowanie z możliwością aktualizacji Wymagania dotyczące zasad aktualizacji systemu ustawionych przez właściciela urządzenia

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem [Zasoby, 139] i poprosić o wyjaśnienia lub zgłosić problemy, które nie zostały omówione 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. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

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

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

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

9. Dozwolone ciągi znaków wersji Androida 6.0: http://source.android.com/docs/compatibility/6.0/versions.html

10. Ustawienia dewelopera Androida: http://developer.android.com/reference/android/provider/Settings.html

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

12. Zarządzanie ABI w Android NDK: https://developer.android.com/ndk/guides/abis.html

13. Zaawansowana architektura SIMD: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

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

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

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

17. HTML5: http://html.spec.whatwg.org/multipage/

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

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

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

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

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

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

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

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

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

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

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

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

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

31. Interfejsy Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

47. Proces obsługi inicjalizacji właściciela urządzenia z Androidem: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Prowadzenie obsługi administracyjnej przez właściciela urządzenia za pomocą NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Aplikacja właściciela profilu na Androida:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Proces provisionowania profilu zarządzanego na Androidzie: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

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

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

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

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

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

56. Kanały aplikacji TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. Wejścia telewizyjne innych firm: /devices/tv/index.html#third-party_input_example

58. Wejścia TV: /devices/tv/index.html#tv_inputs

59. Pola EPG kanału telewizyjnego: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Linkowanie aplikacji do wejścia na telewizorze: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

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

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

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

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

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

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

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

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

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

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

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

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

73. Dumpsys: /devices/input/diagnostics.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

92. Czujniki złożone w ramach projektu Android Open Source: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Tryb ciągłego wyzwalania: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Interfejs API odcisków palców na Androidzie: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. Interfejs HAL odcisku palca Androida: /devices/tech/security/authentication/fingerprint-hal.html

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

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

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

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

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

102. Kod kreskowy NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

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

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

105. Ustawienia udostępniania NFC na Androidzie: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

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

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

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

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

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

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

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

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

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

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

117. Pamięć dostosowywana: http://source.android.com/docs/core/storage/adoptable

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

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

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

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

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

123. Komponenty profilu zasilania: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Podsumowanie zużycia energii: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

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

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

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

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

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

131. Raportowanie zabezpieczeń ekranu blokady: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Szyfrowanie na Androidzie o otwartym kodzie źródłowym: http://source.android.com/docs/security/features/encryption

133. System kluczy Androida: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: http://source.android.com/docs/security/features/authentication/gatekeeper

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

138. Klasa SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

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

140. Obsługa linków aplikacji: https://developer.android.com/training/app-links/index.html

141. Google Digital Asset Links: https://developers.google.com/digital-asset-links

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.